https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
Neil Carlson changed:
What|Removed |Added
CC||neil.n.carlson at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100
--- Comment #7 from James Clarke ---
(In reply to Jakub Jelinek from comment #4)
> That change looks wrong to me.
> Previously the variable was common and thus if you e.g. mixed it with some
> other TU that has const int a = 5; then you could lin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81304
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 24 21:40:21 2017
New Revision: 255144
URL: https://gcc.gnu.org/viewcvs?rev=255144&root=gcc&view=rev
Log:
PR fortran/81304
* trans-openmp.c (gfc_trans_omp_array_red
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79392
Giulio Paci changed:
What|Removed |Added
CC||giuliopaci at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #23 from Marc Glisse ---
(In reply to Harald Anlauf from comment #3)
> subroutine gfcbug138 (yerrmsg)
> character(kind=1,len=*) :: yerrmsg
> yerrmsg = 1_"bug: " // yerrmsg
> end subroutine gfcbug138
[...]
> gfcbug138 (character(ki
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81304
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.0 |6.5
Summary|[6/7/8 Regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #24 from Dominique d'Humieres ---
The following variant does not give the warning
subroutine gfcbug138 (yerrmsg)
character(kind=1,len=*) :: yerrmsg
character(kind=1,len=len(yerrmsg)+5) :: tmp
tmp = 1_"bug: " // yerrmsg
yerrms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #25 from Marc Glisse ---
(In reply to Dominique d'Humieres from comment #24)
> The following variant does not give the warning
That's because the code has become obfuscated enough that we don't have the
simplification l-(l+5) anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
--- Comment #26 from Dominique d'Humieres ---
Another variant without warning:
subroutine gfcbug138 (yerrmsg)
character(kind=1,len=*) :: yerrmsg
yerrmsg = 1_"bug: " // yerrmsg(1:len(yerrmsg)-5)
end subroutine gfcbug138
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
Bug ID: 83149
Summary: ICE on SELECT CASE: crash_signal in toplev.c:325
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83143
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
Bug ID: 83150
Summary: GCC's internal use of `abort`is unsafe in several ways
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #1 from Andrew Pinski ---
>2. if the real `abort` is used, GCC installs a signal handler, which calls
>async-signal-unsafe functions, such as malloc.
The signal handler will always be sync unless someone decides to do a kill from
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #3 from Ben Longbons ---
(In reply to Andrew Pinski from comment #1)
> The signal handler will always be sync unless someone decides to do a kill
> from the command line.
You're assuming that no library ever calls abort(). Glibc cert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #2 from Neil Carlson ---
Here's another example. The ICE is coming at the same place, toplev.c:325, so
I think it may be the same underlying problem. Like the original example, the
ICE occurs only when the main program is in a separ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
--- Comment #3 from Neil Carlson ---
Unlike comment 0 code, comment 2 code also gives an ICE with 7.2.1 and 6.4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83150
--- Comment #4 from Segher Boessenkool ---
(In reply to Ben Longbons from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > Plugins are not well defined in GCC.
>
> That excuse is getting *really* old.
No matter how often you hear
101 - 121 of 121 matches
Mail list logo
