[Bug c/41795] New: Incorrect warning while compiling string constant with "??)"

P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oder at eleks dot lviv dot ua GCC build triplet: x86 GCC host triplet: x86 GCC target triplet: x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41795

[Bug target/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

--- Comment #11 from oder at eleks dot lviv dot ua 2008-05-21 16:27 --- (In reply to comment #10) > OSAtomicIncrement32Barrier will return a 32bit signed extended value to a > 64bit > so using a 64bit compare is fine and ok according to the ABI. Yes, but it returns value

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

-- oder at eleks dot lviv dot ua changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

--- Comment #9 from oder at eleks dot lviv dot ua 2008-05-21 15:39 --- Created an attachment (id=15666) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15666&action=view) Sources without Mac headers So, I had some free time an enthusiasm to modify the example and remov

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

--- Comment #8 from oder at eleks dot lviv dot ua 2008-04-07 08:58 --- Created an attachment (id=15438) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15438&action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

--- Comment #5 from oder at eleks dot lviv dot ua 2008-04-06 20:14 --- (In reply to comment #4) > Both Fink and Macports have > gcc 4.1, 4.2, and 4.3 packages, and Macports even has a 4.4 snapshot. Could you please provide a link to gcc archive? On gcc.gnu.org there is no Ma

[Bug c++/35836] Wrong instruction generated for comparison with zero on PPC 64 bit

--- Comment #2 from oder at eleks dot lviv dot ua 2008-04-06 13:21 --- (In reply to comment #1) > You need to report this with apple or at least try a still maintained gcc > version and provide a testcase without Mac specific headers. Well, it's not so easy. ./configure fo

[Bug c++/35835] Compiler fails to recognize match of local "extern" declarations

--- Comment #2 from oder at eleks dot lviv dot ua 2008-04-05 20:02 --- (In reply to comment #1) > First, this bug should be filed with Apple as you are using Apple's modified > compiler. Second 4.0.x is no longer being maintained, so please try 4.1.x. I don't have ro

[Bug c++/35836] New: Wrong instruction generated for comparison with zero on PPC 64 bit

ison with zero yields incorrect result. osx-leopard:build oder$ g++ -m64 -o test test.cpp osx-leopard:build oder$ ./test 0 -- Summary: Wrong instruction generated for comparison with zero on PPC 64 bit Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oder at eleks dot lviv dot ua GCC build triplet: ppc GCC host triplet: ppc GCC target triplet: ppc http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35836

[Bug c++/35835] New: Compiler fails to recognize match of local "extern" declarations

ls to recognize match of local "extern" declarations Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org R

[Bug c++/33914] New: False warning: allocating zero-element array

iority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oder at eleks dot lviv dot ua GCC build triplet: x86 GCC host triplet: x86 GCC target triplet: x86 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33914

[Bug inline-asm/30117] New: fdivp assembler instruction compiles to fdivrp

assembler instruction compiles to fdivrp Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oder at eleks dot lviv d

[Bug c++/29582] Parameter pushed to stack too soon

-- oder at eleks dot lviv dot ua changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582

[Bug c++/29582] Parameter pushed to stack too soon

--- Comment #4 from oder at eleks dot lviv dot ua 2006-10-30 08:33 --- Created an attachment (id=12509) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12509&action=view) Compilable testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29582

[Bug c++/29582] Parameter pushed to stack too soon

--- Comment #2 from oder at eleks dot lviv dot ua 2006-10-24 16:09 --- (In reply to comment #1) > The evaluation order of function arguments is not specified. If you depend on > side effects to be carried out at a specific point you must make sure there is > a sequence poi

[Bug c++/29582] New: Parameter pushed to stack too soon

es initial one. -- Summary: Parameter pushed to stack too soon Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org

[Bug c++/27838] New: Wrong code generated for for()-loop with enumerated type as index

with enumerated type as index Product: gcc Version: 3.3.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oder at eleks dot