Re: possible bug in gcc compiler

Note, this mailing list is for development of gcc, gcc-help would be more appropriate. On Fri, Mar 11, 2022 at 07:53:32PM +, Larry Jackson via Gcc wrote: > I goofed and failed to put a space after the "case" word: > > switch(nu){ > case1: v1 =val;break; > case2: v2 =val;break; > case3: v3

possible bug in gcc compiler

I goofed and failed to put a space after the "case" word: switch(nu){ case1: v1 =val;break; case2: v2 =val;break; case3: v3 =val;break; case4: v4 =val;break; } gcc compiler showed NO errors or warnings. Execution of the code produced incorrect results. After I added a space(no other changes),

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251 --- Comment #5 from Felix Köhler --- Andrew, Jonathan, thanks to both of you for the concise and helpful explanations! GCC not only is a great compiler, it has a great STL and great implementers :D So, if I want to replace an instance of

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > (In reply to Felix Köhler from comment #0) > > you cannot expect to get passed the accumulator value as the first argument > > to BinOp and the sequence

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251 --- Comment #3 from Jonathan Wakely --- The non-parallel version of std::reduce really only exists for completeness, because the parallel overload (the one taking an execution policy argument) exists, and so a non-parallel one was added too.

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug libstdc++/104251] std::reduce scrambles argument order for BinaryOp function call: Possible bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251 --- Comment #1 from Andrew Pinski --- (In reply to Felix Köhler from comment #0) > According to cppreference.com: > "The behavior is non-deterministic if binary_op is not associative or not > commutative. ... in other words, reduce behaves like

[Bug libstdc++/104251] New: std::reduce scrambles argument order for BinaryOp function call: Possible bug?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104251 Bug ID: 104251 Summary: std::reduce scrambles argument order for BinaryOp function call: Possible bug? Product: gcc Version: 11.1.0 Status: UNCONFIRMED

[Bug c++/100881] New: [c++ modules][possible bug?] default arguments break when the default argument's type isn't explicitly included/exported

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100881 Bug ID: 100881 Summary: [c++ modules][possible bug?] default arguments break when the default argument's type isn't explicitly included/exported Product: gcc

[Bug tree-optimization/96801] Refactoring of LIM introduced possible bug

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96801 --- Comment #2 from Stefan Schulze Frielinghaus --- Can confirm. This is resolved with the mentioned commit. Thanks!

[Bug tree-optimization/96801] Refactoring of LIM introduced possible bug

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96801 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE

[Bug tree-optimization/96801] New: Refactoring of LIM introduced possible bug

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96801 Bug ID: 96801 Summary: Refactoring of LIM introduced possible bug Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree

Re: Possible Bug in make_more_copies

Hi Nick, On Wed, Mar 18, 2020 at 08:56:11PM -0400, Nicholas Krause wrote: > I've not sure if I've misunderstanding something in the combine code but > in make_more_copies > for combine.c this seems very odd: > if (!(REG_P (dest) && !HARD_REGISTER_P (dest))) >     continue; > >     rtx src =

Possible Bug in make_more_copies

Greetings Segher, I've not sure if I've misunderstanding something in the combine code but in make_more_copies for combine.c this seems very odd: if (!(REG_P (dest) && !HARD_REGISTER_P (dest)))     continue;     rtx src = SET_SRC (set);     if (!(REG_P (src) && HARD_REGISTER_P (src)))        

[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 kargl at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED

[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Dec 29 18:10:57 2018 New Revision: 267465 URL: https://gcc.gnu.org/viewcvs?rev=267465=gcc=rev Log: 2018-12-29 Steven G. Kargl PR fortran/88342 *

[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #3 from kargl

[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #1) > (In reply to Matt Thompson from comment #0) > > All, > > > > A colleague of mine encountered an issue with 8.2.0 (but it's also in 7.3.0 > > at least). We

[Bug fortran/88342] Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org ---

[Bug fortran/88342] New: Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88342 Bug ID: 88342 Summary: Possible bug with IEEE_POSITIVE_INF and -ffpe-trap=overflow Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal

Re: Possible bug in cse.c affecting pre/post-modify mem access

That makes me wonder if there is a latent bug though. Consider pushing args to a pure function. Could we then try to CSE the memory reference and get it wrong because we haven't accounted for the autoinc? >>> >>> Can't know for sure but one would hope something would test for >>>

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/15/2018 12:58 PM, A. Skrobov wrote: >>> That makes me wonder if there is a latent bug though. Consider pushing >>> args to a pure function. Could we then try to CSE the memory reference >>> and get it wrong because we haven't accounted for the autoinc? >> >> Can't know for sure but one

Re: Possible bug in cse.c affecting pre/post-modify mem access

>> That makes me wonder if there is a latent bug though. Consider pushing >> args to a pure function. Could we then try to CSE the memory reference >> and get it wrong because we haven't accounted for the autoinc? > > Can't know for sure but one would hope something would test for >

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/14/2018 10:55 PM, Jeff Law wrote: > That does sound vaguely familiar. Did we put autoinc notes on the stack > pushes? Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps. > That makes me wonder if there is a latent bug though. Consider pushing > args to a pure function.

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/12/2018 01:35 PM, Bernd Schmidt wrote: > On 05/12/2018 07:01 PM, Jeff Law wrote: > >> No. We're not supposed to have any auto-inc insns prior to the auto-inc >> pass. A stack push/pop early in the compiler would have to be >> represented by a PARALLEL. >> >> It's been this way forever.

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/12/2018 07:01 PM, Jeff Law wrote: > No. We're not supposed to have any auto-inc insns prior to the auto-inc > pass. A stack push/pop early in the compiler would have to be > represented by a PARALLEL. > > It's been this way forever. It's documented in the internals manual > somewhere.

Re: Possible bug in cse.c affecting pre/post-modify mem access

Jeff Law writes: > On 05/12/2018 10:02 AM, Richard Sandiford wrote: >> "A. Skrobov" writes: If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb (sigh, bad modularity). I'm not at all familiar with how the hashing is used within

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/12/2018 10:02 AM, Richard Sandiford wrote: > "A. Skrobov" writes: >>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb >>> (sigh, bad modularity). I'm not at all familiar with how the hashing >>> is used within the selective scheduler, so I can't

Re: Possible bug in cse.c affecting pre/post-modify mem access

>>> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb >>> (sigh, bad modularity). I'm not at all familiar with how the hashing >>> is used within the selective scheduler, so I can't really say what the >>> selective scheduler *should* be doing here. >> >> OK, I see. Now what do

Re: Possible bug in cse.c affecting pre/post-modify mem access

"A. Skrobov" writes: >> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb >> (sigh, bad modularity). I'm not at all familiar with how the hashing >> is used within the selective scheduler, so I can't really say what the >> selective scheduler *should* be

Re: Possible bug in cse.c affecting pre/post-modify mem access

> If we look in sel-sched-ir.c we see that it calls into hash_rtx_cb > (sigh, bad modularity). I'm not at all familiar with how the hashing > is used within the selective scheduler, so I can't really say what the > selective scheduler *should* be doing here. OK, I see. Now what do you think

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/10/2018 11:45 PM, A. Skrobov wrote: > On Fri, May 11, 2018 at 12:09 AM, Jeff Law wrote: >> >> My recollection is that auto-increment addressing modes should not >> appear in the RTL in the CSE pass. > > Fair enough; but they're explicitly listed in the big switch block in

Re: Possible bug in cse.c affecting pre/post-modify mem access

On Fri, May 11, 2018 at 12:09 AM, Jeff Law wrote: > > My recollection is that auto-increment addressing modes should not > appear in the RTL in the CSE pass. Fair enough; but they're explicitly listed in the big switch block in hash_rtx_cb (). Should my added line change from

Re: Possible bug in cse.c affecting pre/post-modify mem access

On 05/10/2018 01:44 PM, A. Skrobov wrote: > Hello, > > While working on a port of GCC for a non-public architecture that has > pre/post-modify memory access instructions, I discovered what looks > like a bug which can cause incorrect code generation. > > My suggested fix is trivial: >

Re: Possible bug in cse.c affecting pre/post-modify mem access

Hi, "A. Skrobov" writes: > Hello, > > While working on a port of GCC for a non-public architecture that has > pre/post-modify memory access instructions, I discovered what looks > like a bug which can cause incorrect code generation. > > My suggested fix is trivial: >

Possible bug in cse.c affecting pre/post-modify mem access

Hello, While working on a port of GCC for a non-public architecture that has pre/post-modify memory access instructions, I discovered what looks like a bug which can cause incorrect code generation. My suggested fix is trivial:

Re: Possible Bug Fix/No Reply on Bugzilla

Sir, On Thu, Sep 28, 2017 at 4:03 PM, Manuel López-Ibáñez wrote: > On 27/09/17 21:56, nick wrote: >> >> Greetings All, >> >> I commented here a few names ago, >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230. Not >> to be a annoyance but I have a school assignment and

Re: Possible Bug Fix/No Reply on Bugzilla

On 27/09/17 21:56, nick wrote: Greetings All, I commented here a few names ago, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230. Not to be a annoyance but I have a school assignment and would like someone to reply if it's correct or something. I am assuming it's probably wrong but any

Possible Bug Fix/No Reply on Bugzilla

Greetings All, I commented here a few names ago, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230. Not to be a annoyance but I have a school assignment and would like someone to reply if it's correct or something. I am assuming it's probably wrong but any comment would be very helpful

Re: Possible Bug with Building on Current Tree

On Sun, Sep 24, 2017 at 2:28 PM, nick wrote: > Greetings All, > > Probably me doing something stupid what I am configuring gcc on current git > with: > $PWD/../gcc/configure --prefix=$HOME/GCC-7.0.1 > --enable-languages=c,c++,fortran,go > > This is in a directory called

Possible Bug with Building on Current Tree

Greetings All, Probably me doing something stupid what I am configuring gcc on current git with: $PWD/../gcc/configure --prefix=$HOME/GCC-7.0.1 --enable-languages=c,c++,fortran,go This is in a directory called objdir for building gcc as according to docs. It makes with this: make: *** No

Re: [WIP] Possible Bug in vect_bb_slp_scalar_cost?

On Mon, Aug 28, 2017 at 10:57 AM, Dominik Inführ wrote: > Hi, > > As discussed on IRC: This patches fixes the calculation of the scalar costs > of SLP vectorization. I’ve added a test case and the auto_vec allocation is > now reused for all children of a

Re: [WIP] Possible Bug in vect_bb_slp_scalar_cost?

Hi, As discussed on IRC: This patches fixes the calculation of the scalar costs of SLP vectorization. I’ve added a test case and the auto_vec allocation is now reused for all children of a node. diff --git a/gcc/testsuite/gcc.dg/vect/costmodel/x86_64/costmodel-vect-slp.c

Re: [WIP] Possible Bug in vect_bb_slp_scalar_cost?

On Fri, Aug 4, 2017 at 12:08 PM, Dominik Inführ wrote: > Hi, > > vect_bb_slp_scalar_cost computes the scalar cost of a SLP node. If there are > non-scalar uses of a definition, the costs for it and its operands (children) > are ignored. The vector LIFE is

[WIP] Possible Bug in vect_bb_slp_scalar_cost?

Hi, vect_bb_slp_scalar_cost computes the scalar cost of a SLP node. If there are non-scalar uses of a definition, the costs for it and its operands (children) are ignored. The vector LIFE is used to keep track of this and an element is set to true, such that the def and its children are

[Bug target/80124] Possible bug in _mm_cmpeq_ps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #6 from Guille --- Thanks.

[Bug target/80124] Possible bug in _mm_cmpeq_ps

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

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #4 from Marc Glisse --- NaN (all-ones is a NaN) is not equal to itself, that's normal behavior.

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #3 from Guille --- Apologies, this maybe should've gone in the 'C bugs' section, not the C++ section.

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #2 from Guille --- Created attachment 41008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41008=edit the code that triggers possible bug Compile with 'c++ t.c' (or maybe 'c++ -msse -msse2 t.c').

[Bug c++/80124] Possible bug in _mm_cmpeq_ps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 --- Comment #1 from Guille --- I forgot to mention that a while back (~1year) I had a similar problem with _mm256_cmp_ps(a,b, _CMP_EQ_OQ) (the AVX equivalent of _mm_cmpeq_ps), but I wasn't able to isolate the problem back then.

[Bug c++/80124] New: Possible bug in _mm_cmpeq_ps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80124 Bug ID: 80124 Summary: Possible bug in _mm_cmpeq_ps Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #11 from Jonathan Wakely --- Author: redi Date: Fri Mar 17 19:28:42 2017 New Revision: 246247 URL: https://gcc.gnu.org/viewcvs?rev=246247=gcc=rev Log: Backport fixes from trunk Fix alignment bugs in std::codecvt_utf16 *

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #10 from Jonathan Wakely --- Author: redi Date: Fri Mar 17 19:28:29 2017 New Revision: 246246 URL: https://gcc.gnu.org/viewcvs?rev=246246=gcc=rev Log: Backport fixes from trunk Fix alignment bugs in std::codecvt_utf16 *

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #9 from Jonathan Wakely --- Author: redi Date: Thu Mar 16 17:22:47 2017 New Revision: 246205 URL: https://gcc.gnu.org/viewcvs?rev=246205=gcc=rev Log: PR libstdc++/79980 fix target type of cast PR libstdc++/79980 *

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #8 from Jonathan Wakely --- Yes, in about 60 seconds. There's no need to revert anything.

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #7 from Steve Kargl --- On Thu, Mar 16, 2017 at 05:13:51PM +, redi at gcc dot gnu.org wrote: > > --- Comment #6 from Jonathan Wakely --- > It's just a dumb error where I used a typedef that was previously defined, the > fix is:

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #6 from Jonathan Wakely --- It's just a dumb error where I used a typedef that was previously defined, the fix is: static underlying_type::type to_integer(codecvt_mode m) { return static_cast(m); }

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org ---

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #4 from Jonathan Wakely --- Author: redi Date: Thu Mar 16 15:27:51 2017 New Revision: 246200 URL: https://gcc.gnu.org/viewcvs?rev=246200=gcc=rev Log: PR libstdc++/79980 fix BOM detection, maxcode checks, UCS2 handling PR

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #3 from Jonathan Wakely --- Patch posted to https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00675.html Will be committed for stage 1

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #2 from Jonathan Wakely --- Apparently so is min vs max: maxcode = std::max(max_single_utf16_unit, maxcode);

[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed|

[Bug libstdc++/79980] New: Possible bug in codecvt.cpp bitmask setting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 Bug ID: 79980 Summary: Possible bug in codecvt.cpp bitmask setting code Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #10 from Richard Biener --- Author: rguenth Date: Wed Dec 14 10:35:11 2016 New Revision: 243644 URL: https://gcc.gnu.org/viewcvs?rev=243644=gcc=rev Log: 2016-12-14 Richard Biener PR

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Dec 14 10:32:56 2016 New Revision: 243642 URL: https://gcc.gnu.org/viewcvs?rev=243642=gcc=rev Log: 2016-12-14 Richard Biener PR

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #7 from Richard Biener --- Author: rguenth Date: Wed Dec 14 10:31:37 2016 New Revision: 243641 URL: https://gcc.gnu.org/viewcvs?rev=243641=gcc=rev Log: 2016-12-14 Richard Biener PR

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #6 from Jeffrey A. Law --- The patch is fine -- it can't hurt correctness and it's less invasive than pulling out all the backedge handling like we did for later releases. My only worry is that it's really a bandaid for code that is

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #5 from rguenther at suse dot de --- On Fri, 9 Dec 2016, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 > > Jeffrey A. Law changed: > >What|Removed |Added >

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #4

[Bug tree-optimization/78731] [5 Regression] Possible bug with switch when optimization is turned on.

||4.9.4, 6.1.0 Target Milestone|--- |5.5 Summary|Possible bug with switch|[5 Regression] Possible bug |when optimization is turned |with switch when |on. |optimization

[Bug tree-optimization/78731] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned

[Bug tree-optimization/78731] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 --- Comment #2 from Jim Wilson --- The compiler is failing in jump threading as called by dom2. Jeff's 2015-09-30 patch is triggering in dom1, and changing the CFG just enough to prevent the jump threading bug from triggering. So it isn't a

Re: Possible bug with switch when optimization is turned on.

On 12/05/2016 03:24 PM, luke B wrote: The following code seems to be correctly executed when compiled with GCC 4.4.7 and LLVM 6.1. It does not correctly compile with gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4). I created a bug report and added some info.

[Bug tree-optimization/78731] Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 Jim Wilson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug tree-optimization/78731] New: Possible bug with switch when optimization is turned on.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78731 Bug ID: 78731 Summary: Possible bug with switch when optimization is turned on. Product: gcc Version: 5.4.1 Status: UNCONFIRMED Severity: normal

Possible bug with switch when optimization is turned on.

Hi The following code seems to be correctly executed when compiled with GCC 4.4.7 and LLVM 6.1. It does not correctly compile with gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4). The following is what I have reduced the problem to: #include #include #define GENERAL 1 #define

[Bug fortran/68889] Fortran/DWARF: Possible bug in the handling of DW_AT_associated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68889 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

Re: Possible bug: Unaligned bit-field address when predictive commoning.

On Thu, May 12, 2016 at 12:17 PM, Richard Biener wrote: > On Thu, May 12, 2016 at 12:10 PM, Claudiu Zissulescu > wrote: >> Hi, >> >> I've been trying the following simple test case on latest gcc, and it seems >> to produce unwanted

Re: Possible bug: Unaligned bit-field address when predictive commoning.

On Thu, May 12, 2016 at 12:10 PM, Claudiu Zissulescu wrote: > Hi, > > I've been trying the following simple test case on latest gcc, and it seems > to produce unwanted unaligned accesses for bit-fields. > > Test cases: > > struct lock_chain { > unsigned int

Possible bug: Unaligned bit-field address when predictive commoning.

Hi, I've been trying the following simple test case on latest gcc, and it seems to produce unwanted unaligned accesses for bit-fields. Test cases: struct lock_chain { unsigned int irq_context: 2, depth: 6, base: 24; }; struct lock_chain * foo (struct lock_chain *chain) { int i;

[Bug fortran/68889] Fortran/DWARF: Possible bug in the handling of DW_AT_associated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68889 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed|

[Bug fortran/68889] New: Fortran/DWARF: Possible bug in the handling of DW_AT_associated

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68889 Bug ID: 68889 Summary: Fortran/DWARF: Possible bug in the handling of DW_AT_associated Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal

[Bug target/28115] possible bug in recog_memoized usage in rs6000.c??

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28115 --- Comment #8 from Eric Botcazou --- Author: ebotcazou Date: Mon Nov 30 09:43:55 2015 New Revision: 231059 URL: https://gcc.gnu.org/viewcvs?rev=231059=gcc=rev Log: PR target/28115 * config/sparc/sparc.c

[Bug target/28115] possible bug in recog_memoized usage in rs6000.c??

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28115 --- Comment #6 from David Edelsohn --- Author: dje Date: Sun Nov 29 18:11:54 2015 New Revision: 231045 URL: https://gcc.gnu.org/viewcvs?rev=231045=gcc=rev Log: PR target/28115 * config/rs6000/rs6000.c (rs6000_adjust_cost): Correct

[Bug target/28115] possible bug in recog_memoized usage in rs6000.c??

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28115 David Edelsohn changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug c++/62003] Possible bug in std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last

[Bug c++/62003] Possible bug in std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 --- Comment #2 from Daniel Wilczak wilczak at ii dot uj.edu.pl --- OS version Windows 7, 64-bit. gcc version: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32

[Bug c++/62003] Possible bug in std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target||mingw32

[Bug c++/62003] Possible bug in std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 --- Comment #4 from Daniel Wilczak wilczak at ii dot uj.edu.pl --- Me neither - on GNU/Linux the program runs normally. Daniel W dniu 2014-08-04 13:32, redi at gcc dot gnu.org pisze: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 Jonathan

[Bug c++/62003] New: Possible bug in std::complex

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62003 Bug ID: 62003 Summary: Possible bug in std::complex Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c

Need some help with a possible bug

Hi, I'm trying to build the latest gcc and am getting a message from the process collect2: error: ld returned 1 exit status for this library /usr/lsd/Linux/lib/libgmp.so. Here's the full msg: /usr/lsd/Linux/lib/libgmp.so: could not read symbols: File in wrong format When I use the file

Re: Need some help with a possible bug

(should have been gcc-h...@gcc.gnu.org, please send any follow-ups there) On Wed, 23 Apr 2014, George R Goffe wrote: I'm trying to build the latest gcc Do you really need gcj? If not, please disable java. and am getting a message from the process collect2: error: ld returned 1 exit status

Re: status of current_pass (notably in gates) .... [possible bug in 4.9]

On Mon, Mar 10, 2014 at 1:30 PM, Basile Starynkevitch bas...@starynkevitch.net wrote: Hello All, I am a bit confused (or unhappy) about the current_pass variable (in GCC 4.9 svn rev.208447); I believe we have some incoherency about it. It is generally (as it used to be in previous versions

status of current_pass (notably in gates) .... [possible bug in 4.9]

Hello All, I am a bit confused (or unhappy) about the current_pass variable (in GCC 4.9 svn rev.208447); I believe we have some incoherency about it. It is generally (as it used to be in previous versions of GCC) a global pointer to some opt_pass, declared in gcc/tree-pass.h line 590. It is

Patch correcting possible bug in toplevel.c regarding plugin diagnostics finalizartion

Hello All I'm re-reading toplev_main from gcc/toplev.c and I find strange that invoke_plugin_callbacks for PLUGIN_FINISH was called before diagnostic_finish (which I guess is finalizing all the diagnostic infrastructure). My guess would be that some GCC plugins might occasionally emit a

Possible bug; code-block vanishes when adding one assembler-instruction.

I'm using a GCC toolchain similar to Yagarto for making code for the LPC1768 microcontroller. My gcc is version 4.7.2, my binutils is version 2.23.1 To make parts of my code run faster (a timer interrupt to be exact), I've used a modified linker script, so that I get a '.fastcode' section. The

  1   2   >