[Bug c++/117374] New: Strange behavior of co_yield in initializer-list

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117374 Bug ID: 117374 Summary: Strange behavior of co_yield in initializer-list Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from Andrew P

[Bug tree-optimization/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 --- Comment #3 from Carlos Galvez --- Thanks for the quick response! Unfortunately we are stuck on GCC 9 for reasons so I'll try to shuffle the code around a bit to make it work :)

[Bug c++/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 --- Comment #2 from Andrew Pinski --- >From IV-OPTs dup: inv_expr 3: (-() _13 - () &input) - -1 inv_expr 4: -() _13 - () &input That is totally bogus (that was even in GCC 8)

[Bug c++/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 --- Comment #1 from Richard Biener --- looks like a bug in GCC 9.x, note that's EOL and thus will receive no fixes. You can try to bisect where it was fixed since GCC 10.1 seems to work. There might be a duplicate fixed bugreport for this.

[Bug c++/111714] New: Strange behavior when casting std::size_t to bool, UB or compiler bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 Bug ID: 111714 Summary: Strange behavior when casting std::size_t to bool, UB or compiler bug? Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC|

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #12 from Jeffrey A. Law --- Author: law Date: Wed Dec 2 07:42:58 2015 New Revision: 231150 URL: https://gcc.gnu.org/viewcvs?rev=231150&root=gcc&view=rev Log: [PATCH] Fix PR68029 PR driver/68029 * opts-common.c (prun

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #11 from Manuel López-Ibáñez --- (In reply to Jiří Engelthaler from comment #10) > Will this bug be resolved in 6.0 release? Could you submit your patch to gcc-patc...@gcc.gnu.org? See https://gcc.gnu.org/ml/gcc-patches/2015-11/ for

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #10 from Jiří Engelthaler --- Will this bug be resolved in 6.0 release?

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #9 from Jiří Engelthaler --- (In reply to Manuel López-Ibáñez from comment #8) > > Good catch! In principle your patch seems correct. I think you are only > missing a testcase. This patch is small enough to not require a copyright >

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Jiří Engelthaler from comment #7) > Created attachment 36638 [details] > diag_color.patch > > fdiagnostics_color_idx can by on first place so comparing as > 1 will miss > it. > There shoul

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #7 from Jiří Engelthaler --- Created attachment 36638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36638&action=edit diag_color.patch fdiagnostics_color_idx can by on first place so comparing as > 1 will miss it. There should

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #6 from Manuel López-Ibáñez --- (In reply to Jiří Engelthaler from comment #5) > I have tested GCC with reverted r228094 and there is not problem reported by > this bug. > I'm asking someone with rights to reopen the bug 67640 and lin

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #5 from Jiří Engelthaler --- (In reply to Manuel López-Ibáñez from comment #4) > (In reply to Jiří Engelthaler from comment #3) > > (In reply to Manuel López-Ibáñez from comment #2) > > > What does -### show for the call to cc1 ? My c

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #4 from Manuel López-Ibáñez --- (In reply to Jiří Engelthaler from comment #3) > (In reply to Manuel López-Ibáñez from comment #2) > > What does -### show for the call to cc1 ? My commit r228094 to opts-common.c > > should have fixed

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 --- Comment #3 from Jiří Engelthaler --- (In reply to Manuel López-Ibáñez from comment #2) > What does -### show for the call to cc1 ? My commit r228094 to opts-common.c > should have fixed this. $ gcc -fdiagnostics-color=never a.c -### cc1.exe

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Commen

[Bug driver/68029] Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug c/68029] New: Strange behavior of -fdiagnostics-color option

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68029 Bug ID: 68029 Summary: Strange behavior of -fdiagnostics-color option Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug c/39121] strange behavior in chained operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 frankhb1989 at gmail dot com changed: What|Removed |Added CC||frankhb1989 at gmail dot co

[Bug c/39121] strange behavior in chained operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Commen

[Bug c/39121] strange behavior in chained operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 --- Comment #7 from joe.carnuccio at qlogic dot com --- Ok, the sequence points are at each of the assignment operators. The crux of this is that doing the xor chain with dereferenced pointers fails (incorrect execution), whereas doing it with va

[Bug c/39121] strange behavior in chained operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 --- Comment #6 from Andrew Pinski --- (In reply to joe.carnuccio from comment #5) > Since using gcc -Os causes the correct execution, then "sequence point" does > not have anything to do with it. And you are wrong about that. -Os causes what yo

[Bug c/39121] strange behavior in chained operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 --- Comment #5 from joe.carnuccio at qlogic dot com --- Since using gcc -Os causes the correct execution, then "sequence point" does not have anything to do with it.

[Bug c/39121] strange behavior in chained operations

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39121 joe.carnuccio at qlogic dot com changed: What|Removed |Added CC||joe.carnuccio at qlogic

[Bug c++/60041] Strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60041 --- Comment #3 from qRoC --- cout

[Bug c++/60041] Strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60041 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/60041] Strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60041 Paolo Carlini changed: What|Removed |Added Severity|critical|normal

[Bug c++/60041] Strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60041 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler@googlemail.

[Bug c++/60041] New: Strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60041 Bug ID: 60041 Summary: Strange behavior Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c++ Assignee

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #7 from Dominique d'Humieres 2011-02-03 22:13:11 UTC --- On x86_64-apple-darwin10.6.0 the test in attachment 23241 compiles with 4.5.2 (r167027) and trunk r162456, but give an ICE gyre_lanr_discrim.f90:7.19: use gyre_lanr_bvp

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #6 from Mikael Morin 2011-02-03 21:54:09 UTC --- (In reply to comment #5) > Created attachment 23241 [details] > Revised tar archive w/ source & Makefile > > Seems some stuff got left out of the tar file. Here's a new set of source >

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #5 from Rich Townsend 2011-02-03 21:17:29 UTC --- Created attachment 23241 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23241 Revised tar archive w/ source & Makefile Seems some stuff got left out of the tar file. Here's a new

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #4 from Mikael Morin 2011-02-03 19:31:07 UTC --- gyre_lanr_discrim.f90:6.15: use gyre_func 1 Fatal Error: Can't open module file 'gyre_func.mod' for reading at (1): No such file or directory

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 --- Comment #3 from Rich Townsend 2011-02-03 19:20:12 UTC --- Created attachment 23239 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23239 Fixed Makefile Removed some broken dependencies from the original Makefile

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 f

[Bug fortran/47601] Internal Error (mio_component_ref(): Component not found) with strange behavior

st possible > test case, I've found some pretty strange behavior. Oops, I meant pr47463

[Bug fortran/47601] New: Internal Error (mio_component_ref(): Component not found) with strange behavior

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47601 Summary: Internal Error (mio_component_ref(): Component not found) with strange behavior Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority

[Bug c++/44260] Strange behavior on bit fields structures

--- Comment #4 from schwab at linux-m68k dot org 2010-05-24 15:48 --- *** This bug has been marked as a duplicate of 21920 *** -- schwab at linux-m68k dot org changed: What|Removed |Added --

[Bug c++/44260] Strange behavior on bit fields structures

--- Comment #3 from xinping dot huang at gmail dot com 2010-05-24 13:53 --- Subject: Re: Strange behavior on bit fields structures Sorry I made a mistake here, it works on 32bit mode, but failed on the 64bit mode. Wesley 2010/5/24 xinping dot huang at gmail dot com

[Bug c++/44260] Strange behavior on bit fields structures

--- Comment #2 from xinping dot huang at gmail dot com 2010-05-24 13:51 --- Subject: Re: Strange behavior on bit fields sructures. My gcc 4.4.4 generate the correct binary and get the correct result even with -O3 option. Wesley 2010/5/24 dennis at conus dot info

[Bug c++/44260] Strange behavior on bit fields sructures.

--- Comment #1 from dennis at conus dot info 2010-05-24 13:30 --- The code 4.4.1 x86 generating (with -O3 option) for bswap() function I mentioned earlier is strange too: ; bswap(unsigned int) public _Z5bswapj _Z5bswapj proc near var_4 = dword ptr -4 ar

[Bug c++/44260] New: Strange behavior on bit fields sructures.

F; i++) { if (i==0x11223344) printf ("i=%08X, bswap=%08X\n", i, bswap (i)); }; }; -- Summary: Strange behavior on bit fields sructures. Product: gcc Version: 4.4.3 Status: UNCONFIRMED

GCC strange behavior

hink this is a compiler error? -- View this message in context: http://www.nabble.com/GCC-strange-behavior-tp25157468p25157468.html Sent from the gcc - bugs mailing list archive at Nabble.com.

[Bug c/39121] strange behavior in chained operations

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-06 21:21 --- Evaluation order is undefined if there is no sequence point. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added

[Bug c/39121] strange behavior in chained operations

--- Comment #2 from nospam at pamies dot cat 2009-02-06 21:07 --- Is not the same bug as #15145. I agree with you that there is just one sequence point, but the operation is not undefined. void swap(int *a, int *b) { *a ^= *b ^= *a ^= *b; } This code should be compiled to: *a = *a

[Bug c/39121] strange behavior in chained operations

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-06 20:09 --- This is undefined code as you are modifying *a twice without a sequence point inbetween the modifies. *** This bug has been marked as a duplicate of 15145 *** -- pinskia at gcc dot gnu dot org changed:

[Bug c/39121] New: strange behavior of a chain of operations.

^= *b; } int main() { int a = 5; int b = 8; printf("%d, %d\n", a, b); a ^= b ^= a ^= b; printf("%d, %d\n", a, b); swap(&a, &b); printf("%d, %d\n", a, b); } -- Summary: strange behavior of a chain of operations.

[Bug c++/34726] explicit specialization in non-namespace scope strange behavior

--- Comment #1 from bangerth at dealii dot org 2008-01-13 02:17 --- Explicit specializations of member templates need to be declared outside the declaration of the outer class, as per 14.7.3/2. -- bangerth at dealii dot org changed: What|Removed |A

[Bug c++/34726] New: explicit specialization in non-namespace scope strange behavior

ictive template parameter: template class A { template class B { }; template class B { }; }; -- Summary: explicit specialization in non-namespace scope strange behavior Product: gcc V

[Bug c/26271] strange behavior with no warning at -Wall when redeclaring static function extern

--- Comment #1 from pinskia at gcc dot gnu dot org 2006-02-14 00:17 --- This is valid code besides the extra semicolon and converting between between function pointer types and void*. This is a dup of bug 24097. *** This bug has been marked as a duplicate of 24097 *** -- pinskia at

[Bug c/26271] New: strange behavior with no warning at -Wall when redeclaring static function extern

ess of foo() in the context of bar(), or... 3) gcc should consistently generate code for bar() to get the address of some global symbol "foo", not the static function foo() (in the case of the program above, ultimately causing a linker error). -- Summary: strange behavior

strange behavior...

ile trying, I fall into a very strange behavior. I find an example which worked or failed at compil time depanding on the way the class inherit together (it works when public and fails when private) !! So, this is working class A {}; class B { virtual A* getA(); }; class D

[Bug c++/14213] strange behavior with private cp-cstr...

--- Additional Comments From pluto at ds14 dot agh dot edu dot pl 2004-02-20 06:43 --- (In reply to comment #2) > When writing > A a2 = a1; > this has the same requirements as using the > A a2(a1); > syntax. Thus, the copy constructor needs to be accessible. > > W.