https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #8 from James Clarke ---
Created attachment 42719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42719&action=edit
Reduced reproduction.
This is a reduced version of the original reproduction. Creduce will happily
make it even
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83076
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83164
--- Comment #4 from Gerald Pfeifer ---
(In reply to Marc Glisse from comment #2)
> Does it work if you remove the verification
>
> || !types_compatible_p (rhs1_type, rhs2_type)
>
> from tree-cfg.c?
Yes, I just tried this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #9 from Segher Boessenkool ---
What flags does it need? I can't get it to fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #10 from James Clarke ---
(In reply to Segher Boessenkool from comment #9)
> What flags does it need? I can't get it to fail.
Just -O2 -fPIC, at least with 7.2.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #11 from Oleg Endo ---
(In reply to James Clarke from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > What flags does it need? I can't get it to fail.
>
> Just -O2 -fPIC, at least with 7.2.0.
That is, if your de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
--- Comment #12 from Segher Boessenkool ---
Yes I use sh4-linux, but trunk (not 7). Will try 7 later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83152
--- Comment #3 from Dominique d'Humieres ---
> By my count, you are off by one character in one of your field widths.
> Add a space at the end of the lines in the input file or change format to
>
>person_format='(a,2x,i3,2x,f4.2,1x,f3.0)'
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83153
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83152
--- Comment #4 from Dominique d'Humieres ---
*** Bug 83153 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83145
--- Comment #3 from Luboš Luňák ---
You are right, it is controlled by the -fnew-ttp-matching option. But while I
admit I have a problem deciphering what the referenced paper says in practice
or how it exactly applies to this case, this still loo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83167
Bug ID: 83167
Summary: decltype((x)) inside lambda is considered odr-use if x
is not a reference
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66672
Lukas changed:
What|Removed |Added
CC||deaeod at gmail dot com
--- Comment #2 from Luka
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021
--- Comment #9 from Jürgen Reuter ---
Does the reproducer in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83042
maybe help to fix this bug? At the moment our usage of the gcc trunk is frozen
as we cannot work around the many cases where it occurs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83042
--- Comment #7 from Paul Thomas ---
Created attachment 42721
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42721&action=edit
A fix for this PR and PR83021
A fix for this PR
This fixes the problem and boostraps/regtests OK.
Paul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83160
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83076
--- Comment #4 from Paul Thomas ---
(In reply to Paul Thomas from comment #3)
> Yes, indeed it was the main part of my patch. I cannot see at the moment,
> though, why forcing the creation of a vtable is having this effect on caf in
> deallocate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83076
--- Comment #5 from Dominique d'Humieres ---
> Hence, I would say that it is a pre-existing problem that has been exposed
> by the fix for r254427 and is not really a regression.
Still a regression [78 Regression], likely caused by r243021.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83154
Dominique d'Humieres changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168
Bug ID: 83168
Summary: FAIL: gfortran.dg/fmt_f0_2.f90 with a sanitized
libgfortran
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168
--- Comment #2 from Andreas Schwab ---
The first byte just outside the valid range.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168
--- Comment #3 from Jerry DeLisle ---
Thanks,
Try this fix:
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index c9aad150..d26358c0 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -1552,7 +1552,7 @@ select_stri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
Bug ID: 83169
Summary: Optimizer doesn't correctly handle NRVO if
-fno-inline-small-functions or function uninlinable
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #1 from Andrew Pinski ---
This code is all undefined so what do you expect?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #2 from Iain Buclaw ---
A little bit of consistency?
This was found in another language where NRVO is consistency expected to
happen. Having a quick look at bug 58055, seems to suggest that front-end
should generate better codegen i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38153
Volker Reichelt changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83170
Bug ID: 83170
Summary: ice in verify_use with -O3
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83170
--- Comment #1 from David Binderman ---
Reduced C++ code seems to be:
int a;
enum bk { bm };
enum bn { bo };
enum { bp, bq, br, bs };
class d {
public:
d();
char b;
void bv(char, bn);
char bw[];
};
d::d() { bv(b, bo); }
short c;
void d:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83171
Bug ID: 83171
Summary: std::bitset::count not inlining __popcountdi2
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81985
--- Comment #2 from Dominique d'Humieres ---
Along the same line mvbits_2.f90 gives
../../../p_work/libgfortran/intrinsics/mvbits.c:48:30: runtime error: left
shift of negative value -1
../../../p_work/libgfortran/intrinsics/mvbits.c:48:30: runt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83171
Andrew Pinski changed:
What|Removed |Added
Target|x86_64-linux-gnu|
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83171
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #4 from Iain Buclaw ---
(In reply to Jakub Jelinek from comment #3)
> NRVO in the middle-end is solely an optimization. If some FE requires
> something above that, then it needs to do it itself, C++ is an example of a
> FE that does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #5 from Andrew Pinski ---
(In reply to Iain Buclaw from comment #4)
> The generated code sets the address of the constructed variable the same the
> as the return address, yet the condition is assumed false by the optimizer.
data is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83169
--- Comment #6 from Iain Buclaw ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Iain Buclaw from comment #4)
> > The generated code sets the address of the constructed variable the same the
> > as the return address, yet the condit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83172
Bug ID: 83172
Summary: -Wstack-size= doesn't detect the correct stack size
with VLA or alloca
Product: gcc
Version: 4.8.5
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83173
Bug ID: 83173
Summary: C preprocessor generates incorrect linemarkers
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83174
Bug ID: 83174
Summary: -Wvla-larger-than reports wrong VLA size in some cases
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82488
--- Comment #3 from Markus Trippelsdorf ---
Author: trippels
Date: Mon Nov 27 05:20:43 2017
New Revision: 255159
URL: https://gcc.gnu.org/viewcvs?rev=255159&root=gcc&view=rev
Log:
Fix PR82488 - signed integer overflow in expr.c
bootstrap-ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82488
Markus Trippelsdorf changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82488
Markus Trippelsdorf changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175
Bug ID: 83175
Summary: compiler optimizing the code corresponding to double
precision operations
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175
--- Comment #1 from Andrew Pinski ---
Try -fno-strict-aliasing as it looks like the code is violating C/C++ aliasing
rules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81616
--- Comment #12 from Andrew Roberts ---
Ok I've tried again with this weeks snapshot:
gcc version 8.0.0 20171126 (experimental) (GCC)
Taking combination of -march and -mtune which works well on Ryzen:
/usr/local/gcc/bin/gcc -march=core-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175
--- Comment #2 from Sumit ---
(In reply to Andrew Pinski from comment #1)
> Try -fno-strict-aliasing as it looks like the code is violating C/C++
> aliasing rules.
Thanks for the quick response. I am trying that and will let you know.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175
--- Comment #3 from Sumit ---
(In reply to Andrew Pinski from comment #1)
> Try -fno-strict-aliasing as it looks like the code is violating C/C++
> aliasing rules.
Hi Andrew,
It does not have any effect. Still the same problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83175
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83064
--- Comment #14 from Christian Felter ---
I looked into the working draft of Fortran 2015 (J3/16-007r1). In Note 12.52 it
says:
The above constraints are designed to guarantee that a pure procedure is free
from side effects (modifications of dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83168
--- Comment #4 from Dominique d'Humieres ---
> Try this fix:
> ...
It works! Thanks.
en_error()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/graphite-isl-ast-to-gimple.c:205
0x7e403c translate_isl_ast_to_gimple::set_codegen_error()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20171126/work/gcc-8-20171126/gcc/tree.h:3216
0
53 matches
Mail list logo