[Bug tree-optimization/80345] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345 Markus Trippelsdorf changed: What|Removed |Added Status|WAITING |NEW Known to work||6.3.1, 7.0 --- Comment #4 from Markus Trippelsdorf --- 6.3 branch works fine. Only 5.4.1 is affected. So it looks like a missing backport.
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345
Markus Trippelsdorf changed:
What|Removed |Added
Known to work||4.8.5
Version|6.3.0 |5.3.1
Summary|ICE in |[5 Regression] ICE in
|rewrite_use_nonlinear_expr |rewrite_use_nonlinear_expr
|with -O2|with -O2
--- Comment #5 from Markus Trippelsdorf ---
typedef long mp_limb_signed_t;
fn1(mp_limb_signed_t p1) {
int *a = 1;
mp_limb_signed_t i, j;
i = 0;
for (; i < p1; i++) {
j = 0;
for (; j <= i; j++)
*a++ = 0;
j = i + 1;
for (; j < p1; j++)
a++;
}
}
fn2() { fn1(fn2); }
gcc-4.8.5 is fine.
[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390
--- Comment #18 from rguenther at suse dot de ---
On Fri, 7 Apr 2017, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390
>
> --- Comment #16 from Jakub Jelinek ---
> Has somebody the benchmark around to retry with current trunk, with
> -f{,no-}split-paths and compare that to some older trunk and gcc6?
On a broadwell machine I get (-O3 -march=native)
gcc6: 5507.42 Mflops
gcc7: 4787.26 Mflops
gcc7: 5435.08 Mflops [-fno-split-paths]
so the RTL if-conversion works now unless inhibited by path splitting.
What path splitting does is mostly undone by loop disambiguation which
re-creates the merger so path splitting just made the loop multiple
exit (without simplifying the duplicated exit condition).
So we can add more heuristics to tame down loop splitting, for example
never duplicating a joiner that has an exit. Or adding to the
quite stupid if-cvt mitigation code (missing the minmax case).
Or add even more outs to the threading opportunity detection code...
We currently find that
t_175 = PHI
in the merger exposes a threading opportunity because it has one
arg that is unchanged over the latch (t_184 over 6->8) and it has
a use in the threading destination (in the controlling condition
even).
This all just exposes that path splitting is not well integrated
into what it tries to expose (threading). IMHO it should have been
part of backwards/forward threading.
But that ship has sailed (Jeff approved it).
I've tried to fixup after the MIA authors. But well.
I can fixup by removing the pass again. Or adding more oddball
heuristics. This case which seems important for x86_64 is
for (i=j+1; i t)
{
jp = i;
t = ab;
}
}
so reducing MAX plus remembering the index of the maximum value.
We're not phiopt-ing that to MAX because it might not be profitable
(the condition has to remain). So path splitting could be profitable
on some archs. IFF we wouldn't re-create that shared latch
right afterwards anyway (and forget to propagate single-arg PHIs
resulting from the BB duplication).
[Bug middle-end/80341] gcc miscompiles division of signed char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80341 --- Comment #8 from Richard Biener --- Author: rguenth Date: Fri Apr 7 08:20:24 2017 New Revision: 246756 URL: https://gcc.gnu.org/viewcvs?rev=246756&root=gcc&view=rev Log: 2017-04-07 Richard Biener PR middle-end/80341 * tree.c (get_unwidened): Also handle ! for_type case for INTEGER_CSTs. * convert.c (do_narrow): Split out from ... (convert_to_integer_1): ... here. Do not pass final truncation type to get_unwidened for TRUNC_DIV_EXPR. * gcc.dg/torture/pr80341.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr80341.c Modified: trunk/gcc/ChangeLog trunk/gcc/convert.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c
[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80350 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-07 Ever confirmed|0 |1 Known to fail||5.4.1, 6.3.1, 7.0.1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug sanitizer/80349] UBSAN: compile time crash with "type mismatch in binary expression" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349 Richard Biener changed: What|Removed |Added Keywords||ice-checking Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-07 Ever confirmed|0 |1 Known to fail||6.3.1, 7.0.1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug sanitizer/80348] [6/7 Regression] UBSAN: compile time crash in ubsan_instrument_division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80348 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-07 Known to work||5.4.1 Target Milestone|--- |6.4 Summary|UBSAN: compile time crash |[6/7 Regression] UBSAN: |in |compile time crash in |ubsan_instrument_division |ubsan_instrument_division Ever confirmed|0 |1 Known to fail||6.3.1, 7.0.1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug sanitizer/80166] SANITIZER_INTERCEPT_GETGROUPS modifies list when size is 0 Out-of-bounds write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80166 Martin Liška changed: What|Removed |Added Known to work||7.0 Known to fail||5.4.0, 6.3.0 --- Comment #5 from Martin Liška --- Fixed on trunk, queued for backporting.
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |5.5 --- Comment #6 from Richard Biener --- So what fixed it on the GCC 6 branch? Can't reproduce it with my copies of 6.1, 6.2 or 6.3.
[Bug sanitizer/80348] [6/7 Regression] UBSAN: compile time crash in ubsan_instrument_division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80348 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r230365 (Merge C++ delayed folding branch.).
[Bug sanitizer/80349] UBSAN: compile time crash with "type mismatch in binary expression" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Same as PR80348, started with r230365 (Merge C++ delayed folding branch.).
[Bug tree-optimization/80344] -Wuninitialized triggering on a ctor on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80344
Richard Biener changed:
What|Removed |Added
Target||arm
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-04-07
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. The IL we warn about is
B::B() (struct B * const this)
{
struct
{
._0 e;
int i;
int j;
} D.4784;
[100.00%]:
D.4784 ={v} {CLOBBER};
MEM[(struct &)this_2(D)] = D.4784;
return this_2(D);
and we warn about the MEM[(struct &)this_2(D)] = D.4784; assignment.
The warning is clearly correct as the A members are not initialized.
Did you reduce a testcase too far?
[Bug middle-end/80341] [5/6 Regression] gcc miscompiles division of signed char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80341 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||7.0.1 Target Milestone|--- |5.5 Summary|gcc miscompiles division of |[5/6 Regression] gcc |signed char |miscompiles division of ||signed char --- Comment #9 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345 --- Comment #7 from Денис Крыськов --- Created attachment 41149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41149&action=edit gcc5.4 -v stderr/stdout
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345 --- Comment #8 from Денис Крыськов --- (In reply to Markus Trippelsdorf from comment #4) > 6.3 branch works fine. > Only 5.4.1 is affected. So it looks like a missing backport. Microarch is Haswell. I failed to reproduce ICE with gcc 6.3. If this is due to my mistake, I am sorry. I attached gcc 5.4 stderr/stdout.
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345 --- Comment #9 from Martin Liška --- Fixed on trunk (in between 5-base and 6-base) by r233269.
[Bug tree-optimization/80334] [5/6 Regression] Segfault when taking address of copy of unaligned struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Apr 7 08:47:43 2017 New Revision: 246757 URL: https://gcc.gnu.org/viewcvs?rev=246757&root=gcc&view=rev Log: 2017-04-07 Richard Biener PR tree-optimization/80334 * g++.dg/torture/pr80334.C: Use __BIGGEST_ALIGNMENT__ for alignas on stack. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr80334.C
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345 --- Comment #10 from Richard Biener --- Which makes it a dup of PR68021.
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345
Martin Liška changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #11 from Martin Liška ---
(In reply to Martin Liška from comment #9)
> Fixed on trunk (in between 5-base and 6-base) by r233269.
Unfortunately, simple back-porting of the patch does not work on gcc-5 branch:
internal compiler error: in get_computation_aff, at tree-ssa-loop-ivopts.c:3129
fn2() { fn1(fn2); }
^
0xe39a33 get_computation_aff
../../gcc/tree-ssa-loop-ivopts.c:3129
0xe39d48 get_computation_at
../../gcc/tree-ssa-loop-ivopts.c:3205
0xe39dba get_computation
../../gcc/tree-ssa-loop-ivopts.c:3217
0xe421ba rewrite_use_nonlinear_expr
../../gcc/tree-ssa-loop-ivopts.c:6459
0xe42c3a rewrite_use
../../gcc/tree-ssa-loop-ivopts.c:6699
0xe42d13 rewrite_uses
../../gcc/tree-ssa-loop-ivopts.c:6732
0xe43d16 tree_ssa_iv_optimize_loop
../../gcc/tree-ssa-loop-ivopts.c:7062
0xe43dce tree_ssa_iv_optimize()
../../gcc/tree-ssa-loop-ivopts.c:7094
Adding Bin Cheng.
[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80350 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Working on that.
[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390 --- Comment #19 from vincenzo Innocente --- Could you please have a look also to c++ and lto: this is what I get on my skylake: for c++ or lto -fno-split-paths pessimizes [innocent@vinavx3 scimark2TMP]$ gcc -march=native -Wall -Ofast *.c -lm ; ./a.out | grep LU LU Mflops: 5920.14(M=100, N=100) [innocent@vinavx3 scimark2TMP]$ gcc -march=native -Wall -Ofast *.c -lm -fno-split-paths ; ./a.out | grep LU LU Mflops: 6136.33(M=100, N=100) [innocent@vinavx3 scimark2TMP]$ gcc -march=native -Wall -Ofast *.c -lm -flto ; ./a.out | grep LU LU Mflops: 5809.93(M=100, N=100) [innocent@vinavx3 scimark2TMP]$ gcc -march=native -Wall -Ofast *.c -lm -flto -fno-split-paths ; ./a.out | grep LU LU Mflops: 5630.24(M=100, N=100) [innocent@vinavx3 scimark2TMP]$ c++ -march=native -Wall -Ofast *.c -lm ; ./a.out | grep LU LU Mflops: 6001.47(M=100, N=100) [innocent@vinavx3 scimark2TMP]$ c++ -march=native -Wall -Ofast *.c -lm -fno-split-paths ; ./a.out | grep LU LU Mflops: 5920.14(M=100, N=100) [innocent@vinavx3 scimark2TMP]$ c++ -march=native -Wall -Ofast *.c -lm -flto; ./a.out | grep LU LU Mflops: 5434.16(M=100, N=100) [innocent@vinavx3 scimark2TMP]$ c++ -march=native -Wall -Ofast *.c -lm -flto -fno-split-paths ; ./a.out | grep LU LU Mflops: 5434.16(M=100, N=100)
[Bug sanitizer/80348] [6/7 Regression] UBSAN: compile time crash in ubsan_instrument_division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80348 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 #4 from Marek Polacek --- Mine.
[Bug rtl-optimization/80352] New: Improper reload of operands with equiv pseudo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80352
Bug ID: 80352
Summary: Improper reload of operands with equiv pseudo
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ra
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: thopre01 at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
Target Milestone: ---
Hi,
r235184 introduced the ability to reload expressions with equiv but reload
happens incorrectly due to some failed assumptions:
1) Endless series of reloads due to creation of pseudo reg with NO_REGS class
When a memory constraint is matched to an expression with equiv, the
alternative is given the default class: NO_REGS. In curr_insn_transform the
memory reload code is skipped because MEM_P is false and instead the default
register reload is used. It creates a pseudo reg with the class from goal_alt
hence NO_REGS. When analyzing this new insn process_alt_operands fails the
in_class_p check for the register because its class (NO_REGS) have no intersect
with GENERAL_REGS (from the subunion). A reload must then happen again, etc.
2) reload_nregs is increased despite needing a register reload
reload_nregs is only updated when !no_regs_p is true. Hence the cost of memory
reload is not accurate. Fortunately the fix from Jiong in r237277 seems to be
enough to avoid memory reload when register reload is available.
I believe the issues are due to the assumption that memory constraint does not
need a register and has different reload. However with expression with equiv a
register reload is needed followed by a register spill. Regarding 2) winreg
could be used to signal a register is needed and the check to update
reload_nregs use winreg instead. I am not sure how to solve 1) but I believe
get_reload_reg should no be called with NO_REGS class (an assert could be added
btw).
The issue can be reproduced on arm-none-eabi target by compiling the below code
with arm-none-eabi-gcc -S -mcpu=cortex-m7 -mthumb -O2:
void fn2(int *);
void fn1() {
int a[1];
while (1)
fn2(a);
}
[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80350 --- Comment #3 from Martin Liška --- I've got patch that I'm going to submit to mailing list soon.
[Bug c++/80353] New: AVX512: _mm512_slli_epi32, the last argument must be an 8-bit immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80353
Bug ID: 80353
Summary: AVX512: _mm512_slli_epi32, the last argument must be
an 8-bit immediate
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m...@sven-woop.de
Target Milestone: ---
GCC trunk does not propagate constant to _mm512_slli_epi32 intrinsic:
#include
#define __forceinline inline __attribute__((always_inline))
__forceinline __m128i sll128 ( const __m128i a, const int& n ) { return
_mm_slli_epi32(a, n); }
__forceinline __m256i sll256 ( const __m256i a, const int& n ) { return
_mm256_slli_epi32(a, n); }
__forceinline __m512i sll512 ( const __m512i a, const int& n ) { return
_mm512_slli_epi32(a, n); }
void test()
{
__m128i a = sll128(_mm_set1_epi32(0),4);
__m256i b = sll256(_mm256_set1_epi32(0),4);
__m512i c = sll512(_mm512_set1_epi32(0),4);
}
The first two work, while the last not. Output is:
test.cpp:8:73: error: the last argument must be an 8-bit immediate
__forceinline __m512i sll512 ( const __m512i a, const int& n ) { return
_mm512_slli_epi32(a, n); }
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #21 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #20)
> (In reply to Thomas Preud'homme from comment #19)
> > (In reply to Richard Biener from comment #18)
> > > (In reply to Thomas Preud'homme from comment #17)
> > > > (In reply to rguent...@suse.de from comment #16)
> > > > > On Thu, 23 Mar 2017, thopre01 at gcc dot gnu.org wrote:
> > > > > >
> > > > > > Funnily this led back to the Cortex-M0+ reduced testcase. With the
> > > > > > patch in
> > > > > > comment #13 applied we can still see a difference in the push (one
> > > > > > register
> > > > > > pushed Vs 0).
> > > > >
> > > > > I can't reproduce zero pushes here I get three with/without
> > > > > -fno-code-hoisting. code hoisting hoists the two loads inside
> > > > > the switch before it so we have
> > > >
> > > > Ooops my apologize, it needs more flags indeed. -O2 -funroll-all-loops
> > > > shows
> > > > 2 registers pushed Vs 1 when -fno-code-hoisting is added.
> > >
> > > Still can't reproduce. I've configured with
> > >
> > > /space/rguenther/src/svn/gcc-7-branch/configure
> > > --target=arm-suse-linux-gnueabi --disable-libstdcxx-pch
> > > --enable-languages=c,c++
> > >
> > > and am using
> > >
> > > ./cc1 -quiet cortex-m0plus_reproducer.c -O2 -mcpu=cortex-m0plus -mthumb -I
> > > include -fdump-tree-pre-details -fdump-tree-crited -fdump-tree-all
> > > -funroll-all-loops -fno-code-hoisting
> >
> > Oh my bad, I was still not clear enough. I meant using the Cortex-M0+
> > testcase but build it for Cortex-M7. Hopefully with -mcpu=cortex-m7 you
> > should see a difference between with and without code hoisting.
>
> I do. Two pushes with code hoisting and three without. Changed -mcpu above
> to -mcpu=cortex-m7.
I can see this behavior for Cortex-M0+ indeed but the results are different for
Cortex-M7 for me:
% arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
-mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
-fdump-tree-all -funroll-all-loops
% grep push cortex-m0plus_reproducer.s
push{r4, r5}
% arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
-mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
-fdump-tree-all -funroll-all-loops -fno-code-hoisting
% grep push cortex-m0plus_reproducer.s
push{r4}
Would you mind checking again?
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #22 from Thomas Preud'homme ---
(In reply to Thomas Preud'homme from comment #21)
>
> I can see this behavior for Cortex-M0+ indeed but the results are different
> for Cortex-M7 for me:
>
>
> % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> -fdump-tree-all -funroll-all-loops
>
> % grep push cortex-m0plus_reproducer.s
> push{r4, r5}
>
>
>
> % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> -fdump-tree-all -funroll-all-loops -fno-code-hoisting
>
> % grep push cortex-m0plus_reproducer.s
> push{r4}
>
> Would you mind checking again?
btw, this toolchain was built on 2017-04-04 in case that's the issue.
[Bug c/80354] New: Poor support to silence -Wformat-truncation=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80354
Bug ID: 80354
Summary: Poor support to silence -Wformat-truncation=1
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sbergman at redhat dot com
Target Milestone: ---
With recent trunk
> $ gcc --version
> gcc (GCC) 7.0.1 20170406 (experimental)
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
and test.c
> #include
> struct S { char a[3]; };
> void f1(struct S * s, int n) {
> char b[2];
> (void) snprintf(b, sizeof (b), "%s%d", s->a, n);
> }
> void f2(struct S * s, int n) {
> char b[2];
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> (void) e;
> }
> void f3(struct S * s, int n) {
> char b[2];
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> if (e >= sizeof (b)) {}
> }
> void f4(struct S * s, int n) {
> char b[2];
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> if (e >= sizeof (b)) b[1] = 0;
> }
the documentation of -Wformat-truncation=1 (as enabled by -Wall) in
gcc/doc/invoke.texi states it "warns only about calls to bounded functions
whose return value is unused [...]"
However, depending on e.g. -O0 vs. -Og, GCC will warn about f1 (gcc -Wall -O0
-c test.c) or even f1, f2, f3 (gcc -Wall -Og -c test.c), while I think it
should warn about none:
> test.c: In function ‘f1’:
> test.c:5:39: warning: ‘%d’ directive output may be truncated writing between
> 1 and 11 bytes into a region of size between 0 and 2 [-Wformat-truncation=]
> (void) snprintf(b, sizeof (b), "%s%d", s->a, n);
>^~
> test.c:5:5: note: ‘snprintf’ output between 2 and 14 bytes into a destination
> of size 2
> (void) snprintf(b, sizeof (b), "%s%d", s->a, n);
> ^~~
> test.c: In function ‘f2’:
> test.c:9:40: warning: ‘%d’ directive output may be truncated writing between
> 1 and 11 bytes into a region of size between 0 and 2 [-Wformat-truncation=]
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> ^~
> test.c:9:9: note: ‘snprintf’ output between 2 and 14 bytes into a destination
> of size 2
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> ^
> test.c: In function ‘f3’:
> test.c:14:40: warning: ‘%d’ directive output may be truncated writing between
> 1 and 11 bytes into a region of size between 0 and 2 [-Wformat-truncation=]
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> ^~
> test.c:14:9: note: ‘snprintf’ output between 2 and 14 bytes into a
> destination of size 2
> int e = snprintf(b, sizeof (b), "%s%d", s->a, n);
> ^
[Bug target/80353] AVX512: _mm512_slli_epi32, the last argument must be an 8-bit immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80353 Markus Trippelsdorf changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-07 CC||kyukhin at gcc dot gnu.org, ||trippels at gcc dot gnu.org Component|c++ |target Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Only happens with -O0.
[Bug ipa/80212] [5/6/7 Regression] ICE: error: comdat-local function called by virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80212 --- Comment #1 from Martin Liška --- Author: marxin Date: Fri Apr 7 10:36:21 2017 New Revision: 246759 URL: https://gcc.gnu.org/viewcvs?rev=246759&root=gcc&view=rev Log: Add function part to a same comdat group (PR ipa/80212). 2017-04-07 Martin Liska PR ipa/80212 * g++.dg/ipa/pr80212.C: New test. 2017-04-07 Martin Liska PR ipa/80212 * ipa-split.c (split_function): Add function part to a same comdat group. Added: trunk/gcc/testsuite/g++.dg/ipa/pr80212.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/80344] -Wuninitialized triggering on a ctor on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80344 --- Comment #2 from Marek Polacek --- Created attachment 41150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41150&action=edit orig.ii.gz This is the original .ii file.
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #23 from rguenther at suse dot de ---
On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
>
> --- Comment #22 from Thomas Preud'homme ---
> (In reply to Thomas Preud'homme from comment #21)
> >
> > I can see this behavior for Cortex-M0+ indeed but the results are different
> > for Cortex-M7 for me:
> >
> >
> > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > -fdump-tree-all -funroll-all-loops
> >
> > % grep push cortex-m0plus_reproducer.s
> > push{r4, r5}
> >
> >
> >
> > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > -fdump-tree-all -funroll-all-loops -fno-code-hoisting
> >
> > % grep push cortex-m0plus_reproducer.s
> > push{r4}
> >
> > Would you mind checking again?
>
> btw, this toolchain was built on 2017-04-04 in case that's the issue.
Ok, I can reproduce it now. With the proposed patch to fix the other
case it regresses with -fno-code-hoisting though (comment #9 plus fix).
Note that code-hosting is simply doing it's job here, hoisting common
code out of a switch.
[Bug tree-optimization/80344] -Wuninitialized triggering on a ctor on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80344
--- Comment #3 from Richard Biener ---
I believe this is exposed by inlining
this_14(D)->http_ver = Http::ProtocolVersion (); [return slot optimization]
as
D.148385 ={v} {CLOBBER};
MEM[(struct &)this_14(D) + 4] = D.148385;
this_14(D)->http_ver.protocol = 1;
this_14(D)->http_ver.major = 1;
this_14(D)->http_ver.minor = 1;
which is
AnyP::ProtocolVersion Http::ProtocolVersion() ()
{
[0.00%]:
AnyP::ProtocolVersion::ProtocolVersion (&, 1, 1, 1);
return ;
inlined into like
AnyP::ProtocolVersion Http::ProtocolVersion() ()
{
struct ProtocolVersion * D.148207;
[100.00%]:
MEM[(struct &)&] ={v} {CLOBBER};
.protocol = 1;
.major = 1;
.minor = 1;
_7 = &;
return ;
not sure how this ends up happening. Smaller testcase appreciated ;)
The above is from 029t.einline vs. 028t.inline_param1.
[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80345
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #12 from amker at gcc dot gnu.org ---
(In reply to Martin Liška from comment #11)
> (In reply to Martin Liška from comment #9)
> > Fixed on trunk (in between 5-base and 6-base) by r233269.
>
> Unfortunately, simple back-porting of the patch does not work on gcc-5
> branch:
>
> internal compiler error: in get_computation_aff, at
> tree-ssa-loop-ivopts.c:3129
> fn2() { fn1(fn2); }
> ^
> 0xe39a33 get_computation_aff
> ../../gcc/tree-ssa-loop-ivopts.c:3129
> 0xe39d48 get_computation_at
> ../../gcc/tree-ssa-loop-ivopts.c:3205
> 0xe39dba get_computation
> ../../gcc/tree-ssa-loop-ivopts.c:3217
> 0xe421ba rewrite_use_nonlinear_expr
> ../../gcc/tree-ssa-loop-ivopts.c:6459
> 0xe42c3a rewrite_use
> ../../gcc/tree-ssa-loop-ivopts.c:6699
> 0xe42d13 rewrite_uses
> ../../gcc/tree-ssa-loop-ivopts.c:6732
> 0xe43d16 tree_ssa_iv_optimize_loop
> ../../gcc/tree-ssa-loop-ivopts.c:7062
> 0xe43dce tree_ssa_iv_optimize()
> ../../gcc/tree-ssa-loop-ivopts.c:7094
>
> Adding Bin Cheng.
The assertion depends on some other refactoring no on GCC 5 branch. It should
be safe just remove that assertion on gcc 5, I will test a backport.
Thanks.
[Bug target/79889] ICE in aarch64_process_target_attr, at config/aarch64/aarch64.c:9537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79889 --- Comment #1 from Martin Liška --- Author: marxin Date: Fri Apr 7 11:20:01 2017 New Revision: 246760 URL: https://gcc.gnu.org/viewcvs?rev=246760&root=gcc&view=rev Log: Error message on target attribute on aarch64 target (PR target/79889). 2017-04-07 Martin Liska PR target/79889 * g++.dg/ext/mv8.C: Add aarch64* targets. 2017-04-07 Martin Liska PR target/79889 * config/aarch64/aarch64.c (aarch64_process_target_attr): Show error message instead of an ICE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/mv8.C
[Bug ipa/80212] [5/6/7 Regression] ICE: error: comdat-local function called by virtual
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80212 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-07 Known to work||7.0 Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0 --- Comment #2 from Martin Liška --- Fixed on trunk so far, queued for back-porting.
[Bug target/79889] ICE in aarch64_process_target_attr, at config/aarch64/aarch64.c:9537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79889 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Last reconfirmed||2017-4-7 Resolution|--- |FIXED --- Comment #2 from Martin Liška --- Fixed.
[Bug tree-optimization/80344] -Wuninitialized triggering on a ctor on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80344
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #4 from Richard Biener ---
So it happens when inlining
MEM[(struct &)&] ={v} {CLOBBER};
and substituting &this_14(D)->http_ver for the address. Then we trigger
id->regimplify = true; but in the end we simplify it to
MEM[(struct &)this_14(D) + 4] ={v} {CLOBBER};
and gimple_regimplify_operands wrecks this via
else if (i == 2
&& is_gimple_assign (stmt)
&& num_ops == 2
&& get_gimple_rhs_class (gimple_expr_code (stmt))
== GIMPLE_SINGLE_RHS)
gimplify_expr (&op, &pre, NULL,
rhs_predicate_for (gimple_assign_lhs (stmt)),
fb_rvalue);
and {CLOBBER} is not is_gimple_mem_rhs_or_call.
Testing
Index: gcc/gimplify.c
===
--- gcc/gimplify.c (revision 246757)
+++ gcc/gimplify.c (working copy)
@@ -493,7 +493,9 @@ is_gimple_mem_rhs_or_call (tree t)
if (is_gimple_reg_type (TREE_TYPE (t)))
return is_gimple_val (t);
else
-return (is_gimple_val (t) || is_gimple_lvalue (t)
+return (is_gimple_val (t)
+ || is_gimple_lvalue (t)
+ || TREE_CLOBBER_P (t)
|| TREE_CODE (t) == CALL_EXPR);
}
[Bug target/80353] AVX512: _mm512_slli_epi32, the last argument must be an 8-bit immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80353 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- At -O0 that is a user error, the intrinsics have to be called with a compile time constant and -O0 doesn't perform optimizations. That is e.g. why the intrinsics that need that are at -O0 not defined as inline functions, but as preprocessor macros. So, just pass to those constants rather than variables, or say constexpr vars or something similar where you are guaranteed it is evaluated to constant at compile time. Or compile with optimizations.
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #24 from Thomas Preud'homme ---
(In reply to rguent...@suse.de from comment #23)
> On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
> >
> > --- Comment #22 from Thomas Preud'homme ---
> > (In reply to Thomas Preud'homme from comment #21)
> > >
> > > I can see this behavior for Cortex-M0+ indeed but the results are
> > > different
> > > for Cortex-M7 for me:
> > >
> > >
> > > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > > -fdump-tree-all -funroll-all-loops
> > >
> > > % grep push cortex-m0plus_reproducer.s
> > > push{r4, r5}
> > >
> > >
> > >
> > > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > > -fdump-tree-all -funroll-all-loops -fno-code-hoisting
> > >
> > > % grep push cortex-m0plus_reproducer.s
> > > push{r4}
> > >
> > > Would you mind checking again?
> >
> > btw, this toolchain was built on 2017-04-04 in case that's the issue.
>
> Ok, I can reproduce it now. With the proposed patch to fix the other
> case it regresses with -fno-code-hoisting though (comment #9 plus fix).
>
> Note that code-hosting is simply doing it's job here, hoisting common
> code out of a switch.
I understand that. Code is smaller so it's definitely worthwhile at -Os. But it
sometimes lead to worse performance due to more spilling.
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #25 from rguenther at suse dot de ---
On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
>
> --- Comment #24 from Thomas Preud'homme ---
> (In reply to rguent...@suse.de from comment #23)
> > On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
> > >
> > > --- Comment #22 from Thomas Preud'homme ---
> > > (In reply to Thomas Preud'homme from comment #21)
> > > >
> > > > I can see this behavior for Cortex-M0+ indeed but the results are
> > > > different
> > > > for Cortex-M7 for me:
> > > >
> > > >
> > > > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > > > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > > > -fdump-tree-all -funroll-all-loops
> > > >
> > > > % grep push cortex-m0plus_reproducer.s
> > > > push{r4, r5}
> > > >
> > > >
> > > >
> > > > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > > > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > > > -fdump-tree-all -funroll-all-loops -fno-code-hoisting
> > > >
> > > > % grep push cortex-m0plus_reproducer.s
> > > > push{r4}
> > > >
> > > > Would you mind checking again?
> > >
> > > btw, this toolchain was built on 2017-04-04 in case that's the issue.
> >
> > Ok, I can reproduce it now. With the proposed patch to fix the other
> > case it regresses with -fno-code-hoisting though (comment #9 plus fix).
> >
> > Note that code-hosting is simply doing it's job here, hoisting common
> > code out of a switch.
>
> I understand that. Code is smaller so it's definitely worthwhile at -Os. But
> it
> sometimes lead to worse performance due to more spilling.
But there's no good way to estimate that. We have tons of transforms
that have the issue of being "sometimes worse"
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
--- Comment #26 from Thomas Preud'homme ---
(In reply to rguent...@suse.de from comment #25)
> On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
> >
> > --- Comment #24 from Thomas Preud'homme ---
> > (In reply to rguent...@suse.de from comment #23)
> > > On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote:
> > >
> > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155
> > > >
> > > > --- Comment #22 from Thomas Preud'homme
> > > > ---
> > > > (In reply to Thomas Preud'homme from comment #21)
> > > > >
> > > > > I can see this behavior for Cortex-M0+ indeed but the results are
> > > > > different
> > > > > for Cortex-M7 for me:
> > > > >
> > > > >
> > > > > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > > > > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > > > > -fdump-tree-all -funroll-all-loops
> > > > >
> > > > > % grep push cortex-m0plus_reproducer.s
> > > > > push{r4, r5}
> > > > >
> > > > >
> > > > >
> > > > > % arm-none-linux-gnueabi-gcc -S ~/cortex-m0plus_reproducer.c -O2
> > > > > -mcpu=cortex-m7 -mthumb -fdump-tree-pre-details -fdump-tree-crited
> > > > > -fdump-tree-all -funroll-all-loops -fno-code-hoisting
> > > > >
> > > > > % grep push cortex-m0plus_reproducer.s
> > > > > push{r4}
> > > > >
> > > > > Would you mind checking again?
> > > >
> > > > btw, this toolchain was built on 2017-04-04 in case that's the issue.
> > >
> > > Ok, I can reproduce it now. With the proposed patch to fix the other
> > > case it regresses with -fno-code-hoisting though (comment #9 plus fix).
> > >
> > > Note that code-hosting is simply doing it's job here, hoisting common
> > > code out of a switch.
> >
> > I understand that. Code is smaller so it's definitely worthwhile at -Os.
> > But it
> > sometimes lead to worse performance due to more spilling.
>
> But there's no good way to estimate that. We have tons of transforms
> that have the issue of being "sometimes worse"
Yes true.
By the way, your first patch did improve things a bit. If it's not too invasive
could it be possible to commit it for GCC 7?
I think I'll try the approach you suggested in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498#c10 and see if I get some
better results.
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #27 from rguenther at suse dot de --- On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 > > --- Comment #26 from Thomas Preud'homme --- > Yes true. > > By the way, your first patch did improve things a bit. If it's not too > invasive > could it be possible to commit it for GCC 7? It's not really in the shape for being committable. I'll see if I can come up with sth better early in stage1 that might be back-portable. > I think I'll try the approach you suggested in > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498#c10 and see if I get some > better results. For this case distance is minimal already so I don't expect you can do anything (there's also not really separate dataflow for hoisting).
[Bug tree-optimization/80155] [7 regression] Performance regression with code hoisting enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 --- Comment #28 from Thomas Preud'homme --- (In reply to rguent...@suse.de from comment #27) > On Fri, 7 Apr 2017, thopre01 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80155 > > > > --- Comment #26 from Thomas Preud'homme --- > > Yes true. > > > > By the way, your first patch did improve things a bit. If it's not too > > invasive > > could it be possible to commit it for GCC 7? > > It's not really in the shape for being committable. I'll see if I can > come up with sth better early in stage1 that might be back-portable. Thanks. > > > I think I'll try the approach you suggested in > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498#c10 and see if I get some > > better results. > > For this case distance is minimal already so I don't expect you can > do anything (there's also not really separate dataflow for hoisting). If I remember well the key in the benchmark was that the basic block where the code was hoisted from could be reached by a much longer path. So although it was hoisted to a direct predecessor, sometime that value had to be kept for a very long time.
[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607 --- Comment #10 from Christophe Monat --- (In reply to Ramana Radhakrishnan from comment #9) Hello Ramana, Is there a plan to have this patch delivered upstream at some point in the near future ? Best regards, --C
[Bug sanitizer/80349] UBSAN: compile time crash with "type mismatch in binary expression" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349 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
[Bug sanitizer/80349] [6/7 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80349 Marek Polacek changed: What|Removed |Added Target Milestone|--- |6.4 Summary|UBSAN: compile time crash |[6/7 Regression] UBSAN: |with "type mismatch in |compile time crash with |binary expression" message |"type mismatch in binary ||expression" message
[Bug c++/80265] __builtin_{memcmp,memchr,strlen} are not usable in constexpr functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80265
Pedro Alves changed:
What|Removed |Added
CC||palves at redhat dot com
--- Comment #4 from Pedro Alves ---
Meanwhile, maybe this could be punted to the library, making use of
__builtin_constant as a building block? I don't know what guarantees
__builtin_constant officially gives in constexpr, but at least the below
compiles fine with GCC 7, in both -std=gnu++14 and -std=gnu++17 modes.
#include
constexpr size_t constexpr_strlen(const char* s) {
return *s ? constexpr_strlen (s + 1) + 1 : 0;
}
template
struct ce_char_traits : std::char_traits {
using char_type = typename std::char_traits::char_type;
static constexpr std::size_t length(const char_type* s) noexcept {
if (__builtin_constant_p (s))
return constexpr_strlen (s);
return __builtin_strlen (s);
}
};
static_assert (ce_char_traits::length ("") == 0);
static_assert (ce_char_traits::length ("hello") == 5);
static_assert (ce_char_traits::length ("he\0llo") == 2);
static const char array[] = "foo";
static_assert (ce_char_traits::length (array) == 3);
[Bug sanitizer/80350] UBSAN changes code semantics when -fno-sanitize-recover=undefined is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80350 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org
[Bug target/71607] [5/6/7 Regression] [ARM] ice due to forbidden enabled attribute dependency on instruction operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607 Tejas Belagod changed: What|Removed |Added CC||belagod at gcc dot gnu.org --- Comment #11 from Tejas Belagod --- (In reply to Christophe Monat from comment #10) > (In reply to Ramana Radhakrishnan from comment #9) > > Hello Ramana, > > Is there a plan to have this patch delivered upstream at some point in the > near future ? > > Best regards, > --C Hi Christophe, We're working on a fix for this. We'll keep you updated on the progress. Thanks, Tejas.
[Bug rtl-optimization/80343] [7 Regression] ICE in extract_constrain_insn, at recog.c:2213 (error: insn does not satisfy its constraints)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80343
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-04-07
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Doesn't fail with additional -mno-lra.
The insn in question is:
(define_insn "and3_imm"
[(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
(and:GPR (match_operand:GPR 1 "gpc_reg_operand" "%r")
(match_operand:GPR 2 "logical_const_operand" "n")))
(clobber (match_scratch:CC 3 "=x"))]
"rs6000_gen_cell_microcode
&& !rs6000_is_valid_and_mask (operands[2], mode)"
"andi%e2. %0,%1,%u2"
[(set_attr "type" "logical")
(set_attr "dot" "yes")])
where "x" constraint is:
(define_register_constraint "x" "CR0_REGS"
"@internal")
In *.ira we have:
(insn 84 75 78 6 (parallel [
(set (reg:SI 330 [239])
(and:SI (reg/v:SI 199 [ gt ])
(const_int 5 [0x5])))
(clobber (scratch:CC))
]) "pr80343.c":21 165 {andsi3_imm}
(nil))
and -mno-lra reload turns it into:
(insn 84 75 78 6 (parallel [
(set (reg:SI 16 16 [239])
(and:SI (reg/v:SI 31 31 [orig:199 gt ] [199])
(const_int 5 [0x5])))
(clobber (reg:CC 68 0))
]) "pr80343.c":21 165 {andsi3_imm}
(nil))
But LRA turns it into:
(insn 333 328 308 8 (parallel [
(set (reg:SI 15 15 [263])
(and:SI (reg/v:SI 31 31 [orig:199 gt ] [199])
(const_int 5 [0x5])))
(clobber (scratch:CC))
]) "pr80343.c":21 165 {andsi3_imm}
(nil))
- note the SCRATCH in there instead of (reg:CC 68), so it fails the RTL
checking at the end of LRA.
[Bug c/80354] Poor support to silence -Wformat-truncation=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80354 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Martin Sebor --- This is the expected behavior. Whether or not a function's return value is considered used depends on optimization. Simply assigning it to a variable and doing nothing with it that affects the behavior of the program is not in this situation considered using it. This applies to all the cases here. This isn't a property of the warning itself but rather that of its dependency on prior optimizations (which eliminate code that doesn't actually use the value). The idea is that programs that allow output truncation to go undetected are likely buggy. Besides actually handling the truncation (e.g., branching on it and taking some action that does affect the behavior), storing the return value in a volatile variable and reading it should suppress it.
[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70478 --- Comment #8 from Vladimir Makarov --- Author: vmakarov Date: Fri Apr 7 16:01:50 2017 New Revision: 246764 URL: https://gcc.gnu.org/viewcvs?rev=246764&root=gcc&view=rev Log: 2017-04-07 Vladimir Makarov PR rtl-optimization/70478 * lra-constraints.c (process_alt_operands): Disfavor alternative insn memory operands. 2017-04-07 Vladimir Makarov PR rtl-optimization/70478 * gcc.target/s390/pr70478.c: New. Added: trunk/gcc/testsuite/gcc.target/s390/pr70478.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/70703] [6 regression] Regression in register usage on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703 --- Comment #15 from Vladimir Makarov --- Author: vmakarov Date: Fri Apr 7 16:06:28 2017 New Revision: 246765 URL: https://gcc.gnu.org/viewcvs?rev=246765&root=gcc&view=rev Log: 2017-04-07 Vladimir Makarov PR rtl-optimization/70703 * ira-color.c (update_conflict_hard_regno_costs): Use int64_t instead of HOST_WIDE_INT. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c
[Bug fortran/68569] ICE with automatic character object and DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68569
--- Comment #4 from Nicolas Koenig ---
And here is a fix for the first test case (z2a.f90), already regression tested
on x86_64-pc-linux-gnu:
Index: resolve.c
===
--- resolve.c (revision 246743)
+++ resolve.c (working copy)
@@ -14947,6 +14947,12 @@ check_data_variable (gfc_data_variable *var, locus
}
}
+ if (e->ts.type == BT_CHARACTER && e->ts.u.cl->length
+&& e->ts.u.cl->length->expr_type == EXPR_VARIABLE)
+gfc_error("Nonconstant length character at %L in DATA statement",
+ &e->where);
+
+
if (e->rank == 0 || has_pointer)
{
mpz_init_set_ui (size, 1);
[Bug tree-optimization/80344] [7 Regression] -Wuninitialized triggering on a ctor on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80344 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0 Summary|-Wuninitialized triggering |[7 Regression] |on a ctor on ARM|-Wuninitialized triggering ||on a ctor on ARM
[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002 --- Comment #13 from Eric Botcazou --- Author: ebotcazou Date: Fri Apr 7 16:26:52 2017 New Revision: 246767 URL: https://gcc.gnu.org/viewcvs?rev=246767&root=gcc&view=rev Log: Backport from mainline 2017-04-05 Eric Botcazou PR target/78002 * config/aarch64/aarch64.c (aarch64_emit_probe_stack_range): Replace ptr_mode with Pmode throughout. * config/aarch64/aarch64.md (probe_stack_range_
[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78002 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|7.0 |6.4 --- Comment #14 from Eric Botcazou --- Fixed everywhere.
[Bug target/80355] New: Improve __builtin_shuffle on AVX512F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80355
Bug ID: 80355
Summary: Improve __builtin_shuffle on AVX512F
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
As mentioned in https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00375.html
we emit inefficient code for:
typedef long long V __attribute__((vector_size (64)));
typedef int W __attribute__((vector_size (64)));
W f0 (W x) {
return __builtin_shuffle (x, (W) { 8, 9, 10, 11, 12, 13, 14, 15, 0, 1, 2, 3,
4, 5, 6, 7 });
}
V f1 (V x) {
return __builtin_shuffle (x, (V) { 4, 5, 6, 7, 0, 1, 2, 3 });
}
e.g.
vmovdqa64 .LC0(%rip), %zmm1
vpermd %zmm0, %zmm1, %zmm0
or
vmovdqa64 .LC1(%rip), %zmm1
vpermq %zmm0, %zmm1, %zmm0
while we could use vpshufi64x2 instruction instead, which has just immediate.
[Bug c++/80356] New: [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80356 Bug ID: 80356 Summary: [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827 Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 41151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41151&action=edit preprocessed source the reduced test case from PR79294 doesn't ICE anymore, but the unreduced test case still does. Here's a new reduction. Seen with trunk 20170407. $ cat python.ii template struct a; template a < b $ g++ -c -std=c++11 python.ii python.ii:2:35: internal compiler error: in convert_nontype_argument, at cp/pt.c:6827 template a < b ^ 0x5f167b convert_nontype_argument ../../src/gcc/cp/pt.c:6826 0x5f167b convert_template_argument ../../src/gcc/cp/pt.c:7667 0x5f215c coerce_template_parms ../../src/gcc/cp/pt.c:8127 0x5f4bb9 lookup_template_class_1 ../../src/gcc/cp/pt.c:8663 0x5f4bb9 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*, int, int) ../../src/gcc/cp/pt.c:9008 0x68edbd finish_template_type(tree_node*, tree_node*, int) ../../src/gcc/cp/semantics.c:3151 0x63e5f4 cp_parser_template_id ../../src/gcc/cp/parser.c:15495 0x63e74f cp_parser_class_name ../../src/gcc/cp/parser.c:21953 0x648d27 cp_parser_qualifying_entity ../../src/gcc/cp/parser.c:6286 0x648d27 cp_parser_nested_name_specifier_opt ../../src/gcc/cp/parser.c:5972 0x635660 cp_parser_constructor_declarator_p ../../src/gcc/cp/parser.c:25945 0x635660 cp_parser_decl_specifier_seq ../../src/gcc/cp/parser.c:13319 0x635d05 cp_parser_single_declaration ../../src/gcc/cp/parser.c:26625 0x651a9c cp_parser_template_declaration_after_parameters ../../src/gcc/cp/parser.c:26319 0x6517fb cp_parser_explicit_template_declaration ../../src/gcc/cp/parser.c:26554 0x6517fb cp_parser_template_declaration_after_export ../../src/gcc/cp/parser.c:26573 0x636389 cp_parser_declaration ../../src/gcc/cp/parser.c:12449 0x65be8b cp_parser_declaration_seq_opt ../../src/gcc/cp/parser.c:12376 0x65c172 cp_parser_translation_unit ../../src/gcc/cp/parser.c:4366 0x65c172 c_parse_file() ../../src/gcc/cp/parser.c:38427 Please submit a full bug report, with preprocessed source if appropriate.
[Bug target/80357] New: [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80357 Bug ID: 80357 Summary: [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen on trunk 20170407 on powerpc64le-linux-gnu, fails with -O3, works with -O2 $ gcc -c -O3 -msecure-plt igb_ethdev.i /<>/drivers/net/e1000/igb_ethdev.c: In function 'eth_igb_rss_reta_query': /<>/drivers/net/e1000/igb_ethdev.c:3374:1: internal compiler error: in model_update_limit_points_in_group, at haifa-sched.c:1982 0x10eadd3f model_update_limit_points_in_group ../../src/gcc/haifa-sched.c:1982 0x10eadd3f model_update_limit_points ../../src/gcc/haifa-sched.c:1993 0x10eadd3f schedule_insn ../../src/gcc/haifa-sched.c:4077 0x10eb276b schedule_block(basic_block_def**, void*) ../../src/gcc/haifa-sched.c:6944 0x106e7c13 schedule_region ../../src/gcc/sched-rgn.c:3169 0x106e7c13 schedule_insns() ../../src/gcc/sched-rgn.c:3506 0x106e8087 schedule_insns() ../../src/gcc/sched-rgn.c:3491 0x106e8087 rest_of_handle_sched ../../src/gcc/sched-rgn.c:3710 0x106e8087 execute ../../src/gcc/sched-rgn.c:3818 Please submit a full bug report, with preprocessed source if appropriate.
[Bug c++/80356] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80356 Markus Trippelsdorf changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-04-07 CC||jason at gcc dot gnu.org, ||trippels at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- To make it really valid: template struct a; template a x; Confirmed.
[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390 --- Comment #20 from Jakub Jelinek --- So, Richard, any thoughts on what can be done split paths to avoid this?
[Bug rtl-optimization/80358] New: [7 Regression] ICE (cc1 killed) building glib with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80358 Bug ID: 80358 Summary: [7 Regression] ICE (cc1 killed) building glib with -O3 on powerpc64le-linux-gnu Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 41152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41152&action=edit preprocessed source seen with trunk 20170407 on powerpc64le-linux-gnu while building glib with -O3. With -O2 the build succeeds almost immediately, with -O3 it eats up all available memory. $ gcc -c -g -O3 gkeyfilesettingsbackend.i #0 0x10259e1c in ggc_internal_alloc (size=24, f=0x0, s=0, n=1) at ../../src/gcc/ggc-page.c:1327 #1 0x106cbe94 in ggc_internal_alloc ( s=) at ../../src/gcc/ggc.h:134 #2 ggc_alloc_rtx_def_stat (s=) at ../../src/gcc/ggc.h:280 #3 rtx_alloc_stat_v (code=, extra=) at ../../src/gcc/rtl.c:203 #4 0x103aeadc in gen_raw_REG (mode=, regno=) at ../../src/gcc/emit-rtl.c:436 #5 0x103afa98 in gen_reg_rtx (mode=) at ../../src/gcc/emit-rtl.c:1063 #6 0x1061964c in maybe_legitimize_operand (op=0x3fffd7d0, opno=0, icode=) at ../../src/gcc/optabs.c:6944 #7 maybe_legitimize_operands (icode=, opno=0, nops=3, ops=0x3fffd7d0) at ../../src/gcc/optabs.c:7017 #8 0x10619ad8 in maybe_gen_insn (icode=CODE_FOR_adddi3, nops=3, ops=0x3fffd7d0) at ../../src/gcc/optabs.c:7035 #9 0x1061d430 in expand_binop_directly (mode=DImode, binoptab=add_optab, op0=0x3fffb637db60, op1=0x3ffe5dee9360, target=0x0, unsignedp=1, methods=OPTAB_LIB_WIDEN, last=0x3ffe5e963c40) at ../../src/gcc/optabs.c:1071 #10 0x1061d8dc in expand_binop (mode=, binoptab=, op0=0x3fffb637db60, op1=0x3ffe5dee9360, target=0x0, unsignedp=, methods=) at ../../src/gcc/optabs.c:1150 #11 0x103efe3c in force_operand (value=0x3ffe5e971ed8, target=0x0) at ../../src/gcc/expr.c:7316 #12 0x10a9a260 in rs6000_legitimize_address (x=, oldx=, mode=) at ../../src/gcc/config/rs6000/rs6000.c:9008 #13 0x10745edc in default_addr_space_legitimize_address (x=, oldx=, mode=, as=) at ../../src/gcc/targhooks.c:1349 #14 0x103cb1e4 in memory_address_addr_space (mode=, x=0x3ffe5e971ec0, as=) at ../../src/gcc/explow.c:432 #15 0x103acdb4 in change_address_1 (memref=0x3fffb63c32d0, mode=DImode, addr=, validate=1, inplace=false) at ../../src/gcc/emit-rtl.c:2152 #16 0x103b1a54 in adjust_address_1 (memref=0x3fffb63c32d0, mode=DImode, offset=33388112, validate=, adjust_address=, adjust_object=, size=8) at ../../src/gcc/emit-rtl.c:2288 #17 0x10a82d80 in expand_block_compare (operands=) at ../../src/gcc/config/rs6000/rs6000.c:19743 #18 0x10c8efd0 in gen_cmpmemsi (operand0=0x3fffb63c3300, operand1=0x3fffb63c32d0, operand2=0x3fffb63c32e8, operand3=0x3fffb5900470, operand4=0x3fffb5900500) at ../../src/gcc/config/rs6000/rs6000.md:9242 #19 0x10619cfc in insn_gen_fn::operator() (a4=0x3fffb5900500, a3=0x3fffb5900470, a2=0x3fffb63c32e8, a1=0x3fffb63c32d0, a0=0x3fffb63c3300, this=) at ../../src/gcc/recog.h:304 #20 maybe_gen_insn (icode=, nops=, ops=0x3fffdea0) at ../../src/gcc/optabs.c:7051 #21 0x10626aa8 in maybe_expand_insn (icode=, nops=, ops=) at ../../src/gcc/optabs.c:7078 #22 0x103e1830 in expand_cmpstrn_or_cmpmem (icode=, target=, arg1_rtx=0x3fffb63c32d0, arg2_rtx=0x3fffb63c32e8, arg3_type=0x3fffb58b0150, arg3_rtx=0x3fffb5900470, align=8) at ../../src/gcc/expr.c:1905 #23 0x103ec644 in emit_block_cmp_via_cmpmem (align=8, target=0x0, len_type=0x3fffb58b0150, len=0x3fffb5900470, y=0x3fffb63c32e8, x=0x3fffb63c32d0) at ../../src/gcc/expr.c:1927 #24 emit_block_cmp_hints (x=0x3fffb63c32d0, y=0x3fffb63c32e8, len=0x3fffb5900470, len_type=0x3fffb58b0150, target=0x0, equality_only=, y_cfn=0x0, y_cfndata=0x0) at ../../src/gcc/expr.c:1972 #25 0x10285014 in expand_builtin_memcmp (result_eq=, target=0x0, exp=0x3fffb6306a50) at ../../src/gcc/builtins.c:4231 #26 expand_builtin (exp=0x3fffb6306a50, target=, subtarget=, mode=, ignore=) at ../../src/gcc/builtins.c:6754 #27 0x103e7d34 in expand_expr_real_1 (exp=, target=, tmode=, modifier=, alt_rtl=, inner_reference_p=) at ../../src/gcc/expr.c:10822 #28 0x103e97e4 in expand_expr_real (exp=0x3fffb6306a50, target=0x0, tmode=DImode, modifier=, alt_rtl=0x0, inner_reference_p=false) at ../../src/gcc/expr.c:8071 #29 0x103fa0c4 in expand_expr (modifier=, mode=DImode, target=0x0, exp=0x3fffb6306a50) at ../../src/gcc/expr.h:276 #30 expand_expr_real_2 (ops=0x3fffe4d0, target=0x3fffb637d968
[Bug c++/80356] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80356 --- Comment #2 from Markus Trippelsdorf --- (gdb) p debug_tree(type) unit size align 32 symtab 0 alias set -1 canonical type 0x770b55e8 precision 32 min max pointer_to_this > type_6 QI size unit size align 8 symtab 0 alias set -1 canonical type 0x770ccc78 arg-types chain chain >>> reference_to_this > unsigned type_6 DI size constant 64> unit size constant 8> align 64 symtab 0 alias set -1 canonical type 0x77209888> (gdb) p debug_tree(expr->typed.type) unit size align 32 symtab 0 alias set -1 canonical type 0x770b55e8 precision 32 min max pointer_to_this > type_6 QI size constant 8> unit size constant 1> align 8 symtab 0 alias set -1 canonical type 0x770ccc78 arg-types chain chain >>> reference_to_this >
[Bug fortran/80291] [OOP] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80291 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||janus at gcc dot gnu.org Target Milestone|5.5 |7.0 Summary|[5/6/7 Regression] internal |[OOP] ICE in |compiler error: in |gfc_conv_expr_descriptor, |gfc_conv_expr_descriptor, |at |at |fortran/trans-array.c:6662 |fortran/trans-array.c:6662 | --- Comment #5 from janus at gcc dot gnu.org --- (In reply to snowfed from comment #4) > You mention a revision which apparently gave a compile-time error but I'm > fairly certain the code is valid. I agree. AFAICS the code should be valid. So, unless there is an old version which accepts this code, it is actually not a regression.
[Bug fortran/80291] [OOP] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6662
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80291 --- Comment #6 from janus at gcc dot gnu.org --- Here is a slightly further reduced version of the test case: module test implicit none type cell_t contains procedure :: get_mask end type contains elemental logical function get_mask (self, inode) implicit none class(cell_t), intent(in) :: self integer, intent(in) :: inode get_mask = .false. end function end module program gfortran_bug use test implicit none class(cell_t), pointer :: cell associate(mask => cell%get_mask([1,2])) end associate end
[Bug fortran/68829] [5/6/7 Regression] Segfaults with -Ofast due to large array on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68829 --- Comment #6 from Uroš Bizjak --- Polyhedron 11 test_fpu2 currently segfaults on Fedora 25 due to this problem: [uros@localhost source]$ /ssd/uros/gcc-build/gcc/xgcc -B /ssd/uros/gcc-build/gcc -S -Ofast -funroll-loops test_fpu2.f90 [uros@localhost source]$ gfortran test_fpu2.s [uros@localhost source]$ ulimit -s unlimited [uros@localhost source]$ ./a.out Benchmark running, hopefully as only ACTIVE task Test1: Gauss - 1000 ( 250x 250) inverts in 14.892 seconds Err=0. Test2: Crout - 1000 ( 250x 250) inverts in 16.343 seconds Err=0. Test3: Crout -2 (2000x2000) inverts in 9.769 seconds Err=0. Test4: Lapack -2 (2000x2000) inverts in 7.548 seconds Err=0.0013 Total = 48.6 sec [uros@localhost source]$ ulimit -s 8192 [uros@localhost source]$ ./a.out Benchmark running, hopefully as only ACTIVE task Test1: Gauss - 1000 ( 250x 250) inverts in 14.810 seconds Err=0. Test2: Crout - 1000 ( 250x 250) inverts in 16.538 seconds Err=0. Segmentation fault (core dumped) Also on Suse polyhedron tester [1]: 6 Apr 2017 15:03:29 gfortran_lin - Compile test_fpu2 command=/gcc/spec/sb-vangelis-head-64/x86_64/install-201704052254/bin/gfortran -march=native -Ofast -funroll-loops test_fpu2.f90 -static -o test_fpu2 6 Apr 2017 15:03:42 gfortran_lin - Execute test_fpu2 sh: line 1: 29627 Segmentation fault ./test_fpu2 >>gfortran_lin.run test_fpu2 Run # 1 151.34920 151.34920 - Error=100.% sh: line 1: 29633 Segmentation fault ./test_fpu2 >dummyfile test_fpu2 Run # 2 150.31599 150.83260 - Error= 0.3425% sh: line 1: 29639 Segmentation fault ./test_fpu2 >dummyfile test_fpu2 Run # 3 150.74271 150.80263 - Error= 0.1988% sh: line 1: 29645 Segmentation fault ./test_fpu2 >dummyfile test_fpu2 Run # 4 150.90080 150.82718 - Error= 0.1415% [1] https://gcc.opensuse.org/c++bench/pb11/pb11-performance-latest
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
Paolo Bonzini changed:
What|Removed |Added
CC||bonzini at gnu dot org
--- Comment #4 from Paolo Bonzini ---
The beautified code should be something like this:
#include
void *g_malloc0(size_t n) __attribute__((__alloc_size__(1)));
void *g_malloc0_n(size_t n, size_t s) __attribute__((__alloc_size__(1, 2)));
unsigned *f (int length)
{
int tables_nr = (length - 24) / sizeof(unsigned);
if (tables_nr <= 0)
return NULL;
return (unsigned *) (__extension__ ({
size_t n = tables_nr;
size_t s = sizeof (unsigned);
void *p;
if (s == 1)
p = g_malloc0 (n);
else if (__builtin_constant_p (n)
&& (s == 0 || n <= ((size_t)-1) / s))
p = g_malloc0 (n * s);
else
p = g_malloc0_n (n, s);
p;
}));
}
> __s is non-zero, and __n is equal to SIZE_MAX
n is not constant at the g_malloc0_n call site, so I'm not sure what deduction
can be made.
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 --- Comment #5 from Jeffrey A. Law --- My very quick analysis from the IRC chat yesterday was that the first testcase has a path that should have been detected as unexecutable. I'd work from the full testcase rather than the reduced one.
[Bug fortran/79553] [F03] Infinite gfortran loop on invalid code with dummy procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79553 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog, ||diagnostic CC||janus at gcc dot gnu.org Summary|Infinite gfortran loop on |[F03] Infinite gfortran |invalid code with |loop on invalid code with |procedures parameters |dummy procedure --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) > Sorry, I wrongly identified that it's fixed on trunk by r237994. I guess it > should be first back-ported to active branches before it can be closed. Since it's not a regression, I guess it's not necessary to backport? And given that it only concerns invalid code, it's probably not worth it anyway. I'd say this can be closed.
[Bug c++/60932] make stdatomic.h compatible with C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 Patrick Pelissier changed: What|Removed |Added CC||patrick.pelissier at gmail dot com --- Comment #12 from Patrick Pelissier --- Is the status really "wontfix"? This makes any C library which uses stdatomic.h incompatible with g++ (and more and more C code uses stdatomic.h) which is rather bothersome. clang doesn't have this issue. What prevent stdatomic.h to detect if it is included in C++ mode and includes C++ instead?
[Bug rtl-optimization/80358] [7 Regression] ICE (cc1 killed) building glib with -O3 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80358
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-04-07
CC||dje at gcc dot gnu.org,
||segher at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
int a;
void convert_path_key() {
int b;
for (; b >= 0; b--)
;
if (__builtin_memcmp(convert_path_key, &a, b))
g_strdup();
}
[Bug sanitizer/80348] [6/7 Regression] UBSAN: compile time crash in ubsan_instrument_division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80348 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Fri Apr 7 17:51:55 2017 New Revision: 246770 URL: https://gcc.gnu.org/viewcvs?rev=246770&root=gcc&view=rev Log: PR sanitizer/80348 * typeck.c (cp_build_binary_op): Convert COP[01] to ORIG_TYPE. * g++.dg/ubsan/div-by-zero-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/ubsan/div-by-zero-2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/80348] [6 Regression] UBSAN: compile time crash in ubsan_instrument_division
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80348 Marek Polacek changed: What|Removed |Added Summary|[6/7 Regression] UBSAN: |[6 Regression] UBSAN: |compile time crash in |compile time crash in |ubsan_instrument_division |ubsan_instrument_division --- Comment #6 from Marek Polacek --- Fixed on trunk so far.
[Bug c/80359] New: -O3 causes error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80359 Bug ID: 80359 Summary: -O3 causes error: invalid reference prefix Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 41153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41153&action=edit C source code common-filters.c: In function ‘rtf_create_bandpass_analytic’: common-filters.c:643:9: error: invalid reference prefix MEM[base: _429, offset: 0B] common-filters.c:95:7: note: in statement # .MEM_261 = VDEF <.MEM_324> IMAGPART_EXPR = 0.0; common-filters.c:643:9: error: invalid reference prefix MEM[base: _438, offset: 0B] common-filters.c:95:7: note: in statement # .MEM_259 = VDEF <.MEM_281> IMAGPART_EXPR = 0.0; common-filters.c:643:9: internal compiler error: verify_gimple failed 0xc737e2 verify_gimple_in_cfg(function*, bool) ../../trunk/gcc/tree-cfg.c:5266 0xb00366 execute_function_todo ../../trunk/gcc/passes.c:1966 0xb02aa4 do_per_function ../../trunk/gcc/passes.c:1650 0xb02aa4 execute_todo ../../trunk/gcc/passes.c:2016 gcc is recent trunk $ ../results/bin/gcc -v Using built-in specs. COLLECT_GCC=../results/bin/gcc COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.246752/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.246752 --disable-bootstrap --disable-multilib --disable-werror --enable-checking=df,extra,fold,rtl,yes --enable-languages=c,c++,fortran Thread model: posix gcc version 7.0.1 20170407 (experimental) (GCC) I'll have a go at reducing the file.
[Bug c++/80095] [5/6/7 Regression] ICE with this pointer in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80095 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Fri Apr 7 18:09:55 2017 New Revision: 246772 URL: https://gcc.gnu.org/viewcvs?rev=246772&root=gcc&view=rev Log: PR c++/80095 * call.c (build_over_call): Don't check cxx_dialect. * cp-gimplify.c (cp_gimplify_init_expr): Don't check cxx_dialect nor whether SUB is a CONSTRUCTOR. * init.c (build_new_1): Don't check cxx_dialect. * tree.c (replace_placeholders): Add a function comment. Return if not in C++14, or if the object isn't a (member of a) class. * typeck2.c (store_init_value): Don't check cxx_dialect nor whether TYPE is CLASS_TYPE_P. * g++.dg/cpp1y/nsdmi-aggr8.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/nsdmi-aggr8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/cp-gimplify.c trunk/gcc/cp/init.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog
[Bug c++/80095] [5/6 Regression] ICE with this pointer in NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80095 Marek Polacek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE with |[5/6 Regression] ICE with |this pointer in NSDMI |this pointer in NSDMI --- Comment #5 from Marek Polacek --- Fixed on trunk so far.
[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390 --- Comment #21 from rguenther at suse dot de --- On April 7, 2017 6:57:13 PM GMT+02:00, "jakub at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79390 > >--- Comment #20 from Jakub Jelinek --- >So, Richard, any thoughts on what can be done split paths to avoid >this? Invent some new heuristic that avoids splitting this case...
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #6 from Martin Sebor ---
The reduced test case from comment #4 doesn't trigger a warning because in it
the value of n is unknown. The original test case does trigger it because in
it n's range is known. This is evident from the VRP dump which shows:
Value ranges after VRP:
__n_5: ~[1, 18446744071562067967]
...
test_acpi_piix4_tcg ()
{
...
g_assertion_message_cmpnum (0B, "bug2.c", 59, &__func__, "tables_nr > 0",
_71, ">", 0.0, 105);
__n_5 = (gsize) tables_nr_69;
__p_58 = g_malloc0_n (__n_5, 4);
The anti-range implies that the variable's value is either zero or greater than
18446744071562067967 (0x7fff) so the allocation request is either
for zero bytes or some positive multiple of the excessive size. Since zero is
not considered a valid size (unless it's constant) and 18446744071562067967 is
too big the warning triggers.
The inlining context of the call is shown in the full output of the warning.
It might help shed light on where the range comes from.
In function ‘test_acpi_rsdt_table’,
inlined from ‘test_acpi_one.constprop’ at pr80346-2.c:19334:5,
inlined from ‘test_acpi_piix4_tcg’ at pr80346-2.c:19346:5:
pr80346-2.c:19319:59: warning: argument 1 range [18446744071562067968,
18446744073709551615] exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
/ __s)) __p = g_malloc0 (__n * __s); else __p = g_malloc0_n (__n,
__s); __p; }));
^~~~
[Bug debug/80321] [7 regression] infinite recursion with inlining of nested function and debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80321 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-04-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 41154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41154&action=edit gcc7-pr80321.patch Untested fix. The problem is that if we see in BLOCK_NONLOCALIZED_VARS current_function_decl, we don't treat it as declaration (which is everything that is not current_function_decl among other things), therefore we endlessly recurse on it. If we are already processing the current_function_decl, we have a DIE created for it and supposedly also at the correct position in the DIE tree, and that is all we care for declarations, we don't do further processing for those.
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346
--- Comment #7 from Dr. David Alan Gilbert ---
(In reply to Martin Sebor from comment #6)
> The reduced test case from comment #4 doesn't trigger a warning because in
> it the value of n is unknown. The original test case does trigger it
> because in it n's range is known. This is evident from the VRP dump which
> shows:
>
> Value ranges after VRP:
>
> __n_5: ~[1, 18446744071562067967]
> ...
> test_acpi_piix4_tcg ()
> {
> ...
> g_assertion_message_cmpnum (0B, "bug2.c", 59, &__func__, "tables_nr > 0",
> _71, ">", 0.0, 105);
> __n_5 = (gsize) tables_nr_69;
> __p_58 = g_malloc0_n (__n_5, 4);
>
>
> The anti-range implies that the variable's value is either zero or greater
> than 18446744071562067967 (0x7fff) so the allocation request is
> either for zero bytes or some positive multiple of the excessive size.
> Since zero is not considered a valid size (unless it's constant) and
> 18446744071562067967 is too big the warning triggers.
>
> The inlining context of the call is shown in the full output of the warning.
> It might help shed light on where the range comes from.
>
> In function ‘test_acpi_rsdt_table’,
> inlined from ‘test_acpi_one.constprop’ at pr80346-2.c:19334:5,
> inlined from ‘test_acpi_piix4_tcg’ at pr80346-2.c:19346:5:
> pr80346-2.c:19319:59: warning: argument 1 range [18446744071562067968,
> 18446744073709551615] exceeds maximum object size 9223372036854775807
> [-Walloc-size-larger-than=]
> / __s)) __p = g_malloc0 (__n * __s); else __p = g_malloc0_n
> (__n, __s); __p; }));
>
> ^~~~
The original code is here:
http://git.qemu-project.org/?p=qemu.git;a=blob;f=tests/bios-tables-test.c;h=88dbf9785353d6ac82a7000357d4bd4c658319e7;hb=HEAD#l96
(I had boiled it down a bit for this)
but what confuses me is we start if with 'tables_nr' which is an int
This is x86 - so it's 32bit
we then do an assert to guarantee it's positive
-> So the possible range is now 0..0x7fff
Then I expect it gets multiplied by sizeof(uint32_t)
-> Range is now 0..0x1ffc
the range gcc's warning us about looks like it sign extended a -ve 32bit
integer - but our assert makes sure that can't happen.
[Bug c/80359] -O3 causes error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80359
--- Comment #1 from David Binderman ---
Reduced file is this:
FFT(_Complex *X, int length) {
unsigned i, j;
for (; i < length; i++) {
X[i] = 0;
for (j = 0; j < length; j++)
X[i] = X[i] / length;
}
}
Interestingly, it seems to go wrong with -O2, not just -O3.
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 --- Comment #8 from Paolo Bonzini --- g_assertion_message_cmpnum is not declared anymore as noreturn since glib 2.38. https://bugzilla.gnome.org/show_bug.cgi?id=692125 :-O
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 --- Comment #9 from Dr. David Alan Gilbert --- (In reply to Paolo Bonzini from comment #8) > g_assertion_message_cmpnum is not declared anymore as noreturn since glib > 2.38. > https://bugzilla.gnome.org/show_bug.cgi?id=692125 :-O !!!? Oh in that case, that one isn't a gcc bug I guess.
[Bug middle-end/80346] pessimistic stringop-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80346 --- Comment #10 from Martin Sebor --- 108 /* compute the table entries in rsdt */ 109 tables_nr = (rsdt_table->length - sizeof(AcpiRsdtDescriptorRev1)) / 110 sizeof(uint32_t); 111 g_assert_cmpint(tables_nr, >, 0); For GCC to "understand" the assertion it would need to see the condition and be able to prove the allocation that follows cannot be reached (e.g., because the assertion exits the program by calling a noreturn function like abort or exit when the condition is false). From the preprocessed translation unit in attachment 41147 it looks as though the whole g_assert_cmpint expands to an unconditional function call (g_assertion_message_cmpnum) that's not decorated with attribute noreturn, and so the condition doesn't affect the range of the variable. Also, when working with sizes it's best to deal with unsigned types. Storing a size in an int and using it in mixed-type expressions involving size_t (like sizeof) can easily introduce the possibility of overflow (as far as GCC can see) and turn a non-negative range into a negative-positive one. In the attachment, changing the type of the tables_nr local variable from int to size_t eliminates the warning,
[Bug target/80326] _mm512_trunc_ps intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80326 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Apr 7 19:22:00 2017 New Revision: 246774 URL: https://gcc.gnu.org/viewcvs?rev=246774&root=gcc&view=rev Log: PR target/80322 PR target/80323 PR target/80325 PR target/80326 * config/i386/avxintrin.h (_mm256_cvtsd_f64, _mm256_cvtss_f32): New intrinsics. * config/i386/avx512fintrin.h (_mm512_int2mask, _mm512_mask2int, _mm512_abs_ps, _mm512_mask_abs_ps, _mm512_abs_pd, _mm512_mask_abs_pd, _mm512_cvtsd_f64, _mm512_cvtss_f32): Likewise. * gcc.target/i386/avx512f-undefined-1.c: New test. * gcc.target/i386/avx512f-cvtsd-1.c: New test. * gcc.target/i386/avx-cvtsd-1.c: New test. * gcc.target/i386/avx512f-cvtss-1.c: New test. * gcc.target/i386/avx512f-abspd-1.c: New test. * gcc.target/i386/avx-cvtss-1.c: New test. * gcc.target/i386/avx512f-absps-1.c: New test. * gcc.target/i386/avx512f-int2mask-1.c: New test. * gcc.target/i386/avx512f-mask2int-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-absps-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-int2mask-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mask2int-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-undefined-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avxintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/80323] _mm512_int2mask and _mm512_mask2int intrinsics are missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80323 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Fri Apr 7 19:22:00 2017 New Revision: 246774 URL: https://gcc.gnu.org/viewcvs?rev=246774&root=gcc&view=rev Log: PR target/80322 PR target/80323 PR target/80325 PR target/80326 * config/i386/avxintrin.h (_mm256_cvtsd_f64, _mm256_cvtss_f32): New intrinsics. * config/i386/avx512fintrin.h (_mm512_int2mask, _mm512_mask2int, _mm512_abs_ps, _mm512_mask_abs_ps, _mm512_abs_pd, _mm512_mask_abs_pd, _mm512_cvtsd_f64, _mm512_cvtss_f32): Likewise. * gcc.target/i386/avx512f-undefined-1.c: New test. * gcc.target/i386/avx512f-cvtsd-1.c: New test. * gcc.target/i386/avx-cvtsd-1.c: New test. * gcc.target/i386/avx512f-cvtss-1.c: New test. * gcc.target/i386/avx512f-abspd-1.c: New test. * gcc.target/i386/avx-cvtss-1.c: New test. * gcc.target/i386/avx512f-absps-1.c: New test. * gcc.target/i386/avx512f-int2mask-1.c: New test. * gcc.target/i386/avx512f-mask2int-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-absps-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-int2mask-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mask2int-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-undefined-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avxintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/80322] convert intrinsics missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80322 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Apr 7 19:22:00 2017 New Revision: 246774 URL: https://gcc.gnu.org/viewcvs?rev=246774&root=gcc&view=rev Log: PR target/80322 PR target/80323 PR target/80325 PR target/80326 * config/i386/avxintrin.h (_mm256_cvtsd_f64, _mm256_cvtss_f32): New intrinsics. * config/i386/avx512fintrin.h (_mm512_int2mask, _mm512_mask2int, _mm512_abs_ps, _mm512_mask_abs_ps, _mm512_abs_pd, _mm512_mask_abs_pd, _mm512_cvtsd_f64, _mm512_cvtss_f32): Likewise. * gcc.target/i386/avx512f-undefined-1.c: New test. * gcc.target/i386/avx512f-cvtsd-1.c: New test. * gcc.target/i386/avx-cvtsd-1.c: New test. * gcc.target/i386/avx512f-cvtss-1.c: New test. * gcc.target/i386/avx512f-abspd-1.c: New test. * gcc.target/i386/avx-cvtss-1.c: New test. * gcc.target/i386/avx512f-absps-1.c: New test. * gcc.target/i386/avx512f-int2mask-1.c: New test. * gcc.target/i386/avx512f-mask2int-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-absps-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-int2mask-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mask2int-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-undefined-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avxintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/80325] _mm512_undefined intrinsic missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80325 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Apr 7 19:22:00 2017 New Revision: 246774 URL: https://gcc.gnu.org/viewcvs?rev=246774&root=gcc&view=rev Log: PR target/80322 PR target/80323 PR target/80325 PR target/80326 * config/i386/avxintrin.h (_mm256_cvtsd_f64, _mm256_cvtss_f32): New intrinsics. * config/i386/avx512fintrin.h (_mm512_int2mask, _mm512_mask2int, _mm512_abs_ps, _mm512_mask_abs_ps, _mm512_abs_pd, _mm512_mask_abs_pd, _mm512_cvtsd_f64, _mm512_cvtss_f32): Likewise. * gcc.target/i386/avx512f-undefined-1.c: New test. * gcc.target/i386/avx512f-cvtsd-1.c: New test. * gcc.target/i386/avx-cvtsd-1.c: New test. * gcc.target/i386/avx512f-cvtss-1.c: New test. * gcc.target/i386/avx512f-abspd-1.c: New test. * gcc.target/i386/avx-cvtss-1.c: New test. * gcc.target/i386/avx512f-absps-1.c: New test. * gcc.target/i386/avx512f-int2mask-1.c: New test. * gcc.target/i386/avx512f-mask2int-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-abspd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-absps-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-cvtss-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-int2mask-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-mask2int-1.c trunk/gcc/testsuite/gcc.target/i386/avx512f-undefined-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/avx512fintrin.h trunk/gcc/config/i386/avxintrin.h trunk/gcc/testsuite/ChangeLog
[Bug c/80359] -O3 causes error: invalid reference prefix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80359 --- Comment #2 from David Binderman --- This bug seems to have been introduced between revision 245052 and 245800 i.e. sometime during February 2017.
[Bug fortran/68569] ICE with automatic character object and DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68569
--- Comment #5 from Thomas Koenig ---
(In reply to Nicolas Koenig from comment #4)
>
> + if (e->ts.type == BT_CHARACTER && e->ts.u.cl->length
> +&& e->ts.u.cl->length->expr_type == EXPR_VARIABLE)
> +gfc_error("Nonconstant length character at %L in DATA statement",
> + &e->where);
> +
> +
>if (e->rank == 0 || has_pointer)
> {
>mpz_init_set_ui (size, 1);
Does this wirk if the length is n-1?
Maybe comparing against the length being constant would be better.
[Bug c++/80356] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80356 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- This already started ICEing earlier, in r227458, then got fixed in r230924, and starts ICEing again around r241958 (which doesn't make sense, so must be some glitch on the bisect box).
[Bug target/80360] New: internal compiler error: in int_mode_for_mode, at stor-layout.c:405
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80360
Bug ID: 80360
Summary: internal compiler error: in int_mode_for_mode, at
stor-layout.c:405
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: schnetter at gmail dot com
Target Milestone: ---
Created attachment 41155
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41155&action=edit
Gzipped preprocessed failing source code
I encounter an ICE with SIMD vector intrinsics for Intel's Knight's Landing.
{{{
$ /project/projectdirs/m152/schnette/cori/src/spack-view/bin/g++ --version
g++ (GCC) 6.3.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
}}}
{{{
$ /project/projectdirs/m152/schnette/cori/src/spack-view/bin/g++ -march=knl -O
-S test.ii
In file included from
/global/project/projectdirs/m152/schnette/cori/src/spack-view/lib64/gcc/x86_64-pc-linux-gnu/6.3.0/include/immintrin.h:45:0,
from
/global/project/projectdirs/m152/schnette/cori-knl/Cvanilla/arrangements/CactusUtils/Vectors/src/vectors-4-AVX.h:9,
from
/global/project/projectdirs/m152/schnette/cori-knl/Cvanilla/arrangements/CactusUtils/Vectors/src/vectors.h:16,
from
/global/project/projectdirs/m152/schnette/cori-knl/Cvanilla/arrangements/CactusUtils/Vectors/src/test.cc:1:
/global/project/projectdirs/m152/schnette/cori/src/spack-view/lib64/gcc/x86_64-pc-linux-gnu/6.3.0/include/avx512fintrin.h:
In function 'void Vectors_Test(cGH*)':
/global/project/projectdirs/m152/schnette/cori/src/spack-view/lib64/gcc/x86_64-pc-linux-gnu/6.3.0/include/avx512fintrin.h:10018:48:
internal compiler error: in int_mode_for_mode, at stor-layout.c:405
return (__mmask16) __builtin_ia32_kortestchi ((__mmask16) __A,
~~^
(__mmask16) __B);
0xac3ff7 int_mode_for_mode(machine_mode)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/stor-layout.c:405
0x8638ce emit_move_via_integer
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/expr.c:3137
0x86b93a emit_move_insn_1(rtx_def*, rtx_def*)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/expr.c:3518
0x86bc94 emit_move_insn(rtx_def*, rtx_def*)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/expr.c:3586
0x854202 copy_to_reg(rtx_def*)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/explow.c:582
0xd520bd ix86_expand_builtin
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/config/i386/i386.c:41506
0x77753c expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/builtins.c:5626
0x868f70 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/expr.c:10624
0x871d39 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/expr.c:5406
0x872a8f expand_assignment(tree_node*, tree_node*, bool)
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/expr.c:5175
0x792c94 expand_call_stmt
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/cfgexpand.c:2658
0x792c94 expand_gimple_stmt_1
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/cfgexpand.c:3548
0x792c94 expand_gimple_stmt
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/cfgexpand.c:3714
0x794635 expand_gimple_basic_block
/global/project/projectdirs/m152/schnette/cori/src/spack/var/spack/stage/gcc-6.3.0-vqq6v5pzhzo6lz3d2phtyirsatu5cbj7/gcc-6.3.0/gcc/cfgexpand.c:5720
0x799516 execute
/global
[Bug c++/80356] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80356 --- Comment #4 from Jakub Jelinek --- Anyway, what is happening is that we have convert_from_reference applied in a spot where either we do not expect it, or where we should look through the reference type. In particular, coerce_template_parms calls convert_template_argument calls convert_nontype_argument with type REFERENCE_TYPE to FUNCTION_TYPE, but the corresponding argument is INDIRECT_REF result from convert_from_reference, with FUNCTION_TYPE.
[Bug c++/78715] [concepts] Access specifiers ignored after concept declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78715
Casey Carter changed:
What|Removed |Added
CC||Casey at Carter dot net
--- Comment #1 from Casey Carter ---
Another simple program that reproduces this bug with 6.3 and trunk:
template
concept bool C1 = true;
template
concept bool C2 = requires { { 42 } -> C1; };
int main() {
class A { int x; } a;
a.x = 42;
}
Use of a partial-concept-id as a constrained-type-specifier seems to be the
trigger.
[Bug fortran/80361] New: [7.0.1. regression] severe regression recursive call to nonrecursive procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361 Bug ID: 80361 Summary: [7.0.1. regression] severe regression recursive call to nonrecursive procedure Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- WHIZARD 2.4.1 (cf. here: http://www.hepforge.org/archive/whizard/whizard-2.4.1.tar.gz) unit test particle_specifiers (particle_specifiers_2) exhibits now a runtime error: Recursive call to nonrecursive procedure. Reproducer: just do: 'configure', 'make', then in tests/unit_tests 'make check'. I try to produce a smaller case, but I was really flabbergasted that in such a late stage there was again a severe regression created. :(
[Bug c++/80267] [7 Regression] Compiling aborts when template/auto/lambda occur in some way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80267 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/80361] [7.0.1. regression] severe regression recursive call to nonrecursive procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361 --- Comment #1 from Jürgen Reuter --- Bug only appears when using the flags -fbacktrace -ggdb -fcheck=all. With default flags -O2 -g it doesn't occur.
[Bug fortran/80361] [7.0.1. regression] severe regression recursive call to nonrecursive procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80361 --- Comment #2 from Jürgen Reuter --- The problem doesn't appear with our strict flags -O0 -fbacktrace -fcheck=array-temps,bounds,do,mem,pointer
