[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #13 from eggert at cs dot ucla.edu ---
(In reply to Jakub Jelinek from comment #10)
> I don't understand that. You had:
> ((CONSP (Vframe_list)) ? (void) 0 : __builtin_unreachable ());
> for ((tail) = Vframe_list; (CONSP (tail) && (frame1 = XCAR (tail), 1));
> tail = XCDR (tail))
> body...;
> so, the assertion is testing what the CONSP will test on the first iteration.
> So, if Qnil fails CONSP test, then it would fail the assertion, if it
> doesn't, then the first iteration is done unconditionally.
You're right, and sorry about the confusion; I didn't read your earlier message
correctly.
However, the solution that you propose won't work well for Emacs, because the
code is packaged up in this macro:
#define FOR_EACH_FRAME(list_var, frame_var) \
for ((list_var) = Vframe_list;\
(CONSP (list_var)\
&& (frame_var = XCAR (list_var), true)); \
list_var = XCDR (list_var))
where the macro call is the head of a for-loop, like this:
FOR_EACH_FRAME (tail, f)
{
if (EQ (frame, f) && !NILP (prev))
return prev;
f = candidate_frame (f, frame, minibuf);
if (!NILP (f))
prev = f;
}
Although I could replace the macro with its definiens and then rewrite that as
you suggest, the result would be quite a bit harder to follow; and I can't
rewrite FOR_EACH_FRAME to use a while loop preceded by some other stuff, as
that would break the expectation of the macro caller that 'FOR_EACH_FRAME (x,
y) STMT' is a single C statement.
[Bug target/89165] miscompile calling SSE function from non-SSE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89165
--- Comment #2 from Andrew Pinski ---
This is warned about:
t.c: In function ‘g’:
t.c:7:1: warning: SSE vector return without SSE enabled changes the ABI
[-Wpsabi]
7 | simd4f g(simd4f a,simd4f b) {return f(a)+f(b);}
| ^~
t.c:7:8: note: The ABI for passing parameters with 16-byte alignment has
changed in GCC 4.6
7 | simd4f g(simd4f a,simd4f b) {return f(a)+f(b);}
|^
t.c:7:8: warning: SSE vector argument without SSE enabled changes the ABI
[-Wpsabi]
[Bug target/89165] miscompile calling SSE function from non-SSE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89165 Andrew Pinski changed: What|Removed |Added Component|c |target --- Comment #1 from Andrew Pinski --- This should have been rejected or warned about being undefined. Target issue.
[Bug c/89165] New: miscompile calling SSE function from non-SSE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89165
Bug ID: 89165
Summary: miscompile calling SSE function from non-SSE code
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: nbkolchin at gmail dot com
Target Milestone: ---
BUG: calling SSE function with vector argument
from non-SSE code (admittedly, Bad Idea) silently
miscompiles (breaking calling convention).
I would appreciate an error message instead.
https://godbolt.org/z/pIpM95
GCC Version: 8.2
Command line arguments: -m32 -mno-sse -O2
Source code:
typedef float __attribute__((vector_size(16))) simd4f;
__attribute__((target("sse2")))
simd4f f(simd4f a) {return a*a;}
simd4f g(simd4f a,simd4f b) {return f(a)+f(b);}
Generated assembler:
f(float __vector(4)):
mulps %xmm0, %xmm0
ret
g(float __vector(4), float __vector(4)):
subl$76, %esp
movl80(%esp), %eax
leal16(%esp), %edx
pushl 108(%esp)
pushl 108(%esp)
pushl 108(%esp)
pushl 108(%esp)
subl$12, %esp
pushl %edx
callf(float __vector(4))
leal60(%esp), %edx
addl$28, %esp
pushl 124(%esp)
pushl 124(%esp)
pushl 124(%esp)
pushl 124(%esp)
subl$12, %esp
pushl %edx
callf(float __vector(4))
flds44(%esp)
fadds 60(%esp)
fstps 28(%esp)
flds48(%esp)
fadds 64(%esp)
movl28(%esp), %edx
fstps 32(%esp)
flds52(%esp)
fadds 68(%esp)
fstps 36(%esp)
flds56(%esp)
fadds 72(%esp)
fstps 40(%esp)
movl%edx, (%eax)
movl32(%esp), %edx
movl%edx, 4(%eax)
movl36(%esp), %edx
movl%edx, 8(%eax)
movl40(%esp), %edx
movl%edx, 12(%eax)
addl$104, %esp
ret $4
P.S. Originally found here
https://gamedev.ru/code/forum/?id=233033=24#m356
[Bug tree-optimization/81679] use attribute unused on function arguments as an optimization hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81679 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-03 Ever confirmed|0 |1 --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to jos...@codesourcery.com from comment #4) > > On Wed, 2 Aug 2017, msebor at gcc dot gnu.org wrote: > > > > > If there is a concern that the attribute could be used on declarations in > > > existing code that the optimization might break, then the attribute could > > > be > > > specified differently (e.g., as a function attribute with an argument > > > number > > > indicating which argument is unused; that would also differentiate it from > > > the existing function attribute). Or the same feature could be provided > > > under a different attribute. The main idea here is the ability to express > > > the notion that a function doesn't modify an object via its (non-const) > > > pointer argument. The name for the feature is secondary (though "unused" > > > is obviously a nice fit). > > > > The "unused" attribute always means "possibly unused, don't warn if > > actually unused". It would be a mistake to make it mean anything else. > > ...so close this as WONTFIX then? WAITING on a reply
[Bug libfortran/35844] Overwriting the -std= option at runtime via environment variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35844 Jerry DeLisle changed: What|Removed |Added Status|WAITING |RESOLVED CC||jvdelisle at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Jerry DeLisle --- To answer the last question, about nine years.
[Bug libstdc++/89164] New: can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164
Bug ID: 89164
Summary: can construct vector with
non-copyable-but-trivially-copyable elements
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider (from https://stackoverflow.com/q/54498610/2069064):
#include
struct X {
X() = default;
X(const X&) = delete;
};
std::vector v{X{}};
X is trivially copyable, but it isn't actually copy constructible... as a
result X isn't Cpp17EmplaceConstructible into std::vector right? libstdc++
just emits a memmove anyway.
libc++ rejects this.
[Bug target/89112] Incorrect code generated by rs6000 memcmp expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89112 --- Comment #6 from Segher Boessenkool --- The patch in #c5 is pre-approved everywhere. Thanks! #c4... Do you *want* to keep it together? Is it in fact cold? If it is not, maybe you can improve the execution estimate for it?
[Bug tree-optimization/89154] 5% degradation of CPU2006 473.astar starting with r266305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154 --- Comment #1 from Segher Boessenkool --- The new version needs to save r4 because it reuses the reg for storing r7+r8. And we still don't wrap CR separately, sigh.
[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625 --- Comment #6 from Neil Carlson --- Yes, can this please be back-ported? Still broken on at least 8.
[Bug fortran/64962] Use "nonnull"/"returns_nonnull" attribute annotation for procedures (user code + libgfortran)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64962 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/64973] Duplicate use-statements could be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64973 Dominique d'Humieres changed: What|Removed |Added Priority|P4 |P5
[Bug fortran/31592] Better message if using non-intrinsic initialization expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31592 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/55179] Optionally warn when use-associating a module with no (public) symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55179 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/55534] -Wno-missing-include-dirs does not work with gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55534 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5
[Bug fortran/85130] Substrings out of range are not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85130 Dominique d'Humieres changed: What|Removed |Added Priority|P4 |P5
[Bug libfortran/35844] Overwriting the -std= option at runtime via environment variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35844 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5
[Bug fortran/42118] Slow forall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/69485] oddity with -Wtabs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69485 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Dominique d'Humieres --- The behavior of repeated -ffpe-trap and -ffpe-summary is now documented, closing as WONTFIX.
[Bug fortran/89078] [meta-bug] Improve the gfortran manual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89078 Bug 89078 depends on bug 81344, which changed state. Bug 81344 Summary: Can't disable -ffpe-trap (or not documented) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug fortran/81344] Can't disable -ffpe-trap (or not documented)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81344 --- Comment #5 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Sat Feb 2 21:44:34 2019 New Revision: 268480 URL: https://gcc.gnu.org/viewcvs?rev=268480=gcc=rev Log: 2019-02-02 Dominique d'Humieres PR fortran/81344 * invoke.texi: Document the behavior of repeated -ffpe-trap and -ffpe-summary. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/invoke.texi
[Bug c/89163] New: Missed optimization: sar and shr equivalent for non-negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163
Bug ID: 89163
Summary: Missed optimization: sar and shr equivalent for
non-negative numbers
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tspiteri at ieee dot org
Target Milestone: ---
For the minimized test case below, shift is equivalent to same_as, because shr
and sar are equivalent for non-negative numbers. The generated code is not the
same.
int shift(int i) {
return i >= 0 ? (unsigned)i >> 8 : i >> 8;
}
int same_as(int i) {
return i >> 8;
}
shift:
movl%edi, %edx
movl%edi, %eax
shrl$8, %edx
sarl$8, %eax
testl %edi, %edi
cmovns %edx, %eax
ret
same_as:
movl%edi, %eax
sarl$8, %eax
ret
[Bug go/89162] libgo build is broken on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89162 --- Comment #2 from Segher Boessenkool --- Ha, my last build was r268452 :-) Thanks for the fix, and sorry for the noise.
[Bug go/89162] libgo build is broken on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89162 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Andreas Schwab --- Fixed by r268458.
[Bug go/89162] New: libgo build is broken on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89162 Bug ID: 89162 Summary: libgo build is broken on powerpc64-linux Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: go Assignee: ian at airs dot com Reporter: segher at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- libtool: compile: /home/segher/build/tot-master/./gcc/xgcc -B/home/segher/build/tot-master/./gcc/ -B/home/segher/tot/powerpc64-unknown-linux-gnu/bin/ -B/home/segher/tot/powerpc64-unknown-linux-gnu/lib/ -isystem /home/segher/tot/powerpc64-unknown-linux-gnu/include -isystem /home/segher/tot/powerpc64-unknown-linux-gnu/sys-include -m32 -DHAVE_CONFIG_H -I. -I/home/segher/src/gcc/libgo -I /home/segher/src/gcc/libgo/runtime -I/home/segher/src/gcc/libgo/../libffi/include -I../libffi/include -pthread -L../libatomic/.libs -fexceptions -fnon-call-exceptions -Wall -Wextra -Wwrite-strings -Wcast-qual -Werror -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I /home/segher/src/gcc/libgo/../libgcc -I /home/segher/src/gcc/libgo/../libbacktrace -I ../../../gcc/include -g -O2 -m32 -MT runtime/thread.lo -MD -MP -MF runtime/.deps/thread.Tpo -c /home/segher/src/gcc/libgo/runtime/thread.c -fPIC -DPIC -o runtime/.libs/thread.o /home/segher/src/gcc/libgo/runtime/thread.c:56:1: error: mismatch in argument 1 type of built-in function '__sync_bool_compare_and_swap_8'; expected 'volatile void *' [-Werror=builtin-declaration-mismatch] 56 | __sync_bool_compare_and_swap_8 (uint64*, uint64, uint64) | ^~ /home/segher/src/gcc/libgo/runtime/thread.c:113:1: error: mismatch in argument 1 type of built-in function '__sync_add_and_fetch_8'; expected 'volatile void *' [-Werror=builtin-declaration-mismatch] 113 | __sync_add_and_fetch_8 (uint64*, uint64) | ^~
[Bug go/89162] libgo build is broken on powerpc64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89162 Segher Boessenkool changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |9.0
[Bug c++/89160] -Wattributes too eager on C++11 attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89160 --- Comment #2 from Marc Glisse --- Thanks, yes, that's an exact duplicate that I failed to find despite several searches in bugzilla :-(
[Bug c/89161] Bogus -Wformat-overflow warning with value range known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89161
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-02
CC||msebor at gcc dot gnu.org
Blocks||85741
Ever confirmed|0 |1
Known to fail||7.3.0, 8.2.0, 9.0
--- Comment #1 from Martin Sebor ---
I can confirm the warning and agree that GCC could in theory figure out that
the result is between 0 and 9 but it currently doesn't do that. With the
optimization implemented the warning would go away.
Note that there are limitations as how far GCC can go in determining the values
or ranges of non-constant expressions, and warnings that rely on these
abilities (i.e., flow-based warnings) are unavoidably imprecise. This is
documented in the manual which says about -Wformat-overflow:
Warn about calls to formatted input/output functions such as sprintf and
vsprintf that might overflow the destination buffer. When the exact number of
bytes written by a format directive cannot be determined at compile-time it is
estimated based on heuristics that depend on the level argument and on
optimization.
A test case for the missing optimization is:
void f (unsigned short a, unsigned short b)
{
if (a && a < b)
{
int x = (10 * a) / b;
if (x < 0 || 9 < x)
__builtin_abort ();
}
}
Compiling it with the -fdump-tree-vrp=/dev/stdout option shows that range in
which x is computed to be by VRP is:
x_10: int [0, 655350]
...
[local count: 536870913]:
_4 = (int) a_8(D);
_5 = _4 * 10;
_6 = (int) b_9(D);
x_10 = _5 / _6;
if (x_10 > 9)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
[Bug 85741] [meta-bug] bogus/missing -Wformat-overflow
[Bug fortran/78398] missing warnings and inconsistencies with -Wuninitialized (Fortran)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78398 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/64066] [F08] Wrongly accepts ; (semicolon) at ending a null token
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64066 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/59065] questionable bounds for unassociated allocatable/pointer arrays?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59065 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5
[Bug fortran/57360] Implement a warning for implied save
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57360 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5
[Bug c++/86368] an unknown [[attribute]] should not trigger a warning in C++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368 Martin Sebor changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #6 from Martin Sebor --- *** Bug 89160 has been marked as a duplicate of this bug. ***
[Bug c++/89160] -Wattributes too eager on C++11 attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89160 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Martin Sebor --- I think this can be considered a duplicate of bug 86368, even though that bug talks specifically about C++ 17 and this one about all C++ attributes. *** This bug has been marked as a duplicate of bug 86368 ***
[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60144 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Dominique d'Humieres --- > Error messages: > -- > if.F90:2.15: > > if (.TRUE.) >1 > Error: Cannot assign to a named constant at (1) > if.F90:3.11: > > else if (.FALSE.) >1 > Error: Unexpected junk after ELSE statement at (1) > [...] > -- > > Both errors should read something like "Missing THEN after IF/ELSE IF". > > The first error message doesn't even make sense... % gfc dec_type_print_red.f90 dec_type_print_red.f90:20:11: 20 | if (b) type*,a(i) ! test TYPE as PRINT inside one-line IF | 1 Error: Cannot assign to a named constant at (1) (from gfortran.dg/dec_type_print.f90 compiled without the -fdec option). IMO replacing "Cannot assign to a named constant" with "Syntax error" will give an immediate clue of what is wrong. A longer alternative could be something such as ""Syntax error, missing or bad STATEMENT".
[Bug tree-optimization/43565] Missed address comparison folding of DECL_COMMONs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #11 from Marc Nieper-Wißkirchen ---
If ISO C allows such linkage to be created outside of the standard, a number of
other assumption would be violated as well:
In 6.2.4 (2) it says that "an object exists, has a constant address, and
retains its last-stored value throughout its lifetime."
Only "in the case of a volatile object, the last store need not be explicit in
the program" (footnote 34).
So what about making the external creation of linkage between two different
identifiers an error/undefined behavior if they are not declared volatile?
Firstly, not marking them volatile already already causes gcc to make wrong
assumptions (because it does not know about external aliasing):
extern int p;
extern int q;
int foo ()
{
p = 1;
q = 2;
return p;
}
This program compiles at "-O2" to:
foo:
movl$1, p(%rip)
movl$1, %eax
movl$2, q(%rip)
ret
Secondly, not marking them volatile would then allow the compiler to assume
that the addresses of p and q are different (because aliasing the two
identifiers would cause undefined behavior).
[Bug c/89161] New: Bogus -Wformat-overflow warning with value range known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89161
Bug ID: 89161
Summary: Bogus -Wformat-overflow warning with value range known
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
The following code
$ cat bogus1.c
#include
static char* print(const unsigned short a[2])
{
static char buf[3];
if (a[0] && a[0] < a[1])
sprintf(buf, ".%1u", (10 * a[0]) / a[1]);
else
*buf = '\0';
return buf;
}
unsigned short array[2];
int main()
{
printf("%s\n", print(array));
return 0;
}
produces a lot of noise when compiled optimized (no warning without):
$ gcc -Wall -O6 -c bogus1.c
bogus1.c: In function ‘main’:
bogus1.c:7:24: warning: ‘%1u’ directive writing between 1 and 10 bytes into a
region of size 2 [-Wformat-overflow=]
sprintf(buf, ".%1u", (10 * a[0]) / a[1]);
^~~
bogus1.c:7:22: note: directive argument in the range [0, 2147483647]
sprintf(buf, ".%1u", (10 * a[0]) / a[1]);
^~
bogus1.c:7:9: note: ‘sprintf’ output between 3 and 12 bytes into a destination
of size 3
sprintf(buf, ".%1u", (10 * a[0]) / a[1]);
^~~~
even though the compiler could have figured out that because of the "if", the
value range of the integer division expression is actually [0..9], which
perfectly fits into the buffer provided for the sprintf() statement.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.4.0 (GCC)
[Bug fortran/88298] [7/8/9 Regression] Bogus conversion warning for CSHIFT with -fno-range-check -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Thomas Koenig --- Fixed on all open branches, closing.
[Bug fortran/88298] [7/8/9 Regression] Bogus conversion warning for CSHIFT with -fno-range-check -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Sat Feb 2 17:07:40 2019 New Revision: 268479 URL: https://gcc.gnu.org/viewcvs?rev=268479=gcc=rev Log: 2019-02-02 Thomas Koenig PR fortran/88298 Backport from trunk * arith.c (gfc_int2int): Do not warn if src->do_not_warn is set. * gfortran.h (gfc_expr): Add flag do_not_warn. * intrinsic.c (gfc_convert_type_warn): Set expr->do_not_warn if no warning is desired. 2019-02-02 Thomas Koenig PR fortran/88298 Backport from trunk * gfortran.dg/warn_conversion_10.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/warn_conversion_10.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/arith.c branches/gcc-7-branch/gcc/fortran/gfortran.h branches/gcc-7-branch/gcc/fortran/intrinsic.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/32630] [meta-bug] ISO C binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32630 Bug 32630 depends on bug 57048, which changed state. Bug 57048 Summary: [7/8 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/57048] [7/8 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Thomas Koenig --- Fixed on all open branches, closing.
[Bug fortran/57048] [7/8 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Sat Feb 2 16:57:39 2019 New Revision: 268478 URL: https://gcc.gnu.org/viewcvs?rev=268478=gcc=rev Log: 2019-02-02 Thomas Koenig PR fortran/57048 Backport from trunk * interface.c (gfc_compare_types): If a derived type and an integer both have a derived type, and they are identical, this is a C binding type and compares equal. 2019-02-02 Thomas Koenig PR fortran/57048 Backport from trunk * gfortran.dg/c_funptr_1.f90: New file. * gfortran.dg/c_funptr_1_mod.f90: New file. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/c_funptr_1.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/c_funptr_1_mod.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/interface.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/89158] [8/9 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 --- Comment #3 from Marek Polacek --- When reference_binding creates the conversion const int -> const int & the expression is still VIEW_CONVERT_EXPR(Val) so it doesn't set conv->need_temporary_p. Only then do we call mark_rvalue_use which turns it into NON_LVALUE_EXPR<42>.
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #29 from Jerry DeLisle --- Even after getting the patch into gcc 7 I still get a failure in the test case. I suspect some other patch not previously applied to 7 is involved. I do not think this is worth pursuing further so I an closing.
[Bug fortran/88298] [7/8/9 Regression] Bogus conversion warning for CSHIFT with -fno-range-check -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Sat Feb 2 16:53:28 2019 New Revision: 268477 URL: https://gcc.gnu.org/viewcvs?rev=268477=gcc=rev Log: 2019-02-02 Thomas Koenig PR fortran/88298 Backport from trunk * arith.c (gfc_int2int): Do not warn if src->do_not_warn is set. * gfortran.h (gfc_expr): Add flag do_not_warn. * intrinsic.c (gfc_convert_type_warn): Set expr->do_not_warn if no warning is desired. 2019-02-02 Thomas Koenig PR fortran/88298 Backport from trunk * gfortran.dg/warn_conversion_10.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/warn_conversion_10.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/arith.c branches/gcc-8-branch/gcc/fortran/gfortran.h branches/gcc-8-branch/gcc/fortran/intrinsic.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/89160] New: -Wattributes too eager on C++11 attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89160 Bug ID: 89160 Summary: -Wattributes too eager on C++11 attributes Product: gcc Version: 8.2.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Target Milestone: --- A random testcase to illustrate: [[hahaha]] int i; $ g++-snapshot a.c -c -std=gnu++2a a.c:1:16: warning: 'hahaha' attribute directive ignored [-Wattributes] 1 | [[hahaha]] int i; |^ The standard, in [dcl.attr.grammar], says: "Any attribute-token that is not recognized by the implementation is ignored." I believe the intent is that it should be **silently** ignored, unless I really ask for it clearly with something like -Wunknown-c++-attribute (definitely not part of -Wall). There is a strong requirement that standard attributes have to be safe to ignore. I believe I should be able to use newer (C++20) attributes without having older (C++17) compilers complain so noisily. Sadly, clang is just as bad, and ISTR reading that visual studio was even worse, rejecting programs with C++17 attributes in C++14 mode. As a result, we keep having to write a lot of preprocessor nonsense :-(
[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139 --- Comment #4 from Marc Nieper-Wißkirchen --- P.S.: This issue showed up when I tried to analyze why no optimization is happening in bug #89152.
[Bug fortran/57048] [7/8 Regression] Handling of C_PTR and C_FUNPTR leads to reject valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57048 --- Comment #13 from Thomas Koenig --- Author: tkoenig Date: Sat Feb 2 16:35:47 2019 New Revision: 268476 URL: https://gcc.gnu.org/viewcvs?rev=268476=gcc=rev Log: 2019-02-02 Thomas Koenig PR fortran/57048 Backport from trunk * interface.c (gfc_compare_types): If a derived type and an integer both have a derived type, and they are identical, this is a C binding type and compares equal. 2019-02-02 Thomas Koenig PR fortran/57048 Backport from trunk * gfortran.dg/c_funptr_1.f90: New file. * gfortran.dg/c_funptr_1_mod.f90: New file. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/c_funptr_1.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/c_funptr_1_mod.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/interface.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88298] [7/8/9 Regression] Bogus conversion warning for CSHIFT with -fno-range-check -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88298 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Sat Feb 2 16:21:43 2019 New Revision: 268475 URL: https://gcc.gnu.org/viewcvs?rev=268475=gcc=rev Log: 2019-02-02 Thomas Koenig PR fortran/88298 * arith.c (gfc_int2int): Do not warn if src->do_not_warn is set. * gfortran.h (gfc_expr): Add flag do_not_warn. * intrinsic.c (gfc_convert_type_warn): Set expr->do_not_warn if no warning is desired. 2019-02-02 Thomas Koenig PR fortran/88298 * gfortran.dg/warn_conversion_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/warn_conversion_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89158] [8/9 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- From a quick look it seems we haven't properly set need_temporary_p when converting NON_LVALUE_EXPR<42> to const int &. Then taking the address of 42 breaks.
[Bug fortran/64397] [OOP] Runtime segfault with parenthesis expression passed to polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64397 --- Comment #11 from Dominique d'Humieres --- This PR seems to have been fixed by revision r268474.
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 --- Comment #12 from Marc Glisse --- (In reply to Jakub Jelinek from comment #11) > I think there are cases where we set useful range even on other SSA_NAMEs > than the single one used in the condition, and in some cases it should be > good enough, even when the SSA_NAME from the condition has single use. I thought those other SSA_NAMES were the ones I was testing, probably I didn't look closely enough. > Canonical example would be if (int_arg + 32U <= 64U) __builtin_unreachable > (), We don't quite seem to put a range on int_arg with this. We have one temporarily, and deduce ranges for things computed based on int_arg, but I don't see one on int_arg itself after the pass. > etc. So I wonder if we don't need to differentiate between that and the > case like here, where we really don't derive anything useful from it > something & const == const2, and if the other SSA_NAME(s) got useful range > and any of them isn't single use, remove it too. Yes, we should only remove __builtin_unreachable (which we currently don't do at all) if we think we got enough information out of it, something like you describe. And even then, there are various ways we may loose the range information along the way.
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #11 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #9)
> --- gimple-ssa-evrp-analyze.c (revision 268474)
> +++ gimple-ssa-evrp-analyze.c (working copy)
> @@ -217,7 +217,8 @@ evrp_range_analyzer::record_ranges_from_
> push_value_range (vrs[i].first, vrs[i].second);
> if (is_fallthru
> && m_update_global_ranges
> - && all_uses_feed_or_dominated_by_stmt (vrs[i].first, stmt))
> + && all_uses_feed_or_dominated_by_stmt (vrs[i].first, stmt)
> + && !has_single_use (vrs[i].first))
> {
> set_ssa_range_info (vrs[i].first, vrs[i].second);
> maybe_set_nonzero_bits (pred_e, vrs[i].first);
>
> does remove the warning on the reduced testcase. But I didn't run the
> testsuite to check if it made sense. And if it does, it should probably come
> before all_uses_feed_or_dominated_by_stmt because it is cheaper (or be
> integrated with it, since it also iterates over all uses and is used only
> here).
I think there are cases where we set useful range even on other SSA_NAMEs than
the single one used in the condition, and in some cases it should be good
enough, even when the SSA_NAME from the condition has single use.
Canonical example would be if (int_arg + 32U <= 64U) __builtin_unreachable (),
etc. So I wonder if we don't need to differentiate between that and the case
like here, where we really don't derive anything useful from it something &
const == const2, and if the other SSA_NAME(s) got useful range and any of them
isn't single use, remove it too.
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #10 from Jakub Jelinek ---
(In reply to Paul Eggert from comment #8)
> (In reply to Jakub Jelinek from comment #7)
>
> > Or just rewrite whatever you are doing to something that doesn't suffer from
> > this. Say:
> > (tail) = Vframe_list;
> > while ((frame1 = XCAR (tail), 1))
> > {
> > body...;
> > tail = XCDR (tail);
> > if (!CONSP (tail))
> > break;
> > }
>
> Unfortunately that wouldn't be right, since Vframe_list might be Qnil so the
> first XCAR would be invalid.
I don't understand that. You had:
((CONSP (Vframe_list)) ? (void) 0 : __builtin_unreachable ());
for ((tail) = Vframe_list; (CONSP (tail) && (frame1 = XCAR (tail), 1)); tail
= XCDR (tail))
body...;
so, the assertion is testing what the CONSP will test on the first iteration.
So, if Qnil fails CONSP test, then it would fail the assertion, if it doesn't,
then the first iteration is done unconditionally.
[Bug ada/89159] New: limited with, tagged record and access to function confuse the linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89159 Bug ID: 89159 Summary: limited with, tagged record and access to function confuse the linker Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: nicolas at debian dot org Target Milestone: --- The following sources demonstrate the issue with GCC 8.2.0. # gnatmake main x86_64-linux-gnu-gnatlink-8 main.ali /usr/bin/ld: ./ms.o:(.data.rel.ro.local+0x80): undefined reference to `ms__g' -- with Ms; package Ts is type T; type T is new Integer; end Ts; -- limited with Ts; package Ms is type M is tagged null record; procedure G (Container : in M; F : access function return Ts.T); end Ms; -- with Ts; package body Ms is procedure G (Container : in M; F : access function return Ts.T) is Item : Ts.T := F.all; begin null; end G; end Ms; -- with Ts; procedure Main is begin null; end Main;
[Bug middle-end/85563] [8/9 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563
--- Comment #9 from Marc Glisse ---
--- gimple-ssa-evrp-analyze.c (revision 268474)
+++ gimple-ssa-evrp-analyze.c (working copy)
@@ -217,7 +217,8 @@ evrp_range_analyzer::record_ranges_from_
push_value_range (vrs[i].first, vrs[i].second);
if (is_fallthru
&& m_update_global_ranges
- && all_uses_feed_or_dominated_by_stmt (vrs[i].first, stmt))
+ && all_uses_feed_or_dominated_by_stmt (vrs[i].first, stmt)
+ && !has_single_use (vrs[i].first))
{
set_ssa_range_info (vrs[i].first, vrs[i].second);
maybe_set_nonzero_bits (pred_e, vrs[i].first);
does remove the warning on the reduced testcase. But I didn't run the testsuite
to check if it made sense. And if it does, it should probably come before
all_uses_feed_or_dominated_by_stmt because it is cheaper (or be integrated with
it, since it also iterates over all uses and is used only here).
It is a bit strange that EVRP sets a range that means the condition is always
false (well, that is not quite true, sometimes range intersection gives
something weaker), but doesn't remove the unreachable branch itself, which
survives all the way to VRP1. I guess it doesn't cause any trouble except for
having a slightly larger function during IPA.
[Bug lto/88147] [9 Regression] ICE in linemap_line_start, at libcpp/line-map.c:781 starting from r265875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88147 --- Comment #10 from David Malcolm --- FWIW I'm able to reproduce this with r265875 and am running a reduction script over this weekend to see if I can isolate what the issue is/was.
[Bug fortran/53576] Very unhelpful error message: "Unclassifiable statement" instead of "Can't convert TYPE to ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53576 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|normal |enhancement
[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60144 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|minor |enhancement
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880 --- Comment #6 from Jakub Jelinek --- The assert is meaningful, it is a bug if something is created with one context once and then something tries to change that context to something else. So whatever wants to change that is doing something wrong, or it has been created in a wrong context initially.
[Bug fortran/60091] Misleading error messages in rank-2 pointer assignment to rank-1 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60091 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Severity|minor |enhancement
[Bug fortran/54880] [OOP] ICE in gfc_create_module_variable, at fortran/trans-decl.c:4013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54880
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Dominique d'Humieres ---
> One way to get rid of the error is to simply remove the assert that causes it
> (which was already constrained by Paul for PR43450). However, I'm not sure if
> that's justified.
The asserts were introduced at revision r139773 to solve a problem with COMMON
and DW_TAG_common_block (PRs 23057 and 29635). I fail to understand their
logic: why
TYPE_CONTEXT (decl) = sym->ns->proc_name->backend_decl;
if
TYPE_CONTEXT (decl) == sym->ns->proc_name->backend_decl?
Updated patch
--- ../_clean/gcc/fortran/trans-decl.c 2019-02-02 01:32:53.0 +0100
+++ gcc/fortran/trans-decl.c2019-02-02 09:32:15.0 +0100
@@ -4975,14 +4975,6 @@ gfc_create_module_variable (gfc_symbol *
decl = sym->backend_decl;
gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE);
- if (!sym->attr.use_assoc && !sym->attr.used_in_submodule)
- {
- gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE
- || TYPE_CONTEXT (decl) ==
sym->ns->proc_name->backend_decl);
- gcc_assert (DECL_CONTEXT (TYPE_STUB_DECL (decl)) == NULL_TREE
- || DECL_CONTEXT (TYPE_STUB_DECL (decl))
- == sym->ns->proc_name->backend_decl);
- }
TYPE_CONTEXT (decl) = sym->ns->proc_name->backend_decl;
DECL_CONTEXT (TYPE_STUB_DECL (decl)) = sym->ns->proc_name->backend_decl;
gfc_module_add_decl (cur_module, TYPE_STUB_DECL (decl));
> At least it does not introduce any regressions in the testsuite.
Removing an assert cannot introduce any regression.
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #23 from Eric Botcazou --- > Because these testcases uncover real problems in the code base, please see > comment #19. But there are hundreds open PRs in the database for *real* code with *realistic* combinations of options. This one is not one of them. Regarding -fschedule-insns, there was quite some work done some > years ago to enable this option on x86, so by fixing PRs involving > -fchedule-insns, we are inching closer to enabling it by default. IMO it will really be usable only when they double again the # of registers.
[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87485 --- Comment #22 from Uroš Bizjak --- (In reply to Eric Botcazou from comment #21) > Why are we wasting any time or energy on useless PRs like this one involving > an improbable combination of options on nonsensical code, especially > -fschedule-insns which is known to be problematic on x86? We should really > restrict the PRs to sensible command lines at this point, this is getting > worse with every release. Because these testcases uncover real problems in the code base, please see comment #19. Regarding -fschedule-insns, there was quite some work done some years ago to enable this option on x86, so by fixing PRs involving -fchedule-insns, we are inching closer to enabling it by default.
[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393 --- Comment #5 from Paul Thomas --- Author: pault Date: Sat Feb 2 09:23:30 2019 New Revision: 268474 URL: https://gcc.gnu.org/viewcvs?rev=268474=gcc=rev Log: 2019-02-02 Paul Thomas PR fortran/88393 * trans-expr.c (gfc_conv_procedure_call): For derived entities, passed in parentheses to class formals, invert the order of copying allocatable components to taking the _data of the class expression. 2019-02-02 Paul Thomas PR fortran/88393 * gfortran.dg/alloc_comp_assign_16.f03 : New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_16.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88980] [9 regression] segfault on allocatable string member assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88980 --- Comment #3 from Paul Thomas --- Author: pault Date: Sat Feb 2 09:16:44 2019 New Revision: 268473 URL: https://gcc.gnu.org/viewcvs?rev=268473=gcc=rev Log: 2019-02-02 Paul Thomas PR fortran/88980 * trans-array.c (gfc_array_init_size): Add element_size to the arguments. (gfc_array_allocate): Remove the recalculation of the size of the element and use element_size from the call to the above. Unconditionally set the span field of the descriptor. 2019-02-02 Paul Thomas PR fortran/88980 * gfortran.dg/realloc_on_assign_32.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_32.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88685] [8/9 regression] pointer class array argument indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685 --- Comment #6 from Paul Thomas --- Author: pault Date: Sat Feb 2 09:10:58 2019 New Revision: 268472 URL: https://gcc.gnu.org/viewcvs?rev=268472=gcc=rev Log: 2019-02-02 Paul Thomas PR fortran/88685 * expr.c (is_subref_array): Move the check for class pointer dummy arrays to after the reference check. If we haven't seen an array reference other than an element and a component is not class or derived, return false. 2019-02-02 Paul Thomas PR fortran/88685 * gfortran.dg/pointer_array_component_3.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/pointer_array_component_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89158] [8/9 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-02 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r261121. clang as well as icpc accept it.
