(Anti-)Programmierwettbewerb
-
Gut aufgepasst.
pyhax schrieb:
g++ (GCC) 4.7.1 20120721 (prerelease)
Oh, hatte versehentlich mit 4.6.3 getestet.
pyhax schrieb:
clang version 3.2 (trunk)
gut zu wissen. Diese Version ist allerdings noch nicht freigegeben.
clang++ ./test.cpp -otest -std=c++11 -v clang version 3.1 (branches/release_31) Target: x86_64-pc-linux-gnu Thread model: posix "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/x86_64-pc-linux-gnu -internal-isystem /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.1/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /home/matthias -ferror-limit 19 -fmessage-length 158 -mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/test-9u4o7q.o -x c++ ./test.cpp clang -cc1 version 3.1 based upon LLVM 3.1 default target x86_64-pc-linux-gnu ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/backward /usr/bin/../lib/clang/3.1/include /usr/include End of search list. clang: error: unable to execute command: Segmentation fault clang: error: clang frontend command failed due to signal (use -v to see invocation) clang: note: diagnostic msg: Please submit a bug report to http://llvm.org/bugs/ and include command line arguments and all diagnostic information. clang: note: diagnostic msg: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/test-nNEpCD.ii clang: note: diagnostic msg: /tmp/test-nNEpCD.sh
-
template<int ...i> void foo() { foo<i..., i..., i..., i..., i...>(); } int main() { foo<0>(); }schnief. Wie waers damit?

Edit: Camper, was ist eig. mit ROT13?
-
Sone schrieb:
template<int ...i> void foo() { foo<i..., i..., i..., i..., i...>(); } int main() { foo<0>(); }schnief. Wie waers damit?

Edit: Camper, was ist eig. mit ROT13?
Funktioniert mit GCC 4.7.1:
virtual memory exhausted: Nicht genügend Hauptspeicher verfügbarClang (3.2)
clang version 3.2 (trunk) Target: i386-pc-linux-gnu Thread model: posix "/usr/bin/clang-3.2" -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1 -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/i686-pc-linux-gnu -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 161 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/main-IL06Bv.o -x c++ main.cpp clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1 /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/i686-pc-linux-gnu /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward /usr/local/include /usr/bin/../lib/clang/3.2/include /usr/include End of search list. Stack dump: 0. Program arguments: /usr/bin/clang-3.2 -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases -fuse-init-array -target-cpu pentium4 -momit-leaf-frame-pointer -v -resource-dir /usr/bin/../lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1 -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/i686-pc-linux-gnu -internal-isystem /usr/lib/gcc/i686-pc-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 161 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/main-IL06Bv.o -x c++ main.cpp 1. <eof> parser at end of file 2. main.cpp:2:6: instantiating function definition 'foo' 3. main.cpp:2:6: instantiating function definition 'foo' 4. main.cpp:2:6: instantiating function definition 'foo' 5. main.cpp:2:6: instantiating function definition 'foo' 6. main.cpp:2:6: instantiating function definition 'foo' 7. main.cpp:2:6: instantiating function definition 'foo' 8. main.cpp:2:6: instantiating function definition 'foo' 9. main.cpp:2:6: instantiating function definition 'foo' 10. main.cpp:2:6: instantiating function definition 'foo' 11. main.cpp:2:6: instantiating function definition 'foo' clang-3: error: unable to execute command: Segmentation fault clang-3: error: clang frontend command failed due to signal (use -v to see invocation) clang version 3.2 (trunk) Target: i386-pc-linux-gnu Thread model: posix clang-3: note: diagnostic msg: PLEASE submit a bug report to and include the crash backtrace, preprocessed source, and associated run script. clang-3: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-3: note: diagnostic msg: /tmp/main-jJJ2qI.cpp clang-3: note: diagnostic msg: /tmp/main-jJJ2qI.sh clang-3: note: diagnostic msg: ********************
-
Sone schrieb:
template<int ...i> void foo() { foo<i..., i..., i..., i..., i...>(); } int main() { foo<0>(); }schnief. Wie waers damit?

Edit: Camper, was ist eig. mit ROT13?
Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.
-
Encypruon schrieb:
Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.
Da arbeitet jemand ohne ulimit :p
-
Encypruon schrieb:
Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.
Da musste ich an das hier denken.
Hätte es nicht gereicht, zu einem anderen TTY zu wechseln?
-
Encypruon schrieb:
Das Ding ist schlichtweg teuflisch. Bei mir (unter Ubuntu (Linux) 11.10) hat der Compiler (gcc) in ein paar sek. 4,9GiB Ram belegt, was die komplette grafische Oberfläche zum erliegen brachte. Um den PC wieder ins Leben zu rufen, musste ich mit meinem Handy per SSH den Compiler killen.
höhö^^ *g*
-
Wie weit vorn steh ich? :p

Ich arbeite noch an einer anderen Methode.
-
Noch etwas für den GCC:
int main() { decltype(static_cast<int(*)(int*)>(0) ); }$ LANG="C" g++ ./main.cpp -omain -std=c++11 ./main.cpp: In function 'int main()': ./main.cpp:2:37: internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:22878 Please submit a full bug report, with preprocessed source if appropriate. See <https://bugs.archlinux.org/> for instructions.
-
gilt sowas auch?
class c{ public: c(){ new c(); } }; int main(){ new c(); }
-
kellerkindanwärter schrieb:
gilt sowas auch?
class c{ public: c(){ new c(); } }; int main(){ new c(); }Kein Absturz (weder beim GCC noch be clang)
-
so vllt.

#include <stdio.h> class c{ public: ~c(){ this->~c(); } }; int main(){ c x; }
-
kellerkindanwärter schrieb:
so vllt.

Nö.
-
@kellerkindanwärter
Du scheinst hier was falsch verstanden zu haben: es geht nicht darum dass das generierte Programm crasht, sondern darum dass der Compiler crasht. Und zwar richtig crasht -- also nicht ein kontrolliert Abbruch mit einer Fehlermeldung ala "das schachtelt mir zu tief".Das Sahnehäubchen wäre dann noch, wenn du das mit einem laut Standard gültigen Programm hinbekommst. Also etwas was laut Standard "well formed" ist, kein UB zur Folge hat etc.
BTW: bei MSVC 6 war schon sowas in der Art ausreichend:
class foo; class bar {}; typedef bar foo;Wobei das leider kein Sahnehäubchen hat, und mit MSVC 6 Bugs lockt man auch keinen mehr hinterm Ofen vor.
Sahnehäubchen-Bug, bzw. einen der auch moderne Compiler betrifft hab' ich keinen mehr in Erinnerung, sonst hätte ich schon gepostet.
-
Ist mein Bug ein "Sahnehäubchen-Bug" ?

-
pyhax schrieb:
Ist mein Bug ein "Sahnehäubchen-Bug" ?

Der gefällt mir.
Scheint sich um #51908 zu handeln, nur ohne variadic Templates.
-
pyhax schrieb:
Ist mein Bug ein "Sahnehäubchen-Bug" ?

Ich denke schon.
Ist zwar komisch nurtyp;zu schreiben, aber erlaubt isses (Deklaration die nix deklariert). Wird vermutlich mitdecltype(...);nicht anders sein.
(Wobei es vermutlich auch noch crasht wenn du nen Deklarator dazuschreibst.)
-
hustbaer schrieb:
aber erlaubt isses (Deklaration die nix deklariert).
Ich bin ziemlich sicher, dass das nicht erlaubt ist. Es gibt ein paar Fälle, wo die Deklaration selbst keinen Bezeichner einführt, dann gehört dazu aber immer noch etwas anderes, das das tut (bei anonymen unions mindestens ein Member; und unbenannte Bitfelder sind immer Teil einer Klasse).
-
Was soll dieser Wettbewerb erreichen?
Code zum Absturz eines Programmes kann jeder schreiben, nicht nur Anfänger.
Einen Code, der mit unterschiedlichen Compilern mal läuft und mal nicht, findet sich immer. Den Compiler absichtlich zum Absturz bringen?
Ist auch sicher möglich, nur wozu? Die Frage hier erscheint mir wenig interessant zum weiteren Nachdenken. 
Rufe den Pizzadienst. Sein Kassencomputer hat kein solches Problem!

-
camper schrieb:
hustbaer schrieb:
aber erlaubt isses (Deklaration die nix deklariert).
Ich bin ziemlich sicher, dass das nicht erlaubt ist. Es gibt ein paar Fälle, wo die Deklaration selbst keinen Bezeichner einführt, dann gehört dazu aber immer noch etwas anderes, das das tut (bei anonymen unions mindestens ein Member; und unbenannte Bitfelder sind immer Teil einer Klasse).
Hm. OK

Crasht der Code noch wenn man nen Deklarator dranschreibt? Wenn ja wäre ja alles in Butter.@berniebutt
Ach weisste, es gibt immer Dinge die für manche interessant sind, und für andere total doof. Man muss aber nicht überall was dazuschreiben, wo man das doof findet.