[Bug preprocessor/57580] Repeated _Pragma message directives in macro causes problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57580 --- Comment #8 from Jakub Jelinek --- Fixed for 6+.
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650
--- Comment #4 from Georg Koppen ---
It is using -lasan it seems:
Executing: c++ -o firefox -Wall -Wempty-body -Woverloaded-virtual
-Wsign-compare -Wwrite-strings -Wno-invalid-offsetof -Wcast-align -v
-fsanitize=address -Dxmalloc=myxmalloc -fno-exceptions -fno-strict-aliasing
-fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG
-DTRIMMED -g -freorder-blocks -Os -fno-omit-frame-pointer
/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/browser/app/tmpjOe32q.list
-lpthread -fsanitize=address -Wl,-z,noexecstack -Wl,-z,text -Wl,--build-id -B
../../build/unix/gold -Wl,-Bsymbolic -rdynamic
-Wl,-rpath-link,/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/dist/bin
-Wl,-rpath-link,NONE/lib ../../xpcom/glue/standalone/libxpcomglue.a
/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/browser/app/tmpjOe32q.list:
INPUT("nsBrowserApp.o")
INPUT("../../mozglue/build/AsanOptions.o")
INPUT("../../mozglue/build/SSE.o")
INPUT("../../mozglue/build/dummy.o")
INPUT("../../memory/mozalloc/Unified_cpp_memory_mozalloc0.o")
INPUT("../../mozglue/misc/StackWalk.o")
INPUT("../../mozglue/misc/TimeStamp.o")
INPUT("../../mozglue/misc/TimeStamp_posix.o")
INPUT("../../mfbt/Compression.o")
INPUT("../../mfbt/Decimal.o")
INPUT("../../mfbt/Unified_cpp_mfbt0.o")
INPUT("../../memory/fallible/fallible.o")
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-23'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151028 (Debian 5.2.1-23)
COMPILER_PATH=../../build/unix/gold/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=../../build/unix/gold/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'firefox' '-Wall' '-Wempty-body'
'-Woverloaded-virtual' '-Wsign-compare' '-Wwrite-strings'
'-Wno-invalid-offsetof' '-Wcast-align' '-v' '-fsanitize=address' '-D'
'xmalloc=myxmalloc' '-fno-strict-aliasing' '-fno-rtti' '-fno-exceptions'
'-fno-math-errno' '-std=gnu++11' '-pthread' '-pipe' '-D' 'NDEBUG' '-D'
'TRIMMED' '-g' '-freorder-blocks' '-Os' '-fno-omit-frame-pointer'
'-fsanitize=address' '-B' '../../build/unix/gold' '-rdynamic' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/5/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/5/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccNcaQre.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lpthread
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc --sysroot=/ --build-id --eh-frame-hdr -m
elf_x86_64 --hash-style=gnu -export-dynamic -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o firefox
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/5/crtbegin.o -L../../build/unix/gold
-L/usr/lib/gcc/x86_64-linux-gnu/5
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../../../lib -L/lib/x86_64-linux-gnu
-L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/x86_64-linux-gnu/5/../../..
/usr/lib/gcc/x86_64-linux-gnu/5/libasan_preinit.o -lasan
/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-unknown-linux-gnu/browser/app/tm
[Bug tree-optimization/68639] [6 Regression] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68639 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 --- Comment #5 from Jakub Jelinek --- /home/thomas/Arbeit/Tor/mozilla-central/xpcom/glue/standalone/nsXPCOMGlue.cpp:167: error: undefined reference to 'dlerror' That does look like it is actually one of the firefox' objects that needs dlerror, not *asan*. And -fsanitize=address never emits calls to these functions itself, when they aren't present in the source code already. So perhaps firefox has some code guarded with the sanitizer preprocessor macros or something similar? Look for dlerror in nsXPCOMGlue.cpp ?
[Bug tree-optimization/68639] [6 Regression] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68639 --- Comment #4 from Richard Biener --- Author: rguenth Date: Thu Dec 3 08:38:10 2015 New Revision: 231220 URL: https://gcc.gnu.org/viewcvs?rev=231220&root=gcc&view=rev Log: 2015-12-03 Richard Biener PR tree-optimization/68639 * tree-vect-data-refs.c (dr_group_sort_cmp): Split groups belonging to different loops. (vect_analyze_data_ref_accesses): Likewise. * gfortran.fortran-torture/compile/pr68639.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr68639.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- Supposedly r231178 and r231110.
[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800 --- Comment #8 from Richard Biener --- Author: rguenth Date: Thu Dec 3 08:43:22 2015 New Revision: 231221 URL: https://gcc.gnu.org/viewcvs?rev=231221&root=gcc&view=rev Log: 2015-12-03 Richard Biener PR tree-optimization/67800 PR tree-optimization/68333 * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Restore restriction to reduction contexts but allow SLP reductions as well. (vect_recog_sad_pattern): Likewise. (vect_recog_widen_sum_pattern): Likewise. * gcc.target/i386/vect-pr67800.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/vect-pr67800.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug tree-optimization/68333] [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68333 --- Comment #2 from Richard Biener --- Author: rguenth Date: Thu Dec 3 08:43:22 2015 New Revision: 231221 URL: https://gcc.gnu.org/viewcvs?rev=231221&root=gcc&view=rev Log: 2015-12-03 Richard Biener PR tree-optimization/67800 PR tree-optimization/68333 * tree-vect-patterns.c (vect_recog_dot_prod_pattern): Restore restriction to reduction contexts but allow SLP reductions as well. (vect_recog_sad_pattern): Likewise. (vect_recog_widen_sum_pattern): Likewise. * gcc.target/i386/vect-pr67800.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/vect-pr67800.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-patterns.c
[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513 --- Comment #11 from Jan Smets --- Thanks. Can this also be backported to 5.x? Thanks
[Bug c/68668] New: [6 Regression] bogus error: invalid use of array with unspecified bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668
Bug ID: 68668
Summary: [6 Regression] bogus error: invalid use of array with
unspecified bounds
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
% cat vp8_dx_iface.i
typedef const int vp8_tree[];
int fn1(vp8_tree p1) { return p1[0]; }
% gcc -c vp8_dx_iface.i
vp8_dx_iface.i: In function ‘fn1’:
vp8_dx_iface.i:2:1: error: invalid use of array with unspecified bounds
int fn1(vp8_tree p1) { return p1[0]; }
^~~
[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668 Markus Trippelsdorf changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-03 CC||jsm28 at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Started with r231194.
[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 67800, which changed state. Bug 67800 Summary: [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/68333] [6 Regression] FAIL: gcc.dg/vect/slp-multitypes-4.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68333 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Should be fixed now.
[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug bootstrap/68667] [6 Regression] GCC trunk build fails compiling graphite-isl-ast-to-gimple.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68667 Richard Biener changed: What|Removed |Added Keywords||build Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-03 Target Milestone|--- |6.0 Summary|GCC trunk build fails |[6 Regression] GCC trunk |compiling |build fails compiling |graphite-isl-ast-to-gimple. |graphite-isl-ast-to-gimple. |c |c Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed. We need a configure check for that OP.
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-03
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
Well, doing something like that at the optabs.c level wouldn't be really
helpful, as i?86 has tons of different permutation instructions and for many
permutations different sequence lengths.
So, the question is, does any supported CPU have some extra reinterpretation
costs if we use a different integral vector mode (I believe there is some cost
for some CPU when reinterpreting an integral vector as float vector and back,
vice versa, or perhaps even float vector as double vector and vice versa)?
If not, then the easiest fix is IMHO to change either
ix86_expand_vec_perm_const_1
or both
ix86_expand_vec_perm_const and ix86_vectorize_vec_perm_const_ok
to detect the case when V*{QI,HI,SI} permutation is doable in a wider unit mode
same whole vector size mode and just transform it to that case unconditionally.
If there is some cost, then we'd perhaps should do that at the end of
expand_vec_perm_1 (if everything else failed for single instruction), but then
the question is what to do with the 2-5 long sequences, we'd need to repeat
that at all the other spots.
[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #3 from Richard Biener --- Sounds similar to the fixed PR68550. But confirmed, I also saw the ICE (with ISL 0.12 and 0.14).
[Bug testsuite/68232] gcc.dg/ifcvt-4.c fails on some arm configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68232
Andre Vieira changed:
What|Removed |Added
CC||andre.simoesdiasvieira@arm.
||com
--- Comment #3 from Andre Vieira ---
Fails also on any ARM M-profile arch/cpu combination I've tried (all with
-mthumb):
-march={armv6-m,armv7-m}
or -mcpu=cortex-m{0,0plus,3,4,7}
It does pass for armv7-r and cortex-r4 with and without -mthumb.
This all with target 'arm-none-eabi'.
[Bug rtl-optimization/68651] [5/6 Regression][AArch64] Missing combination of shift-by-one with other arithmetic patterns with -mcpu=cortex-a53
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68651 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-03 Component|target |rtl-optimization Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- I think this can/should be fixed in a target-independent way. I have an idea I'm trying out
[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target|powerpc-*-* |powerpc-*-*, arm*-*-* Last reconfirmed|2015-12-02 00:00:00 |2015-12-3 CC||ktkachov at gcc dot gnu.org --- Comment #4 from ktkachov at gcc dot gnu.org --- Seeing this on arm-none-eabi too.
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
--- Comment #4 from rguenther at suse dot de ---
On Thu, 3 Dec 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> Status|UNCONFIRMED |NEW
>Last reconfirmed||2015-12-03
> Ever confirmed|0 |1
>
> --- Comment #3 from Jakub Jelinek ---
> Well, doing something like that at the optabs.c level wouldn't be really
> helpful, as i?86 has tons of different permutation instructions and for many
> permutations different sequence lengths.
>
> So, the question is, does any supported CPU have some extra reinterpretation
> costs if we use a different integral vector mode (I believe there is some cost
> for some CPU when reinterpreting an integral vector as float vector and back,
> vice versa, or perhaps even float vector as double vector and vice versa)?
> If not, then the easiest fix is IMHO to change either
> ix86_expand_vec_perm_const_1
> or both
> ix86_expand_vec_perm_const and ix86_vectorize_vec_perm_const_ok
> to detect the case when V*{QI,HI,SI} permutation is doable in a wider unit
> mode
> same whole vector size mode and just transform it to that case
> unconditionally.
> If there is some cost, then we'd perhaps should do that at the end of
> expand_vec_perm_1 (if everything else failed for single instruction), but then
> the question is what to do with the 2-5 long sequences, we'd need to repeat
> that at all the other spots.
Older AMD CPUs had "reformatting" costs but only when you apply operations
to vectors that may destroy properties such as whether the value is
a NaN - and the formatting penalty applied only when you then perform
an operation in FP representation on that vector that would care about
this.
So generally I think changing from vector integer modes to
vector integer or float modes of different size and then back
for the purpose of permutation is fine.
Doing this for vector float modes might have an issue depending
on the HW thus using vshufpd on a fload vector. Practially
the FP state doesn't change unless you shuffle sub-parts of the
float but of course the HW might not be so clever to detect this.
So I think using larger modes or even smaller modes (we already
try chars in optans.c unconditionally (even for float modes?))
for integer vector mode shuffles is ok. For float vector modes
I would avoid this unless we do more research.
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620
chrbr at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2015-12-3
CC||chrbr at gcc dot gnu.org
--- Comment #2 from chrbr at gcc dot gnu.org ---
confirmed. the following ICE with default configure options
arm-none-eabi-gcc -mfp16-format=ieee -mbig-endian -mfpu=neon-fp16
-mfloat-abi=hard ~/neon-fp16-fail.c
#include "arm_neon.h"
float16x4_t
foo (float32x4_t arg)
{
return vcvt_f16_f32 (arg);
}
[Bug tree-optimization/68659] [6 regression] FAIL: gcc.dg/graphite/id-pr45230-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68659 amker at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed|2015-12-03 00:00:00 |2015-12-02 0:00 --- Comment #5 from amker at gcc dot gnu.org --- (In reply to Richard Biener from comment #3) > Sounds similar to the fixed PR68550. But confirmed, I also saw the ICE > (with ISL 0.12 and 0.14). Yes, seems with the change, more scop is recognized and then the error happens. I will double check that the loop niter analysis is correct.
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #3 from ktkachov at gcc dot gnu.org --- Does that mean we need to define a movv4hf pattern?
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 --- Comment #4 from Christophe Lyon --- Maybe, that's what I'm trying to figure out. Given the comment in arm.h before the definition of CANNOT_CHANGE_MODE_CLASS, maybe we need to define more patterns, for all the sizes where CANNOT_CHANGE_MODE_CLASS is true on big-endian?
[Bug ipa/64812] [4.9 regression] x86 LibreOffice Build failure: undefined reference to acquire
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812
--- Comment #13 from rguenther at suse dot de ---
On Thu, 3 Dec 2015, hubicka at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64812
>
> Jan Hubicka changed:
>
>What|Removed |Added
>
> CC||rguenther at suse dot de
>
> --- Comment #12 from Jan Hubicka ---
> Markus,
> the devirtualization seems valid to me. You are supposed to link with the
> implementaiton of the class. It is possible to overwrite this by manually
> setting the visibility.
>
> We however end up with funny code in optimized dump:
>
> :
> _3 = this_2(D)->D.2399.D.2325._vptr.B;
> _4 = *_3;
> PROF_6 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_6 == acquire)
> goto ;
> else
> goto ;
>
> :
> PROF_10 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_10 == acquire)
> goto ;
> else
> goto ;
>
> :
> PROF_14 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_14 == acquire)
> goto ;
> else
> goto ;
>
> :
> PROF_18 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_18 == acquire)
> goto ;
> else
> goto ;
>
> :
> PROF_22 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_22 == acquire)
> goto ;
> else
> goto ;
>
> :
> PROF_26 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_26 == acquire)
> goto ;
> else
> goto ;
> :
> PROF_30 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_30 == acquire)
> goto ;
> else
> goto ;
>
> :
> PROF_34 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
> WindowListenerMultiplexer)this_2(D)->0);
> if (PROF_34 == acquire)
> goto ;
> else
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
> goto ;
>
> :
> OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0) (this_2(D));
> [tail call]
>
> :
> return;
>
> }
>
> this is result of recursive inlining over the devirtualized call that sort of
> seem legit even though it is bit of overkill.
>
> RTL optimizers simplify this to:
>
> _ZN25WindowListenerMultiplexer7acquireEv:
> .LFB1:
> .cfi_startproc
> movq(%rdi), %rax
> jmp *(%rax)
> .cfi_endproc
> .LFE1:
>
> RIchi, I think PRE is supposed to optimize this?
Ah, for some reason OBJ_TYPE_REF is a GENERIC tree (single RHS) and
SCCVN doesn't handle it at all. I have a patch which will produce
:
_3 = this_2(D)->D.2399.D.2325._vptr.B;
_4 = *_3;
PROF_6 = [obj_type_ref] OBJ_TYPE_REF(_4;(struct
WindowListenerMultiplexer)this_2(D)->0);
if (PROF_6 == acquire)
goto ;
else
goto ;
:
OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0)
(this_2(D)); [tail call]
goto ;
:
OBJ_TYPE_REF(_4;(struct WindowListenerMultiplexer)this_2(D)->0)
(this_2(D)); [tail call]
thus it also misses to "propagate" acquire into the tailcall. That
could be fixed as well but only in two steps, first replacing
the OBJ_TYPE_REF in the call with PROF_6 ("CSE" it) and later
DOM might propagate the equivalence.
[Bug c/68513] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:8832, c_maybe_const_expr in IL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68513 --- Comment #12 from Marek Polacek --- No, this isn't something we'd want to backport I think, For GCC 5, we'll need another (but trivial) fix.
[Bug c++/68669] New: -Wunused-variable is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669
Bug ID: 68669
Summary: -Wunused-variable is not correctly supressed by
#pragmas
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pavel.celba at ricardo dot com
Target Milestone: ---
The GCC version info:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/rs-sync/compilers/gcc/5.1.0/sle11/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/rs-sync/compilers/gcc/5.1.0/sle11
--libdir=/rs-sync/compilers/gcc/5.1.0/sle11/lib64 --enable-lto
--enable-gold=yes --enable-ld=yes
--with-gmp-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-gmp-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
--with-mpfr-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-mpfr-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
--with-mpc-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-mpc-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
--with-ppl-include=/rs-sync/compilers/gcc/5.1.0/sle11/include
--with-ppl-lib=/rs-sync/compilers/gcc/5.1.0/sle11/lib64
Thread model: posix
gcc version 5.1.0 (GCC)
Including following file from the boost unit test framework - boost version
1.58.0:
#include
and trying to supress unused-variable warnings still produce unused variable
warnings:
#ifdef __GNUC__
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#pragma GCC diagnostic ignored "-Wsign-compare"
#endif
#include
#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif
E.g. from our company unit test code compilation:
In file included from
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/unit_test_log.hpp:28:0,
from
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/test_tools.hpp:20,
from
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/unit_test.hpp:19,
from
/store/prtc-rsfile/pc1/pc1PlasticLinux/cpputils/code/unitTest/../include/cuBoostUnitTestHeaderInclude.h:20,
from
/store/prtc-rsfile/pc1/pc1PlasticLinux/cpputils/code/unitTest/src/run_tests.cpp:2:
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/unit_test_log.hpp:134:28:
warning: âboost::unit_test::{anonymous}::unit_test_logâ defined but not used
[-Wunused-variable]
BOOST_TEST_SINGLETON_INST( unit_test_log )
^
/store/prtc-rsfile/pc1/pc1PlasticLinux/boost/1.58.0/boost/test/utils/trivial_singleton.hpp:64:36:
note: in definition of macro âBOOST_TEST_SINGLETON_INSTâ
namespace { BOOST_JOIN( inst, _t)& inst = BOOST_JOIN( inst, _t)::instance(); }
FYI - run_tests.cpp is exactly this:
#define BOOST_TEST_MODULE cpputils_tests test
#include "cuBoostUnitTestHeaderInclude.h"
[Bug c++/68669] -Wunused-variable is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-03 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Please attache the (compressed) preprocessed file run_tests.ii.
[Bug c++/68669] -Wunused-variable is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 --- Comment #2 from Pavel Celba --- Created attachment 36893 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36893&action=edit Preprocessed run_tests.cpp Added the pre-processed run_tests.cpp
[Bug rtl-optimization/68670] New: [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c FAILs with -ftracer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68670 Bug ID: 68670 Summary: [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c FAILs with -ftracer Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Created attachment 36894 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36894&action=edit reduced testcase As mentioned in PR68376#c8, the testcase is failing with -ftracer. On the 5-branch, -O2 -ftracer is needed; -O -tracer is enough on other branches. armv7, aarch64, powerpc, x86_64 is affected; powerpc64 doesn't seem to fail. Dumps up to .optimized look fine, it still seems to be an RTL optimizer bug. Output: $ $CC -O2 -ftracer testcase.c $ ./a.out Aborted $ gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231194-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-231194-checking-yes-rtl-df-nographite Thread model: posix gcc version 6.0.0 20151202 (experimental) (GCC)
[Bug tree-optimization/66051] can't vectorize reductions inside an SLP group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66051 --- Comment #3 from Richard Biener --- Author: rguenth Date: Thu Dec 3 11:26:56 2015 New Revision: 231225 URL: https://gcc.gnu.org/viewcvs?rev=231225&root=gcc&view=rev Log: 2015-12-03 Richard Biener PR tree-optimization/66051 * tree-vect-slp.c (vect_build_slp_tree_1): Remove restriction on load group size. Do not pass in vectorization_factor. (vect_transform_slp_perm_load): Do not require any permute support. (vect_build_slp_tree): Do not pass in vectorization factor. (vect_analyze_slp_instance): Do not compute vectorization factor estimate. Use vector size instead of vectorization factor estimate to split store groups for BB vectorization. * gcc.dg/vect/slp-42.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/slp-42.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug tree-optimization/66051] can't vectorize reductions inside an SLP group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66051 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 66051, which changed state. Bug 66051 Summary: can't vectorize reductions inside an SLP group https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66051 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/68671] New: [5/6 Regression] gcc.dg/torture/pr66952.c FAILs with -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68671 Bug ID: 68671 Summary: [5/6 Regression] gcc.dg/torture/pr66952.c FAILs with -fno-tree-dce Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Created attachment 36895 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36895&action=edit reduced testcase withouth UB For armv7a, aarch64, powerpc, powerpc64 targets (tested in QEMU) (x86_64 is OK), the testcase fails: $ $CC -O2 -fno-tree-dce $ ./a.out Aborted $ armv7a-hardfloat-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-armv7a-hardfloat/bin/armv7a-hardfloat-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231194-checking-yes-rtl-df-nographite-armv7a-hardfloat/bin/../libexec/gcc/armv7a-hardfloat-linux-gnueabi/6.0.0/lto-wrapper Target: armv7a-hardfloat-linux-gnueabi Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl --with-float=hard --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=armv7a-hardfloat-linux-gnueabi --with-ld=/usr/bin/armv7a-hardfloat-linux-gnueabi-ld --with-as=/usr/bin/armv7a-hardfloat-linux-gnueabi-as --with-sysroot=/usr/armv7a-hardfloat-linux-gnueabi --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-231194-checking-yes-rtl-df-nographite-armv7a-hardfloat Thread model: posix gcc version 6.0.0 20151202 (experimental) (GCC)
[Bug middle-end/68672] New: [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68672
Bug ID: 68672
Summary: [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE:
cannot update SSA form: statement uses released SSA
name
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Created attachment 36896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36896&action=edit
preprocessed g++.dg/torture/pr68470.C
Compiler output:
$ x86_64-pc-linux-gnu-gcc -v -O -finline-small-functions -fpartial-inlining
--param=partial-inlining-entry-probability=100 pr68470.ii
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-231194-checking-yes-rtl-df-nographite/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-checking=yes,rtl,df --without-cloog --without-ppl --without-isl
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-231194-checking-yes-rtl-df-nographite
Thread model: posix
gcc version 6.0.0 20151202 (experimental) (GCC)
/repo/gcc-trunk/gcc/testsuite/g++.dg/torture/pr68470.C: In member function
'virtual void I::m_fn3()':
/repo/gcc-trunk/gcc/testsuite/g++.dg/torture/pr68470.C:35:1: error: statement
uses released SSA name:
}
^
# .MEM_20 = VDEF <.MEM>
MEM[(struct &)_12] ={v} {CLOBBER};
The use of _12 should have been replaced
/repo/gcc-trunk/gcc/testsuite/g++.dg/torture/pr68470.C:35:1: internal compiler
error: cannot update SSA form
0xdfa08c update_ssa(unsigned int)
/repo/gcc-trunk/gcc/tree-into-ssa.c:3190
0xc5f257 execute_function_todo
/repo/gcc-trunk/gcc/passes.c:1926
0xc5fc9b execute_todo
/repo/gcc-trunk/gcc/passes.c:2010
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
Tested revisions:
trunk r231194 - ICE
5-branch r231055 - ICE
4_9-branch 231054 - ICE
4_8-branch r224828 - OK
[Bug tree-optimization/68673] New: Handle __builtin_GOMP_task optimally in ipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68673 Bug ID: 68673 Summary: Handle __builtin_GOMP_task optimally in ipa-pta Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03477.html : ... __builtin_GOMP_task supposedly can be treated similarly if the third argument is NULL (if 3rd arg is non-NULL, then the caller passes a different structure from what the callee receives, but perhaps it could be emulated as pretending that cpyfn is called first with address of a temporary var and the data argument and then fn is called with the address of the temporary var). ...
[Bug target/68674] New: ARM attribute target neon warning: incompatible implicit declaration of built-in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674
Bug ID: 68674
Summary: ARM attribute target neon warning: incompatible
implicit declaration of built-in function
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: chrbr at gcc dot gnu.org
Target Milestone: ---
this test compiled with
cc1 -O2 test.c -mcpu=cortex-a9 -mfloat-abi=hard -quiet -mfpu=neon
#include "arm_neon.h"
int8x8_t a, b;
int16x8_t e;
void
__attribute__ ((target("fpu=neon")))
foo(void)
{
e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
}
ICEs with
test.c:10:18: warning: incompatible implicit declaration of built-in function
'__builtin_neon_vaddlsv8qi'
e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
^
test.c:10:7: internal compiler error: in copy_to_mode_reg, at explow.c:595
e = (int16x8_t)__builtin_neon_vaddlsv8qi (a, b);
^~~
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655 --- Comment #5 from Jakub Jelinek --- Created attachment 36897 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36897&action=edit gcc6-pr68655.patch Initial untested patch. Unfortunately, it doesn't seem to be always a win, when looking at the differences between old and new compiler. I'm looking at cd /usr/src/gcc/gcc/testsuite/gcc.dg/torture; for i in vshuf-v*[hqs]i.c; do for j in -msse2 -msse4 -mavx -mavx2 -mavx512f -mavx512bw; do /usr/src/gcc/obj/gcc/cc1.v246 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/1.s; /usr/src/gcc/obj/gcc/cc1 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/2.s; echo ===$i $j===; diff -up /tmp/1.s /tmp/2.s; done; done output now (where cc1.v246 is vanilla cc1, cc1 is one with this patch applied). In some cases the patch helps, but I've seen so far some cases where for AVX512* it resulted in more instructions.
[Bug tree-optimization/68675] New: Handle GOMP_target_ext optimally in ipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68675 Bug ID: 68675 Summary: Handle GOMP_target_ext optimally in ipa-pta Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01336.html : ... What we can and should improve is teach IPA aliasing/points to analysis about the way we lower the host vs. offloading region boundary, so that if alias analysis on the caller of GOMP_target_ext/GOACC_parallel_keyed determines something it can be used on the offloaded function side and vice versa. ... GOACC_parallel_keyed has been implemented, todo: GOMP_target_ext
[Bug target/68674] ARM attribute target neon warning: incompatible implicit declaration of built-in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68674 chrbr at gcc dot gnu.org changed: What|Removed |Added Blocks||65837 Assignee|unassigned at gcc dot gnu.org |chrbr at gcc dot gnu.org --- Comment #1 from chrbr at gcc dot gnu.org --- Found this when fixing target/65837: builtins should have a global scope. but this unmask a few other failures, mostly with the hooks TARGET_VECTORIZE_PREFERRED_SIMD_MODE that return wrongs values for global variables. The problem is that TARGET_NEON is false for global scopes decls, although the types were known. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65837 [Bug 65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655 --- Comment #6 from rguenther at suse dot de --- On Thu, 3 Dec 2015, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655 > > --- Comment #5 from Jakub Jelinek --- > Created attachment 36897 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36897&action=edit > gcc6-pr68655.patch > > Initial untested patch. Unfortunately, it doesn't seem to be always a win, > when looking at the differences between old and new compiler. > I'm looking at > cd /usr/src/gcc/gcc/testsuite/gcc.dg/torture; for i in vshuf-v*[hqs]i.c; do > for > j in -msse2 -msse4 -mavx -mavx2 -mavx512f -mavx512bw; do > /usr/src/gcc/obj/gcc/cc1.v246 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/1.s; > /usr/src/gcc/obj/gcc/cc1 -quiet -O2 $j $i -DEXPENSIVE -o /tmp/2.s; echo ===$i > $j===; diff -up /tmp/1.s /tmp/2.s; done; done > output now (where cc1.v246 is vanilla cc1, cc1 is one with this patch > applied). > In some cases the patch helps, but I've seen so far some cases where for > AVX512* it resulted in more instructions. So maybe that's a too generic handling (doing it up-front?) and maybe it should be done in the shufp[ds] handler only to catch my case? Otherwise the x86 ISA makes this quite awkward without building some pattern recognition scheme with a generator.
[Bug c++/68669] [5 regression] -Wunused-variable is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |NEW
Version|5.1.0 |5.2.1
Summary|-Wunused-variable is not|[5 regression]
|correctly supressed by |-Wunused-variable is not
|#pragmas|correctly supressed by
||#pragmas
--- Comment #3 from Markus Trippelsdorf ---
markus@x4 tmp % cat run_tests.ii
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunused-variable"
class A {
public:
static A &m_fn1();
};
namespace {
A &a = A::m_fn1();
}
#pragma GCC diagnostic pop
markus@x4 tmp % g++ -Wall -std=c++14 -O2 -c run_tests.ii
run_tests.ii:8:4: warning: ‘{anonymous}::a’ defined but not used
[-Wunused-variable]
A &a = A::m_fn1();
^
gcc-6 doesn't warn at all (even without the "diagnostic ignored" pragma).
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 --- Comment #6 from Georg Koppen --- Alright, thanks. So, what happens with r215527 is that checking for dlopen() working properly in the configure script is not enough anymore to decide whether one needs -ldl needs to get added explicitly if address sanitizer is enabled. If it is not enabled the dlopen() check is still sufficient. If one uses dlsym() for instance instead the check for needing -ldl is working as before. I still don't understand exactly why this is needed but I guess this is a thing which needs to get fixed on the Mozilla side. Sorry for the noise.
[Bug sanitizer/68650] Firefox compilation fails with Address Sanitizer (error: undefined reference to 'dlerror')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68650 Georg Koppen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #7 from Georg Koppen --- Resolving this as invalid then.
[Bug middle-end/68672] [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68672 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug tree-optimization/68671] [5/6 Regression] gcc.dg/torture/pr66952.c FAILs with -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68671 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.4
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
--- Comment #7 from Jakub Jelinek ---
I guess it needs analysis.
Some examples of changes:
vshuf-v16qi.c -msse2 test_2, scalar code vs. punpcklqdq, clear win
vshuf-v16qi.c -msse4 test_2, pshufb -> punpcklqdq (is this a win or not?)
(similarly for -mavx, -mavx2, -mavx512f, -mavx512bw)
vshuf-v16si.c -mavx512{f,bw} test_2:
- vpermi2d%zmm1, %zmm1, %zmm0
+ vmovdqa64 .LC2(%rip), %zmm0
+ vpermi2q%zmm1, %zmm1, %zmm0
looks like pessimization.
vshuf-v32hi.c -mavx512bw test_2, similar pessimization.
vshuf-v32hi.c -mavx512bw test_2, similarly:
- vpermi2w%zmm1, %zmm1, %zmm0
+ vmovdqa64 .LC2(%rip), %zmm0
+ vpermi2q%zmm1, %zmm1, %zmm0
vshuf-v4si.c -msse2 test_183, another pessimization:
- pshufd $78, %xmm0, %xmm1
+ movdqa %xmm0, %xmm1
movdb(%rip), %xmm4
pshufd $255, %xmm0, %xmm2
+ shufpd $1, %xmm0, %xmm1
vshuf-v4si.c -msse4 test_183, another pessimization:
- pshufd $78, %xmm1, %xmm0
+ movdqa %xmm1, %xmm0
+ palignr $8, %xmm0, %xmm0
vshuf-v4si.c -mavx test_183:
- vpshufd $78, %xmm1, %xmm0
+ vpalignr$8, %xmm1, %xmm1, %xmm0
vshuf-v64qi.c -mavx512bw, desirable change:
- vpermi2w%zmm1, %zmm1, %zmm0
- vpshufb .LC3(%rip), %zmm0, %zmm1
- vpshufb .LC4(%rip), %zmm0, %zmm0
- vporq %zmm0, %zmm1, %zmm0
+ vpermi2q%zmm1, %zmm1, %zmm0
vshuf-v8hi.c -msse2 test_1 another scalar to punpcklqdq, win
vshuf-v8hi.c -msse4 test_2 (supposedly a win):
- pshufb .LC3(%rip), %xmm0
+ punpcklqdq %xmm0, %xmm0
vshuf-v8hi.c -mavx test_2, similarly:
- vpshufb .LC3(%rip), %xmm0, %xmm0
+ vpunpcklqdq %xmm0, %xmm0, %xmm0
vshuf-v8si.c -mavx2 test_2, another win:
- vmovdqa a(%rip), %ymm0
- vperm2i128 $0, %ymm0, %ymm0, %ymm0
+ vpermq $68, a(%rip), %ymm0
vshuf-v8si.c -mavx2 test_5, another win:
- vmovdqa .LC6(%rip), %ymm0
- vmovdqa .LC7(%rip), %ymm1
- vmovdqa %ymm0, -48(%rbp)
vmovdqa a(%rip), %ymm0
- vpermd %ymm0, %ymm1, %ymm1
- vpshufb .LC8(%rip), %ymm0, %ymm3
- vpshufb .LC10(%rip), %ymm0, %ymm0
- vmovdqa %ymm1, c(%rip)
- vmovdqa b(%rip), %ymm1
- vpermq $78, %ymm3, %ymm3
- vpshufb .LC9(%rip), %ymm1, %ymm2
- vpshufb .LC11(%rip), %ymm1, %ymm1
- vpor%ymm3, %ymm0, %ymm0
- vpermq $78, %ymm2, %ymm2
- vpor%ymm2, %ymm1, %ymm1
- vpor%ymm1, %ymm0, %ymm0
+ vmovdqa .LC7(%rip), %ymm2
+ vmovdqa .LC6(%rip), %ymm1
+ vpermd %ymm0, %ymm2, %ymm2
+ vpermd b(%rip), %ymm1, %ymm3
+ vmovdqa %ymm1, -48(%rbp)
+ vmovdqa %ymm2, c(%rip)
+ vpermd %ymm0, %ymm1, %ymm0
+ vmovdqa .LC8(%rip), %ymm2
+ vpand %ymm2, %ymm1, %ymm1
+ vpcmpeqd%ymm2, %ymm1, %ymm1
+ vpblendvb %ymm1, %ymm3, %ymm0, %ymm0
vshuf-v8si.c -mavx512f test_2, another win?
- vmovdqa a(%rip), %ymm0
- vperm2i128 $0, %ymm0, %ymm0, %ymm0
+ vpermq $68, a(%rip), %ymm0
The above does not list all changes, I've been often ignoring further changes
in the file if say one change adds or removes a .LC*, then everything else is
renumbered (and doesn't sometimes list cases where the same or similar change
appears with multiple ISAs). So the results are clearly mixed.
Perhaps I should just try doing this at the end of expand_vec_perm_1 (i.e. if
we (most likely) couldn't get a single insn normally, see if we would get it
otherwise), and at the end of ix86_expand_vec_perm_const_1 (as the fallback
after all sequences). It won't catch some beneficial one insn to one insn
changes (e.g. where in the original case the insn needs a constant operand in
memory) though.
[Bug rtl-optimization/68670] [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c FAILs with -ftracer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68670 Richard Biener changed: What|Removed |Added Target Milestone|--- |4.9.4
[Bug ipa/68672] [4.9/5/6 Regression] g++.dg/torture/pr68470.C: ICE: cannot update SSA form: statement uses released SSA name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68672 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-03 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|middle-end |ipa Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Looks similar to PR68470, IPA split messes up.
[Bug rtl-optimization/68670] [4.9/5/6 Regression] gcc.c-torture/execute/pr68376-2.c FAILs with -ftracer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68670 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-03 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug fortran/68676] New: ICE in gfc_match_formal_arglist when compiling gfortran.dg/submodule_10.f08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68676
Bug ID: 68676
Summary: ICE in gfc_match_formal_arglist when compiling
gfortran.dg/submodule_10.f08
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Target: alphaev68-linux-gnu
Recent regression on alphaev68-linux-gnu, fails several submodule_??.f08 tests
[1]. The ICE can be triggered with a crosscompiler to alpha-linux-gnu:
~/gcc-build-alpha/gcc/f951 -O submodule_10.f08
f951: internal compiler error: Segmentation fault
0xb19d7f crash_signal
../../gcc-svn/trunk/gcc/toplev.c:334
0x5498e5 gfc_match_formal_arglist(gfc_symbol*, int, int)
../../gcc-svn/trunk/gcc/fortran/decl.c:4829
0x54c88b gfc_match_subroutine()
../../gcc-svn/trunk/gcc/fortran/decl.c:6016
0x5a52f5 decode_statement
../../gcc-svn/trunk/gcc/fortran/parse.c:378
gdb session:
Starting program: /home/uros/gcc-build-alpha/gcc/f951 -O submodule_10.f08
Program received signal SIGSEGV, Segmentation fault.
0x005498e5 in gfc_match_formal_arglist (progname=0x175b330, st_flag=0,
null_flag=1) at ../../gcc-svn/trunk/gcc/fortran/decl.c:4829
4829 if (!sym->abr_modproc_decl && formal && !head)
(gdb) p sym
$1 = (gfc_symbol *) 0x0
(gdb) list
4824 if (!formal && head)
4825arg_count_mismatch = true;
4826
4827 /* Abbreviated module procedure declaration is not meant to have
any
4828 formal arguments! */
4829 if (!sym->abr_modproc_decl && formal && !head)
4830arg_count_mismatch = true;
4831
4832 for (p = formal, q = head; p && q; p = p->next, q = q->next)
4833{
(gdb) bt
#0 0x005498e5 in gfc_match_formal_arglist (progname=0x175b330,
st_flag=0, null_flag=1) at ../../gcc-svn/trunk/gcc/fortran/decl.c:4829
#1 0x0054c88c in gfc_match_subroutine () at
../../gcc-svn/trunk/gcc/fortran/decl.c:6016
#2 0x005a52f6 in decode_statement () at
../../gcc-svn/trunk/gcc/fortran/parse.c:378
#3 0x005a6a58 in next_free () at
../../gcc-svn/trunk/gcc/fortran/parse.c:1076
#4 0x005a6de9 in next_statement () at
../../gcc-svn/trunk/gcc/fortran/parse.c:1310
#5 0x005a95af in parse_contained (module=1) at
../../gcc-svn/trunk/gcc/fortran/parse.c:5038
#6 0x005a99ad in parse_module () at
../../gcc-svn/trunk/gcc/fortran/parse.c:5431
sym is dereferenced when NULL.
[1] https://gcc.gnu.org/ml/gcc-testresults/2015-12/msg00267.html
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
--- Comment #8 from rguenther at suse dot de ---
On Thu, 3 Dec 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
>
> --- Comment #7 from Jakub Jelinek ---
> I guess it needs analysis.
> Some examples of changes:
> vshuf-v16qi.c -msse2 test_2, scalar code vs. punpcklqdq, clear win
> vshuf-v16qi.c -msse4 test_2, pshufb -> punpcklqdq (is this a win or not?)
> (similarly for -mavx, -mavx2, -mavx512f, -mavx512bw)
> vshuf-v16si.c -mavx512{f,bw} test_2:
> - vpermi2d%zmm1, %zmm1, %zmm0
> + vmovdqa64 .LC2(%rip), %zmm0
> + vpermi2q%zmm1, %zmm1, %zmm0
> looks like pessimization.
> vshuf-v32hi.c -mavx512bw test_2, similar pessimization.
> vshuf-v32hi.c -mavx512bw test_2, similarly:
> - vpermi2w%zmm1, %zmm1, %zmm0
> + vmovdqa64 .LC2(%rip), %zmm0
> + vpermi2q%zmm1, %zmm1, %zmm0
> vshuf-v4si.c -msse2 test_183, another pessimization:
> - pshufd $78, %xmm0, %xmm1
> + movdqa %xmm0, %xmm1
> movdb(%rip), %xmm4
> pshufd $255, %xmm0, %xmm2
> + shufpd $1, %xmm0, %xmm1
> vshuf-v4si.c -msse4 test_183, another pessimization:
> - pshufd $78, %xmm1, %xmm0
> + movdqa %xmm1, %xmm0
> + palignr $8, %xmm0, %xmm0
> vshuf-v4si.c -mavx test_183:
> - vpshufd $78, %xmm1, %xmm0
> + vpalignr$8, %xmm1, %xmm1, %xmm0
> vshuf-v64qi.c -mavx512bw, desirable change:
> - vpermi2w%zmm1, %zmm1, %zmm0
> - vpshufb .LC3(%rip), %zmm0, %zmm1
> - vpshufb .LC4(%rip), %zmm0, %zmm0
> - vporq %zmm0, %zmm1, %zmm0
> + vpermi2q%zmm1, %zmm1, %zmm0
> vshuf-v8hi.c -msse2 test_1 another scalar to punpcklqdq, win
> vshuf-v8hi.c -msse4 test_2 (supposedly a win):
> - pshufb .LC3(%rip), %xmm0
> + punpcklqdq %xmm0, %xmm0
> vshuf-v8hi.c -mavx test_2, similarly:
> - vpshufb .LC3(%rip), %xmm0, %xmm0
> + vpunpcklqdq %xmm0, %xmm0, %xmm0
> vshuf-v8si.c -mavx2 test_2, another win:
> - vmovdqa a(%rip), %ymm0
> - vperm2i128 $0, %ymm0, %ymm0, %ymm0
> + vpermq $68, a(%rip), %ymm0
> vshuf-v8si.c -mavx2 test_5, another win:
> - vmovdqa .LC6(%rip), %ymm0
> - vmovdqa .LC7(%rip), %ymm1
> - vmovdqa %ymm0, -48(%rbp)
> vmovdqa a(%rip), %ymm0
> - vpermd %ymm0, %ymm1, %ymm1
> - vpshufb .LC8(%rip), %ymm0, %ymm3
> - vpshufb .LC10(%rip), %ymm0, %ymm0
> - vmovdqa %ymm1, c(%rip)
> - vmovdqa b(%rip), %ymm1
> - vpermq $78, %ymm3, %ymm3
> - vpshufb .LC9(%rip), %ymm1, %ymm2
> - vpshufb .LC11(%rip), %ymm1, %ymm1
> - vpor%ymm3, %ymm0, %ymm0
> - vpermq $78, %ymm2, %ymm2
> - vpor%ymm2, %ymm1, %ymm1
> - vpor%ymm1, %ymm0, %ymm0
> + vmovdqa .LC7(%rip), %ymm2
> + vmovdqa .LC6(%rip), %ymm1
> + vpermd %ymm0, %ymm2, %ymm2
> + vpermd b(%rip), %ymm1, %ymm3
> + vmovdqa %ymm1, -48(%rbp)
> + vmovdqa %ymm2, c(%rip)
> + vpermd %ymm0, %ymm1, %ymm0
> + vmovdqa .LC8(%rip), %ymm2
> + vpand %ymm2, %ymm1, %ymm1
> + vpcmpeqd%ymm2, %ymm1, %ymm1
> + vpblendvb %ymm1, %ymm3, %ymm0, %ymm0
> vshuf-v8si.c -mavx512f test_2, another win?
> - vmovdqa a(%rip), %ymm0
> - vperm2i128 $0, %ymm0, %ymm0, %ymm0
> + vpermq $68, a(%rip), %ymm0
>
> The above does not list all changes, I've been often ignoring further changes
> in the file if say one change adds or removes a .LC*, then everything else is
> renumbered (and doesn't sometimes list cases where the same or similar change
> appears with multiple ISAs). So the results are clearly mixed.
>
> Perhaps I should just try doing this at the end of expand_vec_perm_1 (i.e. if
> we (most likely) couldn't get a single insn normally, see if we would get it
> otherwise), and at the end of ix86_expand_vec_perm_const_1 (as the fallback
> after all sequences).
Yeah, I would have done it only if we fail to permute, not generally.
I think you need to stop at 16 byte boundaries (TImode) only for AVX256
and 32byte (OImode) for AVX512. Not sure if there are cases where
a "effective" DImode permute works with SImode but not DImode,
say { 4, 5, 6, 7, 0, 1, 2, 3 } HImode can be done with both an
SImode { 2, 3, 0, 1 } or a DImode { 1, 0 } permute.
> It won't catch some beneficial one insn to one insn
> changes (e.g. where in the original case the insn needs a constant operand in
> memory) though.
True. I fear that at some point we want a generator covering all
possible permutes using permute patterns (input would be the .md
file and a list of insns to consider - or maybe even autodetect those).
The code handling permutation is already quite unwieldly (and it tries
generating RTL ...) :/
[Bug lto/68556] [6 Regression] -r -flto test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68556 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from H.J. Lu --- Fixed as of r231223.
[Bug testsuite/68545] gcc.dg/guality/guality.exp hides compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68545 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-03 Ever confirmed|0 |1
[Bug fortran/68676] ICE in gfc_match_formal_arglist when compiling gfortran.dg/submodule_10.f08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68676 Dominique d'Humieres changed: What|Removed |Added Target|alphaev68-linux-gnu |alphaev68-linux-gnu ||i386-*-freebsd Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-03 CC||kargl at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- See the thread starting at https://gcc.gnu.org/ml/fortran/2015-12/msg00030.html. Note that I don't see these failures on x86_64-apple-darwin14 (no valgrind error).
[Bug c++/68434] [concepts] ICE: same canonical type node for different types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68434
--- Comment #5 from ryan.burn at gmail dot com ---
reduction for the other test case:
template
struct is_same {
static constexpr bool value = true;
};
template
concept bool Same = is_same::value;
template
concept bool Integral = requires{
{ T() } -> Same;
};
struct A {
using value_type = bool;
};
template
using not_ = A;
int main() {
Integral>;
return 0;
}
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68139 Ville Voutilainen changed: What|Removed |Added Status|NEW |ASSIGNED CC||ville.voutilainen at gmail dot com Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at gmail dot com --- Comment #2 from Ville Voutilainen --- Mine.
[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636
--- Comment #3 from Richard Biener ---
Can you try the following w/o the asm?
typedef unsigned long uintptr_t;;
volatile unsigned int x;
void testTestTest(int zeroIsCavium)
{
x = *((volatile unsigned int *) (((volatile void *)((uintptr_t)(0x00800070) |
((0xA000) + (uintptr_t)(0x00800070)) >= 0x0080) && (zeroIsCavium ==
0) ) ? 0x2000 : 0));
}
[Bug rtl-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68624 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Dec 3 13:28:55 2015 New Revision: 231226 URL: https://gcc.gnu.org/viewcvs?rev=231226&root=gcc&view=rev Log: [RTL-ifcvt] PR rtl-optimization/68624: Clean up logic that checks for clobbering conflicts across basic blocks PR rtl-optimization/68624 * ifcvt.c (noce_try_cmove_arith): Check clobbers of temp regs in both blocks if they exist and simplify the logic choosing the order to emit them in. * gcc.c-torture/execute/pr68624.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr68624.c Modified: trunk/gcc/ChangeLog trunk/gcc/ifcvt.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68624 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/68669] [5 regression] -Wunused-variable is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 Markus Trippelsdorf changed: What|Removed |Added CC||hubicka at ucw dot cz --- Comment #4 from Markus Trippelsdorf --- Started with r210522.
[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I'll have a go at this.
[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560
Dominique d'Humieres changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Component|lto |fortran
--- Comment #2 from Dominique d'Humieres ---
For the test
program test
implicit none
integer :: c(2), d(2)
real, allocatable :: x(:,:)
allocate(x(2,5))
c = shape(x)
d = shape(x,kind=4)
end
the result of the compilation with -fdump-tree-original is
...
{
struct array2_real(kind=4) * D.3443;
struct array1_integer(kind=4) parm.1;
parm.1.dtype = 265;
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 2;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) &c[0];
parm.1.offset = -1;
D.3443 = &x;
_gfortran_shape_4 (&parm.1, D.3443);
}
{
integer(kind=4) * D.3453;
static integer(kind=4) C.3452 = 4;
struct array2_real(kind=4) * D.3451;
struct array1_integer(kind=4) parm.2;
parm.2.dtype = 265;
parm.2.dim[0].lbound = 1;
parm.2.dim[0].ubound = 2;
parm.2.dim[0].stride = 1;
parm.2.data = (void *) &d[0];
parm.2.offset = -1;
D.3451 = &x;
D.3453 = &C.3452;
_gfortran_shape_4 (&parm.2, D.3451, D.3453);
}
...
and -Wlto-type-mismatch seems right to complain that
_gfortran_shape_4 (&parm.2, D.3451, D.3453);
does not match
_gfortran_shape_4 (&parm.1, D.3443);
I have tried to understand why using the optional 'kind' argument generates a
third argument (not needed as it is reflected by _gfortran_shape_x for kind=x).
Looking at libgfortran/generated/shape_i4.c I see that shape_4 expects only two
arguments.
Looking at gcc/fortran/trans-intrinsic.c, I see
...
case GFC_ISYM_SHAPE:
case GFC_ISYM_SPREAD:
case GFC_ISYM_YN2:
/* Ignore absent optional parameters. */
return 1;
...
Am I correct to understand that it is intended to prevents the emission of the
optional argument? If yes, why is it not working (I lost the scent after that)?
[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636 Richard Biener changed: What|Removed |Added Target||mips-wrs-vxworks Host||x86_64-linux --- Comment #4 from Richard Biener --- With the cross configuration as specified on IRC I cannot reproduce on trunk or the GCC 5 branch head.
[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-03
Ever confirmed|0 |1
--- Comment #5 from Richard Biener ---
Ok, so we get in
bool
get_pointer_alignment_1 (tree exp, unsigned int *alignp,
unsigned HOST_WIDE_INT *bitposp)
{
...
else if (TREE_CODE (exp) == SSA_NAME
&& POINTER_TYPE_P (TREE_TYPE (exp)))
{
unsigned int ptr_align, ptr_misalign;
struct ptr_info_def *pi = SSA_NAME_PTR_INFO (exp);
if (pi && get_ptr_info_alignment (pi, &ptr_align, &ptr_misalign))
{
*bitposp = ptr_misalign * BITS_PER_UNIT;
*alignp = ptr_align * BITS_PER_UNIT;
a ptr_align of 536870912 and multiplying that by 8 overflows 'unsigned int'
to zero. And then in the caller
374 known_alignment
375 = get_pointer_alignment_1 (addr, &ptr_align, &ptr_bitpos);
376 align = MAX (ptr_align, align);
MAX (0, 8) is 8 ...
[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636 --- Comment #6 from Richard Biener --- And we also return true thus "known" which will override the type alignment present on the MEM_REF: /* When EXP is an actual memory reference then we can use TYPE_ALIGN of a pointer indirection to derive alignment. Do so only if get_pointer_alignment_1 did not reveal absolute alignment knowledge and if using that alignment would improve the situation. */ if (!addr_p && !known_alignment && TYPE_ALIGN (TREE_TYPE (exp)) > align) align = TYPE_ALIGN (TREE_TYPE (exp));
[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636
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 #7 from Richard Biener ---
Fix:
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 231058)
+++ gcc/builtins.c (working copy)
@@ -497,6 +497,10 @@ get_pointer_alignment_1 (tree exp, unsig
{
*bitposp = ptr_misalign * BITS_PER_UNIT;
*alignp = ptr_align * BITS_PER_UNIT;
+ /* Make sure to return a sensible alignment when the multiplication
+by BITS_PER_UNIT overflowed. */
+ if (*alignp == 0)
+ *alignp = 1u << (HOST_BITS_PER_INT - 1);
/* We cannot really tell whether this result is an approximation. */
return true;
}
[Bug rtl-optimization/68636] [5/6 Regression] unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636 Richard Biener changed: What|Removed |Added Known to work||4.8.5 Target Milestone|--- |5.4 Summary|unnecessary unaligned load |[5/6 Regression] |on mips o32 |unnecessary unaligned load ||on mips o32
[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 --- Comment #3 from Dominique d'Humieres --- I see the same problem with program test_count integer, dimension(2,3) :: a, b logical, dimension(2,3) :: mask integer :: i(2), j(3) a = reshape( (/ 1, 2, 3, 4, 5, 6 /), (/ 2, 3 /)) b = reshape( (/ 0, 7, 3, 4, 5, 8 /), (/ 2, 3 /)) mask = a.ne.b j=count(mask, 1, kind=4) i=count(mask, 2) end program test_count ... _gfortran_count_4_l (&parm.4, D.3452, D.3454); ... _gfortran_count_4_l (&parm.6, D.3463, D.3465, D.3467); ...
[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez --- (In reply to Markus Trippelsdorf from comment #3) > gcc-6 doesn't warn at all (even without the "diagnostic ignored" pragma). Even with an explicit -Wunused-variable? Does the warning call in the gcc-5 branch contain %q+D? Does it work correctly if you change it to %qD?
[Bug fortran/68009] [6 Regression] prototype for gfortran_runtime_error with inline matmul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68009 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Dominique d'Humieres --- So let me move it to NEW.
[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic --- Comment #6 from Manuel López-Ibáñez --- Perhaps you need to try with -Wunused-const-variable ? There may be some problem with TREE_READONLY (decl).
[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #2) > Am I correct to understand that it is intended to prevents the emission of > the optional argument? I think so. > If yes, why is it not working (I lost the scent after > that)? I think the problem is that it's actually working. The optional arguments are removed... When they are not present, the procedure declaration also loses them.
[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 --- Comment #7 from Markus Trippelsdorf --- (In reply to Manuel López-Ibáñez from comment #6) > Perhaps you need to try with -Wunused-const-variable ? There may be some > problem with TREE_READONLY (decl). There is no -Wunused-const-variable in gcc-5.
[Bug target/68620] ICE on gcc.target/arm/attr-neon-fp16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68620 --- Comment #5 from Christophe Lyon --- (In reply to ktkachov from comment #3) > Does that mean we need to define a movv4hf pattern? Isn't *neon_mov providing this (with the VDX iterator) I think what's not matching here is (set (subreg:SI (reg:V4HF) XXX) (subreg:SI (reg:V4HF) XXX)) because we cannot generate (subreg:SI (reg:V4HF) XXX)
[Bug target/68471] ICE: in df_refs_verify, at df-scan.c:4022 with -mmitigate-rop and long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68471 --- Comment #2 from Bernd Schmidt --- Author: bernds Date: Thu Dec 3 14:17:35 2015 New Revision: 231228 URL: https://gcc.gnu.org/viewcvs?rev=231228&root=gcc&view=rev Log: Fix some issues with the ROP patch (PR 68471, 68472) PR target/68471 PR target/68472 * config/i386/i386.c (ix86_mitigate_rop): Don't call compute_bb_for_insn again. Call df_insn_rescan_all. * config/i386/i386.md (set_got_rex64): Override modrm_class. * regrename.c (build_def_use): Ignore stack regs if regstack_completed. testsuite/ * gcc.target/i386/rop1.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/regrename.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 --- Comment #5 from Dominique d'Humieres --- > I think the problem is that it's actually working. The optional arguments are > removed... When they are not present, the procedure declaration also loses > them. Well, it is not how I read static integer(kind=4) C.3452 = 4; ... D.3451 = &x; D.3453 = &C.3452; _gfortran_shape_4 (&parm.2, D.3451, D.3453); There is a third argument D.3453 and its value is 4 (if it's not the KIND, what is it?).
[Bug target/68472] ICE: in ix86_get_modrm_for_rop, at config/i386/i386.c:27389 with -fPIC -mcmodel=medium -mmitigate-rop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68472 --- Comment #1 from Bernd Schmidt --- Author: bernds Date: Thu Dec 3 14:17:35 2015 New Revision: 231228 URL: https://gcc.gnu.org/viewcvs?rev=231228&root=gcc&view=rev Log: Fix some issues with the ROP patch (PR 68471, 68472) PR target/68471 PR target/68472 * config/i386/i386.c (ix86_mitigate_rop): Don't call compute_bb_for_insn again. Call df_insn_rescan_all. * config/i386/i386.md (set_got_rex64): Override modrm_class. * regrename.c (build_def_use): Ignore stack regs if regstack_completed. testsuite/ * gcc.target/i386/rop1.c: New test. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.md trunk/gcc/regrename.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/68649] [6 Regression] note: code may be misoptimized unless -fno-strict-aliasing is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68649
--- Comment #8 from Dominique d'Humieres ---
Further reduced test
REAL*8 :: a8(16),b8(4,4), c8(16), d8(4,4)
c8=RESHAPE(b8,(/16/))
d8=RESHAPE(a8,(/4,4/))
END
> Notice the difference in size of the records.
How do they relate to the array sizes?
From https://gcc.gnu.org/onlinedocs/gfortran/RESHAPE.html#RESHAPE
Description:
Reshapes SOURCE to correspond to SHAPE. If necessary, the new array may be
padded with elements from PAD or permuted as defined by ORDER.
> In libgfortran there is
> void
> reshape_r8 (gfc_array_r8 * const restrict ret,
> gfc_array_r8 * const restrict source,
> shape_type * const restrict shape,
> gfc_array_r8 * const restrict pad,
> shape_type * const restrict order)
>
> ideally the fortran-fe produced declaration of reshape_r8 should be just one
> per
> unit and interoperable with the declaration above that is pointer to:
> #define GFC_ARRAY_DESCRIPTOR(r, type) \
> struct {\
> type *base_addr;\
> size_t offset;\
> index_type dtype;\
> descriptor_dimension dim[r];\
> }
Are you meaning that fortran-fe should produce one reshape_r8xx per shape of
source?
[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 --- Comment #8 from Manuel López-Ibáñez --- (In reply to Markus Trippelsdorf from comment #7) > (In reply to Manuel López-Ibáñez from comment #6) > > Perhaps you need to try with -Wunused-const-variable ? There may be some > > problem with TREE_READONLY (decl). > > There is no -Wunused-const-variable in gcc-5. I mean to trigger the bug (or check the correct behavior) with gcc 6.
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655 --- Comment #10 from Jakub Jelinek --- And no, precomputing the permutations isn't going to work, there are just too many of them, and the amount of permutation instructions on i?86 is huge too.
[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 --- Comment #9 from Markus Trippelsdorf --- Well, why don't you answer these questions yourself?
[Bug middle-end/68677] New: Sibcall doesn't work on function with no return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68677
Bug ID: 68677
Summary: Sibcall doesn't work on function with no return
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-6 tmp]$ cat x.c
extern void bar (void) __attribute__ ((noreturn));
void
foo (void)
{
bar ();
}
[hjl@gnu-6 tmp]$ gcc -S x.c -O3
[hjl@gnu-6 tmp]$ cat x.s
.file "x.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
callbar
.cfi_endproc
.LFE0:
.size foo, .-foo
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident "GCC: (GNU) 5.2.1 20151104 (Red Hat 5.2.1-4)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 tmp]$
[Bug c/68533] bogus location for "warning: ‘struct s3’ declared inside parameter list will not be visible outside of this definition or declaration"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68533 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 6+.
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
Jakub Jelinek changed:
What|Removed |Added
Attachment #36897|0 |1
is obsolete||
--- Comment #9 from Jakub Jelinek ---
Created attachment 36898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36898&action=edit
gcc6-pr68655.patch
Second attempt, this one tries it only for a single insn if we couldn't get a
single insn otherwise, and then as a final fallback if nothing else worked.
Running the same command, I see only beneficial changes this time:
vshuf-v16qi.c -msse2 test_2, scalar to punpcklqdq
vshuf-v64qi.c -mavx512bw test_2
- vpermi2w%zmm1, %zmm1, %zmm0
- vpshufb .LC3(%rip), %zmm0, %zmm1
- vpshufb .LC4(%rip), %zmm0, %zmm0
- vporq %zmm0, %zmm1, %zmm0
+ vpermi2q%zmm1, %zmm1, %zmm0
vshuf-v8hi.c -msse2 test_2, scalar to punpcklqdq
and that is it.
Also on:
typedef unsigned short v8hi __attribute__((vector_size(16)));
typedef int v4si __attribute__((vector_size(16)));
typedef long long v2di __attribute__((vector_size(16)));
v2di
f1 (v2di a, v2di b)
{
return __builtin_shuffle (a, b, (v2di) { 0, 2 });
}
v8hi
f2 (v8hi a, v8hi b)
{
return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 8, 9, 10, 11 });
}
v4si
f3 (v4si a, v4si b)
{
return __builtin_shuffle (a, b, (v4si) { 0, 1, 4, 5 });
}
v8hi
f4 (v8hi a, v8hi b)
{
return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 12, 13, 14, 15 });
}
with -O2 -msse2 (or -msse3) the diff in f2 is scalar code to punpcklqdq,
with -O2 -mssse3 the diff is f2:
- punpcklwd %xmm1, %xmm0
- pshufb .LC0(%rip), %xmm0
+ punpcklqdq %xmm1, %xmm0
f4:
- palignr $8, %xmm1, %xmm0
- palignr $8, %xmm0, %xmm0
+ shufpd $2, %xmm1, %xmm0
for -O2 -msse4 just the f2 change, for each of -O2 -mavx{,2,512f,512vl} f2:
- vpunpcklwd %xmm1, %xmm0, %xmm1
- vpshufb .LC0(%rip), %xmm1, %xmm0
+ vpunpcklqdq %xmm1, %xmm0, %xmm0
[Bug c++/68669] [5 regression] -Wunused-variable in anonymous namespace is not correctly supressed by #pragmas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68669 Manuel López-Ibáñez changed: What|Removed |Added CC|manu at gcc dot gnu.org| --- Comment #10 from Manuel López-Ibáñez --- (In reply to Markus Trippelsdorf from comment #9) > Well, why don't you answer these questions yourself? Because I don't have latest trunk build and ready. If you don't want to answer them, that is ok. Maybe somebody else will, maybe they are not important after all. I'm just pointing out things that may help to identify and fix the bug. That was all.
[Bug target/68655] SSE2 cannot vec_perm of low and high part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
--- Comment #11 from rguenther at suse dot de ---
On Thu, 3 Dec 2015, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68655
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> Attachment #36897|0 |1
> is obsolete||
>
> --- Comment #9 from Jakub Jelinek ---
> Created attachment 36898
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36898&action=edit
> gcc6-pr68655.patch
>
> Second attempt, this one tries it only for a single insn if we couldn't get a
> single insn otherwise, and then as a final fallback if nothing else worked.
> Running the same command, I see only beneficial changes this time:
> vshuf-v16qi.c -msse2 test_2, scalar to punpcklqdq
> vshuf-v64qi.c -mavx512bw test_2
> - vpermi2w%zmm1, %zmm1, %zmm0
> - vpshufb .LC3(%rip), %zmm0, %zmm1
> - vpshufb .LC4(%rip), %zmm0, %zmm0
> - vporq %zmm0, %zmm1, %zmm0
> + vpermi2q%zmm1, %zmm1, %zmm0
> vshuf-v8hi.c -msse2 test_2, scalar to punpcklqdq
> and that is it.
> Also on:
> typedef unsigned short v8hi __attribute__((vector_size(16)));
> typedef int v4si __attribute__((vector_size(16)));
> typedef long long v2di __attribute__((vector_size(16)));
>
> v2di
> f1 (v2di a, v2di b)
> {
> return __builtin_shuffle (a, b, (v2di) { 0, 2 });
> }
>
> v8hi
> f2 (v8hi a, v8hi b)
> {
> return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 8, 9, 10, 11 });
> }
>
> v4si
> f3 (v4si a, v4si b)
> {
> return __builtin_shuffle (a, b, (v4si) { 0, 1, 4, 5 });
> }
>
> v8hi
> f4 (v8hi a, v8hi b)
> {
> return __builtin_shuffle (a, b, (v8hi) { 0, 1, 2, 3, 12, 13, 14, 15 });
> }
>
> with -O2 -msse2 (or -msse3) the diff in f2 is scalar code to punpcklqdq,
> with -O2 -mssse3 the diff is f2:
> - punpcklwd %xmm1, %xmm0
> - pshufb .LC0(%rip), %xmm0
> + punpcklqdq %xmm1, %xmm0
> f4:
> - palignr $8, %xmm1, %xmm0
> - palignr $8, %xmm0, %xmm0
> + shufpd $2, %xmm1, %xmm0
> for -O2 -msse4 just the f2 change, for each of -O2 -mavx{,2,512f,512vl} f2:
> - vpunpcklwd %xmm1, %xmm0, %xmm1
> - vpshufb .LC0(%rip), %xmm1, %xmm0
> + vpunpcklqdq %xmm1, %xmm0, %xmm0
LGTM
[Bug middle-end/68677] Sibcall doesn't work on function with no return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68677 --- Comment #1 from Richard Biener --- It's a feature for debugging of abort()-like calls. And in this case it's a tailcall as well (which is probably what you are after).
[Bug c++/68678] New: Initialization of pointer by constant expression using static ctor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68678
Bug ID: 68678
Summary: Initialization of pointer by constant expression using
static ctor.
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sorganov at gmail dot com
Target Milestone: ---
g++ 5 produces initialization for the following case using static constructor,
while earlier versions of g++ as well as gcc 5 in C compilation mode do it
using simple entry in .data section.
This sounds like missed optimization.
$ cat dynamic-init.cc
typedef struct S { int x; } S;
void const* p = (void*)(0x1234 + sizeof(S));
$ ~/try/gcc-5.2.0/bin/gcc -O2 -c -save-temps dynamic-init.cc
$ cat dynamic-init.s
.file "dynamic-init.cc"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.section.text.startup,"ax",@progbits
.LHOTB0:
.p2align 4,,15
.type _GLOBAL__sub_I_p, @function
_GLOBAL__sub_I_p:
.LFB1:
.cfi_startproc
movq$4664, p(%rip)
ret
.cfi_endproc
.LFE1:
.size _GLOBAL__sub_I_p, .-_GLOBAL__sub_I_p
.section.text.unlikely
.LCOLDE0:
.section.text.startup
.LHOTE0:
.section.init_array,"aw"
.align 8
.quad _GLOBAL__sub_I_p
.globl p
.bss
.align 8
.type p, @object
.size p, 8
p:
.zero 8
.ident "GCC: (GNU) 5.2.1 20151116"
.section.note.GNU-stack,"",@progbits
Here is what gcc 4.4.5 did:
$ gcc -O2 -c -save-temps dynamic-init.cc
$ cat dynamic-init.s
.file "dynamic-init.cc"
.globl p
.data
.align 8
.type p, @object
.size p, 8
p:
.quad 4664
.ident "GCC: (GNU) 4.4.5 20101112 (Red Hat 4.4.5-2)"
.section.note.GNU-stack,"",@progbits
$
[Bug tree-optimization/68673] Handle __builtin_GOMP_task optimally in ipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68673
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
E.g.
#define N 2
int
f1 (void)
{
int a[N], b[N], c[N];
int *ap = &a[0];
int *bp = &b[0];
int *cp = &c[0];
#pragma omp task shared (ap, bp, cp)
for (unsigned int idx = 0; idx < N; idx++)
{
ap[idx] = 1;
bp[idx] = 2;
cp[idx] = ap[idx];
}
return *cp;
}
int
f2 (void)
{
int a[N], b[N], c[N];
int *ap = &a[0];
int *bp = &b[0];
int *cp = &c[0];
#pragma omp task // implicitly firstprivate (ap, bp, cp)
for (unsigned int idx = 0; idx < N; idx++)
{
ap[idx] = 1;
bp[idx] = 2;
cp[idx] = ap[idx];
}
return *cp;
}
struct A { A (); A (const A &); ~A (); int a; void foo (); };
int
f3 (void)
{
int a[N], b[N], c[N];
int *ap = &a[0];
int *bp = &b[0];
int *cp = &c[0];
A d;
#pragma omp task shared (ap, bp, cp) firstprivate (d)
for (unsigned int idx = 0; idx < N; idx++)
{
d.foo ();
ap[idx] = 1;
bp[idx] = 2;
cp[idx] = ap[idx];
}
return *cp;
}
The first two GOMP_task calls have the same struct used on the caller and
callee, while the third one has different structs (the caller's struct has a
pointer to A in it, the callee's struct has A itself in it, the cpyfn callback
is called to run the copy constructor and copy other pointers etc. from the
caller's struct to the callee's struct. Note with the recent optimization I
wrote, f1 is handled as firstprivate (ap, bp, cp) too, because none of those
pointers are written in the task region.
[Bug c/68272] Unwanted out-of-line instances for C inline functions that are also GCC builtins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68272 --- Comment #6 from Sergey Organov --- For reference, the work-around for the problem is __attribute__((gnu_inline)), i.e., effectively turning inlining mode back to pre-c99.
[Bug middle-end/68677] Sibcall doesn't work on function with no return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68677 --- Comment #2 from Jakub Jelinek --- I believe this is intentional and has been discussed in the past. E.g. one of the often used noreturn functions is abort and its callers, in that case we better not sibcall to that, as it will be harder to find out where exactly the code aborted. Also, often not doing a sibcall is shorter, you can stay where you were with the stack pointer, while for sibcall you'd bump the stack pointer first.
[Bug lto/65745] [5/6 Regression] lto ICE (Segmentation fault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65745 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Matthias Klose --- the ICE seems to be gone, the package still fails to build with LTO. Opened http://bugs.debian.org/806963 for that, so maybe close this issue for now?
[Bug tree-optimization/68599] [6 Regression] gcc.dg/tree-ssa/pr45122.c and tree-vrp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68599 --- Comment #5 from Jeffrey A. Law --- Author: law Date: Thu Dec 3 15:40:08 2015 New Revision: 231231 URL: https://gcc.gnu.org/viewcvs?rev=231231&root=gcc&view=rev Log: [PR tree-optimization/68599] Avoid over-zealous optimization with -funsafe-loop-optimizations PR tree-optimization/68599 * loop-init.c (rtl_loop_init): Set LOOPS_HAVE_RECORDED_EXITS in call to loop_optimizer_init. * loop-iv.c (get_simple_loop_desc): Only allow unsafe loop optimization to drop the assumptions/infinite notations if the loop has a single exit. Modified: trunk/gcc/ChangeLog trunk/gcc/loop-init.c trunk/gcc/loop-iv.c
[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 --- Comment #6 from Mikael Morin --- (In reply to Dominique d'Humieres from comment #5) > > I think the problem is that it's actually working. The optional arguments > > are > > removed... When they are not present, the procedure declaration also loses > > them. > > Well, it is not how I read > > static integer(kind=4) C.3452 = 4; > ... > D.3451 = &x; > D.3453 = &C.3452; > _gfortran_shape_4 (&parm.2, D.3451, D.3453); > > There is a third argument D.3453 and its value is 4 (if it's not the KIND, > what is it?). In this case, the argument _is_ present, so it's not removed in the procedure declaration. This seems to be done on purpose (grep for ignore_optional) but I must admit that I don't understand why.
[Bug tree-optimization/68599] [6 Regression] gcc.dg/tree-ssa/pr45122.c and tree-vrp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68599 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law --- Fixed by commit on trunk.
[Bug c/68668] [6 Regression] bogus error: invalid use of array with unspecified bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668
--- Comment #3 from Marek Polacek ---
I'm using slightly adjusted testcase:
typedef const int T[];
int
fn1 (T p)
{
return p[0];
}
It looks like grokdeclarator creates a wrong type for PARM_DECL "p". It says
its type is "const int[] *", but that doesn't seem to be correct, it
should be "const int *". That also the reason why we generate this bogus
warning:
m.c:5:10: warning: return makes integer from pointer without a cast
[-Wint-conversion]
return p[0];
^
[Bug fortran/68560] [6 Regression] The test gfortran.dg/shape_8.f90 now fails when compiled with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68560 --- Comment #7 from Dominique d'Humieres --- > In this case, the argument _is_ present, so it's not removed in the procedure > declaration. This seems to be done on purpose (grep for ignore_optional) but > I > must admit that I don't understand why. Indeed I have seen 'ignore_optional', but I did not understand what it was supposed to do (as in "don't emit it").
