https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99555
Tom de Vries changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d9f462fb372fb02da032cefd6b091d7582c425ae
commit r11-8230-gd9f462fb372fb02da032cefd6b091d7582c425ae
Author: Jakub Jelinek
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #3 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534
Paul Thomas changed:
What|Removed |Added
Assignee|pault at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
DB changed:
What|Removed |Added
CC||db0451 at gmail dot com
--- Comment #10 from DB --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100130
Bug ID: 100130
Summary: R section flag handling doesn't cope with intervening
decls
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100130
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2021-04-17
Ever confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99914
--- Comment #5 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:bda519596543e49f77914b5677693e86be5d01d0
commit r11-8234-gbda519596543e49f77914b5677693e86be5d01d0
Author: Iain Buclaw
Date: Tue Ap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100115
--- Comment #2 from Boris Kolpackov ---
> I'm trying to reduce the test case to something manageable but that can take
> many hours, even days.
Right. On our side we have spent hours, even days trying to suppress this
warning (both by rearrang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100131
Bug ID: 100131
Summary: [meta-bug] internal compiler error: in
hashtab_chk_error, at hash-table.c:137
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99227
--- Comment #3 from Alexander Lelyakin ---
During last two and a half weeks
3 bugs was closed:
99283 - in assert_definition
99284 - in key_mergeable
99427 - non-constant condition for static assertion
99246 ICE in write_location was reopened un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100131
Alexander Lelyakin changed:
What|Removed |Added
CC||alexander.lelyakin@googlema
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #18 from Jonny Grant ---
Hello Martin
It looks better.
May I ask, if the "implicitly generated copy assignment" and "copy constructor"
could be mentioned in the warning that they were implicitly generated?
Thank you, Jonny
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971
David Stone changed:
What|Removed |Added
CC||davidfromonline at gmail dot
com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100114
--- Comment #6 from Jakub Jelinek ---
Fixed on the trunk so far, guess some backporting will be useful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95034
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100124
Martin Sebor changed:
What|Removed |Added
Blocks||69698
--- Comment #5 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128
--- Comment #1 from Jonathan Wakely ---
(In reply to Travis Downs from comment #0)
> Evidently, the behavior and definitions exposed by these headers should not
> depend on the order of include. I suspect there are other cases besides the
> __NO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95364
Andrew Pinski changed:
What|Removed |Added
Severity|normal |trivial
Summary|[Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100128
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Glibc should probably act as though __NO_CTYPE is implicitly defined by
> __cplusplus, so that the effect is independent of the order of includes.
Or it sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100062
--- Comment #2 from Iain Buclaw ---
(In reply to Richard Biener from comment #1)
> Since you say this happens on a DSO level why is this not achieved via some
> additional object at link-time (like crt*.o)? It sounds like you place
> the CDTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88175
--- Comment #19 from Jonathan Wakely ---
Why is that needed? It says the location is something like:
In member function ‘info& info::operator=(const info&)’,
or:
In copy constructor ‘info::info(const info&)’,
If that isn't explicitly defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95763
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95816
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-04-17
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100115
--- Comment #3 from Martin Sebor ---
The reason why the warning tends to disappear in a simpler test case is because
of the limit (I just had it happen with my reduction). Don't spend more time
on it than you already have, I'll work with the at
mpiling with -O1 or -O2, curiously not with
-O3 unless -fcheck=recursion is used
Seen on:
GNU Fortran (GCC) 11.0.1 20210417 (experimental)
GNU Fortran (GCC) 10.3.1 20210417
GNU Fortran (GCC) 9.3.1 20210417
Thank you very much.
Best regards,
José Rui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132
--- Comment #1 from José Rui Faustino de Sousa ---
Patch posted
https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #11 from YunQiang Su ---
This problem will happen when gcc is configured with
--with-build-config=bootstrap-lto-lean
Option.
28 matches
Mail list logo
