https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92254
--- Comment #6 from Dmitry G. Dyachenko ---
r277655 PASS for me: testcase and original case.
Thank You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #91 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77328
--- Comment #4 from Eric Gallager ---
(In reply to Martin Sebor from comment #3)
> GCC 8 and 9 output for the test case is slightly different (underlining the
> sprintf argument is a nice improvement) but still not what it should be:
>
> pr77328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84810
--- Comment #1 from Jason Merrill ---
Author: jason
Date: Thu Oct 31 02:31:48 2019
New Revision: 277655
URL: https://gcc.gnu.org/viewcvs?rev=277655&root=gcc&view=rev
Log:
PR c++/84810 - constraints on lambdas
Attached is a patch that adds parsi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
Bug 67491 depends on bug 92268, which changed state.
Bug 92268 Summary: [concepts] hard error satisfying return-type-requirement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #8 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #5)
> >Then how can I build a new version of GCC on MinGW? :(
>
> Wait for the bug to fixed. Bugs happen. Most people compiling the trunk
> don't build using mingw. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299
--- Comment #2 from Andrew Pinski ---
Where are you getting these testcases from? If they are from a "standards
complaincy" test, then I think you need to write to them about being broken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147
--- Comment #2 from Matthias Klose ---
this is not about powerpc64le-linux-gnu(64bit little endian), but
powerpc-linux-gnu (32bit, big endian).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92299
Bug ID: 92299
Summary: The expression X / abs (X) is simplified to 1 even
when the variable X is 0
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #7 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #5)
> >Then how can I build a new version of GCC on MinGW? :(
>
> Wait for the bug to fixed. Bugs happen. Most people compiling the trunk
> don't build using mingw. You
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #9 from Jason Merrill ---
Author: jason
Date: Thu Oct 31 02:01:16 2019
New Revision: 277654
URL: https://gcc.gnu.org/viewcvs?rev=277654&root=gcc&view=rev
Log:
PR c++/92268 - hard error satisfying return-type-requirement
Prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92298
Bug ID: 92298
Summary: The expression X / X is simplified to 1 even when the
variable X is 0
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
--- Comment #6 from Jim Wilson ---
Looking at some other targets. ARM has movcc but not 128-bit long double.
Aaarch has movcc and 128-bit long double, but has 128-bit load/store so this is
only 4 instructions. mips64, powerpc64, and sparc64 ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92263
Jim Wilson changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot
gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #6 from fdlbxtqi ---
(In reply to fdlbxtqi from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > Most likely the reduced testcase is just:
> > #pragma push_macro("__has_builtin")
> >
> > --- CUT ---
> > > I did finish co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #5 from Andrew Pinski ---
>Then how can I build a new version of GCC on MinGW? :(
Wait for the bug to fixed. Bugs happen. Most people compiling the trunk don't
build using mingw. You are the bleading edge with compiling on the tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #4 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #3 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #2)
> Most likely the reduced testcase is just:
> #pragma push_macro("__has_builtin")
>
> --- CUT ---
> > I did finish compilation with the same script 3 days ago. Now It f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Andrew Pinski changed:
What|Removed |Added
Keywords||build, ice-on-valid-code
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92297
Bug ID: 92297
Summary: The expression 0 / X is simplified to 0 even when the
variable X is 0
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
--- Comment #1 from fdlbxtqi ---
Here are the patches I am using from msys2.
https://bitbucket.org/ejsvifq_mabmip/mingw-gcc-mcf-gthread/src/master/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92296
Bug ID: 92296
Summary: GCC build ICE on MinGW-w64. internal compiler error:
Segmentation fault #pragma
push_macro("__has_builtin")
Product: gcc
Version: 10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
Eric Gallager changed:
What|Removed |Added
Keywords||diagnostic
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92286
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92295
Bug ID: 92295
Summary: Inefficient vector constructor
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92147
--- Comment #1 from Gaius Mulley ---
I've just seen gm2 master branch build successfully
on powerpc64le-unknown-linux-gnu (make -j 24).
It is currently running the regression tests - looks like it will fail on
15 tests - 6 more than the amd64
(6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92218
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-gnu-linux, |powerpc*
|powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92281
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83732
Kenman Tsang changed:
What|Removed |Added
CC||kentsangkm at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
a.h.jaffe at gmail dot com changed:
What|Removed |Added
CC||a.h.jaffe at gmail dot com
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274
--- Comment #4 from joseph at codesourcery dot com ---
It's actually generic to anything using make; make is designed around
strings that get passed to the shell / split on spaces, rather than having
a generic escape mechanism for special chara
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91369
--- Comment #19 from Jakub Jelinek ---
Author: jakub
Date: Wed Oct 30 21:55:12 2019
New Revision: 277649
URL: https://gcc.gnu.org/viewcvs?rev=277649&root=gcc&view=rev
Log:
PR c++/91369 - Implement P0784R7: constexpr new
* constex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022
--- Comment #4 from Jonathan Wakely ---
Oh, and I removed __cpp_lib_constexpr from today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022
--- Comment #3 from Jonathan Wakely ---
(In reply to emsr from comment #2)
> I think we're done.
> The __cpp_lib_constexpr may not do anything or may not be in the newest
> drafts anymore. We should probably kill it. I was very confused as peop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89022
--- Comment #2 from emsr at gcc dot gnu.org ---
I think we're done.
The __cpp_lib_constexpr may not do anything or may not be in the newest drafts
anymore. We should probably kill it. I was very confused as people were going
back and forth about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284
Tobias Burnus changed:
What|Removed |Added
Keywords||wrong-code
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
fdlbxtqi changed:
What|Removed |Added
Resolution|WORKSFORME |INVALID
--- Comment #11 from fdlbxtqi ---
No
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92247
fdlbxtqi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92024
--- Comment #3 from Bernd Edlinger ---
Author: edlinger
Date: Wed Oct 30 20:29:21 2019
New Revision: 277643
URL: https://gcc.gnu.org/viewcvs?rev=277643&root=gcc&view=rev
Log:
2019-10-30 Bernd Edlinger
* doc/invoke.texi (-Wshadow, -Ws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236
--- Comment #1 from Jason Merrill ---
It would also be helpful to explain for
static_assert (!Int);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92208
--- Comment #4 from Tobias Burnus ---
Author: burnus
Date: Wed Oct 30 20:01:36 2019
New Revision: 277639
URL: https://gcc.gnu.org/viewcvs?rev=277639&root=gcc&view=rev
Log:
Fortran] PR 92208 don't use function-result dummy variable as actual argu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92090
--- Comment #4 from seurer at gcc dot gnu.org ---
I retested and the ICE part only occurs on a BE system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70320
Jozef Lawrynowicz changed:
What|Removed |Added
CC||jozefl.gcc at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #5 from Bill Schmidt ---
For 32-bit big-endian PowerPC (using the 32-bit ELF ABI), the same code
generation is provided by GCC and Clang. I.e., here's the code generation for
Clang with -O2 -m32 -mbig-endian, using 6.0.0-1ubuntu2:
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274
--- Comment #3 from Andrew Pinski ---
(In reply to Heiko Eißfeldt from comment #2)
> IMHO there are better structured alternatives available (for example the
> schily build system from schilytools (sourceforge)).
NOTE GCC is not the only issue h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92134
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92134
--- Comment #2 from Marek Polacek ---
Author: mpolacek
Date: Wed Oct 30 18:49:59 2019
New Revision: 277636
URL: https://gcc.gnu.org/viewcvs?rev=277636&root=gcc&view=rev
Log:
PR c++/92134 - constinit malfunction in static data member.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
Wilco changed:
What|Removed |Added
Target||aarch64
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92254
--- Comment #5 from Dmitry G. Dyachenko ---
very strange
r277625 FAIL for me for testcase from c#1 and for original problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294
Bug ID: 92294
Summary: alias attribute generates incorrect code
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278
--- Comment #8 from Dmitry G. Dyachenko ---
r277625 PASS for me for testcase from c#0 and for original problem.
Thank you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #7 from Jason Merrill ---
Created attachment 47136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47136&action=edit
patch for the simple case
This untested patch fixes my testcase and Jon's, though not the more complex
case. N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92206
--- Comment #8 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you! I can confirm that the patch resolved the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284
--- Comment #4 from José Rui Faustino de Sousa ---
Sorry I blooped while trying to simplify the sample code... :-(
The new code should ICE 10.0.0, but not 9.1.0, using either the C procedure or
the Fortran bind(c) one.
Using just the "arr_set"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284
José Rui Faustino de Sousa changed:
What|Removed |Added
Attachment #47134|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284
José Rui Faustino de Sousa changed:
What|Removed |Added
Attachment #47130|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
--- Comment #3 from Jakub Jelinek ---
In this particular case, there is instrumentation added because of the
-fsanitize=return for the missing return in the function and that affects the
warning location.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92293
Bug ID: 92293
Summary: No reason given for template argument deduction
failure with zero-length array
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
--- Comment #1 from joseph at codesourcery dot com ---
This would be an interaction between the built-in function having a printf
format attribute and the header having either a gnu_printf or an ms_printf
format attribute (depending on feature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
--- Comment #6 from Jason Merrill ---
(In reply to Jason Merrill from comment #5)
> On further thought, I'm not sure normalizing the dependent form is really
> necessary, either here or for nested-requirements, as long as we get the
> proper SFIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
Bug ID: 92292
Summary: duplicate -Wformat warnings about incorrect printf
format specifiers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91927
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from Wil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92268
Jason Merrill changed:
What|Removed |Added
Summary|Constraint normalization|[concepts] hard error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88337
--- Comment #6 from Marek Polacek ---
First steps: this now compiles in c++2a:
struct B {
virtual void baz () {}
};
struct D : B { };
constexpr bool
fn ()
{
bool ok = true;
B b;
B *b1 = &b;
if (D *pd = dynamic_cast(b1))
ok = fals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92254
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278
--- Comment #7 from Martin Jambor ---
*** Bug 92254 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92284
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #4 from gnzlbg ---
Thanks for chiming in. I see the value in having a simple ABI rule. I guess
what confuses me is that the address passed in the calling convention for that
struct will never be used for anything or dereferenced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92291
Bug ID: 92291
Summary: Non-optimal code generated for H8
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #3 from Jozef Lawrynowicz ---
(In reply to gnzlbg from comment #2)
> > I can only speak for msp430, but there's no problem with that generated
> > assembly. Structures and unions are always passed by reference.
>
> I suppose that by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92230
Ariel Torti changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92272
--- Comment #4 from Jonathan Wakely ---
Author: redi
Date: Wed Oct 30 15:48:11 2019
New Revision: 277629
URL: https://gcc.gnu.org/viewcvs?rev=277629&root=gcc&view=rev
Log:
Apply C++20 changes to various iterator types
This ensures that __normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92272
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|jwakely at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92274
--- Comment #2 from Heiko Eißfeldt ---
As I see it, there are multiple issues with the current approach.
1. Since absolute paths (as opposed to relative paths) are used, one cannot
move the configured source tree to some other location and use i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
--- Comment #2 from gnzlbg ---
> I can only speak for msp430, but there's no problem with that generated
> assembly. Structures and unions are always passed by reference.
I suppose that by this you mean that the current behavior is "by design",
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92290
Bug ID: 92290
Summary: Inconsistent -Warray-bounds warning
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
Jozef Lawrynowicz changed:
What|Removed |Added
CC||jozefl.gcc at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
--- Comment #1 from Tony E Lewis ---
Sorry: I should have said...
Even the original warning isn't ideal because the compiler has enough
information to know that all paths through f() either return a value or throw.
So I don't think it should war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #6 from Martin Liška ---
Created attachment 47132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47132&action=edit
Debugging patch
With the attached patch (and r276645) run succeeds.
If you change s/counter < 2/counter < 1/ the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92289
Bug ID: 92289
Summary: Worse "control reaches end of non-void function"
diagnostic with undefined sanitizer
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92231
--- Comment #2 from Jakub Jelinek ---
Created attachment 47131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47131&action=edit
gcc10-pr92231.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92288
Bug ID: 92288
Summary: [10 Regression] 502.gcc_r ICE with -O3 -march=skylake
-fno-checking since r277621
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92288
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79274
--- Comment #2 from dave.anglin at bell dot net ---
On 2019-10-30 10:12 a.m., iains at gcc dot gnu.org wrote:
> when you say "Think this is a result of emutls." - you mean that hppa is also
> (Darwin does) using emuTLS?
hppa uses emutls on hpux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92287
Bug ID: 92287
Summary: Mismatches in the calling convention for zero sized
types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 92275, which changed state.
Bug 92275 Summary: [10 Regression] ICE: error: definition in block 11 does not
dominate use in block 15 since r277566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92275
What|Rem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92275
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92278
--- Comment #5 from Martin Jambor ---
See https://gcc.gnu.org/ml/gcc-patches/2019-10/msg02139.html for a possible
fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89346
Peter Cordes changed:
What|Removed |Added
CC||peter at cordes dot ca
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79274
Iain Sandoe changed:
What|Removed |Added
Target|hppa2.0w-hp-hpux11.11 |hppa2.0w-hp-hpux11.11,*-*-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92283
--- Comment #5 from Martin Liška ---
So the problematic file is results.f. If I use code from the previous revision
for the file, there is no miscomparison.
Now I'll bisect which loop is causing the miscompilation. Optimized dumps
differ quite s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92275
--- Comment #4 from Richard Biener ---
Author: rguenth
Date: Wed Oct 30 13:52:27 2019
New Revision: 277621
URL: https://gcc.gnu.org/viewcvs?rev=277621&root=gcc&view=rev
Log:
2019-10-30 Richard Biener
PR tree-optimization/92275
1 - 100 of 176 matches
Mail list logo
