https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78179
sandra at gcc dot gnu.org changed:
What|Removed |Added
CC||sandra at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87161
Bug ID: 87161
Summary: if -Werror appear after -Wmissing-prototypes the
warning is not turn into error
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86134
--- Comment #11 from Pádraig Brady ---
I agree that -Wno-... should never be promoted to an error as we see with:
$ echo 'int maint(){}' | gcc -S -x c -Wno-unknown-warning-option -Wall -Werror
-Wextra -Wno-error=return-type -
: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87125
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #2 from Jan Hubicka ---
Indeed, having -fdump-tree-vect-details-blocks dump would probably make it easy
to figure out what happens.
What is configuration tripplet and exact invocation line for the test?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87158
Martin Sebor changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87159
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87158
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Thu Aug 30 21:25:10 2018
New Revision: 264000
URL: https://gcc.gnu.org/viewcvs?rev=264000=gcc=rev
Log:
PR testsuite/87158 - FAIL gcc.c-torture/execute/memchr-1.c on big endian
targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87158
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87141
--- Comment #3 from martin ---
Created attachment 44633
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44633=edit
config.log of root gcc dir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87160
Bug ID: 87160
Summary: Maybe miscompilation of a polyhedron test
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52034
Marc Glisse changed:
What|Removed |Added
Last reconfirmed|2012-01-29 00:00:00 |2018-8-30
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
--- Comment #1 from Bill Schmidt ---
I doubt the test cases need updating. Looks like this change had a surprising
side of effect of breaking vectorization for this test on Power, which needs to
be understood and fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87159
Bug ID: 87159
Summary: [9 regression] new test
gcc.c-torture/execute/memchr-1.c fails starting with
introduction in r263963
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85357
--- Comment #7 from janus at gcc dot gnu.org ---
Further reduced test case for the ICE:
module base
implicit none
contains
subroutine summation(i)
integer, intent(in) :: i
end subroutine
end module
module extended
use base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86007
--- Comment #3 from Ștefan Talpalaru ---
The problem persists in 8.2.0 and in current trunk. You need to run that
command a hundred of times or so, on a Piledriver, to replicate it:
for i in `seq 1 100`; do gcc -S t.c -march=native -v 2>&1 |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87152
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87158
Martin Sebor changed:
What|Removed |Added
Target||powerpc64-linux
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87152
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87158
Bug ID: 87158
Summary: FAIL gcc.c-torture/execute/memchr-1.c on big endian
targets
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87157
Bug ID: 87157
Summary: [9 regression]
gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c fails
starting with r263981
Product: gcc
Version: 9.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87156
Bug ID: 87156
Summary: [9 Regression] ICE building libstdc++ for mips64
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87152
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84707
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
--- Comment #8 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84707
Nathan Sidwell changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148
--- Comment #4 from Martin Sebor ---
The decision to reject the code in comment #0 was deliberate (as Jonathan
explained in comment #2). We wanted (and still do) G++ to enforce rules that
are at least as strict as C's (and GCC's in C mode).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87103
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
--- Comment #8 from Jan Hubicka ---
Author: hubicka
Date: Thu Aug 30 15:50:39 2018
New Revision: 263988
URL: https://gcc.gnu.org/viewcvs?rev=263988=gcc=rev
Log:
PR lto/86517
* lto-opts.c (lto_write_options): Always stream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #7 from Segher Boessenkool ---
There are three things going wrong:
1) You configure without having an assembler available. This will disable
various features in your compiler. The same happens on e.g. the x86 port.
2) We allow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37158
H.J. Lu changed:
What|Removed |Added
Target Milestone|--- |8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
--- Comment #47 from qinzhao at gcc dot gnu.org ---
all the issues triggered by the previous patch have been fixed.
I am planing to close this PR as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86519
--- Comment #21 from qinzhao at gcc dot gnu.org ---
the latest patch to this test bug has just been checked in at:
https://gcc.gnu.org/viewcvs/gcc?view=revision=263983
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87141
--- Comment #2 from martin ---
>Can you even execute a simple hello world you compile yourself?
Yes (using /opt/gcc-7.3/bin/gcc).
>here (x86_64-linux) 126 is ENOKEY. Looks like somehow your platform requires
signed executables?
No, I already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87146
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87154
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104
--- Comment #12 from pipcet at gmail dot com ---
(In reply to pipcet from comment #11)
> (insn 7 6 8 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (and:DI (not:DI (reg/v:DI 86 [ i ]))
> (const_int 12 [0xc]))
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #6 from Jakub Jelinek ---
Perhaps that
if (conv->kind == ck_rvalue)
conv = next_conversion (conv);
shouldn't be done if (flags & LOOKUP_PREFER_RVALUE) or if
conv->rvaluedness_matches_p? Just a wild guess though, that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
--- Comment #4 from Jonathan Wakely ---
Yes but it would conflict with n1::n2::bob because n2 is an inline namespace.
It seems like the diagnostic is misleading, it suggests n1::bob conflicts with
itself, but actually it conflicts with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
--- Comment #3 from Artem Yurchenko ---
(In reply to Nathan Sidwell from comment #2)
> Hm, while I understand the intent here, I wonder if clang is succeeding by
> accident? The std is not completely clear whether all anonymous namespaces
> may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #5 from Jakub Jelinek ---
r251035 clearly has code that handles that rule:
+
+ if (flags & LOOKUP_PREFER_RVALUE)
+ {
+ /* The implicit move specified in 15.8.3/3 fails "...if the type of
+the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #4 from Jonathan Wakely ---
Right. CWG 1579 says we should move here:
struct A { };
struct B { B(A&&) { } };
B f() { A a; return a; }
That's a different case though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87135
--- Comment #1 from Jonathan Wakely ---
This changed with https://wg21.link/lwg2156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #6 from Segher Boessenkool ---
So, so far I have only reproduced it if I configure the compiler for
ppc64le-linux
(not powerpc64le-linux), _and_ I have no working assembler for that. Is that
your situation, too?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87135
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
--- Comment #3 from Stephan Bergmann ---
(In reply to Jakub Jelinek from comment #2)
> This changed with r251035 aka PR80452 aka C++ Core issue 1579.
> So, is this really invalid?
but CWG1579 didn't change the "if the type of the first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87147
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87147
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Thu Aug 30 12:37:10 2018
New Revision: 263980
URL: https://gcc.gnu.org/viewcvs?rev=263980=gcc=rev
Log:
2018-08-30 Richard Biener
PR tree-optimization/87147
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
--- Comment #2 from Nathan Sidwell ---
Hm, while I understand the intent here, I wonder if clang is succeeding by
accident? The std is not completely clear whether all anonymous namespaces may
share the same unique identifier or not. We do,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #5 from Segher Boessenkool ---
So both -Q --help=target as well as -fverbose-asm say -mfprnd is on; but the
ICE is because TARGET_FPRND is _off_. What.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
Jonathan Wakely changed:
What|Removed |Added
CC||nathan at gcc dot gnu.org
Known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37158
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87155
Bug ID: 87155
Summary: unnamed namespace redeclaration error when inline
namespace is present
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #4 from Segher Boessenkool ---
I have reproduced it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87154
--- Comment #1 from Ögmundur Petersson ---
Created attachment 44630
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44630=edit
This file works fine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87154
Bug ID: 87154
Summary: Internal compiler error: in gimplify_expr, at
gimplify.c:12215
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37158
Artem Alimarin changed:
What|Removed |Added
CC||artem.alimarin at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83877
--- Comment #3 from Marco Castelluccio ---
The problem we have is that there's a directory containing gcno files and
multiple directories containing gcda files (one for each test suite execution).
gcov expects the gcda and gcno files to be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86536
--- Comment #4 from Marco Castelluccio ---
Sorry for the delay, it sounds fine to me, I can't think of anything better
than that!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87153
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic, ra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84980
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87153
Bug ID: 87153
Summary: Confusing / Incorrect clobber warning with ISRA /
-Wclobber
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
--- Comment #2 from Jonathan Wakely ---
Ah, the regression started with the same revision as the ICE, r241425 (applying
the fix from r257311 to that revision fixes the ICE but gives the "taking the
address of temporary" error).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86995
vladlazar at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455
Dominique d'Humieres changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133
--- Comment #9 from Segher Boessenkool ---
It's a different symptom, but sure, might be related. Somehow your toolchain
thinks it is a newer ISA but not compliant to older ISAs :-/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #3 from Segher Boessenkool ---
That one works fine on both native and cross for me, too.
Please describe your config better? binutils version, libc version, exact
configure command, to start with?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148
--- Comment #3 from Jonathan Wakely ---
See PR 68478 in particular for the change requiring a complete type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86995
--- Comment #7 from vladlazar at gcc dot gnu.org ---
Author: vladlazar
Date: Thu Aug 30 09:30:49 2018
New Revision: 263973
URL: https://gcc.gnu.org/viewcvs?rev=263973=gcc=rev
Log:
Enable underflow check in canonicalize_comparison. (PR86995)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148
Jonathan Wakely changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87152
Bug ID: 87152
Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:15484
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #2 from Martin Liška ---
But ICEs with:
$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90
-c -mno-fprnd
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/nint_2.f90:52:0:
52 | end
|
Error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
--- Comment #1 from Martin Liška ---
Native compiler works fine however.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87133
--- Comment #8 from Martin Liška ---
Same happens for:
./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/do_check_3.f90
#0 lookup_handler (scode=1122058) at insn-opinit.c:1156
#1 0x032f34de in raw_optab_handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87147
--- Comment #2 from Richard Biener ---
OK, so the issue is that while non-iterating RPO VN assumes executable
backedges it fails to mark destination blocks as executable.
Testing fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151
Bug ID: 87151
Summary: allocating array of character
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87150
Bug ID: 87150
Summary: move ctor wrongly chosen in return stmt (derived vs.
base)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87147
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Summary|GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87146
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87145
Richard Biener changed:
What|Removed |Added
Known to work||6.3.0
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87149
Bug ID: 87149
Summary: ICE in extract_insn, at recog.c:2305 on ppc64le
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #5 from rguenther at suse dot de ---
On Thu, 30 Aug 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
>
> --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87147
Martin Liška changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87141
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87148
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Richard Biener ---
> You also might want to test the patch from PR87132.
I had it in my tree already last night. I've now retried the exact same
tree without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87136
--- Comment #3 from Darko Veberic ---
i will, soon. the delta is still running. unfortunately, the .ii file had 100k
lines...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87134
--- Comment #2 from Richard Biener ---
You also might want to test the patch from PR87132.
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Richard Biener ---
> If you disable bootstrap does it work? The
96 matches
Mail list logo
