[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671
--- Comment #5 from Kirill Yukhin ---
(In reply to ktkachov from comment #3)
> CC'ing Kirill for AVX512 opinion
I suppose that there's something wrong w/ MD patterns.
E.g. for example provided pattern is:
;; /export/users/kyukhin/gcc/git/gcc/gcc/config/i386/sse.md: 9199
(define_insn ("avx512vl_truncatev4siv4qi2_mask")
[
(set (match_operand:V16QI 0 ("register_operand") ("=v"))
(vec_concat:V16QI (vec_merge:V4QI (truncate:V4QI
(match_operand:V4SI 1 ("register_operand") ("v")))
(vec_select:V4QI (match_operand:V16QI 2
("vector_move_operand") ("0C"))
(parallel [
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 2 [0x2])
(const_int 3 [0x3])
]))
(match_operand:QI 3 ("register_operand") ("Yk")))
(const_vector:V12QI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
Right now I think that 2nd operand predicate is not correct.
It should be const0_rtx (of corresponding mode) or duplicate of operand 0
(result actually)
This is whats contstraint tells.
However predicate says simply that operand is either const0_rtx or
nonimmediate: no connection with operand 0.
[Bug target/69619] [6 Regression] compilation doesn't terminate during CCMP expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69619 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed then. Wilco, can you please file a separate PR for fixing up the ccmp interface more properly for GCC 7?
[Bug c++/69684] New: Useless -Wparentheses for A || !A && B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69684
Bug ID: 69684
Summary: Useless -Wparentheses for A || !A && B
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wipedout at yandex dot ru
Target Milestone: ---
I'm compiling this with gcc 5.3.0 with -O3 -Wall -std=c++11
void test()
{
int a, b;
if(a || !a && b);
}
Please ignore the uninitialized variables for now.
I get this warning emitted:
warning: suggest parentheses around '&&' within '||' [-Wparentheses]
There're two options of how to put parentheses here.
Option one is to repeat the default behavior:
if(a || (!a && b));
Option two is this:
if((a || !a) && b);
and then I have "always true" on the left hand of && which is likely not what
anyone would want. So option two makes no sense and there's only one reasonable
way to put parentheses in this code and so the suggestion is completely useless
in this code.
[Bug target/69685] New: GCC cross compiler build failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685 Bug ID: 69685 Summary: GCC cross compiler build failed Product: gcc Version: 4.9.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pieter.cardoen at hotmail dot com Target Milestone: --- Created attachment 37591 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37591&action=edit Console output Dear I am trying to build gcc 4.9.3 for target avr-unknown-elf. If I build it, it seems that the build hangs on this item: /home/test02/build-gcc/./gcc/xgcc -B/home/test02/build-gcc/./gcc/ -B/usr/local/g cc-4.9.3-avr-unknown-elf/avr-unknown-elf/bin/ -B/usr/local/gcc-4.9.3-avr-unknown -elf/avr-unknown-elf/lib/ -isystem /usr/local/gcc-4.9.3-avr-unknown-elf/avr-unkn own-elf/include -isystem /usr/local/gcc-4.9.3-avr-unknown-elf/avr-unknown-elf/sy s-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototy pes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-p rologues -Os -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_li bc -DDF=SF -Dinhibit_libc -mcall-prologues -Os -I. -I. -I../.././gcc -I../../.. /gcc-4.9.3/libgcc -I../../../gcc-4.9.3/libgcc/. -I../../../gcc-4.9.3/libgcc/../g cc -I../../../gcc-4.9.3/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _satfra ctHQUSQ.o -MT _satfractHQUSQ.o -MD -MP -MF _satfractHQUSQ.dep -DL_satfract -DFRO M_HQ -DTO_USQ -c ../../../gcc-4.9.3/libgcc/fixed-bit.c -fvisibility=hidden -DHID E_EXPORTS A console screenshot has been added to this thread. What's the reason that this problem occurs and how can I debug this kind of issues? I use these packages: gcc-4.9.3 mpfr-3.1.3 gmp-6.1.0 mpc-1.0.3 isl-0.14 binutils-2.22.90 newlib-2.2.0 Thanks Pieter
[Bug c++/69686] New: Useless -Wparentheses for A && B || !A && C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686
Bug ID: 69686
Summary: Useless -Wparentheses for A && B || !A && C
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: wipedout at yandex dot ru
Target Milestone: ---
I'm compiling this with gcc 5.3.0 with -O3 -Wall -std=c++11
void test()
{
int a, b, c;
if(a && b || !a && c);
}
Please ignore the uninitialized variables. I get this warning:
warning: suggest parentheses around '&&' within '||' [-Wparentheses]
Okay, there're four ways to put them here:
Option one is repeating the default behavior
if((a && b) || (!a && c));
Option two is
if(a && (b || !a) && c);
Note "a && (b || !a)" part which is equivalent to "a && b || a && !a" which
contains "a && !a" which is always "false" and so makes no sense.
Option three is
if((a && b || !a) && c);
which now contains "a && b || !a" which makes no sense.
Option four is
if(a && (b || !a && c)); which contains the same nonsense as option two.
So here there's only once reasonable way to put parentheses and the warning is
useless.
[Bug target/69274] [6 Regression] 435.gromacs performance regression after r231814 on x86 Haswell and bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener --- Ok, it's also really enabled attributes that previously triggered non-commutative ops. The following patch (in testing now) fixes the SPEC regression. Index: gcc/ira.c === --- gcc/ira.c (revision 231814) +++ gcc/ira.c (working copy) @@ -1888,10 +1888,11 @@ ira_setup_alts (rtx_insn *insn, HARD_REG } if (commutative < 0) break; - if (curr_swapped) - break; + /* Swap forth and back to avoid changing recog_data. */ std::swap (recog_data.operand[commutative], recog_data.operand[commutative + 1]); + if (curr_swapped) + break; } }
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677 --- Comment #11 from Jakub Jelinek --- (In reply to H.J. Lu from comment #9) > Another problem. STV is disabled even when stack is aligned: See the other PR, that has been discussed as one of the possible approaches, but as TARGET_STV does not affect just the stv pass, but also expansion, it is not at all clear which of the approaches is better. Therefore, it was agreed on to disable STV in these rare cases altogether for GCC 6, and for GCC 7 somebody who cares enough can perform appropriate testing/benchmarking and tweak it.
[Bug c++/69686] Useless -Wparentheses for A && B || !A && C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686 Richard Biener changed: What|Removed |Added Keywords||diagnostic --- Comment #1 from Richard Biener --- This is a coding-style warning so the association will be obvious. The compiler doesn't do any analysis about possible associations and their "sense".
[Bug target/69685] GCC cross compiler build failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685 Richard Biener changed: What|Removed |Added Target||avr --- Comment #1 from Richard Biener --- You can look where gcc "hangs" by appending -v to the command-line, looking for the command that hangs (likely a ../gcc/cc1 invocation) and attaching to that process with gdb.
[Bug c++/69684] Useless -Wparentheses for A || !A && B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69684 --- Comment #1 from Richard Biener --- See other PR, this is about coding-style. One could say even a || !a && b doesn't make sense as the !a in the !a && b conditon will always be true and thus this is a || b. So a diagnostic is warranted - maybe it's wording is not exactly helpful and "warning: your condition is obfuscated" would be better? ;)
[Bug c++/69683] multiline raw string R"()" for C++11 warning in false #ifdef when -std=c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683 Richard Biener changed: What|Removed |Added Keywords||diagnostic Severity|major |normal --- Comment #1 from Richard Biener --- Not true - raw string processing is part of the lexing phase. I agree it's not very helpful in this case.
[Bug tree-optimization/69682] expression (a && (b==c)) with side effects rewritten to ((b==c) & a)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69682
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #3 from Richard Biener ---
Note the documentation says the following:
---
@item -fsignaling-nans
@opindex fsignaling-nans
Compile code assuming that IEEE signaling NaNs may generate user-visible
traps during floating-point operations. Setting this option disables
optimizations that may change the number of exceptions visible with
signaling NaNs. This option implies @option{-ftrapping-math}.
This option causes the preprocessor macro @code{__SUPPORT_SNAN__} to
be defined.
The default is @option{-fno-signaling-nans}.
This option is experimental and does not currently guarantee to
disable all GCC optimizations that affect signaling NaN behavior.
---
but even with -fsignalling-nans the bug reproduces with GCC 5.3.0.
This is due to PR69308 which I believe is a dup of this bug (this means
trunk is not affected). This will be fixed in GCC 5.4.0.
*** This bug has been marked as a duplicate of bug 69308 ***
[Bug tree-optimization/69308] ifcombine joins together floating point expression with side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308 --- Comment #14 from Richard Biener --- *** Bug 69682 has been marked as a duplicate of this bug. ***
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677 Richard Biener changed: What|Removed |Added Target||i?86-*-* Priority|P3 |P1 Target Milestone|--- |6.0
[Bug tree-optimization/69675] [6 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0
[Bug target/69685] GCC cross compiler build failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69685 --- Comment #2 from Pieter Cardoen --- How do you mean: appending -v? The only command I execute is: ../gcc-4.9.3/configure --prefix=/usr/local/gcc-4.9.3-avr-unknown-elf \ --target=avr-unknown-elf --build=i686-pc-$(ENV) \ --enable-languages=c,c++ --with-newlib \ --disable-__cxa_atexit --disable-nls \ --disable-threads --disable-shared \ --enable-static --disable-win32-registry \ --disable-sjlj-exceptions --with-dwarf2 \ --with-gmp=$(PKG_DIR) --with-mpfr=$(PKG_DIR) \ --with-mpc=$(PKG_DIR) --with-isl-prefix=$(PKG_DIR) make -j2 make install
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #6 from Kirill Yukhin --- This bug seems to be mine.
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #12 from Jakub Jelinek ---
Author: jakub
Date: Fri Feb 5 09:23:03 2016
New Revision: 233167
URL: https://gcc.gnu.org/viewcvs?rev=233167&root=gcc&view=rev
Log:
PR bootstrap/69677
* config/i386/i386.c (convert_scalars_to_vector): Readd stack
alignment fixes.
(ix86_option_override_internal): Disable TARGET_STV even for
-m{incoming,preferred}-stack-boundary=3.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Fixed.
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 Kirill Yukhin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |kyukhin at gcc dot gnu.org
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- So do you want to use reg_or_0_operand? I don't think we usually tie output with input already in the predicates, except when match_dup is used.
[Bug tree-optimization/69675] [6 Regression] [graphite] ICE: verify_ssa failed (definition in block 42 does not dominate use in block 34)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-05 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- Confirmed.
[Bug libgomp/69625] S/390 deadlock in libgomp.c/doacross-1.c test (vararg function trashes r6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625 --- Comment #2 from Andreas Krebbel --- Author: krebbel Date: Fri Feb 5 10:08:17 2016 New Revision: 233168 URL: https://gcc.gnu.org/viewcvs?rev=233168&root=gcc&view=rev Log: S/390: Fix r6 vararg handling. This patch fixes a problem introduced with the GPR into FPR slot save feature for leaf functions. r6 is argument register as well as call-saved. Currently we might decide that it will be a candidate for being saved into an FPR. If it turns out later that r6 also needs to be saved due to being required for vararg we undo the FPR save decision and put it on the stack again. Unfortunately the code did not adjust the GPR restore range accordingly so that the register does not get restored in the load multiple. This fixes the following testcases on s390x: < FAIL: libgomp.c/doacross-1.c execution test < FAIL: libgomp.c/doacross-2.c execution test < FAIL: libgomp.c/doacross-3.c execution test < FAIL: libgomp.c++/doacross-1.C execution test gcc/ChangeLog: 2016-02-05 Andreas Krebbel PR target/69625 * config/s390/s390.c (SAVE_SLOT_NONE, SAVE_SLOT_STACK): New defines. (s390_register_info_gprtofpr): Use new macros above. (s390_register_info_stdarg_fpr): Adjust max_fpr to better match its name. (s390_register_info_stdarg_gpr): Adjust max_gpr to better match its name. Adjust restore and save gpr ranges. (s390_register_info_set_ranges): New function. (s390_register_info): Use new macros above. Call s390_register_info_set_ranges. (s390_optimize_register_info): Likewise. (s390_hard_regno_rename_ok): Use new macros. (s390_hard_regno_scratch_ok): Likewise. (s390_emit_epilogue): Likewise. (s390_can_use_return_insn): Likewise. (s390_optimize_prologue): Likewise. * config/s390/s390.md (GPR2_REGNUM, GPR6_REGNUM): New constants. Modified: trunk/gcc/ChangeLog trunk/gcc/config/s390/s390.c trunk/gcc/config/s390/s390.md
[Bug c++/69686] Useless -Wparentheses for A && B || !A && C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686 --- Comment #2 from Jonathan Wakely --- (In reply to wipedout from comment #0) > So here there's only once reasonable way to put parentheses and the warning > is useless. But how long does it take most readers of the code to do that analysis and conclude only one arrangement makes sense? Isn't it better to just add the parentheses to disambiguate it so the meaning is obvious immediately? Which is what the warning suggests. The warning is working exactly as designed, if you don't like it disable the warning.
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #8 from Kirill Yukhin --- (In reply to Jakub Jelinek from comment #7) > So do you want to use reg_or_0_operand? I don't think we usually tie output > with input already in the predicates, except when match_dup is used. That is the issue. reg_or_0_operand won't work (although it is better than "vector_move_operand" since it is prohibits memory) We want 2nd operand to be either: 1. const0_rtx 2. match_dup 0 I cannot see in gcc/genpreds.c if a reference to another operands is possible from the other. We might invent some complicated subst. But patterns look too complicated for that. Maybe extend genpreds.c and friends introducing new version of predicate which will take instead of (op, mode) -> (op, mode, operands). Not sure in volume of efforts though. Really hope there's some simpler solution.
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- But something like that might remove the flexibility from the register allocator. Wonder why the RA in this case doesn't see that the value loaded into that pseudo register is CONST0_RTX which satisfies the C constraint and doesn't undo CSE (rematerialize) in that case if it doesn't have that value already loaded in the matching register to the output one.
[Bug c++/69686] Useless -Wparentheses for A && B || !A && C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jonathan Wakely --- Working as designed, many developers would find adding the parentheses makes the code clearer.
[Bug c++/69684] Useless -Wparentheses for A || !A && B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69684 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Working as designed, many developers would find adding the parentheses makes the code clearer. *** This bug has been marked as a duplicate of bug 69686 ***
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #10 from Kirill Yukhin --- (In reply to Jakub Jelinek from comment #9) > But something like that might remove the flexibility from the register > allocator. > > Wonder why the RA in this case doesn't see that the value loaded into that > pseudo register is CONST0_RTX which satisfies the C constraint and doesn't > undo CSE (rematerialize) in that case if it doesn't have that value already > loaded in the matching register to the output one. Then I see two options: 1. Split all patterns into match_dup and 0_operand by hand 2. Implement dedicated subst for such a patterns which will do p.1 while processing MD. Not sure it'll be easy
[Bug c++/69686] Useless -Wparentheses for A && B || !A && C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686 --- Comment #4 from Jonathan Wakely --- *** Bug 69684 has been marked as a duplicate of this bug. ***
[Bug c/69687] New: Buffer Overflow in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 Bug ID: 69687 Summary: Buffer Overflow in libiberty Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: boehme.marcel at gmail dot com Target Milestone: --- Created attachment 37592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37592&action=edit Test Case #1 The attached program binary causes a buffer overflow in cplus-dem.c when it tries to demangle specially crafted function arguments in the binary. Both the buffer size as well as the buffer content are controlled from the binary. objdump -x -C nm -C Tested on the following configurations * 2.6.32-573.7.1.el6.x86_64 #1 SMP Tue Sep 22 22:00:00 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux * 4.1.12-boot2docker #1 SMP Tue Nov 3 06:03:36 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux * Binutils versions: 2.20 and 2.26 Best regards, - Marcel Backlink: https://sourceware.org/bugzilla/show_bug.cgi?id=19571
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677
--- Comment #14 from Ilya Enkovich ---
(In reply to H.J. Lu from comment #6)
> STV turns:
>
> insn 21 19 23 4 (parallel [
> (set (reg:DI 102 [ val ])
> (and:DI (reg/v:DI 97 [ val ])
> (mem/u:DI (plus:SI (mult:SI (reg/v:SI 96 [ mode ])
> (const_int 8 [0x8]))
> (symbol_ref:SI ("mode_mask_array") [flags 0x40]
> )) [13 mode_mask_array S8 A64])))
> (clobber (reg:CC 17 flags))
> ]) /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:134
> 332 {*anddi3_doubleword}
> (expr_list:REG_DEAD (reg/v:DI 97 [ val ])
> (expr_list:REG_DEAD (reg/v:SI 96 [ mode ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)
> (insn 23 21 24 4 (parallel [
> (set (reg:DI 103)
> (ashift:DI (const_int 1 [0x1])
> (subreg:QI (reg:SI 91 [ _8 ]) 0)))
> (clobber (reg:CC 17 flags))
> ]) /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:135
> 449 {*ashldi3_doubleword}
> (expr_list:REG_DEAD (reg:SI 91 [ _8 ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
>
> into
> (insn 47 19 21 4 (set (reg:DI 111)
> (mem/u:DI (plus:SI (mult:SI (reg/v:SI 96 [ mode ])
> (const_int 8 [0x8]))
> (symbol_ref:SI ("mode_mask_array") [flags 0x40] 0xf517e160 mode_mask_array>)) [13 mode_mask_array S8 A64]))
> /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:134 -1
> (nil))
> (insn 21 47 23 4 (set (subreg:V2DI (reg:DI 102 [ val ]) 0)
> (and:V2DI (subreg:V2DI (reg/v:DI 97 [ val ]) 0)
> (subreg:V2DI (reg:DI 111) 0)))
> /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:134 3253
> {*andv2di3}
> (expr_list:REG_DEAD (reg/v:DI 97 [ val ])
> (expr_list:REG_DEAD (reg/v:SI 96 [ mode ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil)
> (insn 23 21 45 4 (parallel [
> (set (reg:DI 103)
> (ashift:DI (const_int 1 [0x1])
> (subreg:QI (reg:SI 91 [ _8 ]) 0)))
> (clobber (reg:CC 17 flags))
> ]) /export/gnu/import/git/gcc-regression/gcc/gcc/simplify-rtx.c:135
> 449 {*ashldi3_doubleword}
> (expr_list:REG_DEAD (reg:SI 91 [ _8 ])
> (expr_list:REG_UNUSED (reg:CC 17 flags)
> (nil
>
> So STV requires 16 byte stack alignment and uses 16 byte stack alignment.
I don't see how STV requires 16 byte stack alignment here. All registers are
DI here. Emitted movdqa is not produced by STV, it seems like LRA bug which
writes 8 bytes to stack but reads 16.
[Bug c/69687] Buffer Overflow in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 --- Comment #1 from Marcel Böhme --- Created attachment 37593 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37593&action=edit Test Case #2
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677 --- Comment #15 from Ilya Enkovich --- (In reply to Jakub Jelinek from comment #13) > Fixed. I think you just hide LRA issue disabling STV and LRA still may generate incorrect register fill
[Bug c++/69687] Buffer Overflow in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org Component|c |c++ --- Comment #2 from Markus Trippelsdorf --- I don't think it makes much sense to fuzz the demangler with arbitrary binary files. This isn't some daemon that runs 24/7 and is vulnerable to buffer overflow attacks.
[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #11 from Jakub Jelinek ---
void bar (void);
void
foo (int p2, int p3)
{
unsigned long a = p2;
unsigned long b = (~(unsigned long) ((unsigned int) p3 + -1U)) + a;
unsigned long c = (a - (unsigned long) ((unsigned int) p3 + -1U)) + (-1UL);
if (b != c)
bar ();
}
shows this folding inconsistency in the *.original dump:
long unsigned int a = (long unsigned int) p2;
long unsigned int b = (a - (long unsigned int) ((unsigned int) p3 +
4294967295)) - 1;
long unsigned int c = (a - (long unsigned int) ((unsigned int) p3 +
4294967295)) + 18446744073709551615;
but *.gimple already canonicalizes it, so that it does + 18446744073709551615
at the end in both cases.
[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
--- Comment #12 from Richard Biener ---
(In reply to Jakub Jelinek from comment #11)
> void bar (void);
>
> void
> foo (int p2, int p3)
> {
> unsigned long a = p2;
> unsigned long b = (~(unsigned long) ((unsigned int) p3 + -1U)) + a;
> unsigned long c = (a - (unsigned long) ((unsigned int) p3 + -1U)) + (-1UL);
> if (b != c)
> bar ();
> }
>
> shows this folding inconsistency in the *.original dump:
> long unsigned int a = (long unsigned int) p2;
> long unsigned int b = (a - (long unsigned int) ((unsigned int) p3 +
> 4294967295)) - 1;
> long unsigned int c = (a - (long unsigned int) ((unsigned int) p3 +
> 4294967295)) + 18446744073709551615;
> but *.gimple already canonicalizes it, so that it does +
> 18446744073709551615 at the end in both cases.
associate_trees doesn't re-fold the result (due to fear of recursion I guess)
[Bug libgcj/38812] gcj-built executables don't run after strip (libgcj erroneously references _environ)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38812 --- Comment #8 from Peter Keller --- (In reply to Eric Gallager from comment #7) > (In reply to Eric Gallager from comment #6) > > There's also some places where environ is used as an extern variable in > > libiberty that would need similar fixes; specifically in pex-unix.c and > > xmalloc.c. > > ...and it turns out that that is bug 63758, for reference... (sorry for the > digression; I hadn't seen the other one previously...) ... which was marked as RESOLVED/FIXED on 2015-12-07. It would be great if someone committed a fix for this bug, using the same method.
[Bug c++/69688] New: -Wsign-compare causes bogus error: size of array ‘uc_code’ is not an integral constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69688
Bug ID: 69688
Summary: -Wsign-compare causes bogus error: size of array
‘uc_code’ is not an integral constant-expression
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
struct ScriptObjectFixture
{
static const int code_size;
static const char code[];
static wchar_t uc_code[];
ScriptObjectFixture()
{
for (int i = 0; i < code_size; i++)
uc_code[i] = 0;
}
};
const char ScriptObjectFixture::code[] = "x";
const int ScriptObjectFixture::code_size = sizeof(ScriptObjectFixture::code) -
1;
wchar_t ScriptObjectFixture::uc_code[ScriptObjectFixture::code_size];
$ g++ w.cc -c -Wsign-compare
w.cc:17:68: error: size of array ‘uc_code’ is not an integral
constant-expression
wchar_t ScriptObjectFixture::uc_code[ScriptObjectFixture::code_size];
^
Without -Wsign-compare there's no diagnostic.
Caused by r230365
[Bug c++/69687] Buffer Overflow in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 --- Comment #3 from Marcel Böhme --- Hi Markus, Indeed, it depends on the use case. I find it quite unsettling to know that common digital forensics tools, such as gdb and objdump, are vulnerable to execute arbitrary code. How much credibility would a virus scanner have that installs a virus only because it *scanned* a malicious software? Best regards, - Marcel
[Bug c++/69688] [6 Regression] -Wsign-compare causes bogus error: size of array ‘uc_code’ is not an integral constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69688 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-05 Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677 --- Comment #16 from Uroš Bizjak --- (In reply to Ilya Enkovich from comment #15) > (In reply to Jakub Jelinek from comment #13) > > Fixed. > > I think you just hide LRA issue disabling STV and LRA still may generate > incorrect register fill Yes, but stage 4 is not the time to solve these kind of bugs. As said, the fix disables STV for rare and unusual cases. I expect that proper fix will be developed during gcc-7 time, and this includes various RA fixes. Previous patch relaxed alignment requirements to 64 bits, and this triggered RA bug. So, unless we want to delay release for a couple of weeks (a month?), we will leave alignment to 128 bits. That doesn't mean that incorrect register fill RA bug should't be fixed during stage-4. Do we have a small testcase that exposes it?
[Bug c++/69683] multiline raw string R"()" for C++11 warning in false #ifdef when -std=c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683 --- Comment #2 from Juan Rada-Vilela --- Indeed, it is unfortunate, especially because I compile my software with `-Werror`, so now I have to choose between ignoring warnings or using raw strings. Is there anything I can do to avoid triggering a warning and yet use a raw string?
[Bug c++/69683] multiline raw string R"()" for C++11 warning in false #ifdef when -std=c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683 --- Comment #3 from Jonathan Wakely --- (In reply to Juan Rada-Vilela from comment #0) > BUT it is expected from the compiler to ignore everything within the > `#ifdef` because `X` was not defined. The compiler still has to do tokenization to determine where the end of the #ifdef block is. Similarly you get a warning for: #if 0 These aren't valid tokens. #endif q.cc:2:11: warning: missing terminating ' character (And this obviously isn't "major" because it's only a warning!)
[Bug c++/69683] multiline raw string R"()" for C++11 warning in false #ifdef when -std=c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683 --- Comment #4 from Jonathan Wakely --- (In reply to Juan Rada-Vilela from comment #2) > Is there anything I can do to avoid triggering a warning and yet > use a raw string? You can use R""(this)"" or R"xxx"(this)"xxx" as the raw string, so the quotes are matched and don't confuse the C++98 compiler.
[Bug c++/69683] multiline raw string R"()" for C++11 warning in false #ifdef when -std=c++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69683 --- Comment #5 from Juan Rada-Vilela --- (In reply to Jonathan Wakely from comment #4) > (In reply to Juan Rada-Vilela from comment #2) > > Is there anything I can do to avoid triggering a warning and yet > > use a raw string? > > You can use R""(this)"" or R"xxx"(this)"xxx" as the raw string, so the > quotes are matched and don't confuse the C++98 compiler. Thank you so much. This solves this issue nicely.
[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
--- Comment #5 from Yuri Rumyantsev ---
Jacub,
I'd like to clarify one your remark:
5) IMHO you should give up also for !is_gimple_assign, say trying to move an
elemental function call into the conditional is just wrong
What's wrong in call motion? Note that masked stores and loads are
also represented as call. I assume that likely simd clone function
calls msut not be moved.
Thanks ahead.
Yuri.
P.S. It means that my patch is not correct and should be fixed.
2016-02-04 17:48 GMT+03:00 Yuri Rumyantsev :
> Jacub,
>
> Thanks a lot for your detail comments!
>
> I've just sent a patch for review to gcc-patches. Could you please
> take a look on it?
>
> Best regards.
> Yuri.
>
> 2016-02-03 20:22 GMT+03:00 jakub at gcc dot gnu.org
> :
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652
>>
>> Jakub Jelinek changed:
>>
>>What|Removed |Added
>>
>> CC|jakub at redhat dot com|
>>
>> --- Comment #3 from Jakub Jelinek ---
>> Clearly a bug in optimize_mask_stores.
>> At the start of that function we have:
>> ...
>> mask__46.14_129 = vect__14.9_121 != vect__21.12_127;
>> _46 = _14 != _21;
>> mask__ifc__47.15_130 = mask__46.14_129;
>> _ifc__47 = _46;
>> MASK_STORE (vectp.16_132, 8B, mask__ifc__47.15_130, vect__22.13_128);
>> vect__24.20_140 = MEM[(double *)vectp.18_138];
>> _24 = *_13;
>> vect__25.21_141 = vect__21.12_127 + vect__24.20_140;
>> _25 = _21 + _24;
>> MASK_STORE (vectp.22_145, 8B, mask__ifc__47.15_130, vect__25.21_141);
>> k_27 = k_28 + 1;
>> ...
>> Now, the MASK_STORE calls are processed from last to first, which is fine, we
>> first move the second MASK_STORE and the vector stmts that feed it:
>> vect__24.20_140 = MEM[(double *)vectp.18_138];
>> vect__25.21_141 = vect__21.12_127 + vect__24.20_140;
>> MASK_STORE (vectp.22_145, 8B, mask__ifc__47.15_130, vect__25.21_141);
>> but then continue trying to move the second MASK_STORE into the same
>> conditional block, because it has the same mask. In this case it is wrong,
>> because there is
>> the scalar load in between (_24 = *_13) that just waits for DCE, but
>> generally
>> there could be arbitrary code.
>> /* Put other masked stores with the same mask to STORE_BB. */
>> if (worklist.is_empty ()
>> || gimple_call_arg (worklist.last (), 2) != mask
>> || worklist.last () != stmt1)
>> break;
>> has a simplistic check (doesn't consider other MASK_STORE unless the walking
>> walked up to that stmt), but of course it doesn't work too well if some
>> scalar
>> stmts were skipped.
>>
>> I see various issues in that function:
>> 1) wrong formatting:
>> gsi_to = gsi_start_bb (store_bb);
>> if (dump_enabled_p ())
>> {
>> dump_printf_loc (MSG_NOTE, vect_location,
>>"Move stmt to created bb\n");
>> dump_gimple_stmt (MSG_NOTE, TDF_SLIM, last, 0);
>> }
>> /* Move all stored value producers if possible. */
>> while (!gsi_end_p (gsi))
>> {
>> The Move all stored value and everything below up to corresponding closing }
>> should be moved two columns to the left
>> 2) IMHO stmt1 should be set to NULL before that while (!gsi_end_p (gsi)),
>> as the function is prepared to handle multiple bbs
>> 3) next to gimple_vdef non-NULL break IMHO should be also
>> gimple_has_volatile_ops -> break check, just for safety, we don't wanto to
>> mishandle say volatile reads etc.
>> 4) you have to skip over debug stmts if there are any, otherwise we have a
>> -fcompare-debug issue
>> 5) IMHO you should give up also for !is_gimple_assign, say trying to move an
>> elemental function call into the conditional is just wrong
>> 6) the
>> /* Skip scalar statements. */
>> if (!VECTOR_TYPE_P (TREE_TYPE (lhs)))
>> continue;
>> should be reconsidered. IMHO if you have scalar stmts that feed just the
>> stmts
>> in the STORE_BB, there is no reason not to move them too, if you have scalar
>> stmts that feed other stmts too, IMHO you should give up on them if they
>> have a
>> vuse; what code did you have in mind when adding the !VECTOR_TYPE_P check?
>> 7) FOR_EACH_IMM_USE_FAST loop should ignore debug stmts, at least for
>> decisions
>> when to stop in some stmt; bet the debug stmts if there are any need to be
>> reset
>> if we move the def stmt that they are using, otherwise we risk
>> -fcompare-debug
>> issues
>> 8) the worklist.last () != stmt1 check need to be -fcompare-debug friendly
>> too,
>> so if there are debug stmts in between the last moved stmt and the previous
>> MASK_STORE, we need to handle it as if there aren't any debug stmts in
>> between
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for t
[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652 --- Comment #6 from Jakub Jelinek --- Well, MASK_STORE you don't want to handle in that loop, that is a store. MASK_LOAD is an exception, so IMHO you should just check for is_gimple_assign || MASK_LOAD. Allowing move of arbitrary other stmts looks dangerous. Another question is what to do with gimple_clobber_p. Those should have a vdef, so we handle them likely conservatively, which might be good enough for now. Or does vectorization just remove them already?
[Bug rtl-optimization/69689] New: gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689
Bug ID: 69689
Summary: gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Blocks: 69274
Target Milestone: ---
Target: i?86-*-*
With
Index: gcc/ira.c
===
--- gcc/ira.c (revision 231814)
+++ gcc/ira.c (working copy)
@@ -1888,10 +1888,11 @@ ira_setup_alts (rtx_insn *insn, HARD_REG
}
if (commutative < 0)
break;
- if (curr_swapped)
- break;
+ /* Swap forth and back to avoid changing recog_data. */
std::swap (recog_data.operand[commutative],
recog_data.operand[commutative + 1]);
+ if (curr_swapped)
+ break;
}
}
I see
FAIL: gcc.target/i386/addr-sel-1.c scan-assembler b+1
where we fail to reload_combine
(insn 6 21 8 2 (parallel [
(set (reg:SI 1 dx [orig:87 _2 ] [87])
(plus:SI (reg:SI 0 ax [99])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
])
/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.target/i386/addr-sel-1.c:13
218 {*addsi_1}
(nil))
...
(insn 10 8 11 2 (set (reg:SI 1 dx [98])
(sign_extend:SI (mem/j:QI (plus:SI (reg:SI 1 dx [orig:87 _2 ] [87])
(symbol_ref:SI ("b") [flags 0x2] )) [0 b S1 A8])))
/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.target/i386/addr-sel-1.c:13
151 {extendqisi2}
(nil))
probably because dx dies in the same instruction it is used in.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274
[Bug 69274] [6 Regression] 435.gromacs performance regression after r231814 on
x86 Haswell and bdver2
[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 --- Comment #16 from Richard Biener --- Testing of the tree-ssanames.c change went ok on x86_64, can somebody see whether this fixes the testcase on mips?
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 alalaw01 at gcc dot gnu.org changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #27 from alalaw01 at gcc dot gnu.org --- (In reply to Richard Biener from comment #25) > (In reply to alalaw01 from comment #23) > > Well, this one is not fixed by -fno-aggressive-loop-optimizations. > > No, that just disabled one symptom of the issue at that point in time. > Fixing the issue also fixes this occurance (well, I hope so ;)) So by "fixing the issue" - we mean, making --std=legacy prevent this (as although against the SPEC, colleagues with more FORTRAN knowledge than I suggest this is common)? SPEC seem to be saying they will not change the source: https://www.spec.org/cpu2006/Docs/faq.html#Run.05 As Jakub suggested in comment #13: > So, perhaps we want some flag on the Fortran COMMON decls that would be set > on > COMMON that ends with an array and would tell get_ref_base_and_extent > (and > other spots?) that accesses can be beyond end of the decl? but only if --std=legacy ? ? ? Should I raise a new bug for this, as both this and 53068 are CLOSED?
[Bug target/56993] power gcc built 416.gamess generates wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #11 from Richard Biener --- .
[Bug tree-optimization/69652] [6 Regression] [ICE] verify_ssa fail w/ -O2 -ffast-math -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652 --- Comment #7 from rguenther at suse dot de --- On Fri, 5 Feb 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69652 > > --- Comment #6 from Jakub Jelinek --- > Well, MASK_STORE you don't want to handle in that loop, that is a store. > MASK_LOAD is an exception, so IMHO you should just check for is_gimple_assign > || MASK_LOAD. Allowing move of arbitrary other stmts looks dangerous. Why? We track "dangerous" by having a VDEF. That's good enough IMHO. > Another question is what to do with gimple_clobber_p. Those should have a > vdef, so we handle them likely conservatively, which might be good enough for > now. Or does vectorization just remove them already? It does.
[Bug driver/69690] New: -pg -fomit-frame-pointer fails with error even if -pg does not depend on frame pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69690
Bug ID: 69690
Summary: -pg -fomit-frame-pointer fails with error even if -pg
does not depend on frame pointers
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
common cc1 options in gcc/gcc.c has
"%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}}"
but at least on arm and aarch64 -pg does not depend on the frame pointer.
in fact there is no frame pointer by default and -pg works fine,
however requesting -fomit-frame-pointer explicitly fails with
arm-none-linux-gnueabihf-gcc: error: -pg and -fomit-frame-pointer are
incompatible
this logic seems to be there since ancient times:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=11ce684d779b50cf49fa1a9216e55c2dca06b4fc
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #28 from rguenther at suse dot de --- On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 > > alalaw01 at gcc dot gnu.org changed: > >What|Removed |Added > > Resolution|INVALID |FIXED > > --- Comment #27 from alalaw01 at gcc dot gnu.org --- > (In reply to Richard Biener from comment #25) > > (In reply to alalaw01 from comment #23) > > > Well, this one is not fixed by -fno-aggressive-loop-optimizations. > > > > No, that just disabled one symptom of the issue at that point in time. > > Fixing the issue also fixes this occurance (well, I hope so ;)) > > So by "fixing the issue" - we mean, making --std=legacy prevent this (as > although against the SPEC, colleagues with more FORTRAN knowledge than I > suggest this is common)? SPEC seem to be saying they will not change the > source: https://www.spec.org/cpu2006/Docs/faq.html#Run.05 > > > As Jakub suggested in comment #13: > > > So, perhaps we want some flag on the Fortran COMMON decls that would be set > > on > COMMON that ends with an array and would tell get_ref_base_and_extent > > (and > > other spots?) that accesses can be beyond end of the decl? > > but only if --std=legacy ? ? ? > > Should I raise a new bug for this, as both this and 53068 are CLOSED? I think this has been discussed in some other dup already and the Fortran FE folks disagreed (it was never "legal", not even in F77). I also don't see how it can be a FE only fix. Possibly we can implemnet a middle-end switch that tells us that the size of commons is not to be trusted. The FE could then set that flag with -std=legacy. You can, after all, "simulate" the very same failure with C.
[Bug rtl-optimization/69689] gcc.target/i386/addr-sel-1.c FAILs with PR69274 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69689 --- Comment #1 from Richard Biener --- It's actually because ax dies in the ... instruction. So no easy fix here. Maybe postreload reload_combine needs to be "integrated" into LRA.
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #29 from Wilco --- (In reply to rguent...@suse.de from comment #28) > On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote: > > Should I raise a new bug for this, as both this and 53068 are CLOSED? > > I think this has been discussed in some other dup already and > the Fortran FE folks disagreed (it was never "legal", not even in F77). > > I also don't see how it can be a FE only fix. Possibly we can > implemnet a middle-end switch that tells us that the size of commons > is not to be trusted. The FE could then set that flag with -std=legacy. > > You can, after all, "simulate" the very same failure with C. Isn't there already a special exception for C (array of size 1 at end of structure)? The same exception could be enabled with -std=legacy. You'd only need to do extra FE work if you wanted to just do this for COMMON, but that seems hardly worth the extra effort - how much gain do we really get from the array size 1 optimization apart from repeatedly breaking SPEC benchmarks in various ways? Disabling it will likely remove the need for -fno-aggressive-loop-optimizations as well.
[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607 vries at gcc dot gnu.org changed: What|Removed |Added Attachment #37585|0 |1 is obsolete|| --- Comment #11 from vries at gcc dot gnu.org --- Created attachment 37594 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37594&action=edit Updated tentative patch This patch builds, and runs target-libgomp with -flto -flto-partition=1to1 -fno-toplevel-reorder, giving the same failures as normal (-fno-lto).
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368 --- Comment #30 from Jakub Jelinek --- (In reply to Wilco from comment #29) > (In reply to rguent...@suse.de from comment #28) > > On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote: > > > > Should I raise a new bug for this, as both this and 53068 are CLOSED? > > > > I think this has been discussed in some other dup already and > > the Fortran FE folks disagreed (it was never "legal", not even in F77). > > > > I also don't see how it can be a FE only fix. Possibly we can > > implemnet a middle-end switch that tells us that the size of commons > > is not to be trusted. The FE could then set that flag with -std=legacy. > > > > You can, after all, "simulate" the very same failure with C. > > Isn't there already a special exception for C (array of size 1 at end of > structure)? Yes, the exception is for flexible array members and what people commonly use as flexible array member replacement (basically [0] sized arrays and all other arrays at the end of structures/unions, unless followed by some other field in outer structure or by another array member. But, all those exceptions are for the case how you can legally use flexible array members, i.e. heap allocated objects (or mmap etc.), so pretty much where the base is a pointer dereference. If the base is a symbol, the only supported case is the GNU extension of initializing flexible array members. Otherwise, if you have size of some decl 32 bytes, trying to access 32th and following byte is considered undefined. And what Richi suggests, some new switch which would allow treating DECL_COMMON bases more conservatively, expecting that if you have a flexible array member or something like that at the end of a DECL_COMMON decl that in (invalid) program it might be unified with a larger DECL_COMMON from other TU.
[Bug rtl-optimization/69691] New: [6 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Bug ID: 69691
Summary: [6 Regression] wrong code at -O2 on x86_64-linux-gnu
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
$ xgcc -O2 zz.c; ./a.out
Aborted (core dumped)
extern int tolower (int) __attribute__ ((leaf));
char *USHyphens[] = { ".ach4", 0 };
#define LCNT (26 + 1 + 4)
#define SEPCNT 10
typedef struct sHyphenNode
{
char sepcnts[SEPCNT];
struct sHyphenNode *Daughters[LCNT];
} THyphenNode, *PHyphenNode;
static PHyphenNode HyphenRoot = 0;
static int
GetIndex (char ch)
{
if (ch == 0)
__builtin_abort ();
if ((tolower (ch) >= 'a' - 1) && (tolower (ch) <= 'z'))
return (tolower (ch) - ('a' - 1));
else if (ch == '.')
return 0;
else
{
__builtin_printf ("unallowed character %d\n", ch);
return -1;
}
}
static void
InitHyphenNode (PHyphenNode Node)
{
int z;
for (z = 0; z < LCNT; Node->Daughters[z++] = 0);
for (z = 0; z < SEPCNT; Node->sepcnts[z++] = 0);
}
void
BuildTree (char **Patterns)
{
char **run, ch, *pos, sing[500], *rrun;
char RunCnts[SEPCNT];
int z, l, rc, index;
PHyphenNode Lauf;
HyphenRoot = (PHyphenNode) __builtin_malloc (sizeof (THyphenNode));
InitHyphenNode (HyphenRoot);
for (run = Patterns; *run != 0; run++)
{
__builtin_strcpy (sing, *run);
rrun = sing;
do
{
pos = __builtin_strchr (rrun, ' ');
if (pos)
*pos = '\0';
l = __builtin_strlen (rrun);
rc = 0;
Lauf = HyphenRoot;
for (z = 0; z < SEPCNT; RunCnts[z++] = 0);
for (z = 0; z < l; z++)
{
ch = rrun[z];
if ((ch >= '0') && (ch <= '9'))
RunCnts[rc] = ch - '0';
else
{
index = GetIndex (ch);
if (!Lauf->Daughters[index])
{
Lauf->Daughters[index] =
(PHyphenNode) __builtin_malloc (sizeof (THyphenNode));
InitHyphenNode (Lauf->Daughters[index]);
}
Lauf = Lauf->Daughters[index];
rc++;
}
}
__builtin_memcpy (Lauf->sepcnts, RunCnts, SEPCNT);
if (pos)
rrun = pos + 1;
}
while (pos);
}
}
void
DoHyphens (char *word)
{
char Field[300];
char Res[300];
int z, z2, z3, l;
PHyphenNode Lauf;
l = __builtin_strlen (word);
*Field = 'a' - 1;
for (z = 0; z < l; z++)
{
Field[z + 1] = tolower ((unsigned int) word[z]);
if (GetIndex (Field[z + 1]) <= 0)
return;
}
Field[l + 1] = 'a' - 1;
l += 2;
for (z = 0; z <= l + 1; Res[z++] = 0);
if (!HyphenRoot)
return;
for (z = 0; z < l; z++)
{
Lauf = HyphenRoot;
for (z2 = z; z2 < l; z2++)
{
Lauf = Lauf->Daughters[GetIndex (Field[z2])];
if (!Lauf)
break;
for (z3 = 0; z3 <= z2 - z + 2; z3++)
if (Lauf->sepcnts[z3] > Res[z + z3])
Res[z + z3] = Lauf->sepcnts[z3];
}
}
for (z = 3; z < l - 2; z++)
if ((Res[z] & 1) == 1)
asm ("");
}
int
main ()
{
BuildTree (USHyphens);
DoHyphens ("a");
}
[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691 Marek Polacek changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from Marek Polacek --- The testcase ICEd since r230150 and is miscompiled since r231300.
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #31 from rguenther at suse dot de ---
On Fri, 5 Feb 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
>
> --- Comment #30 from Jakub Jelinek ---
> (In reply to Wilco from comment #29)
> > (In reply to rguent...@suse.de from comment #28)
> > > On Fri, 5 Feb 2016, alalaw01 at gcc dot gnu.org wrote:
> >
> > > > Should I raise a new bug for this, as both this and 53068 are CLOSED?
> > >
> > > I think this has been discussed in some other dup already and
> > > the Fortran FE folks disagreed (it was never "legal", not even in F77).
> > >
> > > I also don't see how it can be a FE only fix. Possibly we can
> > > implemnet a middle-end switch that tells us that the size of commons
> > > is not to be trusted. The FE could then set that flag with -std=legacy.
> > >
> > > You can, after all, "simulate" the very same failure with C.
> >
> > Isn't there already a special exception for C (array of size 1 at end of
> > structure)?
>
> Yes, the exception is for flexible array members and what people commonly use
> as flexible array member replacement (basically [0] sized arrays and all other
> arrays at the end of structures/unions, unless followed by some other field in
> outer structure or by another array member.
> But, all those exceptions are for the case how you can legally use flexible
> array members, i.e. heap allocated objects (or mmap etc.), so pretty much
> where
> the base is a pointer dereference. If the base is a symbol, the only
> supported
> case is the GNU extension of initializing flexible array members.
> Otherwise, if you have size of some decl 32 bytes, trying to access 32th and
> following byte is considered undefined.
>
> And what Richi suggests, some new switch which would allow treating
> DECL_COMMON
> bases more conservatively, expecting that if you have a flexible array member
> or something like that at the end of a DECL_COMMON decl that in (invalid)
> program it might be unified with a larger DECL_COMMON from other TU.
Yes.
Note there isn't really a special-casing of [1] sized arrays. It just
happens to fall out of the case where maxsize ends up equal to size.
Thus a "fix" for the case where treating a[i] as a[0] is the issue
would be
Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c (revision 233172)
+++ gcc/tree-dfa.c (working copy)
@@ -617,7 +617,11 @@ get_ref_base_and_extent (tree exp, HOST_
if (maxsize == -1
&& DECL_SIZE (exp)
&& TREE_CODE (DECL_SIZE (exp)) == INTEGER_CST)
- maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+ {
+ maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
+ if (maxsize == size)
+ maxsize = -1;
+ }
}
else if (CONSTANT_CLASS_P (exp))
{
but that wouldn't fix the aggressive-loop optimization issue as that is
_not_ looking at DECL_SIZE but at the array types domain. Fortran
has a union/record type with one array element of size one.
A Fortran FE fix for that would be to make that array have unknown size
but still somehow force a size to the decl (the FE doesn't know there
is another unit that also defines the decl but with some larger size).
We have a similar issue with deriving alignment from DECL_COMMONs
where appearantly the ELF spec doesn't say anything here and thus
we give up and can't re-align global DECL_COMMONs for better
vectorization for example.
[Bug target/69274] [6 Regression] 435.gromacs performance regression after r231814 on x86 Haswell and bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274 --- Comment #11 from Richard Biener --- Alternate fix not causing PR69689 (but also not getting the extra speedup observed with the original fix): Index: gcc/ira.c === --- gcc/ira.c (revision 233172) +++ gcc/ira.c (working copy) @@ -1774,7 +1774,7 @@ ira_setup_alts (rtx_insn *insn, HARD_REG int nop, nalt; bool curr_swapped; const char *p; - int commutative = -1; + int commutative = -1, alt_commutative = -1; extract_insn (insn); alternative_mask preferred = get_preferred_alternatives (insn); @@ -1838,6 +1838,8 @@ ira_setup_alts (rtx_insn *insn, HARD_REG case '%': /* The commutative modifier is handled above. */ + if (alt_commutative < 0) + alt_commutative = nop; break; case '0': case '1': case '2': case '3': case '4': @@ -1889,10 +1891,13 @@ ira_setup_alts (rtx_insn *insn, HARD_REG } if (commutative < 0) break; + /* Swap forth and back to avoid changing recog_data. */ + if (! curr_swapped + || alt_commutative < 0) + std::swap (recog_data.operand[commutative], + recog_data.operand[commutative + 1]); if (curr_swapped) break; - std::swap (recog_data.operand[commutative], -recog_data.operand[commutative + 1]); } }
[Bug target/69692] New: STV is disabled even when stack is aligned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69692
Bug ID: 69692
Summary: STV is disabled even when stack is aligned
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ienkovich at gcc dot gnu.org
Target Milestone: ---
Target: i686
[hjl@gnu-skl-1 pr69677]$ cat x.i
struct bar
{
int i[16] __attribute__ ((aligned(16)));
};
extern void fn2 (void);
long long a, b;
struct bar
fn1 (struct bar x)
{
long long c = a;
a = b ^ a;
fn2 ();
a = c;
return x;
}
[hjl@gnu-skl-1 pr69677]$ make x.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -m32 -O2 -msse2
-mno-accumulate-outgoing-args -mpreferred-stack-boundary=2 -S x.i
[hjl@gnu-skl-1 pr69677]$ cat x.s
.file "x.i"
.text
.p2align 4,,15
.globl fn1
.type fn1, @function
fn1:
.LFB0:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
pushl %edi
pushl %esi
pushl %ebx
pushl %ecx
.cfi_offset 7, -12
.cfi_offset 6, -16
.cfi_offset 3, -20
.cfi_offset 1, -24
leal8(%ebp), %ecx
subl$4, %esp
movla, %eax
movla+4, %edi
movl(%ecx), %ebx
movl%ecx, %esi
movl%eax, %edx
xorlb, %edx
movl%eax, -20(%ebp)
movl%edx, a
movlb+4, %edx
xorl%edi, %edx
movl%edx, a+4
callfn2
movl-20(%ebp), %eax
movl%edi, a+4
movl%eax, a
movl4(%esi), %eax
movl%eax, (%ebx)
movl8(%esi), %eax
movl%eax, 4(%ebx)
movl12(%esi), %eax
movl%eax, 8(%ebx)
movl16(%esi), %eax
movl%eax, 12(%ebx)
movl20(%esi), %eax
movl%eax, 16(%ebx)
movl24(%esi), %eax
movl%eax, 20(%ebx)
movl28(%esi), %eax
movl%eax, 24(%ebx)
movl32(%esi), %eax
movl%eax, 28(%ebx)
movl36(%esi), %eax
movl%eax, 32(%ebx)
movl40(%esi), %eax
movl%eax, 36(%ebx)
movl44(%esi), %eax
movl%eax, 40(%ebx)
movl48(%esi), %eax
movl%eax, 44(%ebx)
movl52(%esi), %eax
movl%eax, 48(%ebx)
movl56(%esi), %eax
movl%eax, 52(%ebx)
movl60(%esi), %eax
movl%eax, 56(%ebx)
movl64(%esi), %eax
movl%eax, 60(%ebx)
addl$4, %esp
movl%ebx, %eax
popl%ecx
.cfi_restore 1
popl%ebx
.cfi_restore 3
popl%esi
.cfi_restore 6
popl%edi
.cfi_restore 7
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret $4
.cfi_endproc
.LFE0:
.size fn1, .-fn1
.comm b,8,8
.comm a,8,8
.ident "GCC: (GNU) 6.0.0 20160205 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-skl-1 pr69677]$
[Bug debug/59474] Invalid binaries produced when making win32 EXEs with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59474 Johannes S. Mueller-Roemer changed: What|Removed |Added CC||j.s.mueller-roemer at gmx dot net --- Comment #2 from Johannes S. Mueller-Roemer --- This is still broken in 5.1.0 and 5.3.0.
[Bug c++/69688] [6 Regression] -Wsign-compare causes bogus error: size of array ‘uc_code’ is not an integral constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69688 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 --- Mine.
[Bug rtl-optimization/64081] [5/6 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #25 from Alexander Fomin --- Good new, thank you! Sent to ML.
[Bug target/69693] New: Wrong mode is used to load spilled register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693
Bug ID: 69693
Summary: Wrong mode is used to load spilled register
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ienkovich at gcc dot gnu.org
Target Milestone: ---
The problem appears for code generated by STV pass. This code uses paradoxical
subregs which may cause spill/fill mismatch.
>cat test.i
extern const unsigned int a[];
extern const unsigned long long b[];
int
fn1 (unsigned int p1, unsigned long long p2)
{
unsigned int p3;
p3 = a[p1];
if (p3 == 0 || p3 > 64)
return 0;
p2 &= b[p1];
return p2 == ((unsigned long long) 1 << (p3 - 1));
}
>gcc test.i -m32 -O2 -march=corei7 -S
>cat test.s
.file "test.i"
.text
.p2align 4,,15
.globl fn1
.type fn1, @function
fn1:
.LFB0:
.cfi_startproc
pushl %ebx
.cfi_def_cfa_offset 8
.cfi_offset 3, -8
subl$24, %esp
.cfi_def_cfa_offset 32
movl32(%esp), %edx
movl36(%esp), %ecx
movl40(%esp), %ebx
movla(,%edx,4), %eax
movl%ecx, (%esp)
movl%ebx, 4(%esp)
leal-1(%eax), %ecx
xorl%eax, %eax
cmpl$63, %ecx
ja .L2
movqb(,%edx,8), %xmm0
xorl%eax, %eax
xorl%edx, %edx
testb $32, %cl
sete%al
movdqa (%esp), %xmm2
setne %dl
sall%cl, %eax
sall%cl, %edx
pand%xmm0, %xmm2
movd%eax, %xmm0
pinsrd $1, %edx, %xmm0
pxor%xmm2, %xmm0
punpcklqdq %xmm0, %xmm0
ptest %xmm0, %xmm0
sete%al
.L2:
addl$24, %esp
.cfi_def_cfa_offset 8
movzbl %al, %eax
popl%ebx
.cfi_restore 3
.cfi_def_cfa_offset 4
ret
.cfi_endproc
.LFE0:
.size fn1, .-fn1
.ident "GCC: (GNU) 6.0.0 20160127 (experimental)"
.section.note.GNU-stack,"",@progbits
Here we use movdqa to load a spilled value. But value has DImode and was
spilled using two movl instructions. Ideally we shouldn't allocate GPR for
DImode register in this test at all and no spill/fill should occur.
Using gcc version 6.0.0 20160127
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677 --- Comment #17 from Ilya Enkovich --- (In reply to Uroš Bizjak from comment #16) > That doesn't mean that incorrect register fill RA bug should't be fixed > during stage-4. Do we have a small testcase that exposes it? I submitted PR69693 for RA problem.
[Bug target/69693] Wrong mode is used to load spilled register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69693 --- Comment #1 from Ilya Enkovich --- We should be able to revert r233167 if this issue is fixed
[Bug target/69274] [6 Regression] 435.gromacs performance regression after r231814 on x86 Haswell and bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274 --- Comment #12 from Richard Biener --- Key assembly difference seems to be extra reg-reg copies around a loop. But maybe perf lies to me (the description cites fsettle as the real offender but perf points me to inl1130). As I can reproduce the isssue even w/o -fschedule-insns2 I doubted the issue was scheduling related (but I didn't try if -fschedule-insns fixed things). Both loops are rather large though (and vectorized). perf for me shows (reproducible) Samples: 2M of event 'cycles', Event count (approx.): 2251122016217 31.85% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl1130_ 24.64% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] inl1130_ 6.46% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] search_neighbour 6.39% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] search_neighbour 1.70% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl1100_ 1.69% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] inl1100_ 0.96% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl1000_ 0.96% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] inl1000_ 0.86% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl0100_ 0.85% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] inl0100_ 0.75% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] inl1120_ 0.70% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] fsettle_ 0.68% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] fsettle_ 0.65% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] inl1120_ 0.61% gromacs_base.am gromacs_base.amd64-m64-gcc42-nn [.] update 0.61% gromacs_peak.am gromacs_peak.amd64-m64-gcc42-nn [.] update thus not fsettle but the attached. BASE separated: Samples: 1M of event 'cycles', Event count (approx.): 1045723281935, DSO: gromac 68.56% gromacs_base.am [.] inl1130_ 13.92% gromacs_base.am [.] search_neighbours 3.65% gromacs_base.am [.] inl1100_ 2.07% gromacs_base.am [.] inl1000_ 1.84% gromacs_base.am [.] inl0100_ 1.61% gromacs_base.am [.] inl1120_ 1.47% gromacs_base.am [.] fsettle_ PEAK separated: Samples: 1M of event 'cycles', Event count (approx.): 879799417599, DSO: gromacs 63.05% gromacs_peak.am [.] inl1130_ 16.35% gromacs_peak.am [.] search_neighbours 4.33% gromacs_peak.am [.] inl1100_ 2.45% gromacs_peak.am [.] inl1000_ 2.18% gromacs_peak.am [.] inl0100_ 1.79% gromacs_peak.am [.] fsettle_ 1.66% gromacs_peak.am [.] inl1120_ 1.56% gromacs_peak.am [.] update 1.56% gromacs_peak.am [.] put_in_list.constprop.14
[Bug target/69274] [6 Regression] 435.gromacs performance regression after r231814 on x86 Haswell and bdver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69274 --- Comment #13 from Richard Biener --- It would be interesting to see whether FDO also shows the regression (I only have a non-march=native FDO tester and the non-march=native tester doesn't show the regression already). Because it might be that while we vectorize the loops we always end up executing scalar code only due to low loop trip counts. Well, I'll try to investigate in that direction next week.
[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-02-05
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Adjusted testcase, so that it doesn't depend on ASCII ordering, tolower etc.
char u[] = { 46, 97, 99, 104, 52, 0 };
char *v[] = { u, 0 };
static struct S { char a[10]; struct S *b[31]; } *w = 0;
__attribute__((noinline, noclone)) int
fn (int x)
{
if (__builtin_strchr (u, x) || x == 96)
return x;
__builtin_abort ();
}
__attribute__((noinline, noclone)) int
foo (char x)
{
if (x == 0)
__builtin_abort ();
if (fn (x) >= 96 && fn (x) <= 122)
return (fn (x) - 96);
else if (x == 46)
return 0;
else
{
__builtin_printf ("foo %d\n", x);
return -1;
}
}
__attribute__((noinline, noclone)) void
bar (char **x)
{
char **b, c, *d, e[500], *f, g[10];
int z, l, h, i;
struct S *s;
w = __builtin_calloc (1, sizeof (struct S));
for (b = x; *b; b++)
{
__builtin_strcpy (e, *b);
f = e;
do
{
d = __builtin_strchr (f, 32);
if (d)
*d = 0;
l = __builtin_strlen (f);
h = 0;
s = w;
__builtin_memset (g, 0, sizeof (g));
for (z = 0; z < l; z++)
{
c = f[z];
if (c >= 48 && c <= 57)
g[h] = c - 48;
else
{
i = foo (c);
if (!s->b[i])
s->b[i] = __builtin_calloc (1, sizeof (struct S));
s = s->b[i];
h++;
}
}
__builtin_memcpy (s->a, g, 10);
if (d)
f = d + 1;
}
while (d);
}
}
__attribute__((noinline, noclone)) void
baz (char *x)
{
char a[300], b[300];
int z, y, t, l;
struct S *s;
l = __builtin_strlen (x);
*a = 96;
for (z = 0; z < l; z++)
{
a[z + 1] = fn ((unsigned int) x[z]);
if (foo (a[z + 1]) <= 0)
return;
}
a[l + 1] = 96;
l += 2;
__builtin_memset (b, 0, l + 2);
if (!w)
return;
for (z = 0; z < l; z++)
{
s = w;
for (y = z; y < l; y++)
{
s = s->b[foo (a[y])];
if (!s)
break;
for (t = 0; t <= y - z + 2; t++)
if (s->a[t] > b[z + t])
b[z + t] = s->a[t];
}
}
for (z = 3; z < l - 2; z++)
if ((b[z] & 1) == 1)
asm ("");
}
int
main ()
{
bar (v);
char c[] = { 97, 97, 97, 97, 97, 0 };
baz (c);
return 0;
}
[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC||vmakarov at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
This looks like a LRA bug.
We have:
(insn 153 152 276 18 (parallel [
(set (reg/f:DI 183 [ ivtmp.58 ])
(plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0])))
(clobber (reg:CC 17 flags))
]) 219 {*adddi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUIV (plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0]))
(nil
...
(insn 64 159 185 18 (set (reg:DI 182 [ ivtmp.58 ])
(reg/f:DI 183 [ ivtmp.58 ])) pr69691.c:94 85 {*movdi_internal}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0]))
(nil)))
(insn 186 185 323 18 (set (reg:SI 247)
(plus:SI (plus:SI (subreg:SI (reg/f:DI 183 [ ivtmp.58 ]) 0)
(subreg:SI (reg:DI 202) 0))
(const_int 1 [0x1]))) 214 {*leasi}
(nil))
in *.ira, and LRA creates:
(note 153 152 349 18 NOTE_INSN_DELETED)
...
(insn 64 350 185 18 (set (reg:DI 3 bx [orig:182 ivtmp.58 ] [182])
(plus:DI (reg/f:DI 7 sp)
(const_int 32 [0x20]))) pr69691.c:94 215 {*leadi}
(expr_list:REG_EQUAL (plus:DI (reg/f:DI 20 frame)
(const_int -608 [0xfda0]))
(nil)))
(note 185 64 186 18 NOTE_INSN_DELETED)
(insn 186 185 351 18 (set (reg:SI 0 ax [247])
(plus:SI (plus:SI (reg:SI 7 sp)
(reg:SI 42 r13 [202]))
(const_int 65 [0x41]))) 214 {*leasi}
(nil))
out of this. Note, frame-608 is eliminated to sp+32 (looks correct), but in
insn 186 which is supposed to be (int)(frame-608) + (int)r13 + 1 the used
offset is 65, instead of 32+1, so it seems that the 32 from sp+32 got added
twice there during LRA. Vlad, can you please have a look?
That said, on the generated assembly, I find it weird that nothing post reload
CSEs simple stuff like:
leaq32(%rsp), %rdi
leaq32(%rsp), %r14
or
leaq32(%rsp), %rax
movl%esi, %esi
leaq336(%rsp), %r14
leaq32(%rsp), %rbx
Wouldn't it be smaller and better to use movq %rdi, %r14 or movq %rax, %rbx?
Smaller for sure (movq is 2 bytes smaller than leaq with 1 byte immediate).
[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948 --- Comment #10 from Patrick Palka --- Author: ppalka Date: Fri Feb 5 14:36:44 2016 New Revision: 233176 URL: https://gcc.gnu.org/viewcvs?rev=233176&root=gcc&view=rev Log: Fix PR c++/68948 (wrong code generation due to invalid constructor call) gcc/cp/ChangeLog: PR c++/68948 * pt.c (tsubst_baselink): Diagnose an invalid constructor call if lookup_fnfields returns NULL_TREE and the name being looked up has the form A::A. gcc/testsuite/ChangeLog: PR c++/68948 * g++.dg/template/pr68948.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr68948.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607 --- Comment #12 from vries at gcc dot gnu.org --- (In reply to vries from comment #11) > Created attachment 37594 [details] > Updated tentative patch > > This patch builds, and runs target-libgomp with -flto -flto-partition=1to1 > -fno-toplevel-reorder, giving the same failures as normal (-fno-lto). same for -flto-partition=balanced.
[Bug c++/69694] New: type incomplete depending if constructing function is templated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69694
Bug ID: 69694
Summary: type incomplete depending if constructing function is
templated
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bloerwald at googlemail dot com
Target Milestone: ---
Created attachment 37595
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37595&action=edit
source file triggering the bug when compiled with -DA
Depending on whether or not the function creating an object of Fun is a
template or not, Fun is either incomplete or not, in the snippet below. In
addition, once it is referenced from a non-templated function, it is no longer
incomplete in following templated functions.
$ gcc/5.3.0/bin/g++ -fno-strict-aliasing -fwrapv -W -Wall -Werror -Wextra
-std=c++11 -c snippet.cpp -DA
snippet.cpp: In function ‘void a()’:
snippet.cpp:24:44: error: invalid use of incomplete type ‘struct Fun’
template void a() { Fun {}.fun(); }
^
snippet.cpp:8:46: note: declaration of ‘struct Fun’
template struct Fun;
The definitions -DA, -DB, -DC can be used to demonstrate the effect of "once
referenced from non-templated" described above:
-DA: a fails
-DB: success
-DC: c fails
-DA -DB: a fails
-DA -DC: a and c fail
-DB -DC: success (c is fine!)
-DA -DB -DC: a fails, c is fine
Also fails with gcc 4.9.2, succeeds with clang 3.5.1/3.7.1.
Replacing `void fun();` with `void operator()();` and the calls with
`Fun{}();` lets the error message degrade to "no match for call to
‘(Fun) ()’" (note the braces around Fun).
[Bug target/69671] [6 Regression] FAIL: gcc.target/i386/avx512vl-vpmovqb-1.c scan-assembler-times vpmovqb[ \\t]+[^{\n]*%ymm[0-9]+[^\n]*%xmm[0-9]+{%k[1-7]}{z}(?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69671 --- Comment #11 from Jakub Jelinek --- BTW, can you see if the cse.c one-liner has significant effect on say SPEC2k6 with -mavx512* options? If yes, then either we need some help from the RA to deal with this, or perhaps the one-liner should be reverted for GCC 6.
[Bug target/69369] [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369 Ilya Enkovich changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Ilya Enkovich --- Fixed
[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648 --- Comment #11 from Bernd Schmidt --- FWIW that passes bootstrap & regtest on x86_64-linux.
[Bug target/69648] [5/6 Regression] wrong code with -O -mtune=winchip-c6 -fPIC -fexpensive-optimizations -msse4 @ i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69648 --- Comment #12 from Bernd Schmidt --- err, with -fPIC in the CFLAGS was what I was going to say.
[Bug target/69369] [6 Regression] internal compiler error: in remove_unreachable_nodes, at ipa.c:457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69369 --- Comment #6 from Ilya Enkovich --- Author: ienkovich Date: Fri Feb 5 14:41:00 2016 New Revision: 233177 URL: https://gcc.gnu.org/viewcvs?rev=233177&root=gcc&view=rev Log: gcc/ 2016-02-05 Ilya Enkovich PR target/69369 Revert r232560: 2016-01-19 Jan Hubicka * cgraphunit.c (cgraph_node::reset): Clear thunk info and instrumented_version. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c
[Bug c++/66999] Missing comma in lambda capture causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66999
sshannin at gmail dot com changed:
What|Removed |Added
CC||sshannin at gmail dot com
--- Comment #1 from sshannin at gmail dot com ---
Confirmed still present in gcc 5.3.0.
I got a smaller example with a slightly different flavor if it helps:
---
#include
struct foo {
void bar() {
std::function f = std::function(
[&this]() {
int x;
});
}
};
[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948 --- Comment #12 from Patrick Palka --- Created attachment 37596 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37596&action=edit better fix for gcc 7
[Bug c++/68948] G++ voluntarily removes a function call with terrible side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68948 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #11 from Patrick Palka --- Conservative fix applied for GCC 6, a better fix (attached) is going to replace it for GCC 7. A diagnostic is now issued for this invalid constructor call. (Hopefully for GCC 7 we will no longer silently discard erroneous code like that, see https://gcc.gnu.org/ml/gcc-patches/2015-12/msg02234.html)
[Bug c++/69686] Useless -Wparentheses for A && B || !A && C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686 --- Comment #5 from wipedout at yandex dot ru --- Here the compiler just enforces people to add parentheses so that they accidentally put them wrong and then the compiler is happy and the code is buggy.
[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691 --- Comment #4 from Jakub Jelinek --- I think the bug is in move_plus_up, as that function transforms: (subreg:SI (plus:DI (reg/f:DI 20 frame) (const_int 16 [0x10])) 0) into: (plus:SI (plus:SI (subreg:SI (reg/f:DI 20 frame) 0) (const_int 16 [0x10])) (const_int 16 [0x10])) which looks just wrong, it should have been (plus:SI (subreg:SI (reg/f:DI 20 frame) 0) (const_int 16 [0x10])))
[Bug c++/69277] [6 Regression] ICE mangling a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Sebor --- Fixed (for the third time).
[Bug c++/69251] [6 Regression] ICE in unify_array_domain on a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69251 Bug 69251 depends on bug 69277, which changed state. Bug 69277 Summary: [6 Regression] ICE mangling a flexible array member https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69277 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/69686] Useless -Wparentheses for A && B || !A && C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69686 --- Comment #6 from Jonathan Wakely --- (In reply to wipedout from comment #5) > Here the compiler just enforces people to add parentheses so that they > accidentally put them wrong and then the compiler is happy and the code is > buggy. Yes, the compiler forces people to put them in the wrong place. That's right. That's not a ridiculous assertion at all. Thanks for your bug report.
[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 --- Comment #17 from Jeffrey A. Law --- I've got enough state on this BZ and remember just enough MIPS that I can verify behaviour with a cross.
[Bug c++/69687] Buffer Overflow in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687 --- Comment #4 from Marcel Böhme --- Here is my preliminary analysis: The function demangle_args (cplus-dem.c:4424) parses the (crafted) mangled function args from the binary. In line 4452, r is read from mangled. In line 4491, we enter a loop with r iterations. In line 4498, arg is parsed from mangled (always from the same region). In each loop iteration arg is appended to decl, such that the length of decl grows in each iteration. The function string_appends (cplus-dem.c:4820) appends string arg to string decl. In line 4827, it uses string_need to check whether sufficient memory is allocated in decl to append arg. Then, it memcopies whatever is in arg to the end of decl. The function string_need (cplus-dem.c:4751) checks whether sufficient memory is available to append size-of-arg more characters. If not, xrealloc decl with n=2*(length of decl + length of arg) characters. Since n is a signed int, n wraps over at some iteration. Since, realloc expects n to be unsigned, we end up allocating less memory then actually needed. In the beginning though n is too large and xrealloc simply complains. However, if you play a bit with the length of arg, you'll quickly turn that integer overflow in a buffer overflow. Later, string_appends will memcopy whatever arg contains. In our simple test case the relevant bits in the binary are specified the binary (arbitrarily): r = 8000, arg = "A__\235\235\235_N" of length 020. A particularly malicious attacker could craft an executable that executes when *analysed* by objdump, nm or gdb, or any other libbfd / libiberty - based forensics tool (if the demangling option is switched on). -- Marcel Böhme Postdoctoral Researcher TSUNAMi Security Research Lab National University of Singapore
[Bug rtl-optimization/69691] [6 Regression] wrong code at -O2 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69691 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 37597 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37597&action=edit gcc6-pr69691.patch Untested fix.
[Bug libgomp/69607] undefined reference to MAIN__._omp_fn.0 in atomic_capture-1.f with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69607 --- Comment #13 from vries at gcc dot gnu.org --- (In reply to vries from comment #11) > Created attachment 37594 [details] > Updated tentative patch > > This patch builds, and runs target-libgomp with -flto -flto-partition=1to1 > -fno-toplevel-reorder, giving the same failures as normal (-fno-lto). Hmm, fails with -fno-use-linker-plugin though.
[Bug bootstrap/69677] [6 Regression] bootstrap failed with --with-arch=corei7 --with-cpu=corei7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69677 --- Comment #18 from hjl at gcc dot gnu.org --- Author: hjl Date: Fri Feb 5 16:24:06 2016 New Revision: 233180 URL: https://gcc.gnu.org/viewcvs?rev=233180&root=gcc&view=rev Log: Add a testcase for PR target/69677 PR target/69677 * gcc.target/i386/pr69677.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr69677.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273 --- Comment #18 from Jeffrey A. Law --- Richi, The patch fixes both the original testcase as well as the reduced testcase. The difficultly I see is building a reliable test for the regression suite. Parsing RTL dumps looking for the right assignments to the argument registers is, umm, painful.
[Bug fastjar/69695] New: slice of an array retains pointer attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695 Bug ID: 69695 Summary: slice of an array retains pointer attribute Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fastjar Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- The following testcase: > cat test.f90 module point implicit none type point_type integer, dimension(:,:), pointer :: array end type point_type contains subroutine ptest(a) integer, dimension(:), intent(in), pointer :: a write(*,*) a**2 end subroutine ptest end module point program test use point implicit none integer :: i, j type(point_type), pointer:: p1 integer, dimension(:,:), pointer :: a allocate(p1) allocate(p1%array(5,2)) p1%array=42 a => p1%array call ptest(a(:,2)) end program test returns a valgrind error and seemingly wrong output: > gfortran -g test.f90 > valgrind ./a.out ==81284== Memcheck, a memory error detector ==81284== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==81284== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==81284== Command: ./a.out ==81284== ==81284== Invalid read of size 4 ==81284==at 0x400920: __point_MOD_ptest (test.f90:9) ==81284==by 0x400B64: MAIN__ (test.f90:22) ==81284==by 0x400BA3: main (test.f90:13) ==81284== Address 0x4dbf458 is 0 bytes after a block of size 40 alloc'd ==81284==at 0x4A06B3F: malloc (vg_replace_malloc.c:299) ==81284==by 0x4009B9: MAIN__ (test.f90:19) ==81284==by 0x400BA3: main (test.f90:13) ==81284== 1764176417641764 0 ==81284== ==81284== HEAP SUMMARY: ==81284== in use at exit: 112 bytes in 2 blocks ==81284== total heap usage: 21 allocs, 19 frees, 11,952 bytes allocated ==81284== ==81284== LEAK SUMMARY: ==81284==definitely lost: 72 bytes in 1 blocks ==81284==indirectly lost: 40 bytes in 1 blocks ==81284== possibly lost: 0 bytes in 0 blocks ==81284==still reachable: 0 bytes in 0 blocks ==81284== suppressed: 0 bytes in 0 blocks ==81284== Rerun with --leak-check=full to see details of leaked memory ==81284== ==81284== For counts of detected and suppressed errors, rerun with: -v ==81284== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 5) However, the underlying problem is that gfortran doesn't generate a compile time error, as the array slice is passed to a subroutine that expects a pointer argument. Ifort diagnoses this clearly: > ifort test.f90 test.f90(22): error #7121: A ptr dummy may only be argument associated with a ptr, and this array element or section does not inherit the POINTER attr from its parent array. [A] call ptest(a(:,2)) -^ compilation aborted for test.f90 (code 1) I think this should be diagnosed by gfortran as well.
[Bug fortran/69695] slice of an array retains pointer attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug fortran/69368] [6 Regression] spec2006 test case 416.gamess fails with the g++ 6.0 compiler starting with r232508
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69368
--- Comment #32 from alalaw01 at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #31)
>
> Thus a "fix" for the case where treating a[i] as a[0] is the issue
> would be
>
> Index: gcc/tree-dfa.c
> ===
> --- gcc/tree-dfa.c (revision 233172)
> +++ gcc/tree-dfa.c (working copy)
> @@ -617,7 +617,11 @@ get_ref_base_and_extent (tree exp, HOST_
>if (maxsize == -1
> && DECL_SIZE (exp)
> && TREE_CODE (DECL_SIZE (exp)) == INTEGER_CST)
> - maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
> + {
> + maxsize = wi::to_offset (DECL_SIZE (exp)) - bit_offset;
> + if (maxsize == size)
> + maxsize = -1;
> + }
> }
>else if (CONSTANT_CLASS_P (exp))
> {
Maybe if we only did that for DECL_COMMONs if -std=legacy was in force?
Tho as you say:
> but that wouldn't fix the aggressive-loop optimization issue as that is
> _not_ looking at DECL_SIZE but at the array types domain.
I wonder if we can't get both places looking at the same thing (DECL_SIZE or
array type domain), but I haven't looked into that at all.
[Bug tree-optimization/69282] [6 Regression] aarch64/armhf ICE on SPEC2006 464.h264ref at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69282 --- Comment #14 from Jim Wilson --- Andrew Pinksi wrote the patch to fix the ICE. I was expecting him to submit it. He also pointed out that the code with the patch is inefficient, and can be optimized by adding some patterns to the aarch64 and arm backends. I thought he was going to do the aarch64 work. I volunteered to look at the arm backend. Adding a vcond_mask* pattern gives a sequence one instruction shorter. To get a sequence two instructions shorter it looks like I need to rewrite some patterns to use vector rtl instead of unspecs, which seemed inappropriate at this time. I was going to look at this again when we move to stage 1. This stuff should perhaps be a separate bug report.
