[Bug c++/90801] A recurring hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90801 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Jun 13 08:41:13 2019 New Revision: 272235 URL: https://gcc.gnu.org/viewcvs?rev=272235=gcc=rev Log: 2019-06-13 Richard Biener PR c++/90801 * typeck2.c (split_nonconstant_init_1): Properly count num_split_elts, optimize single constructor elt removal. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck2.c
[Bug c/90867] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867 --- Comment #1 from Sven Schmidt --- Created attachment 46486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46486=edit Assembler output
[Bug middle-end/90864] Suboptimal codegen of structs in C/C++on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90864 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-13 Component|target |middle-end Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Probably quite a number of duplicates exist.
[Bug target/90867] [7/8/9/10 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Known to work||5.5.0
Keywords||wrong-code
Last reconfirmed||2019-06-13
Component|c |target
Ever confirmed|0 |1
Summary|Multiplication or typecast |[7/8/9/10 Regression]
|of integer and double |Multiplication or typecast
|always zero when... |of integer and double
||always zero when...
Target Milestone|--- |7.5
Known to fail||6.4.0
--- Comment #2 from Richard Biener ---
Confirmed when compiling with -march=native. It seems to work with
-march=haswell or other specific archs. Also fails with -mavx or even -msse2.
For some reason main() ends up with x87 math and bogus calling conventions.
Also:
> gcc-8 t.c -msse2 -fdump-tree-optimized -mfpmath=sse
t.c:16:1: warning: SSE instruction set disabled, using 387 arithmetics
{
^
may hint at the underlying issue. Worked in GCC 5.
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 Martin Liška changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Martin Liška --- So my patch survives bootstrap and regression tests, can you please Martin take the issue? Patch candidate: diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c index 944650cecd5..a9b1147a2e7 100644 --- a/gcc/tree-ssa-strlen.c +++ b/gcc/tree-ssa-strlen.c @@ -324,7 +324,7 @@ get_stridx (tree exp) off = TREE_OPERAND (ptr, 1); /* Scale the array index by the size of the element type (normally 1 for char). */ - off = fold_build2 (MULT_EXPR, TREE_TYPE (off), off, + off = fold_build2 (MULT_EXPR, TREE_TYPE (eltsize), off, eltsize); ptr = TREE_OPERAND (ptr, 0); }
[Bug middle-end/90868] Duplicate OpenACC 'declare' directives for `extern` variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90868 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-06-13 Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/90868] New: Duplicate OpenACC 'declare' directives for `extern` variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90868 Bug ID: 90868 Summary: Duplicate OpenACC 'declare' directives for `extern` variables Product: gcc Version: 10.0 URL: https://github.com/OpenACC/openacc-spec/issues/194 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- Working on getting clarified what the intended behavior should be.
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 --- Comment #4 from Richard Biener --- (In reply to Martin Liška from comment #3) > So my patch survives bootstrap and regression tests, can you please Martin > take the issue? > > Patch candidate: > diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c > index 944650cecd5..a9b1147a2e7 100644 > --- a/gcc/tree-ssa-strlen.c > +++ b/gcc/tree-ssa-strlen.c > @@ -324,7 +324,7 @@ get_stridx (tree exp) > off = TREE_OPERAND (ptr, 1); > /* Scale the array index by the size of the element >type (normally 1 for char). */ > - off = fold_build2 (MULT_EXPR, TREE_TYPE (off), off, > + off = fold_build2 (MULT_EXPR, TREE_TYPE (eltsize), off, >eltsize); > ptr = TREE_OPERAND (ptr, 0); > } Of course this shouldn't make a difference. The issue is likely a type mismatch and 'off' being a pointer type? Probably mem_ref_offset () should be used to extract it.
[Bug tree-optimization/90856] [10 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90856 --- Comment #5 from Jakub Jelinek --- Created attachment 46487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46487=edit gcc10-pr90856.patch Untested fix.
[Bug tree-optimization/43491] Unnecessary temporary for global register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
--- Comment #12 from rguenther at suse dot de ---
On Wed, 12 Jun 2019, wschmidt at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
>
> Bill Schmidt changed:
>
>What|Removed |Added
>
> Target|arm-none-eabi |arm-none-eabi, powerpc*-*-*
> CC||wschmidt at gcc dot gnu.org
>
> --- Comment #10 from Bill Schmidt ---
> This remains a problem and was rediscovered recently here with GCC 10.
> However, it seems worse than before in that conditions "c" and "d" of the
> original bug report are no longer necessary to get the unnecessary temporary.
>
> /* test case */
> struct foo {
> int bar;
> int baz;
> };
>
> register struct foo *local asm("r13");
>
> void fn(void)
> {
> if (local->bar)
> local->bar = 0;
> local->baz--;
> }
> /* end test case */
>
> Compile with -O2. As in the other case, the copy-to-temporary is introduced
> at
> gimplification and remains in place at expand time.
>
> wschmidt@marlin:~/src$ cat nick2.c.005t.gimple
> fn ()
> {
> local.0_1 = local;
There's a conflict of interest here. We do not consider hard-registers
as GIMPLE registers and thus do not rewrite them into SSA. This in
turn requires "loads" from them to make the indirection valid GIMPLE.
If we'd rewrite the hard registers into SSA it's much harder to avoid
messing with them (we might get away with setting
SSA_NAME_OCCURS_IN_ABNORMAL_PHI on them, who knows).
Note that we happily create overlapping life-ranges of the loaded
hardreg SSA names thus propagating those out isn't the solution
either. I guess one idea would be to make out-of-SSA rewrite
the hardregs into SSA and then prioritize SSA coalescing to
coalesce the now SSA copies with higher priority as others.
The easiest way to trick the SSA rewriter to allow rewriting
hardregs would be to extend DECL_IS_GIMPLE_REG_P to apply
to hardregs.
No time to do all this but the out-of-SSA coalescing strategy
looks easiest.
[Bug tree-optimization/90869] New: Non-disambiguated memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90869
Bug ID: 90869
Summary: Non-disambiguated memory accesses
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Hi,
in the following testcases we should be able to disambiguate accesses:
struct a
{
int ia;
struct b
{
int ib;
struct c
{
int ic;
} c[2];
} b[5];
} a;
test (int i,int j)
{
struct c *bptr=[i].c[1];
struct c *cptr=[j].c[2];
bptr->ic=1;
cptr->ic=2;
return bptr->ic;
}
and
struct data {int data,data2;} *ptr;
int *ptr2;
struct a {struct data a;};
struct b {struct a a[10];} *bptr;
test (int i)
{
struct a *aptr = >a[i];
aptr->a.data=0;
ptr->data2=1;
return aptr->a.data;
}
(this one works with clang but does not because of way we fold address
calculations)
and
typedef int (*fnptr) ();
__attribute__ ((used))
int *a,**aptr=
__attribute__ ((used))
struct b {int *a;} *bptr,b;
static void
inline_me_late (int argc)
{
if (argc == -1)
*bptr = b;
}
int
main (int argc)
{
a = 0;
inline_me_late (argc);
if (!__builtin_constant_p (a == 0))
__builtin_abort ();
return 0;
}
compiled with -O3 -flto -fno-early-inlining
[Bug tree-optimization/90869] Non-disambiguated memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90869
--- Comment #1 from Jan Hubicka ---
Another testcase. Here we should disambiguate both cases while we do only
second
struct a {int a1; int a2;};
struct b:a {};
struct b bvar,*bptr2;
int
test(void)
{
struct a *bptr =
bptr->a2=0;
bptr2->a1=1;
return bptr->a2;
}
int
test2(void)
{
struct b *bptr =
bptr->a2=0;
bptr2->a1=1;
return bptr->a2;
}
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #5 from Jakub Jelinek ---
There is a way out of this. Defer building those conditionals till the sanopt
pass, before that have new IFN_UBSAN_* internal calls in the IL like we already
do with IFN_UBSAN_{NULL,BOUNDS,OBJECT_SIZE,PTR,VPTR}. Another advantage of
doing that would be we would create the ubsan data only for code that actuall
survives till the sanopt pass and is not optimized away before that.
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 --- Comment #2 from Martin Liška --- I'm testing a patch candidate..
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #7 from ktkachov at gcc dot gnu.org --- I also see this when building 502.gcc_r from SPEC
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 --- Comment #2 from sshannin at gmail dot com --- Thanks for such a quick reply. I just wanted to make sure I'm understanding you correctly about what you mean when you say this is expected. Are you indicating that it's desirable that the ubsan instrumentation is visible to gcov and thus shows up as coverage gaps? That seems to be what you're indicating, but seems surprising to me, as it roughly makes the gcov output useless. Certainly I'm not trying to get coverage about code that the compiler inserted as an implementation detail of checking division. Is there way to mark the ubsan-generated code as such so that gcov ignores it instead of marking every division operation as having an uncovered branch?
[Bug c/79775] Confusing fix-it diagnostics with double pointers to structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79775
--- Comment #3 from felix ---
A particularly amusing variant of this bug occurs with the following code:
struct x { struct x **xx; };
int y = __builtin_offsetof(struct x, xx->xx);
which gives the warning
$ gcc xx.c
xx.c:3:40: error: ‘*0->xx’ is a pointer; did you mean to use ‘->’?
int y = __builtin_offsetof(struct x, xx->xx);
^~
->
mentioning `*0`, which doesn't appear in the source code at all. Similarly for
C++:
$ g++ xx.c
xx.c:3:42: error: request for member ‘xx’ in ‘*((x*)0)->x::xx’, which is of
pointer type ‘x*’ (maybe you meant to use ‘->’ ?)
int y = __builtin_offsetof(struct x, xx->xx);
^~
Compare The Other Compiler, which refuses to parse `->` inside
`__builtin_offsetof` altogether:
$ clang xx.c
xx.c:3:40: error: expected ')'
int y = __builtin_offsetof(struct x, xx->xx);
^
xx.c:3:27: note: to match this '('
int y = __builtin_offsetof(struct x, xx->xx);
^
1 error generated.
I assume GCC parses it in order to have a more user-friendly ‘cannot apply
‘offsetof’ to a non constant address’ error, but I'm not sure if this is worth
it.
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866
--- Comment #6 from Dmitry G. Dyachenko ---
(In reply to Dmitry G. Dyachenko from comment #5)
> $ cat x.i
> typedef enum { a } b;
> typedef struct {
> int c[0];
> } d;
> typedef struct {
> int *data;
> } e;
> typedef struct {
> e buffer;
> } f;
> int g, h;
> int i();
> int i(f *j, d *k, b l, int m) {
> if (l)
> if (m) {
> h = j->buffer.data[0];
> k->c[g] = k->c[g] * 8;
> }
> return 0;
>
add missed }
$ cat x.i
$ cat x.i
typedef enum { a } b;
typedef struct {
int c[0];
} d;
typedef struct {
int *data;
} e;
typedef struct {
e buffer;
} f;
int g, h;
int i();
int i(f *j, d *k, b l, int m) {
if (l)
if (m) {
h = j->buffer.data[0];
k->c[g] = k->c[g] * 8;
}
return 0;
}
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 --- Comment #3 from Martin Liška --- (In reply to sshannin from comment #2) > Thanks for such a quick reply. I just wanted to make sure I'm understanding > you correctly about what you mean when you say this is expected. > > Are you indicating that it's desirable that the ubsan instrumentation is > visible to gcov and thus shows up as coverage gaps? No, it's not desirable, but the current gcov can't distinguish between read code and the instrumented one. > That seems to be what > you're indicating, but seems surprising to me, as it roughly makes the gcov > output useless. > > Certainly I'm not trying to get coverage about code that the compiler > inserted as an implementation detail of checking division. Is there way to > mark the ubsan-generated code as such so that gcov ignores it instead of > marking every division operation as having an uncovered branch? No, please do not combine UBSAN and GCOV. Use the separately.
[Bug sanitizer/90865] ubsan causes coverage branch errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865 --- Comment #4 from Martin Liška --- > No, it's not desirable, but the current gcov can't distinguish between read > code and the instrumented one. > * real code
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #1 from David Binderman --- I also see this crash, when bootstrapping the compiler with -O3. ../../../trunk/libgcc/libgcc2.c during GIMPLE pass: strlen ../../../trunk/libgcc/unwind-dw2.c: In function ‘execute_stack_op’: ../../../trunk/libgcc/unwind-dw2.c:526:1: internal compiler error: in fold_binary_loc, at fold-const.c:9827
[Bug c/90867] New: Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867
Bug ID: 90867
Summary: Multiplication or typecast of integer and double
always zero when...
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sven.schm...@gmx-topmail.de
Target Milestone: ---
Created attachment 46485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46485=edit
Compiler output text
A multiplication of integer with double or a typecast of integer to double is
always zero when compiling with -march=native and the function is defined
"GENERIC" with "__attribute__ ((target ("arch=x86-64")))" or any other arch.
The bug occurs an all gcc 64-bit (x86-64) for Linux since gcc-6 I've tested.
Not affected is gcc 32-bit (i386) or other systems like gcc for mingw.
-
#include
#include
/*
* no opcode optimization allowed
*/
#if __i386__
# define GENERIC__attribute__ ((target ("arch=i386")))
#else
# define GENERIC__attribute__ ((target ("arch=x86-64")))
#endif
uint64_t freq = 36UL; /* 3.6 GHz = 3600.0 MHz */
GENERIC int main (void)
{
printf("freq = %f Hz\n", (double)freq);
printf("freq = %f kHz\n", 1e-3 * freq);
printf("freq = %f MHz\n", 1e-6 * freq);
printf("freq = %f GHz\n", 1e-9 * freq);
return 0;
}
-
Compile with: gcc -v -save-temps -Wall -Wextra -march=native test.c -o test
Result when running is:
-
freq = 0.00 Hz
freq = 0.00 kHz
freq = 0.00 MHz
freq = 0.00 GHz
-
Compiling same code with -m32...
gcc -m32 -v -save-temps -Wall -Wextra -march=native test.c -o test
...gives expected results:
-
freq = 36.00 Hz
freq = 360.00 kHz
freq = 3600.00 MHz
freq = 3.60 GHz
-
gcc --version: gcc (Debian 8.3.0-6) 8.3.0
gcc compiles assembler code for the old FPU and there is a bug in machine code.
When compiling same code without architecture restrictions assembler code is
build for SSE unit without bug.
Compiler output file is appended.
Best regards
Sven
[Bug tree-optimization/90856] [10 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90856
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
Less undefined testcase also failing at -O3:
typedef struct { int v; } S1;
typedef struct { S1 s1[32]; } S2;
S1 clearS1() { S1 s; s.v = 1; return s; }
void
clearS2(__seg_gs S2 *p, int n)
{
for (int i = 0; i < n; ++i)
p->s1[i] = clearS1();
}
on trunk the issue is SRAs new build_reconstructed_reference which
fails to propagate address-space information from the base to the
model reference.
Testing patch.
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866
--- Comment #5 from Dmitry G. Dyachenko ---
$ cat x.i
typedef enum { a } b;
typedef struct {
int c[0];
} d;
typedef struct {
int *data;
} e;
typedef struct {
e buffer;
} f;
int g, h;
int i();
int i(f *j, d *k, b l, int m) {
if (l)
if (m) {
h = j->buffer.data[0];
k->c[g] = k->c[g] * 8;
}
return 0;
$ gcc -fpreprocessed -O2 -fsanitize=thread -c x.i
during GIMPLE pass: strlen
x.i: In function ‘i’:
x.i:13:5: internal compiler error: in fold_binary_loc, at fold-const.c:9827
13 | int i(f *j, d *k, b l, int m) {
| ^
0x667691 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/src/gcc_current/gcc/fold-const.c:9827
0xcc9bed fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/dimhen/src/gcc_current/gcc/fold-const.c:12338
0x11b4a62 get_stridx
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:327
0x11b4a62 get_stridx
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:293
0x11bb65c strlen_check_and_optimize_stmt
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:3721
0x11bb65c strlen_dom_walker::before_dom_children(basic_block_def*)
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:4009
0x18dfca2 dom_walker::walk(basic_block_def*)
/home/dimhen/src/gcc_current/gcc/domwalk.c:312
0x11b0ea0 execute
/home/dimhen/src/gcc_current/gcc/tree-ssa-strlen.c:4089
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #8 from Martin Sebor --- Thanks for all the small test cases!
[Bug fortran/90870] New: new test case gfortran.dg/deferred_character_33.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870 Bug ID: 90870 Summary: new test case gfortran.dg/deferred_character_33.f90 fails Product: gcc Version: 7.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- FAIL: gfortran.dg/deferred_character_33.f90 -O0 execution test FAIL: gfortran.dg/deferred_character_33.f90 -O1 execution test FAIL: gfortran.dg/deferred_character_33.f90 -O2 execution test FAIL: gfortran.dg/deferred_character_33.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test FAIL: gfortran.dg/deferred_character_33.f90 -O3 -g execution test FAIL: gfortran.dg/deferred_character_33.f90 -Os execution test These all fail in the same way spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-7-test/gcc/testsuite/gfortran/../../gfortran -B/home/seurer/gcc/build/gcc-7-test/gcc/testsuite/gfortran/../../ -B/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/ /home/seurer/gcc/gcc-7-test/gcc/testsuite/gfortran.dg/deferred_character_33.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -pedantic-errors /home/seurer/gcc/gcc-7-test/gcc/testsuite/gfortran.dg/deferred_character_33a.f90 -B/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs -L/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libatomic/.libs -lm -o ./deferred_character_33.exe PASS: gfortran.dg/deferred_character_33.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-7-test/gcc:.:/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libgfortran/.libs:/home/seurer/gcc/build/gcc-7-test/powerpc64-unknown-linux-gnu/./libatomic/.libs:/home/seurer/gcc/build/gcc-7-test/gcc:/home/seurer/gcc/build/gcc-7-test/./gmp/.libs:/home/seurer/gcc/build/gcc-7-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-7-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-7-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-7-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-7-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-7-test/./isl/.libs:/home/seurer/gcc/build/gcc-7-test/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.2.0/lib64 Execution timeout is: 300 spawn [open ...] STOP 1 FAIL: gfortran.dg/deferred_character_33.f90 -O0 execution test
[Bug tree-optimization/90869] Non-disambiguated memory accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90869 --- Comment #2 from Jan Hubicka --- Author: hubicka Date: Thu Jun 13 15:00:41 2019 New Revision: 272247 URL: https://gcc.gnu.org/viewcvs?rev=272247=gcc=rev Log: PR tree-optimize/90869 * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Watch for view converts in MEM_REF referencing decl rather than view converts from decl type to MEM_REF type. * g++.dg/tree-ssa/alias-access-path-1.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/alias-access-path-1.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866
--- Comment #9 from ktkachov at gcc dot gnu.org ---
Here's another one since my reducer finished :)
struct {
int a[0];
} b;
int c;
int d[0];
void e() {
b.a[c] = d[c + 1];
b.a[c + 1] = d[c];
}
-O3 needed on an aarch64 target
[Bug tree-optimization/90856] [10 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90856 --- Comment #6 from Richard Biener --- Author: rguenth Date: Thu Jun 13 13:03:13 2019 New Revision: 272244 URL: https://gcc.gnu.org/viewcvs?rev=272244=gcc=rev Log: 2019-06-13 Richard Biener PR tree-optimization/90856 * tree-sra.c (build_ref_for_model): Only use build_reconstructed_reference when address-spaces are the same. * gcc.target/i386/pr90856.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr90856.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c
[Bug testsuite/90812] Tests misuse "dg-require-effective-target int32plus" to check for 64-bit integer support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90812 --- Comment #3 from Jozef Lawrynowicz --- (In reply to Richard Biener from comment #2) > I think most tests like this end up using 'long long' and use > __SIZEOF_LONG_LONG__ to guard code. There's a dejagnu effective target for > long long support. The problem is that the effective target keyword that checks that long long is 64-bits, also checks that int and long are 32-bits: > llp64 Target has 32-bit int and long, 64-bit long long and pointers. msp430-elf has 16-bit int, 32-bit long and 64-bit long long. And whilst almost all targets have 64-bit long long, avr can have 32-bit long long in one configuration. So I think an effective target to solely check that __INT64_TYPE__ is supported would be useful. I prefer this to guarding the code with sizeof(long long), as with "dg-require-effective target int64type", the testsuite will recognize the test is unsupported, rather than doing nothing and passing.
[Bug tree-optimization/90856] [10 Regression] ICE: verify_gimple failed (error: incompatible types in 'PHI' argument 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90856 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug target/90822] Remove PowerPC lfiwax and lfiwzx patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90822 Michael Meissner changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Michael Meissner --- Unfortunately, it won't be possible to eliminate the lfiwax and lfiwzx patterns completely. These are still needed on 32-bit system, where the sign/zero extend SImode to DImode is only done in GPR registers. But for 64-bit systems, we can eliminate using lfiwax/lfiwzk and use the normal patterns.
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #10 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00793.html
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #20 from Christophe Lyon ---
Hi Kugan,
The new test fails with -mabi=ilp32:
FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tld2w\\t{z[0-9]+.s -
z[0-9]+.s}, p[0-7]/z, \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 2
FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tst2w\\t{z[0-9]+.s -
z[0-9]+.s}, p[0-7], \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 1
[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 --- Comment #3 from Jan Hubicka --- Does adding initializers to those vars fix the bootstrap? Or does it run into wrong code? Honza
[Bug tree-optimization/90876] fold zero-equality of memcmp and strncmp involving strings of unequal lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90876 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90626 Blocks||83819 --- Comment #1 from Martin Sebor --- See also pr90626 for a related opportunity (my patch for it handles the strncmp case mentioned in comment #0 but not memcmp). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 [Bug 83819] [meta-bug] missing strlen optimizations
[Bug ipa/90874] trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90874 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Blocks||89863 --- Comment #1 from Eric Gallager --- This is cppcheck, right? Assuming so... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 [Bug 89863] [meta-bug] Issues that cppcheck finds that gcc misses
[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 Rainer Orth changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Rainer Orth --- A reghunt just found that this is caused by r272247: 2019-06-13 Jan Hubicka PR tree-optimization/90869 * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Watch for view converts in MEM_REF referencing decl rather than view converts from decl type to MEM_REF type.
[Bug fortran/89647] Host associated procedure unable to be used as binding target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89647 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- I have posted a patch that seems to fix this bug at https://gcc.gnu.org/ml/fortran/2019-06/msg00075.html As stated, it feels like a kludge.
[Bug tree-optimization/90876] fold zero-equality of memcmp and strncmp involving strings of unequal lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90876 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52171, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83026 --- Comment #2 from Martin Sebor --- Bug 52171 is also related although its focus is on runtime optimization as opposed to folding.
[Bug target/90877] New: Dead codes in ix86_register_move_cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90877
Bug ID: 90877
Summary: Dead codes in ix86_register_move_cost
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: skpgkp1 at gmail dot com, ubizjak at gmail dot com
Target Milestone: ---
ix86_register_move_cost has
if (inline_secondary_memory_needed (mode, class1, class2, false))
{
...
return cost;
}
/* Moves between SSE/MMX and integer unit are expensive. */
if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)
|| SSE_CLASS_P (class1) != SSE_CLASS_P (class2))
/* ??? By keeping returned value relatively high, we limit the number
of moves between integer and MMX/SSE registers for all targets.
Additionally, high value prevents problem with x86_modes_tieable_p(),
where integer modes in MMX/SSE registers are not tieable
because of missing QImode and HImode moves to, from or between
MMX/SSE registers. */
return MAX (8, MMX_CLASS_P (class1) || MMX_CLASS_P (class2)
? ix86_cost->mmxsse_to_integer : ix86_cost->ssemmx_to_integer);
Since inline_secondary_memory_needed has
/* ??? This is a lie. We do have moves between mmx/general, and for
mmx/sse2. But by saying we need secondary memory we discourage the
register allocator from using the mmx registers unless needed. */
if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2))
return true;
MMX_CLASS_P (class1) != MMX_CLASS_P (class2) is always false. Also
struct processor_costs has:
const int mmxsse_to_integer; /* cost of moving mmxsse register to
integer. */
const int ssemmx_to_integer; /* cost of moving integer to mmxsse register.
*/
the mmxsse_to_integer field is never used.
[Bug tree-optimization/90626] fold strcmp(a, b) == 0 to zero when one string length is exact and the other is unequal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90626 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-13 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/90805] Overflow in switch case is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90805 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/90875] New: warnings about switch values outside range don't have associated option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90875
Bug ID: 90875
Summary: warnings about switch values outside range don't have
associated option
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
See c_do_switch_warnings. E.g.,
void f(char c)
{
switch (c)
case 300:;
}
z.C: In function ‘void f(char)’:
z.C:4:5: warning: case label value exceeds maximum value for type
4 | case 300:;
| ^~~~
[Bug target/87281] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 Jason Duerstock changed: What|Removed |Added CC||jason.duerstock at gmail dot com --- Comment #2 from Jason Duerstock --- Does this still show up in 9.1?
[Bug tree-optimization/90876] New: fold zero-equality of memcmp and strncmp involving strings of unequal lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90876
Bug ID: 90876
Summary: fold zero-equality of memcmp and strncmp involving
strings of unequal lengths
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Thanks to the solution for pr83026 committed in r261039 GCC optimizes strcmp
inequalities involving strings of different lengths. However, it only handles
simple cases involving strcmp and misses other, equivalent cases involving
strncmp or memcmp that could be easily handled as well. The test case below
shows the optimization in f0 and its absence in f1 and f2:
$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
int f0 (void)
{
char a[4], b[4];
__builtin_strcpy (a, "12");
__builtin_strcpy (b, "123");
return 0 == __builtin_strcmp (a, b); // folded to 0
}
int f1 (void)
{
char a[4], b[4];
__builtin_strcpy (a, "12");
__builtin_strcpy (b, "123");
return 0 == __builtin_strncmp (a, b, 3); // not folded
}
int f2 (void)
{
char a[4], b[4];
__builtin_strcpy (a, "12");
__builtin_strcpy (b, "123");
return 0 == __builtin_memcmp (a, b, 3); // not folded
}
;; Function f0 (f0, funcdef_no=0, decl_uid=1906, cgraph_uid=1, symbol_order=0)
f0 ()
{
[local count: 1073741824]:
return 0;
}
;; Function f1 (f1, funcdef_no=1, decl_uid=1911, cgraph_uid=2, symbol_order=1)
f1 ()
{
char b[4];
char a[4];
int _1;
_Bool _2;
int _6;
[local count: 1073741824]:
__builtin_memcpy (, "12", 3);
MEM [(char * {ref-all})] = MEM [(char
* {ref-all})"123"];
_1 = __builtin_strncmp (, , 3);
_2 = _1 == 0;
_6 = (int) _2;
a ={v} {CLOBBER};
b ={v} {CLOBBER};
return _6;
}
;; Function f2 (f2, funcdef_no=2, decl_uid=1916, cgraph_uid=3, symbol_order=2)
f2 ()
{
char b[4];
char a[4];
int _1;
_Bool _2;
int _6;
[local count: 1073741824]:
__builtin_memcpy (, "12", 3);
MEM [(char * {ref-all})] = MEM [(char
* {ref-all})"123"];
_1 = __builtin_memcmp_eq (, , 3);
_2 = _1 == 0;
_6 = (int) _2;
a ={v} {CLOBBER};
b ={v} {CLOBBER};
return _6;
}
[Bug fortran/90870] new test case gfortran.dg/deferred_character_33.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870 --- Comment #3 from Dominique d'Humieres --- > So, removing the test case. The same should be done for the GGC8 and 9 branches.
[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #10 from kargl at gcc dot gnu.org --- Fixed on trunk.
[Bug other/89863] [meta-bug] Issues that cppcheck finds that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 88810, which changed state. Bug 88810 Summary: gcc/fortran/dependency.c:2200: possible cut'n'paste error ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 Rainer Orth changed: What|Removed |Added Target|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11,i686- ||pc-linux-gnu Host|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11,i686- ||pc-linux-gnu Build|i386-pc-solaris2.11,|i386-pc-solaris2.11, |sparc-sun-solaris2.11 |sparc-sun-solaris2.11,i686- ||pc-linux-gnu --- Comment #1 from Rainer Orth --- Also seen on Linux/i686.
[Bug tree-optimization/77820] A jump threading opportunity with conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77820 --- Comment #3 from Jeffrey A. Law --- Author: law Date: Thu Jun 13 18:55:55 2019 New Revision: 272261 URL: https://gcc.gnu.org/viewcvs?rev=272261=gcc=rev Log: PR tree-optimization/77820 * tree-ssa-threadedge.c (edge_forwards_cmp_to_conditional_jump_through_empty_bb_p): New function. (thread_across_edge): Add call to edge_forwards_cmp_to_conditional_jump_through_empty_bb_p. PR tree-optimization/77820 * gcc.dg/tree-ssa/phi_on_compare-1.c: New testcase. * gcc.dg/tree-ssa/phi_on_compare-2.c: New testcase. * gcc.dg/tree-ssa/phi_on_compare-3.c: New testcase. * gcc.dg/tree-ssa/phi_on_compare-4.c: New testcase. * gcc.dg/tree-ssa/split-path-6.c: Update testcase. * gcc.target/sh/pr51244-20.c: Update testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-2.c trunk/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-3.c trunk/gcc/testsuite/gcc.dg/tree-ssa/phi_on_compare-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/split-path-6.c trunk/gcc/testsuite/gcc.target/sh/pr51244-20.c trunk/gcc/tree-ssa-threadedge.c
[Bug fortran/90870] new test case gfortran.dg/deferred_character_33.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870 --- Comment #4 from Dominique d'Humieres --- > > So, removing the test case. > > The same should be done for the GGC8 and 9 branches. May be not. My versions are probably not up to date.
[Bug fortran/68544] ICE trying to pass derived type constructor as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544 --- Comment #11 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 13 18:40:19 2019 New Revision: 272259 URL: https://gcc.gnu.org/viewcvs?rev=272259=gcc=rev Log: 2019-06-13 Steven G. Kargl PR fortran/68544 * resolve.c (is_dt_name): New function to compare symbol name against list of derived types. (resolve_actual_arglist): Use it to find wrong code. 2019-06-13 Steven G. Kargl PR fortran/68544 * gfortran.dg/pr68544.f90: New test. * gfortran.dg/pr85687.f90: Modify test for new error message. Added: trunk/gcc/testsuite/gfortran.dg/pr68544.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr85687.f90
[Bug fortran/90870] new test case gfortran.dg/deferred_character_33.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870 --- Comment #1 from Thomas Koenig --- Author: tkoenig Date: Thu Jun 13 17:00:22 2019 New Revision: 272249 URL: https://gcc.gnu.org/viewcvs?rev=272249=gcc=rev Log: 2019-06-13 Thomas Koenig PR fortran/90870 * gfortran.dg/deferred_character_33.f90: Remove failing test. * gfortran.dg/deferred_character_33a.f90: Likewise. Removed: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deferred_character_33.f90 branches/gcc-7-branch/gcc/testsuite/gfortran.dg/deferred_character_33a.f90 Modified: branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug c++/88324] segfault with constexpr lambda in template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88324 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Fixed by r269972 which has a test for this.
[Bug c/90874] New: trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90874 Bug ID: 90874 Summary: trunk/gcc/ipa-utils.h:243: possible cut-n-paste error ? Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/gcc/ipa-utils.h:243]: (style) Consecutive return, break, continue, goto or throw statements are unnecessary. svn blame says 272037hubicka return TYPE_NAME (t) && TREE_CODE (TYPE_NAME (t)) == TYPE_DECL 272037hubicka && DECL_ASSEMBLER_NAME_SET_P (TYPE_NAME (t)); 231098hubicka return false;
[Bug tree-optimization/90872] New: [8 regression] ICE on invalid in contains_struct_check()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90872
Bug ID: 90872
Summary: [8 regression] ICE on invalid in
contains_struct_check()
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
r267346 PASS
r267961 FAIL
r272203 FAIL
$ cat x.i
a() {
void b() = ;
b == 0
$ /usr/local/gcc_current/bin/gcc -fpreprocessed -c x.i
x.i:1:1: warning: return type defaults to 'int' [-Wimplicit-int]
1 | a() {
| ^
x.i: In function 'a':
x.i:2:3: error: function 'b' is initialized like a variable
2 | void b() = ;
| ^~~~
x.i:2:14: error: expected expression before ';' token
2 | void b() = ;
| ^
x.i:3:9: error: expected ';' at end of input
3 | b == 0
| ^
| ;
x.i:3:3: error: expected declaration or statement at end of input
3 | b == 0
| ^
x.i:1:1: internal compiler error: Segmentation fault
1 | a() {
| ^
0xfeddbf crash_signal
/home/dimhen/src/gcc_current/gcc/toplev.c:326
0xd3aee7 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/dimhen/src/gcc_current/gcc/tree.h:3310
0xd3aee7 unshare_body
/home/dimhen/src/gcc_current/gcc/gimplify.c:933
0xd3af82 unshare_body
/home/dimhen/src/gcc_current/gcc/gimplify.c:940
0xd47262 gimplify_body(tree_node*, bool)
/home/dimhen/src/gcc_current/gcc/gimplify.c:13902
0xd47697 gimplify_function_tree(tree_node*)
/home/dimhen/src/gcc_current/gcc/gimplify.c:14058
0xb9ea77 cgraph_node::analyze()
/home/dimhen/src/gcc_current/gcc/cgraphunit.c:667
0xba180d analyze_functions
/home/dimhen/src/gcc_current/gcc/cgraphunit.c:1126
0xba2462 symbol_table::finalize_compilation_unit()
/home/dimhen/src/gcc_current/gcc/cgraphunit.c:2833
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/90779] Fortran array initialization in offload regions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90779 --- Comment #3 from Andrew Stubbs --- My code now compiles successfully, with the patch, but it hangs at runtime. I need to investigate, but debugging runtime issues on the GPU is slow work.
[Bug middle-end/89292] [9 regression] test case gcc.target/powerpc/rs6000-fpint.c fails after r268705
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89292 seurer at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-06-13 Resolution|DUPLICATE |--- Ever confirmed|0 |1 --- Comment #4 from seurer at gcc dot gnu.org --- 89271 is marked as fixed from over a month go but this problem is still occurring. So it appears it was not a duplicate. make -k check-gcc RUNTESTFLAGS=powerpc.exp=gcc.target/powerpc/rs6000-fpint.c . . . FAIL: gcc.target/powerpc/rs6000-fpint.c scan-assembler-not stfiwx . . . # of expected passes1 # of unexpected failures1
[Bug target/63810] gcc sets incorrect macro for OS X deployment targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63810 --- Comment #32 from Iain Sandoe --- Author: iains Date: Thu Jun 13 18:53:05 2019 New Revision: 272260 URL: https://gcc.gnu.org/viewcvs?rev=272260=gcc=rev Log: Darwin, Driver - Improve processing of macosx-version-min= For PR target/63810 some improvements were made in the parsing of the version string at the point it's used to define the built-in __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__. This is fine, but the specs processing also uses the version, and specs version-compare doesn't like leading zeros on components. This means that while we succeed in processing -mmacosx-version-min=010.2.99 on compile lines, it fails for any other line that uses the value as part of a spec (in particular, link lines fail). To fix this, we need to apply a bit of clean-up to the version that's presented to the driver, and push that back into the command line opts. The value can come from four places: 1. User-entered on the command line 2. User-entered as MACOSX_DEPLOYMENT_TARGET= environment var. 3. Absent those two 3a For self-hosting systems, look-up from the kernel 3b For cross-compilers, as a default supplied at configure time. We apply the clean-up to all 4 (although it shouldn't really be needed for the cases under 3). We also supply a test-case that adapts to the target-version of the system, so that the link requirements are met by the SDK in use (if you try to link i686-darwin9 on an x86-64-darwin18 SDK, it will fail). gcc/ 2019-06-13 Iain Sandoe * config/darwin-driver.c (validate_macosx_version_min): New. (darwin_default_min_version): Cleanup and validate supplied version. (darwin_driver_init): Likewise and push cleaned version into opts. gcc/testsuite/ 2019-06-13 Iain Sandoe * gcc.dg/darwin-minversion-link.c: New test. Added: trunk/gcc/testsuite/gcc.dg/darwin-minversion-link.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin-driver.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/77820] A jump threading opportunity with conditionals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77820 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #4 from Jeffrey A. Law --- Fixed on the trunk.
[Bug other/90871] New: [10 regression] g++.dg/ext/altivec-15.C fails after r272236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90871 Bug ID: 90871 Summary: [10 regression] g++.dg/ext/altivec-15.C fails after r272236 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98 -maltivec -mno-vsx -S -o altivec-15.s /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:10:18: error: 'Float' does not name a type; did you mean 'float'? /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:8:1: error: two or more data types in declaration of 'SinCos' /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:12:30: error: 'Float' was not declared in this scope; did you mean 'float'? /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:12:43: error: 'Float' was not declared in this scope; did you mean 'float'? /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:12:50: error: 'sine' was not declared in this scope; did you mean 'signed'? /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:12:56: error: 'Float' was not declared in this scope; did you mean 'float'? /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:12:63: error: 'cosine' was not declared in this scope compiler exited with status 1 PASS: g++.dg/ext/altivec-15.C -std=gnu++98 (test for errors, line 10) PASS: g++.dg/ext/altivec-15.C -std=gnu++98 (test for errors, line 12) FAIL: g++.dg/ext/altivec-15.C -std=gnu++98 (test for excess errors) Excess errors: /home/seurer/gcc/gcc-test/gcc/testsuite/g++.dg/ext/altivec-15.C:8:1: error: two or more data types in declaration of 'SinCos'
[Bug fortran/90870] new test case gfortran.dg/deferred_character_33.f90 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90870 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Thomas Koenig --- The patch itself is safe, but apparently the test case hit some bug that was fixed later. So, removing the test case. Thanks for the heads-up!
[Bug target/90871] [10 regression] g++.dg/ext/altivec-15.C fails after r272236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90871 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #2 from Paolo Carlini --- Should be fixed.
[Bug target/90871] [10 regression] g++.dg/ext/altivec-15.C fails after r272236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90871 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-13 Component|other |target Ever confirmed|0 |1
[Bug target/90871] [10 regression] g++.dg/ext/altivec-15.C fails after r272236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90871 --- Comment #1 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Jun 13 17:10:03 2019 New Revision: 272250 URL: https://gcc.gnu.org/viewcvs?rev=272250=gcc=rev Log: 2019-06-13 Paolo Carlini PR target/90871 * g++.dg/ext/altivec-15.C: Add dg-error directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/altivec-15.C
[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810 --- Comment #9 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 13 17:45:52 2019 New Revision: 272254 URL: https://gcc.gnu.org/viewcvs?rev=272254=gcc=rev Log: 2019-06-13 Steven G. Kargl PR fortran/88810 * dependency.c (gfc_dep_resolver): Re-arrange code to make the logic a bit more transparent. Fix 2 nearby formatting issues. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c
[Bug bootstrap/90873] New: [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 Bug ID: 90873 Summary: [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11, sparc-sun-solaris2.11 Target: i386-pc-solaris2.11, sparc-sun-solaris2.11 Build: i386-pc-solaris2.11, sparc-sun-solaris2.11 Between 20190612 (r272223) and 20190613 (r272247), 32-bit bootstrap got broken on Solaris/x86 and Solaris/SPARC: /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c: In function 'bool simplify_rotate(gimple_stmt_iterator*)': /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c:1650:40: error: '#'target_mem_ref' not supported by dump_expr#' may be used uninitialized in this function [-Werror=maybe-uninitialized] 1650 | if (cdef_arg2[i] == def_arg2[1 - i] | ~~^ /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c:1695:28: error: '#'target_mem_ref' not supported by dump_expr#' may be used uninitialized in this function [-Werror=maybe-uninitialized] 1695 | if (tem == def_arg2[1 - i] || tem == def_arg2_alt[1 - i]) | ~~^ /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c:1718:22: error: '#'target_mem_ref' not supported by dump_expr#' may be used uninitialized in this function [-Werror=maybe-uninitialized] 1718 | if (cdef_code[1 - i] == BIT_AND_EXPR | ~~~^ /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c:1719:43: error: '#'target_mem_ref' not supported by dump_expr#' may be used uninitialized in this function [-Werror=maybe-uninitialized] 1719 | && tree_fits_shwi_p (cdef_arg2[1 - i]) |~~~^ /vol/gcc/src/hg/trunk/local/gcc/tree-ssa-forwprop.c:1722:36: error: '#'target_mem_ref' not supported by dump_expr#' may be used uninitialized in this function [-Werror=maybe-uninitialized] 1722 | && TREE_CODE (cdef_arg1[1 - i]) == SSA_NAME) |^ A amd64-pc-solaris2.11 bootstrap is already running make check, but sparcv9-sun-solaris2.11 bootstrap breaks later building the 32-bit libgomp: #‘target_mem_ref’ not supported by expression#’/vol/gcc/src/hg/trunk/local/libgomp/ordered.c: In function ‘gomp_doacross_ull_init’: /vol/gcc/src/hg/trunk/local/libgomp/ordered.c:607:23: error: may be used uninitialized in this function [-Werror=maybe-uninitialized] 607 |shift_count += bits[i - 1]; | ^~~
[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 Rainer Orth changed: What|Removed |Added Target Milestone|--- |10.0
[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 --- Comment #6 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Jun 13 18:07:53 2019 New Revision: 272255 URL: https://gcc.gnu.org/viewcvs?rev=272255=gcc=rev Log: 2019-06-13 Steven G. Kargl PR fortran/89344 * expr.c (gfc_check_vardef_context): Check for INTENT(IN) variable in SELECT TYPE construct. 2019-06-13 Steven G. Kargl PR fortran/89344 * gfortran.dg/pr89344.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr89344.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89344] uncaught programmer error: polymorphic variable is INTENT(IN) but assigned to without error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89344 --- Comment #7 from kargl at gcc dot gnu.org --- Fixed on trunk. Thanks for the bug report. Leavin PR open as I haven't decided if I will back port the patch to other branches.
[Bug fortran/68544] ICE trying to pass derived type constructor as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68544 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #12 from kargl at gcc dot gnu.org --- Fixed on trunk. Thanks for bug report. Sorry it took so long to fix.
[Bug c++/90875] warnings about switch values outside range don't have associated option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90875 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-13 Ever confirmed|0 |1
[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878 --- Comment #2 from Uroš Bizjak --- Why is this PR marked as a regression?
[Bug c++/90880] New: compile error instead of SFINAE with non-public member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880
Bug ID: 90880
Summary: compile error instead of SFINAE with non-public member
variables
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Hello,
I searched for bugs related to SFINAE, and I do not think that this one has
already reported:
#include
#include
template struct status : std::false_type{};
template struct status :
std::true_type {};
struct s1{int member;};
struct s2{int _member;};
class c1{int member;};
class c2{int _member;};
int main(){
static_assert(status::value, "has member");
static_assert(!status::value, "has no member");
(void) status::value;
//static_assert(status::value, "has member");
static_assert(!status::value, "has no member");
}
-
This code compiles fine with msvc and clang, but with g++ it triggers following
compiler error:
--
bug.cpp: In substitution of ‘template struct status [with T = c1]’:
bug.cpp:15:19: required from here
bug.cpp:6:58: error: ‘int c1::member’ is private within this context
template struct status :
std::true_type {};
~^~~~
bug.cpp:10:14: note: declared private here
class c1{int member;};
^~
bug.cpp: In instantiation of ‘struct status’:
bug.cpp:15:19: required from here
bug.cpp:6:58: error: ‘int c1::member’ is private within this context
template struct status :
std::true_type {};
~^~~~
bug.cpp:10:14: note: declared private here
class c1{int member;};
^~
bug.cpp:6:58: error: ‘int c1::member’ is private within this context
template struct status :
std::true_type {};
~^~~~
bug.cpp:10:14: note: declared private here
class c1{int member;};
--
While the error message could be correct (more on that later), the issue is
that because of SFINAE, this should never be compile-error (just like for `s2`
and `c2`).
I've commented `static_assert(status::value, "has member");` out, because
clang++ compiles `status::value` to false, while msvc to true.
I'm not 100% sure which of the compiler is correct, but `status::value`
should definitively compile.
[Bug tree-optimization/84577] snprintf with null buffer not eliminated when return value is in a known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84577 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-06-14 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Working on a solution.
[Bug c/90882] Possible security breach through undefined behavior when treating boolean as int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90882 --- Comment #4 from Andrew Pinski --- Since it is undefined behavior both GCC and clang are correct. -fsanitizer=undefined can be detect it at runtime. This code is undefined in two different ways really. you also violate C aliasing rules (though it is turned off until -O2 and above).
[Bug fortran/90578] Wrong code with LSHIFT and optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90578 --- Comment #8 from anlauf at gcc dot gnu.org --- Patch at https://gcc.gnu.org/ml/fortran/2019-06/msg00077.html
[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878 --- Comment #3 from H.J. Lu --- (In reply to Uroš Bizjak from comment #2) > Why is this PR marked as a regression? GCC 7 doesn't use memory: [hjl@gnu-cfl-1 sse-move]$ cat x.s .file "x.i" .text .p2align 4,,15 .globl foo .type foo, @function foo: .LFB0: .cfi_startproc vmovd %xmm0, %eax vxorpd %xmm0, %xmm0, %xmm0 andl$2147483647, %eax vmovd %eax, %xmm1 vcvtss2sd %xmm1, %xmm0, %xmm0 ret .cfi_endproc .LFE0: .size foo, .-foo .ident "GCC: (GNU) 7.3.1 20181128" .section.note.GNU-stack,"",@progbits [hjl@gnu-cfl-1 sse-move]$
[Bug c++/90880] compile error instead of SFINAE with non-public member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-13 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- (In reply to Federico Kircheis from comment #1) > After researching a little bit more, I've convinced myself that > `status::value` should be false, as `decltype` has no special rules for > accessing private data, thus clang is correct. Agreed. And G++ should accept it.
[Bug target/90878] New: [8/9/10 Regression] integer -> SSE register move isn't generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878
Bug ID: 90878
Summary: [8/9/10 Regression] integer -> SSE register move isn't
generated
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: skpgkp1 at gmail dot com, ubizjak at gmail dot com
Target Milestone: ---
[hjl@gnu-cfl-1 sse-move]$ cat x.i
union ieee754_float
{
float f;
struct
{
unsigned int mantissa:23;
unsigned int exponent:8;
unsigned int negative:1;
} ieee;
};
double
foo (float f)
{
union ieee754_float u;
u.f = f;
u.ieee.negative = 0;
return u.f;
}
[hjl@gnu-cfl-1 sse-move]$ /usr/gcc-9.1.1-x32-tuning/bin/gcc -S -O2
-march=skylake x.i
[hjl@gnu-cfl-1 sse-move]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
vmovd %xmm0, %eax
andl$2147483647, %eax
movl%eax, -4(%rsp)
vcvtss2sd -4(%rsp), %xmm0, %xmm0
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 9.1.1 20190517"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 sse-move]$
Skylake cost has
2, 2, /* SSE->integer and integer->SSE moves
*/
which are the same cost as the normal register move. But integer->SSE
isn't used since ix86_register_move_cost has
/* Moves between SSE/MMX and integer unit are expensive. */
if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)
|| SSE_CLASS_P (class1) != SSE_CLASS_P (class2))
/* ??? By keeping returned value relatively high, we limit the number
of moves between integer and MMX/SSE registers for all targets.
Additionally, high value prevents problem with x86_modes_tieable_p(),
where integer modes in MMX/SSE registers are not tieable
because of missing QImode and HImode moves to, from or between
MMX/SSE registers. */
return MAX (8, MMX_CLASS_P (class1) || MMX_CLASS_P (class2)
? ix86_cost->mmxsse_to_integer : ix86_cost->ssemmx_to_integer);
integer->SSE is always 8 which much more expensive than integer
register store whose cost is 3.
[Bug tree-optimization/90879] New: fold zero-equality of strcmp between a longer string and a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90879
Bug ID: 90879
Summary: fold zero-equality of strcmp between a longer string
and a smaller array
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Here's another strcmp optimization opportunity (besides pr90626 and pr90876)
that could easily be taken advantage of on top of the solution for pr83026.
When strncmp is called with a bound in excess of the sizes of the pointed-to
arrays, GCC eliminates the pointless excessive bound and transforms the strncpy
call to strcpy (in a subset of the cases when this is possible). This can be
seen in function f in the test case below.
But when, in a call to strcmp or strncmp, a string argument is longer than the
size of the array it's being compared with for equality, the optimization fails
to take advantage of the fact that a string that long cannot be equal to one
stored in a smaller array. This can be seen in function g in the test case.
The existing optimization has all the smarts to go this extra step, it just
doesn't do it.
$ cat a.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout a.c
extern char a[4];
void f (void)
{
if (0 == __builtin_strncmp (a, "12345", 8)) // transformed to strcmp
__builtin_abort (); // when the whole expression
could be folded to zero
}
void g (void)
{
if (0 == __builtin_strcmp (a, "123456")) // not folded
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=0)
f ()
{
int _1;
[local count: 1073741824]:
_1 = __builtin_strcmp (, "12345");
if (_1 == 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=1)
g ()
{
int _1;
[local count: 1073741824]:
_1 = __builtin_strcmp (, "123456");
if (_1 == 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return;
}
[Bug target/90878] [8/9/10 Regression] integer -> SSE register move isn't generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90878
--- Comment #1 from H.J. Lu ---
If we make integer register store more expensive, this testcase will
regress:
[hjl@gnu-cfl-1 unroll]$ cat x.i
void
foo (long p2, long *diag, long d, long i)
{
long k;
k = p2 < 3 ? p2 + p2 : p2 + 3;
while (i < k)
diag[i++] = d;
}
[hjl@gnu-cfl-1 unroll]$ make
/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-wip-debug/build-x86_64-linux/gcc/ -O3
-march=skylake -S x.i
[hjl@gnu-cfl-1 unroll]$ cat x.s
.file "x.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
leaq(%rdi,%rdi), %rax
leaq3(%rdi), %r8
cmpq$2, %rdi
cmovle %rax, %r8
cmpq%rcx, %r8
jle .L10
movq%rcx, %rax
notq%rax
movq%r8, %r9
addq%r8, %rax
subq%rcx, %r9
cmpq$3, %rax
jbe .L5
movq%r9, %rdi
shrq$2, %rdi
vmovq %rdx, %xmm1
leaq(%rsi,%rcx,8), %rax
salq$5, %rdi
vpbroadcastq%xmm1, %ymm0
addq%rax, %rdi
.p2align 4,,10
.p2align 3
.L6:
vmovdqu %ymm0, (%rax)
addq$32, %rax
cmpq%rdi, %rax
jne .L6
movq%r9, %rax
andq$-4, %rax
addq%rax, %rcx
cmpq%rax, %r9
je .L9
vzeroupper
.L5:
leaq1(%rcx), %rax
movq%rdx, (%rsi,%rcx,8)
cmpq%r8, %rax
jge .L10
leaq2(%rcx), %rdi
movq%rdx, (%rsi,%rax,8)
cmpq%rdi, %r8
jle .L10
addq$3, %rcx
movq%rdx, (%rsi,%rdi,8)
cmpq%rcx, %r8
jle .L10
movq%rdx, (%rsi,%rcx,8)
ret
.p2align 4,,10
.p2align 3
.L9:
vzeroupper
.L10:
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 10.0.0 20190613 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 unroll]$
since higher integer register store cost will reduce loop unroll count.
[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #5 from Steve Ellcey --- This had also broken the glibc build on my aarch64 system but the patch in Comment #4 seems to have fixed things and I can build again.
[Bug c++/90881] New: -Wunused-value false positive with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881
Bug ID: 90881
Summary: -Wunused-value false positive with
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.kircheis at gmail dot com
Target Milestone: ---
Hello,
consider
#include
template struct status : std::false_type{};
template struct status :
std::true_type {};
struct s1{int member;};
struct s2{int _member;};
int main(){
static_assert(status::value, "has member");
static_assert(!status::value, "has no member");
}
When compiling with `-Wall` (or `-Wunused-value`), g++ generates following
warning:
--
bug.cpp: In instantiation of ‘struct status’:
bug.cpp:11:26: required from here
bug.cpp:5:58: warning: left operand of comma operator has no effect
[-Wunused-value]
template struct status :
std::true_type {};
~^~~~
bug.cpp:5:58: warning: left operand of comma operator has no effect
[-Wunused-value]
--
The warning is incorrect, as removing the left operand changes the behaviour of
the program, thus it has effect:
#include
template struct status : std::false_type{};
template struct status : std::true_type {};
// ! removed left operand
struct s1{int member;};
struct s2{int _member;};
int main(){
static_assert(status::value, "has member");
static_assert(!status::value, "has no member");
}
Does not compile:
--
bug.cpp: In function ‘int main()’:
bug.cpp:12:16: error: static assertion failed: has no member
static_assert(!status::value, "has no member");
--
because `status` does not detect anymore if the member-variable `member` is
present or not.
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-14 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirmed. We shouldn't give that warning in unevaluated contexts (decltype, sizeof, etc.) because unevaluated operands have no effects at all, with or without the comma operator.
[Bug c++/90880] compile error instead of SFINAE with non-public member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880 --- Comment #3 from Federico Kircheis --- (In reply to Jonathan Wakely from comment #2) > (In reply to Federico Kircheis from comment #1) > > After researching a little bit more, I've convinced myself that > > `status::value` should be false, as `decltype` has no special rules for > > accessing private data, thus clang is correct. > > Agreed. And G++ should accept it. Thank you. Sorry if linking to external bug trackers in comments is bad practice, but I did not saw any rule about it. Since it could be interesting for those having this issue, here is the bug report for MSVC: https://developercommunity.visualstudio.com/content/problem/607019/incorrect-decltype-on-non-public-member-variables.html
[Bug tree-optimization/90662] strlen of a string in a vla plus offset not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90662 --- Comment #6 from Martin Sebor --- Author: msebor Date: Fri Jun 14 02:07:02 2019 New Revision: 272281 URL: https://gcc.gnu.org/viewcvs?rev=272281=gcc=rev Log: PR tree-optimization/90662 - strlen of a string in a vla plus offset not folded gcc/ChangeLog: PR tree-optimization/90662 * tree-ssa-strlen.c (get_stridx): Convert fold_build2 operands to the same type. gcc/testsuite/ChangeLog: PR tree-optimization/90662 * gcc.dg/pr90866-2.c: New test. * gcc.dg/pr90866.c: Ditto. Added: trunk/gcc/testsuite/gcc.dg/pr90866-2.c trunk/gcc/testsuite/gcc.dg/pr90866.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-strlen.c
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90662 Resolution|--- |FIXED --- Comment #11 from Martin Sebor --- Patch committed in r272281.
[Bug bootstrap/90873] [10 regression] -Wmaybe-uninitialized warning in gcc/tree-ssa-forwprop.c breaks 32-bit bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90873 --- Comment #4 from Jan Hubicka --- Author: hubicka Date: Thu Jun 13 21:56:37 2019 New Revision: 272273 URL: https://gcc.gnu.org/viewcvs?rev=272273=gcc=rev Log: PR bootstrap/90873 * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Also check that dbase is not TARGET_MEM_REF. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-alias.c
[Bug target/87281] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 --- Comment #3 from joseph at codesourcery dot com --- No idea. I ran all-languages builds for all glibc ABIs as a one-off when adding the --full-gcc option to build-many-glibcs.py, and reported the GCC bugs that showed up. The idea was that since maintainers of such language libraries (and of libsanitizer) had concerns about glibc header changes sometimes breaking the build of those libraries, I'd provide the facility in build-many-glibcs.py for people with those concerns to run a bot testing them with current glibc, in order to detect problems quickly rather than only after an issue gets into a glibc release. But I was definitely leaving it up to people with such concerns to deal with running the bot, and I don't think anyone has taken up doing so.
[Bug c++/90880] compile error instead of SFINAE with non-public member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880 --- Comment #1 from Federico Kircheis --- After researching a little bit more, I've convinced myself that `status::value` should be false, as `decltype` has no special rules for accessing private data, thus clang is correct. If someone could confirm this, I could try to make a bug report to the msvc team
[Bug c++/90881] -Wunused-value false positive in SFINAE context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90881 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Patch: https://gcc.gnu.org/ml/gcc-patches/2019-06/msg00810.html
[Bug c/90882] Possible security breach through undefined behavior when treating boolean as int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90882 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- If you use -fsanitizer=undefined, it will be able to find this incorrect behavior.
[Bug target/87281] qsort checking ICE in ia64_reorg building libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87281 --- Comment #4 from Jason Duerstock --- As of r272229 I can't replicate this: $ ~/glibc/scripts/build-many-glibcs.py bmg --full-gcc compilers ia64-linux-gnu PASS: compilers-ia64-linux-gnu check-host-libraries ... PASS: compilers-ia64-linux-gnu done
[Bug ipa/90401] Missed propagation of by-ref constant argument to callee function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90401 Feng Xue changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Feng Xue --- Fixed
[Bug tree-optimization/89713] Optimize away an empty loop whose finiteness can not be analytically determined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89713 Feng Xue changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Feng Xue --- Fixed
[Bug tree-optimization/90866] New: [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866
Bug ID: 90866
Summary: [10 Regression] ICE in fold_binary_loc, at
fold-const.c:9827 since r272197
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org
Target Milestone: ---
Following is causing ICE:
$ cat ~/Programming/testcases/slp.i
int a[1024], b[1024];
void
fn1() {
int i = 0;
for (;; i++) {
b[16] = a[i * 16 + 10];
b[i * 16 + 11] = a[i * 16 + 11] * 3;
b[i * 16 + 12] = a[i * 16 + 12] * 4;
b[i * 16 + 13] = a[i * 16 + 13] * 4;
b[i * 16 + 14] = a[i * 16 + 14] * 3;
}
}
$ ./xgcc -B. -fno-tree-loop-optimize -O3 ~/Programming/testcases/slp.i
during GIMPLE pass: strlen
/home/marxin/Programming/testcases/slp.i: In function ‘fn1’:
/home/marxin/Programming/testcases/slp.i:4:1: internal compiler error: in
fold_binary_loc, at fold-const.c:9827
4 | fn1() {
| ^~~
0xc9487c fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marxin/Programming/gcc/gcc/fold-const.c:9827
0xca00d8 fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
/home/marxin/Programming/gcc/gcc/fold-const.c:12338
0x144ddd1 get_stridx
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:327
0x1456bc1 handle_pointer_plus
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:3216
0x14584bb strlen_check_and_optimize_stmt
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:3725
0x14597db strlen_dom_walker::before_dom_children(basic_block_def*)
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:4009
0x1e6bae2 dom_walker::walk(basic_block_def*)
/home/marxin/Programming/gcc/gcc/domwalk.c:312
0x1459a70 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-strlen.c:4089
[Bug tree-optimization/90866] [10 Regression] ICE in fold_binary_loc, at fold-const.c:9827 since r272197
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90866 Martin Liška changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-06-13 Known to work||9.1.0 Target Milestone|--- |10.0 Ever confirmed|0 |1 Known to fail||10.0
