[Bug c++/70675] New: [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 Bug ID: 70675 Summary: [6 Regression] compare-debug failure building LLVM 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: --- Looks related to PR70594. markus@x4 tmp % g++ --save-temps -O0 -fcompare-debug -c WinCOFFObjectWriter.ii g++: error: WinCOFFObjectWriter.ii: -fcompare-debug failure markus@x4 tmp % diff -u WinCOFFObjectWriter.gkd WinCOFFObjectWriter.gk.gkd --- WinCOFFObjectWriter.gkd 2016-04-15 09:00:15.277105520 +0200 +++ WinCOFFObjectWriter.gk.gkd 2016-04-15 09:00:19.370332015 +0200 @@ -13249,7 +13249,7 @@ 11: struct StringTableBuilder Strings = TARGET_EXPR >> 1 1 ; @@ -14236,7 +14236,7 @@ 11: struct StringTableBuilder Strings = TARGET_EXPR >> 1 1 ; @@ -19519,7 +19519,7 @@ 10: struct StringTableBuilder Strings = TARGET_EXPR >> 1 1 ; @@ -20315,7 +20315,7 @@ 15: struct StringTableBuilder Strings = TARGET_EXPR >> 1 1 ; @@ -27563,7 +27563,7 @@ 164: struct StringTableBuilder Strings = TARGET_EXPR >> 1 1 ; @@ -88237,7 +88237,7 @@ 7: struct StringTableBuilder Strings = TARGET_EXPR >> 1 1 ;
[Bug target/70674] [4.9/5/6 regression] S/390: Memory access below stack pointer in epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674 Richard Biener changed: What|Removed |Added Priority|P1 |P3 Target Milestone|--- |4.9.4 --- Comment #1 from Richard Biener --- please fill in known-to-work/fail fields. If it's present in 4.9 it can't be P1 (but it is P2). If it's only latent on branches and exposed on trunk then it can be P1.
[Bug rtl-optimization/68814] [4.9/5 regression] gcc.dg/pr63594-2.c fails since r226005
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68814 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c/70671] Wrong column number shown for "error: cannot take address of bit-field"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70671 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-15 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/70666] SLP vectorization opportunity to use load element + splat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70666 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-15 Blocks||53947 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed and mine. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from Richard Biener --- Testcase?
[Bug c++/70617] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70617 --- Comment #7 from Jan Smets --- Should I open a different issue for that?
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Richard Biener --- Fixed.
[Bug tree-optimization/70130] [6 Regression] h264ref fails with verification error starting with r231674 (r224221 is the true start of the problem)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70130 --- Comment #30 from Richard Biener --- Author: rguenth Date: Fri Apr 15 07:28:44 2016 New Revision: 235006 URL: https://gcc.gnu.org/viewcvs?rev=235006&root=gcc&view=rev Log: 2016-04-15 Richard Biener Alan Modra PR tree-optimization/70130 * tree-vect-data-refs.c (vect_supportable_dr_alignment): Detect when alignment stays not the same and no not use the realign scheme then. * gcc.dg/vect/O3-pr70130.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/O3-pr70130.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 --- Comment #2 from Markus Trippelsdorf --- Created attachment 38277 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38277&action=edit unreduced testcase
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 --- Comment #3 from Markus Trippelsdorf --- Created attachment 38278 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38278&action=edit somewhat reduced testcase ~300k seems to be the smallest possible size.
[Bug target/70133] AArch64 -mtune=native generates improperly formatted -march parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70133 --- Comment #14 from Christophe Lyon --- We (Linaro) have backported the relevant patches to our 5.x branch, and this fix is available in our 5.3-2016.04 snapshot.
[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662 --- Comment #2 from Kirill Yukhin --- Author: kyukhin Date: Fri Apr 15 08:25:49 2016 New Revision: 235008 URL: https://gcc.gnu.org/viewcvs?rev=235008&root=gcc&view=rev Log: AVX-512. Fix mem operand modifier for Intel syntax. PR target/70662 gcc/ * config/i386/sse.md: Use proper memory operand modifiers. testsuite/gcc/ * gcc.target/i386/pr70662.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr70662.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/67701] Unnecessary/bad instructions for u32-casted access to external symbol (assumes misaligned, superfluous load)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67701 --- Comment #9 from Richard Biener --- Note the issue should be partly mitigated by the fix for PR70424. The issue in comment#6 is still there as we still trust the alignment of an underlying decl more than the alignment info present on the MEM_REF.
[Bug target/70676] New: suboptimal code generation on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70676 Bug ID: 70676 Summary: suboptimal code generation on AVR Product: gcc Version: 5.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: night_ghost at ykoctpa dot ru Target Milestone: --- gcc -Os -fno-optimize-sibling-calls don't optimizes out tail recursion: return SPI::transfer(0xff); f54:8f ef ldi r24, 0xFF; 255 f56:0e 94 d9 2e call 0x5db2 ; 0x5db2 <_ZN3SPI8transferEh> } f5a:08 95 ret where it should be ldi r24, 0xFF; 255 jmp 0x5db2 ; 0x5db2 <_ZN3SPI8transferEh> Yes I can remove -fno-optimize-sibling-calls but then size of compiled project will be much more: with:30566 bytes (93.3% Full) without: 30772 bytes and binary don't fit to flash (30720 is maximum) Reason is that even with -Os optimize-sibling-calls tries to make epilogue for each tail recursion: 2080:<->92 e0 <-->ldi<--->r25, 0x02<->; 2 2082:<->df 91 <-->pop<--->r29 2084:<->cf 91 <-->pop<--->r28 2086:<->1f 91 <-->pop<--->r17 2088:<->0f 91 <-->pop<--->r16 208a:<->ff 90 <-->pop<--->r15 208c:<->ef 90 <-->pop<--->r14 208e:<->bf 90 <-->pop<--->r11 2090:<->af 90 <-->pop<--->r10 2092:<->9f 90 <-->pop<--->r9 2094:<->8f 90 <-->pop<--->r8 2096:<->0c 94 2a 0f <-->jmp<--->0x1e54<>; 0x1e54 <_ZL12osd_printf_1PKcf> (rjmp here) 209a:<->df 91 <-->pop<--->r29 209c:<->cf 91 <-->pop<--->r28 209e:<->1f 91 <-->pop<--->r17 20a0:<->0f 91 <-->pop<--->r16 20a2:<->ff 90 <-->pop<--->r15 20a4:<->ef 90 <-->pop<--->r14 20a6:<->bf 90 <-->pop<--->r11 20a8:<->af 90 <-->pop<--->r10 20aa:<->9f 90 <-->pop<--->r9 20ac:<->8f 90 <-->pop<--->r8 20ae:<->08 95 <-->ret Can GCC in -Os really optimize only size and rollback optimizations if size of "optimized" code is more than size of non-optimized ?
[Bug target/67701] Unnecessary/bad instructions for u32-casted access to external symbol (assumes misaligned, superfluous load)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67701 --- Comment #10 from Richard Biener --- The reason for the legacy on x86 targets is indeed not present on strict-alignment platforms if it is the case that on strict-alignment platforms unaligned accesses trap (and are not merely slow). Index: gcc/builtins.c === --- gcc/builtins.c (revision 235005) +++ gcc/builtins.c (working copy) @@ -339,7 +339,8 @@ get_object_alignment_2 (tree exp, unsign 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 + if (!addr_p + && (!known_alignment || STRICT_ALIGNMENT) && TYPE_ALIGN (TREE_TYPE (exp)) > align) align = TYPE_ALIGN (TREE_TYPE (exp)); else
[Bug target/70677] New: Suboptimal cond on AVR: unneeded stack frame
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70677
Bug ID: 70677
Summary: Suboptimal cond on AVR: unneeded stack frame
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: night_ghost at ykoctpa dot ru
Target Milestone: ---
here a lot of commands to deal with stack frame for only one byte
//(out of scope:
struct Point {
byte x;
byte y;
};
static boolean inline is_alt(point p){
return (p.y & 0x40);
}
//)
static void panVel(point p){
1e14: cf 93 pushr28
1e16: df 93 pushr29
1e18: 1f 92 pushr1
1e1a: cd b7 in r28, 0x3d ; 61
1e1c: de b7 in r29, 0x3e ; 62
printSpeed(cnvGroundSpeed(),is_alt(p));
1e1e: 96 fb bst r25, 6
1e20: 22 27 eor r18, r18
1e22: 20 f9 bld r18, 0
1e24: 29 83 std Y+1, r18; 0x01
1e26: 0e 94 33 09 call0x1266; 0x1266 <_ZL14cnvGroundSpeedv>
1e2a: ab 01 movwr20, r22
1e2c: bc 01 movwr22, r24
}
1e2e: 29 81 ldd r18, Y+1; 0x01
1e30: 87 e8 ldi r24, 0x87 ; 135
1e32: 92 e0 ldi r25, 0x02 ; 2
1e34: 0e 94 c6 0e call0x1d8c; 0x1d8c <_ZL10printSpeedPKcfh>
1e38: 0f 90 pop r0
1e3a: df 91 pop r29
1e3c: cf 91 pop r28
1e3e: 08 95 ret
R18 can be PUSH'ed, moved to r28 or even calculated after call to x1266
[Bug c/70678] New: Static function compilation behaviour changes with __attribute__((optimize("O2"))) even if already compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70678
Bug ID: 70678
Summary: Static function compilation behaviour changes with
__attribute__((optimize("O2"))) even if already
compiling with -O2
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lutoma at ohai dot su
Target Milestone: ---
Noticed this while tracking down another issue. I have seen this on GCC 4.6.4
and 5.3.0.
#include
#include
static void test_function() {
printf("Hello world!\n");
}
int main() {
test_function();
return EXIT_SUCCESS;
}
Compiled using "gcc -o test test.c -O2 -save-temps -Wall -Wextra
-fno-strict-aliasing -fwrapv", GCC will optimize the test_function() by
including it into main().
If the function definition is changed to
static void __attribute__((optimize("O2"))) test_function() {
and the file is compiled using the same command, the test_function() will stay
separate, and is not optimized into main(), even though the optimization levels
have not changed.
Intermediate with the additional optimize attribute:
https://gist.githubusercontent.com/lutoma/b36eda746d618c2e5f8b0e28e1478b34/raw/a9ce9f8d23f954a112a911621e3e3c10d3a1f307/test.i
Intermediate without the additional attribute:
https://gist.githubusercontent.com/lutoma/ac300f0349be4e4de15a4709813e17f0/raw/4b193c8d2aca363c26a0241ad6d7a821427593a5/test.i
Generated assembly for the functions:
Without extra optimize attribute:
004003f0 :
4003f0: 48 83 ec 08 subrsp,0x8
4003f4: bf 94 05 40 00 movedi,0x400594
4003f9: e8 c2 ff ff ff call 4003c0
4003fe: 31 c0 xoreax,eax
400400: 48 83 c4 08 addrsp,0x8
400404: c3 ret
[…]
With the extra attribute:
00400506 :
400506: bf 94 05 40 00 movedi,0x400594
40050b: e9 b0 fe ff ff jmp4003c0
004003f0 :
4003f0: 48 83 ec 08 subrsp,0x8
4003f4: 31 c0 xoreax,eax
4003f6: e8 0b 01 00 00 call 400506
4003fb: 31 c0 xoreax,eax
4003fd: 48 83 c4 08 addrsp,0x8
400401: c3 ret
[…]
Sorry if this is a duplicate or intended/undefined behaviour in some way.
Cheers,
Lukas
[Bug rtl-optimization/69633] [6 Regression] Redundant move is generated after r228097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69633 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/70568] [4.9/5/6 regression] PowerPC64: union of floating and fixed doesn't use POWER8 GPR/VSR moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70568 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug sanitizer/70624] [6 Regression] Several hundred asan failures with 6.0 on x86_64-apple-darwin10.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70624 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #6 from Richard Biener --- Seems we have a fix - lets fix it for GCC 6.
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 --- Comment #4 from Richard Biener --- Does removing "deletable" from the constexpr_call_table fix it? Does playing with GC parameters allow further reduction?
[Bug target/70674] [4.9/5/6 regression] S/390: Memory access below stack pointer in epilogue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70674 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Severity|critical|normal
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-15 Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- Confirmed btw.
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #6 from Richard Biener ---
Index: gcc/cp/constexpr.c
===
--- gcc/cp/constexpr.c (revision 235005)
+++ gcc/cp/constexpr.c (working copy)
@@ -915,7 +915,7 @@ struct constexpr_ctx {
/* A table of all constexpr calls that have been evaluated by the
compiler in this translation unit. */
-static GTY ((deletable)) hash_table
*constexpr_call_table;
+static GTY (()) hash_table *constexpr_call_table;
static tree cxx_eval_constant_expression (const constexpr_ctx *, tree,
bool, bool *, bool *, tree * = NULL);
fixes it.
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 --- Comment #7 from Richard Biener --- Which means playing with gc parameters might reduce it to sth suitable for the testsuite?
[Bug c++/70679] New: [6 Regression] -fcompare-debug building LLVM with checking=release compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70679
Bug ID: 70679
Summary: [6 Regression] -fcompare-debug building LLVM with
checking=release compiler
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: ---
trippels@gcc2-power8 llvm_build % g++ --save-temps -fcompare-debug
-DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fPIC -fvisibility-inlines-hidden
-Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual
-Wno-missing-field-initializers -pedantic -Wno-long-long
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -std=c++11 -O2
-pipe -mlra -Ilib/Support -I/home/trippels/llvm/lib/Support -Iinclude
-I/home/trippels/llvm/include -UNDEBUG -fno-exceptions -fno-rtti -MMD -MT
lib/Support/CMakeFiles/LLVMSupport.dir/CommandLine.cpp.o -MF
lib/Support/CMakeFiles/LLVMSupport.dir/CommandLine.cpp.o.d -o
lib/Support/CMakeFiles/LLVMSupport.dir/CommandLine.cpp.o -c
/home/trippels/llvm/lib/Support/CommandLine.cpp
g++: warning: -pipe ignored because -save-temps specified
g++: error: /home/trippels/llvm/lib/Support/CommandLine.cpp: -fcompare-debug
failure
trippels@gcc2-power8 llvm_build % diff -u CommandLine.gkd CommandLine.gk.gkd
--- CommandLine.gkd 2016-04-15 09:31:13.246179530 +
+++ CommandLine.gk.gkd 2016-04-15 09:31:16.646253990 +
@@ -24217,8 +24217,8 @@
(code_label # 0 0 868 "" [1 uses])
(note # 0 0 [bb 13] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 (set (reg:DI 9 9 [368])
-(const_int 808517632 [0x3031]))
/home/trippels/llvm/include/llvm/Support/raw_ostream.h:169# {*movdi_internal64}
- (expr_list:REG_EQUAL (const_int 808517632 [0x3031])
+(const_int 858849280 [0x3331]))
/home/trippels/llvm/include/llvm/Support/raw_ostream.h:169# {*movdi_internal64}
+ (expr_list:REG_EQUAL (const_int 858849280 [0x3331])
(nil)))
(insn # 0 0 (set (reg:DI 9 9 [368])
(ior:DI (reg:DI 9 9 [368])
@@ -24235,7 +24235,7 @@
(insn # 0 0 (set (reg:DI 9 9 [317])
(ior:DI (reg:DI 9 9 [368])
(const_int 14640 [0x3930])))
/home/trippels/llvm/include/llvm/Support/raw_ostream.h:169# {*booldi3_imm}
- (expr_list:REG_EQUIV (const_int 347262077025328 [0x30313a31333a3930])
+ (expr_list:REG_EQUIV (const_int 3688793552780409136 [0x33313a31333a3930])
(nil)))
(insn # 0 0 (set (mem:DI (reg/f:DI 10 10 [orig:176 prephitmp_70 ] [176]) [
MEM[(void *)prephitmp_70]+0 S8 A8])
(reg:DI 9 9 [317]))
/home/trippels/llvm/include/llvm/Support/raw_ostream.h:169# {*movdi_internal64}
Unfortunately it doesn't fail on the CommandLine.ii file.
[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662 --- Comment #3 from Kirill Yukhin --- Author: kyukhin Date: Fri Apr 15 09:36:31 2016 New Revision: 235013 URL: https://gcc.gnu.org/viewcvs?rev=235013&root=gcc&view=rev Log: AVX-512. Use proper mem ops modifier for Intel syntax in broadcast patter. PR target/70662 gcc/ * config/i386/sse.md: Use proper memory operand modifiers. gcc/testsuite. * gcc.target/i386/pr70662.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr70662.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/sse.md branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug fortran/70673] [5/6 Regression] ICE with module containing functions with allocatable character scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70673 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-15 CC||tkoenig at gcc dot gnu.org Known to work||4.8.5, 4.9.3 Version|fortran-dev |6.0 Blocks||68241 Summary|ICE with module containing |[5/6 Regression] ICE with |functions with allocatable |module containing functions |character scalars |with allocatable character ||scalars Ever confirmed|0 |1 Known to fail||5.3.0, 6.0 --- Comment #3 from Dominique d'Humieres --- The tests compile with 4.8.5 and 4.9.3, but give an ICE with 5.3 and trunk (6.0). The change occurred between revisions r219174 (2015-01-04, OK) and r219318 (2015-01-07, ICE); r219193 (pr47674)? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 [Bug 68241] [meta-bug] Deferred-length character
[Bug c++/70679] [6 Regression] -fcompare-debug building LLVM with checking=release compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70679 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #1 from Richard Biener --- Can you see if the fix in PR70675 works? That is, is this a dup? Does reducing GC params make it reproduce with the .ii file?
[Bug c/70678] Static function compilation behaviour changes with __attribute__((optimize("O2"))) even if already compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70678
--- Comment #1 from Richard Biener ---
Declaring test_function inline and using -Winline shows:
t.c:4:52: warning: inlining failed in call to ‘test_function’: optimization
level attribute mismatch [-Winline]
static inline void __attribute__((optimize("O2"))) test_function() {
^
which is because while -fwrapv is still set -fno-strict-aliasing is not.
This is because parse_optimize_options (-O2) will turn on -fstrict-aliasing.
It does that via calling
301 default_options_optimization (opts, opts_set,
302 decoded_options, decoded_options_count,
303 loc, lang_mask, &handlers, dc);
and I think this is intended behavior. It's a little inconsistent that
-fwrapv is not changed, but that's because it is never on by default.
[Bug c++/70679] [6 Regression] -fcompare-debug building LLVM with checking=release compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70679 --- Comment #2 from Markus Trippelsdorf --- (In reply to Richard Biener from comment #1) > Can you see if the fix in PR70675 works? That is, is this a dup? Unfortunately no. > Does reducing GC params make it reproduce with the .ii file? --param ggc-min-expand=5 --param ggc-min-heapsize=5 doesn't help.
[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70436 --- Comment #18 from Jakub Jelinek --- Created attachment 38279 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38279&action=edit gcc6-pr70436-omp.patch Untested fix for OpenMP/OpenACC/Cilk+/#pragma GCC ivdep, both C and C++.
[Bug c++/70679] [6 Regression] -fcompare-debug building LLVM with checking=release compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70679
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #3 from Markus Trippelsdorf ---
Sorry this is a bogus bug.
CommandLine.cpp contains:
std::cout << " Built " << __DATE__ << " (" << __TIME__ << ").\n"
So this is simply the __TIME__ difference...
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 38280 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38280&action=edit gcc6-pr70675.patch Untested fix.
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #20 from Jakub Jelinek ---
The empty class passing ABI changes were reverted and are going to be resolved
only for GCC7+.
I've tried your testcase (and latest preprocessed hash_policy.ii from i686
build) with -g -O2 {,-finline-small-functions} {,-fpic} -mx32, and certainly
don't see any .cfi_escape directives in there. So, what is the real bug then?
>From gcc-testresults, it seems it only fails with -mx32 -fpic, and not with
plain -mx32, but that is all I can find out.
[Bug middle-end/70680] New: [5/6 Regression] OpenMP SIMD linear variable privatized too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70680
Bug ID: 70680
Summary: [5/6 Regression] OpenMP SIMD linear variable
privatized too eagerly
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amonakov at gcc dot gnu.org
Target Milestone: ---
#include
int main()
{
int i=0;
#pragma omp task default(shared) if(0)
{
#pragma omp simd
for (i=0; i<100; i++)
;
#ifdef USE
asm("" : : "r"(i));
#endif
}
printf("%d\n", i);
}
Per my understanding of the OpenMP spec, this program should always print
'100'; indeed, that is observed with gcc-4.9, but gcc-5 does not share 'i' with
the task region, unless a dummy use is injected after the openmp-simd loop:
$ gcc-4.9 -O2 -fopenmp t.c && ./a.out
100
$ gcc-5.1 -O2 -fopenmp t.c && ./a.out
0
$ gcc-5.1 -DUSE -O2 -fopenmp t.c && ./a.out
100
[Bug middle-end/70680] [5/6 Regression] OpenMP SIMD linear variable privatized too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70680 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.4
[Bug rtl-optimization/70681] New: [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 Bug ID: 70681 Summary: [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc 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: ktkachov at gcc dot gnu.org Target Milestone: --- Target: arm, powerpc As reported at: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg01640.html and https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00094.html The tests: gcc.dg/ira-shrinkwrap-prep-2.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping" gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping" Have started failing on arm and powerpc after a regalloc change. On arm at least the resulting codegen doesn't look worse (https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00223.html) but arguably shrink-wrapping could be improved (https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00265.html) This is a report to track work on shrinkwrapping or adjustment of the testscases
[Bug rtl-optimization/70681] [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-15 Known to work||5.3.1 Ever confirmed|0 |1 Known to fail||6.0
[Bug middle-end/70680] [5/6 Regression] OpenMP SIMD linear variable privatized too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70680 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-04-15 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Confirmed, gimplification bug where the shared (i) clause isn't added; I'll have a look next week; it doesn't have to block 6.1 though, can be backported after it goes out.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #14 from Richard Biener --- (In reply to Josh Poimboeuf from comment #13) > So if I understand correctly, some reachable code is incorrectly getting > marked unreachable and then getting discarded. > > Interestingly, the function's epilogue (frame pointer restore) and return > instruction are also getting discarded. Can you tell if that will always be > the case when this bug triggers? I don't think we can rely on that. The path could simply fall thru to a random instruction which is still inside the function. Say, if it was if (x) ... else ... foo (); then the arm marked unreachable would simply disappear. > If so, that should make it possible for objtool to reliably detect the bug.
[Bug c/70678] Static function compilation behaviour changes with __attribute__((optimize("O2"))) even if already compiling with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70678 --- Comment #2 from Lukas Martini --- Hi, thanks for testing. I have to admit the explanation regarding how the various switches play together went a little over my head, but if you tell me that's intended behaviour, I'll trust your word on it :) Just to be sure: For me, this also happens when "-fno-strict-aliasing -fwrapv" are not added as parameters, I only added those because I saw them mentioned somewhere in the bug reporting guidelines. If it's still intended behaviour without them, feel free to close this bug report and thanks for the help! Cheers, Lukas
[Bug c/70651] [6 Regression] ICE on valid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #7 from Marek Polacek ---
I'm testing this:
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -5725,7 +5725,12 @@ build_va_arg (location_t loc, tree expr, tree type)
/* Verify that &ap is still recognized as having va_list type. */
tree canon_expr_type
= targetm.canonical_va_list_type (TREE_TYPE (expr));
- gcc_assert (canon_expr_type != NULL_TREE);
+ if (canon_expr_type == NULL_TREE)
+ {
+ error_at (loc,
+ "first argument to % not of type %");
+ return error_mark_node;
+ }
return build_va_arg_1 (loc, type, expr);
}
@@ -5793,7 +5798,12 @@ build_va_arg (location_t loc, tree expr, tree type)
/* Verify that &ap is still recognized as having va_list type. */
tree canon_expr_type
= targetm.canonical_va_list_type (TREE_TYPE (expr));
- gcc_assert (canon_expr_type != NULL_TREE);
+ if (canon_expr_type == NULL_TREE)
+ {
+ error_at (loc,
+ "first argument to % not of type %");
+ return error_mark_node;
+ }
}
else
{
[Bug c/70436] [4.9/5/6 Regression] -Wparentheses missing ambiguous else warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70436 --- Comment #19 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 12:24:18 2016 New Revision: 235020 URL: https://gcc.gnu.org/viewcvs?rev=235020&root=gcc&view=rev Log: PR c/70436 c/ * c-parser.c (c_parser_pragma): Add IF_P argument, pass it down where needed. (c_parser_external_declaration, c_parser_struct_or_union_specifier, c_parser_parameter_declaration, c_parser_compound_statement_nostart, c_parser_objc_class_instance_variables, c_parser_objc_methodprotolist): Adjust c_parser_pragma callers. (c_parser_statement_after_labels): Likewise. Adjust c_parser_cilk_for caller. (c_parser_omp_structured_block): Add IF_P argument, pass it down to c_parser_statement. (c_parser_oacc_data, c_parser_oacc_host_data, c_parser_oacc_loop, c_parser_oacc_kernels_parallel, c_parser_omp_critical, c_parser_omp_simd, c_parser_omp_for, c_parser_omp_master, c_parser_omp_ordered, c_parser_omp_parallel, c_parser_omp_single, c_parser_omp_task, c_parser_omp_taskgroup, c_parser_omp_distribute, c_parser_omp_teams, c_parser_omp_target_data, c_parser_omp_target, c_parser_omp_taskloop, c_parser_omp_construct, c_parser_cilk_grainsize, c_parser_cilk_simd, c_parser_cilk_for): Add IF_P argument, pass it down where needed. (c_parser_omp_for_loop): Likewise. Clear IF_P if nbraces. (c_parser_omp_sections_scope): Adjust c_parser_omp_structured_block calls. cp/ * parser.c (cp_parser_pragma): Add IF_P argument, pass it down where needed. (cp_parser_declaration_seq_opt, cp_parser_member_specification_opt, cp_parser_objc_interstitial_code, cp_parser_omp_declare_simd, cp_parser_oacc_routine): Adjust cp_parser_pragma callers. (cp_parser_statement): Likewise. Adjust cp_parser_cilk_for caller. (cp_parser_omp_structured_block): Add IF_P argument, pass it down to cp_parser_statement. (cp_parser_oacc_data, cp_parser_oacc_host_data, cp_parser_oacc_loop, cp_parser_oacc_kernels_parallel, cp_parser_omp_critical, cp_parser_omp_simd, cp_parser_omp_for, cp_parser_omp_master, cp_parser_omp_ordered, cp_parser_omp_parallel, cp_parser_omp_single, cp_parser_omp_task, cp_parser_omp_taskgroup, cp_parser_omp_distribute, cp_parser_omp_teams, cp_parser_omp_target_data, cp_parser_omp_target, cp_parser_omp_taskloop, cp_parser_omp_construct, cp_parser_cilk_grainsize, cp_parser_cilk_simd, cp_parser_cilk_for): Add IF_P argument, pass it down where needed. (cp_parser_omp_for_loop): Likewise. Clear IF_P if nbraces. (cp_parser_omp_sections_scope): Adjust cp_parser_omp_structured_block calls. testsuite/ * c-c++-common/Wparentheses-1.c: New test. * c-c++-common/gomp/Wparentheses-1.c: New test. * c-c++-common/gomp/Wparentheses-2.c: New test. * c-c++-common/gomp/Wparentheses-3.c: New test. * c-c++-common/gomp/Wparentheses-4.c: New test. * c-c++-common/cilk-plus/PS/Wparentheses-1.c: New test. * c-c++-common/cilk-plus/CK/Wparentheses-1.c: New test. * c-c++-common/goacc/Wparentheses-1.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wparentheses-1.c trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/Wparentheses-1.c trunk/gcc/testsuite/c-c++-common/cilk-plus/PS/Wparentheses-1.c trunk/gcc/testsuite/c-c++-common/goacc/Wparentheses-1.c trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-1.c trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-2.c trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-3.c trunk/gcc/testsuite/c-c++-common/gomp/Wparentheses-4.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/70019] VLA size overflow not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70019 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 12:29:32 2016 New Revision: 235021 URL: https://gcc.gnu.org/viewcvs?rev=235021&root=gcc&view=rev Log: PR c++/69517 PR c++/70019 PR c++/70588 * g++.dg/cpp1y/vla11.C: Revert for real. Removed: trunk/gcc/testsuite/g++.dg/cpp1y/vla11.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588 --- Comment #10 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 12:29:32 2016 New Revision: 235021 URL: https://gcc.gnu.org/viewcvs?rev=235021&root=gcc&view=rev Log: PR c++/69517 PR c++/70019 PR c++/70588 * g++.dg/cpp1y/vla11.C: Revert for real. Removed: trunk/gcc/testsuite/g++.dg/cpp1y/vla11.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/69517] [7 regression] SEGV on a VLA with excess initializer elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517 --- Comment #13 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 12:29:32 2016 New Revision: 235021 URL: https://gcc.gnu.org/viewcvs?rev=235021&root=gcc&view=rev Log: PR c++/69517 PR c++/70019 PR c++/70588 * g++.dg/cpp1y/vla11.C: Revert for real. Removed: trunk/gcc/testsuite/g++.dg/cpp1y/vla11.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 --- Comment #21 from H.J. Lu --- (In reply to Jakub Jelinek from comment #20) > From gcc-testresults, it seems it only fails with -mx32 -fpic, and not with > plain -mx32, but that is all I can find out. See: https://gcc.gnu.org/ml/gcc-regression/2016-04/msg00123.html https://gcc.gnu.org/ml/gcc-regression/2016-04/msg00129.html
[Bug rtl-optimization/70681] [6 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 --- Comment #1 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Apr 15 12:45:20 2016 New Revision: 235024 URL: https://gcc.gnu.org/viewcvs?rev=235024&root=gcc&view=rev Log: [testsuite] PR rtl-optimization/70681: XFAIL ira-shrinkwrap-prep-2.c and pr10474.c tests on arm, powerpc PR rtl-optimization/70681 * gcc.dg/ira-shrinkwrap-prep-2.c: XFAIL shrinkwrapping dump scan on arm and powerpc. * gcc.dg/pr10474.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-2.c trunk/gcc/testsuite/gcc.dg/pr10474.c
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239 --- Comment #22 from H.J. Lu --- Created attachment 38281 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38281&action=edit A testcase Compile it with -O2 -S -mx32.
[Bug middle-end/67239] [6 Regression] FAIL: 23_containers/unordered_set/insert/hash_policy.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67239
--- Comment #23 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #20)
> The empty class passing ABI changes were reverted and are going to be
> resolved only for GCC7+.
> I've tried your testcase (and latest preprocessed hash_policy.ii from i686
> build) with -g -O2 {,-finline-small-functions} {,-fpic} -mx32, and certainly
> don't see any .cfi_escape directives in there. So, what is the real bug
> then?
i686 != x32. Please try the testcase in
https://gcc.gnu.org/bugzilla/attachment.cgi?id=38281
and compile it with -O2 -S:
[hjl@gnu-6 libstdc++-v3]$ ../../gcc/xgcc -B../../gcc/ -O2 -S hash_policy.ii
-mx32
[hjl@gnu-6 libstdc++-v3]$ grep cfi_escape hash_policy.s
.cfi_escape 0x2e,0x10
.cfi_escape 0x2e,0
[hjl@gnu-6 libstdc++-v3]$
[Bug rtl-optimization/70681] [6/7 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 ktkachov at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |7.0 Summary|[6 Regression] FAIL:|[6/7 Regression] FAIL: |gcc.dg/ira-shrinkwrap-prep- |gcc.dg/ira-shrinkwrap-prep- |2.c gcc.dg/pr10474.c on|2.c gcc.dg/pr10474.c on |arm and powerpc |arm and powerpc --- Comment #2 from ktkachov at gcc dot gnu.org --- Tests xfailed on arm and powerpc for GCC 6. Changing milestone for GCC 7
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 13:07:43 2016 New Revision: 235025 URL: https://gcc.gnu.org/viewcvs?rev=235025&root=gcc&view=rev Log: PR c++/70675 * tree-pretty-print.c (do_niy): Add FLAGS argument, pass it down to dump_generic_node. (NIY): Pass also flags to do_niy. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-pretty-print.c
[Bug c++/70675] [6 Regression] compare-debug failure building LLVM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70675 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug c++/70505] [4.9/5/6 Regression] Constexpr failure when template type specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70505 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/70651] [6 Regression] ICE on invalid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Fri Apr 15 13:15:23 2016 New Revision: 235027 URL: https://gcc.gnu.org/viewcvs?rev=235027&root=gcc&view=rev Log: PR c/70651 * c-common.c (build_va_arg): Change two asserts into errors and return error_mark_node. * c-c++-common/pr70651.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr70651.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- Even with the #c10 change it looks to be aliasing violation, does it work fine if you compile with -fno-strict-aliasing or use may_alias on the type through which it is read?
[Bug c/70651] [6 Regression] ICE on invalid code on x86_64-linux-gnu in build_va_arg, at c-family/c-common.c:5728
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70651 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #16 from Jan Hubicka --- > Honza? This seems to be somewhat fragile (redirecting things to unreachable > but _not_ changing the actual predicates in the IL). Claiming the > predicate is constant true is also a bit bogus (as can be seen in following > optimization). At WPA stage inliner can not update IL, so it simply redirects to builtin_unreachable if predicate is FALSE and expects scalar passes to be monotonously smarter than IPA analysis. BB3 predicate true is conservatively correct: there is no predicate to represent that something is not constant because we assume scalar optimizers to possibly be stronger than us and decide better. Here we manage to assume that builtin_constant_p is true and thus we conclude the following BB is unreachable: BB 4 predicate:(op0[ref offset: 0] not constant) iftmp.0_26 = __builtin_bswap64 (_3); freq:0.61 size: 1 time: 1 This is because ipa-prop analyzes the values in node_name: Jump functions of caller broken/2: callsite broken/2 -> wwn_to_u64/1 : param 0: UNKNOWN Aggregate passed by reference: offset: 0, cst: 255 offset: 8, cst: 255 offset: 16, cst: 255 offset: 24, cst: 255 offset: 32, cst: 255 offset: 40, cst: 255 offset: 48, cst: 255 offset: 56, cst: 255 but later we fold: : node_name[0] = 255; node_name[1] = 255; node_name[2] = 255; node_name[3] = 255; node_name[4] = 255; node_name[5] = 255; node_name[6] = 255; node_name[7] = 255; _14 = MEM[(const u64 *)&node_name]; _15 = __builtin_constant_p (_14); into false (which is stupid, but conservatively correct modulo the assumption about IPA passes being consistently weakter than local passes). Making IPA passes to fold builtin_constant_p call into true is technically possible, if I add builtin_true and redirect to it, but it would not be very good if the local passes can not fold above (as the wrong arm is taken). So can we possibly fix the local passes? Honza
[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662
--- Comment #4 from H.J. Lu ---
The fix is incomplete:
[hjl@gnu-6 gcc]$ /export/build/gnu/gcc-x32/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc-x32/build-x86_64-linux/gcc/ -mx32 -mtune=slm
-fno-diagnostics-show-caret -fdiagnostics-color=never -Og -fschedule-insns
-fno-tree-fre -mavx512vbmi --param=max-sched-ready-insns=1 -masm=intel -c -o
pr70662.o
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.target/i386/pr70662.c
/tmp/ccatFXMU.s: Assembler messages:
/tmp/ccatFXMU.s:240: Error: operand size mismatch for `vpbroadcastd'
[hjl@gnu-6 gcc]$
vpbroadcastdzmm17{k1}, QWORD PTR [esp+184]
[Bug fortran/70673] [5/6 Regression] ICE with module containing functions with allocatable character scalars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70673 --- Comment #4 from David Kinniburgh --- It seems the problem usually arises when there is reassignment in one line, eg character(:), allocatable: s, t s = s(2:) ! or even s = s whereas forcing the temporary t = s(2:) s = t seems to work. But it is not quite that simple as the above doesn't always fail. It requires other things to be happening too.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #17 from Josh Poimboeuf --- (In reply to Richard Biener from comment #14) > (In reply to Josh Poimboeuf from comment #13) > > Interestingly, the function's epilogue (frame pointer restore) and return > > instruction are also getting discarded. Can you tell if that will always be > > the case when this bug triggers? > > I don't think we can rely on that. The path could simply fall thru to > a random instruction which is still inside the function. Say, if it was > > if (x) > ... > else > ... > foo (); > > then the arm marked unreachable would simply disappear. I tried doing that by putting the offending wwn_to_u64() call in an if statement, but then the bug disappeared. In fact, adding *any* code before the call seems to make the bug disappear.
[Bug c/70671] Wrong column number shown for "error: cannot take address of bit-field"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70671 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've got a fix (extremely trivial).
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 Jan Hubicka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mjambor at suse dot cz --- Comment #18 from Jan Hubicka --- Jakub: There is indeed aliasing issue, but with -fno-strict-aliasing the bug is the same. Apparently this is ipa-prop bug, because ipa-prop does not track size of accesses and thus it does not know there is a mismatch. The value produced is thus not INT_MAX as intended but 255. This is Martin's area.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #19 from Jan Hubicka --- Josh: This is limitation of ipa-prop tracking. It very easily gives up on determinging constantness of aggregate parameter. Hope Martin will fix it next stage1. WIP patches was done few releases back but not merged so far.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #20 from Josh Poimboeuf --- Thanks very much to everyone who has looked into this so far. It would be very helpful to get answers to the following questions, so we can understand the impact to the kernel: 1) Is there a reliable way to avoid the bug, either in code or with a gcc flag? 2) Is there a reliable way to detect the bug by looking at the object code?
[Bug target/70682] New: [6 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70682
Bug ID: 70682
Summary: [6 Regression] -fcompare-debug building LLVM with
checking=release compiler on ppc64le
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Target Milestone: ---
Target: ppc64le
Created attachment 38282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38282&action=edit
unreduced testcase
On ppc64le running r235027 I get:
trippels@gcc2-power8 llvm_build % g++ --save-temps -fcompare-debug -O3
-fno-devirtualize -c CGStmtOpenMP.gk.ii
g++: error: CGStmtOpenMP.gk.ii: -fcompare-debug failure
trippels@gcc2-power8 llvm_build % diff -u CGStmtOpenMP.gk.gkd
CGStmtOpenMP.gk.gk.gkd
--- CGStmtOpenMP.gk.gkd 2016-04-15 13:59:37.734070548 +
+++ CGStmtOpenMP.gk.gk.gkd 2016-04-15 13:59:50.954364032 +
@@ -177184,7 +177184,7 @@
(mem/f/c:DI (plus:DI (reg/f:DI 1 1)
(const_int 928 [0x3a0])) [ MEM[(struct
specific_clause_iterator *)&D.]+0 S8 A128]))# {*movdi_internal64}
(nil))
-(insn # 0 0 (set (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849456_I_665.9647 ] [786])
+(insn # 0 0 (set (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849458_I_665.9647 ] [786])
(vec_select:V2DI (mem/c:V2DI (plus:DI (reg/f:DI 1 1)
(reg:DI 10 10 [916])) [ MEM[(struct
specific_clause_iterator *)&D.]+0 S16 A128])
(parallel [
@@ -177209,12 +177209,12 @@
(nil))
(insn:TI # 0 0 (set (mem/c:V2DI (plus:DI (reg/f:DI 1 1)
(reg:DI 10 10 [917])) [ MEM[(struct specific_clause_iterator
*)&__for_begin]+0 S16 A128])
-(vec_select:V2DI (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849456_I_665.9647 ] [786])
+(vec_select:V2DI (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849458_I_665.9647 ] [786])
(parallel [
(const_int 1 [0x1])
(const_int 0 [0])
])))
/home/trippels/llvm/tools/clang/lib/CodeGen/CGStmtOpenMP.cpp:2355#
{*vsx_stxvd2x2_le_v2di}
- (expr_list:REG_DEAD (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849456_I_665.9647 ] [786])
+ (expr_list:REG_DEAD (reg:V2DI 32 0 [orig:786
vect_begin_iterator_D849458_I_665.9647 ] [786])
(expr_list:REG_DEAD (reg:DI 10 10 [917])
(nil
(jump_insn # 0 0 (set (pc)
[Bug rtl-optimization/21150] Suboptimal byte extraction from 64bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21150 --- Comment #7 from Denis Vlasenko --- Fixed at least in 4.7.2, maybe earlier. With -m32 -fomit-frame-pointer -O2: a: movzbl v+45, %eax xorbv+36, %al xorbv, %al xorbv+54, %al xorbv+63, %al xorbv+9, %al xorbv+18, %al xorbv+27, %al ret b: movzbl v+18, %eax xorbv+9, %al xorbv, %al xorbv+27, %al xorbv+36, %al xorbv+45, %al xorbv+54, %al xorbv+63, %al ret c: movzbl v+9, %eax xorbv, %al xorbv+18, %al xorbv+27, %al xorbv+36, %al xorbv+45, %al xorbv+54, %al xorbv+63, %al ret d: movzbl v+18, %eax xorbv+9, %al xorbv, %al xorbv+27, %al xorbv+36, %al xorbv+45, %al xorbv+54, %al xorbv+63, %al ret With same but -Os, my only complaint is that word-sized XORs are needlessly adding partial register update stalls: d: movbv+18, %al xorbv+9, %al xorlv, %eax xorbv+27, %al xorlv+36, %eax xorbv+45, %al xorbv+54, %al xorbv+63, %al ret but overall it looks much better. Feel free to close this BZ.
[Bug sanitizer/70683] [6 Regression] -fcompare-debug bug with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70683 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-15 Target Milestone|--- |6.0 Ever confirmed|0 |1
[Bug sanitizer/70683] New: [6 Regression] -fcompare-debug bug with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70683
Bug ID: 70683
Summary: [6 Regression] -fcompare-debug bug with
-fsanitize=address
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
On a testcase that has been provided privately to me and I can't share (and
that can't be easily reduced), I'm seeing differences in sanopt optimization,
without -gtoggle ASAN_CHECK is optimized away, while with -gtoggle it is.
maybe_optimize_asan_check_ifn works with a hash_map using tree_operand_hash.
What I'm seeing is that in both cases we first process ASAN_CHECK with ptr
&m_nullId.m_id
which is ADDR_EXPR of COMPONENT_REF of VAR_DECL, and then later on there is
ASAN_CHECK with ptr
&m_nullId.m_id
which is actually ADDR_EXPR of COMPONENT_REF of MEM_REF of ADDR_EXPR of
VAR_DECL.
The FIELD_DECL and VAR_DECL in both cases are the same.
Now, because of the VAR_DECL vs. MEM_REF[&VAR_DECL, 0] difference both hash
differently using iterative_hash_expr.
Unlike the hash, the comparison is done using operand_equal_p (, , 0), which
has:
2833 else if (flags & OEP_ADDRESS_OF)
2834{
2835 /* If we are interested in comparing addresses ignore
2836 MEM_REF wrappings of the base that can appear just for
2837 TBAA reasons. */
2838 if (TREE_CODE (arg0) == MEM_REF
2839 && DECL_P (arg1)
2840 && TREE_CODE (TREE_OPERAND (arg0, 0)) == ADDR_EXPR
2841 && TREE_OPERAND (TREE_OPERAND (arg0, 0), 0) == arg1
2842 && integer_zerop (TREE_OPERAND (arg0, 1)))
2843return 1;
2844 else if (TREE_CODE (arg1) == MEM_REF
2845 && DECL_P (arg0)
2846 && TREE_CODE (TREE_OPERAND (arg1, 0)) == ADDR_EXPR
2847 && TREE_OPERAND (TREE_OPERAND (arg1, 0), 0) == arg0
2848 && integer_zerop (TREE_OPERAND (arg1, 1)))
2849return 1;
2850 return 0;
2851}
and thus returns that the two are equal. While both of the decls in here
(VAR_DECL and FIELD_DECL) have the same DECL_UID for no -gtoggle vs. -gtoggle,
I presume the problem is that there are other tree expressions pushed into the
hash_map as keys that have some DECL_UID differences somewhere, in any case
both the hash maps have the same number of elements, but report different
number of collisions (note debug stmts never query anything, so that is not the
issue).
So, I believe the bug is that we have a hash function that can return different
hashes even for objects that compare equal by the comparison function, so it is
then by pure luck if we find a match or not.
IMHO the right solution would be to have next to operand_equal_p a hashing
function that guarantees that if operand_equal_p returns true on two tree
expressions, then they have the same hash.
As short term, perhaps (maybe just for sanopt, as that is where the problem is
reported), we could use a comparison function that compares both the hash
values and operand_equal_p, i.e. tree expressions that hash differently would
never compare equal. This can be done either by remembering also the hash
value, or just computing iterative_hash_expr each time.
[Bug ipa/70646] [4.9/5/6 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #21 from rguenther at suse dot de --- On April 15, 2016 3:31:33 PM GMT+02:00, "hubicka at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 > >--- Comment #16 from Jan Hubicka --- >> Honza? This seems to be somewhat fragile (redirecting things to >unreachable >> but _not_ changing the actual predicates in the IL). Claiming the >> predicate is constant true is also a bit bogus (as can be seen in >following >> optimization). > >At WPA stage inliner can not update IL, so it simply redirects to >builtin_unreachable if predicate is FALSE and expects scalar passes to >be >monotonously smarter than IPA analysis. > >BB3 predicate true is conservatively correct: there is no predicate to >represent that something is not constant because we assume scalar >optimizers to >possibly be stronger than us and decide better. > >Here we manage to assume that builtin_constant_p is true and thus we >conclude >the following BB is unreachable: >BB 4 predicate:(op0[ref offset: 0] not constant) > >iftmp.0_26 = __builtin_bswap64 (_3); > >freq:0.61 size: 1 time: 1 >This is because ipa-prop analyzes the values in node_name: > >Jump functions of caller broken/2: > >callsite broken/2 -> wwn_to_u64/1 : > >param 0: UNKNOWN > >Aggregate passed by reference: > offset: 0, cst: 255 > offset: 8, cst: 255 > offset: 16, cst: 255 > offset: 24, cst: 255 > offset: 32, cst: 255 > offset: 40, cst: 255 > offset: 48, cst: 255 > offset: 56, cst: 255 > >but later we fold: > >: > >node_name[0] = 255; > >node_name[1] = 255; > >node_name[2] = 255; > >node_name[3] = 255; > >node_name[4] = 255; > >node_name[5] = 255; > >node_name[6] = 255; > >node_name[7] = 255; > >_14 = MEM[(const u64 *)&node_name]; > >_15 = __builtin_constant_p (_14); > > >into false (which is stupid, but conservatively correct modulo the >assumption >about IPA passes being consistently weakter than local passes). > >Making IPA passes to fold builtin_constant_p call into true is >technically >possible, if I add builtin_true and redirect to it, but it would not be >very >good if the local passes can not fold above (as the wrong arm is >taken). > >So can we possibly fix the local passes?You can't rely on this happening, >consider -fno-foo. So my original local hack was to not do this built-in constant stuff for is_refp Richard. >Honza
[Bug c/70671] Wrong column number shown for "error: cannot take address of bit-field"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70671 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Fri Apr 15 14:46:06 2016 New Revision: 235032 URL: https://gcc.gnu.org/viewcvs?rev=235032&root=gcc&view=rev Log: PR c/70671 * c-typeck.c (build_unary_op): Pass location down to error and warning call. * gcc.dg/bitfld-22.c: New test. Added: trunk/gcc/testsuite/gcc.dg/bitfld-22.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/70671] Wrong column number shown for "error: cannot take address of bit-field"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70671 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Marek Polacek --- Fixed.
[Bug sanitizer/70683] [6 Regression] -fcompare-debug bug with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70683 --- Comment #1 from Jakub Jelinek --- I guess most or all hash tables using iterative_hash_expr as hashing function and operand_equal_p as comparison function are affected.
[Bug c++/70594] [6 Regression] -fcompare-debug failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 --- Comment #51 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 14:51:06 2016 New Revision: 235033 URL: https://gcc.gnu.org/viewcvs?rev=235033&root=gcc&view=rev Log: PR c++/70594 * constexpr.c (constexpr_call_table): Preserve in GC. (struct fundef_copy, struct fundef_copies_table_t): Delete. (fundef_copies_table): Preserve in GC. Change to pointer to tree->tree hash. (maybe_initialize_fundef_copies_table): Adjust. (get_fundef_copy): Return a TREE_LIST. Use non-inserting search. (save_fundef_copy): Adjust for a TREE_LIST. (cxx_eval_call_expression): Adjust for a fundef_copy TREE_LIST. (fini_constexpr): New. * cp-tree.h (fini_constexpr): Declare. * decl2.c (c_parse_final_cleanups): Call fini_constexpr. Modified: trunk/gcc/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c
[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662 --- Comment #5 from Kirill Yukhin --- Author: kyukhin Date: Fri Apr 15 15:13:42 2016 New Revision: 235037 URL: https://gcc.gnu.org/viewcvs?rev=235037&root=gcc&view=rev Log: AVX-512, Fix mode size check. PR target/70662 gcc/ * config/i386/sse.md(define_insn "_vec_dup"): Fix mode size check. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/i386/sse.md
[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662 --- Comment #6 from Kirill Yukhin --- Author: kyukhin Date: Fri Apr 15 15:17:31 2016 New Revision: 235038 URL: https://gcc.gnu.org/viewcvs?rev=235038&root=gcc&view=rev Log: AVX-512. Fix mode size check. PR target/70662 gcc/ * config/i386/sse.md(define_insn "_vec_dup"): Fix mode size check. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md
[Bug target/70662] vpbroadcastq assemble failure with -masm=intel -mavx512vbmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70662 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Apr 15 15:53:01 2016 New Revision: 235040 URL: https://gcc.gnu.org/viewcvs?rev=235040&root=gcc&view=rev Log: PR target/70662 * config/i386/sse.md (define_insn "_vec_dup"): Fix mode size check. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/i386/sse.md
[Bug c++/64329] Crash when returning reference from lambda with deduced type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64329
Michael Stahl changed:
What|Removed |Added
CC||mstahl at redhat dot com
--- Comment #1 from Michael Stahl ---
i believe i've hit the same problem, here's the footgun reproducer i came up
with:
#include
#include
int foo = 42;
int const& bar()
{
return foo;
}
int main()
{
std::function f{ [] () { return bar(); } };
int const& rfoo = f();
printf("%p %p\n", (void*)&foo, (void*)&rfoo);
return &foo == &rfoo;
}
this is g++ (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
> g++ -std=c++11 -Wall -Wextra -pedantic -Weffc++ -W lambdaref.cc && ./a.out
0x60204c (nil)
the problem is that the deduced return type of the lambda is a value
type, never a reference type. this caught me by surprise, but it's
the same rule as for "auto".
if the C++ committee has to make surprising and error-prone type
inference rules, then at least implementations like g++ could
give a warning about returning a reference from a lambda that
is implicitly copied to a value, only to be implicitly converted
again into nothing.
Visual Studio 2013 gives a "warning C4172 returning address of local
variable or temporary" from somewhere inside its std::function code.
[Bug c++/64329] Crash when returning reference from lambda with deduced type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64329 --- Comment #3 from Jonathan Wakely --- Oops, the original report was for 4.9.1, but the bug is still present in 4.9.3
[Bug c++/64329] Crash when returning reference from lambda with deduced type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64329 --- Comment #2 from Jonathan Wakely --- (In reply to Michael Stahl from comment #1) > i believe i've hit the same problem I don't think so. The original bug report is for 4.9.3, and seems to be an actual compiler bug that is fixed already in GCC 5 and later. Your case is invalid code. While I agree a warning would be nice, it's not the same as a bug in 4.9.3 that has been fixed.
[Bug target/70682] [6/7 Regression] -fcompare-debug building LLVM with checking=release compiler on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70682 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Markus Trippelsdorf --- The issue was fixed by r235033. Closing.
[Bug c++/70505] [4.9/5/6/7 Regression] Constexpr failure when template type specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70505 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Apr 15 16:32:22 2016 New Revision: 235042 URL: https://gcc.gnu.org/viewcvs?rev=235042&root=gcc&view=rev Log: PR c++/70505 * pt.c (tsubst_baselink): Give the new TEMPLATE_ID_EXPR unknown_type_node, too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-template10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug libfortran/70684] New: incorrect reading of values from file on Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684 Bug ID: 70684 Summary: incorrect reading of values from file on Windows Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: ajmay81 at googlemail dot com Target Milestone: --- When writing and then reading back values from a file on Windows (program built with gfortran via mxe cross compiler) the wrong values are read. Here is a trivial example: program test implicit none integer,parameter :: isize=12 integer,parameter :: funit=12 integer :: i double precision, dimension(isize) :: a do i=1,isize a(i)=dble(i) enddo write(6,*)'Value to write' do i=1,isize write(6,*)a(i) enddo open(funit,file='test.txt') write(funit,'(1x,6(f25.20,'',''))') (a(i),i=1,isize) close(funit) do i=1,isize a(i)=0d0 enddo open(funit,file='test.txt') read(funit,*) (a(i),i=1,isize) close(funit) write(6,*)'Values after read' do i=1,isize write(6,*)a(i) enddo end And compiled with: x86_64-w64-mingw32.static-gfortran test.f90 On Linux the values 1-12 are read, but on Windows the values 1-6,0,7-11 are read. It seems that the file is written with Windows line endings on Windows, but when read Linux line endings are expected. I think it should be consistent, at least one should be able to read files back on the same system they are generated. I grepped through a recent 5.3.0 tarball, and it's a bit of a guess but in libgfortran/io/transfer.c the function next_record_r() knows only about '\n' line endings, yet it's opposite number next_record_w() knows about both '\n' and '\r' - so perhaps the same logic just needs copying to the read function?
[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 --- Comment #10 from Jason Merrill --- Author: jason Date: Fri Apr 15 17:03:33 2016 New Revision: 235043 URL: https://gcc.gnu.org/viewcvs?rev=235043&root=gcc&view=rev Log: PR c++/67164 * pt.c (copy_template_args): New. (tsubst_pack_expansion): Use it. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic-tuple2.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/pt.c
[Bug c/70668] nds32-elf toolchain fails to compile on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 --- Comment #4 from Stefan Reinauer --- Thanks to Segher Boessenkool, https://review.coreboot.org/#/c/14380/2 fixes the issue.
[Bug c/70668] nds32-elf toolchain fails to compile on OSX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668 --- Comment #5 from Stefan Reinauer --- Created attachment 38283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38283&action=edit Fix for the issue
[Bug libstdc++/65434] Memory leak in pool constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65434
Patrick J. LoPresti changed:
What|Removed |Added
CC||lopresti at gmail dot com
--- Comment #5 from Patrick J. LoPresti ---
Seems pretty sloppy not to free what you allocate, and then demand all leak
checking tools forever work around the sloppiness... Even if you are the
runtime.
Couldn't you fix this by using the init_priority attribute on emergency_pool?
Alternatively, do like any application would and use a Meyers singleton instead
of a global variable? Like so:
namespace {
pool &emergency_pool()
{
static pool emp;
return emp;
}
}
Since destructors always run in the opposite order of construction, you would
just need to make sure you obtain the first reference early enough.
[Bug c++/70685] New: [6/7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70685 Bug ID: 70685 Summary: [6/7 Regression] ICE: Segmentation fault 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 CC: jason at gcc dot gnu.org Target Milestone: --- Created attachment 38284 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38284&action=edit unreduced testcase A very recent regression. Was fine a yesterday. markus@x4 /tmp % clang++ -std=c++14 -c sum.ii markus@x4 /tmp % g++ -c sum.ii In file included from ../libs/hana/test/range/sum.cpp:9:0: ../boost/hana/range.hpp: In instantiation of ‘static constexpr auto boost::hana::sum_impl::apply(const boost::hana::range&) [with = boost::hana::integral_constant_tag; T = int; T from = -3; T to = -1]’: ../boost/hana/sum.hpp:45:42: required from ‘constexpr decltype(auto) boost::hana::sum_t::operator()(Xs&&) const [with Xs = boost::hana::range; M = boost::hana::integral_constant_tag]’ ../libs/hana/test/range/sum.cpp:23:102: required from here ../boost/hana/range.hpp:187:61: in constexpr expansion of ‘boost::hana::sum_impl::sum_helper(-3, (-1 - 1))’ ../boost/hana/range.hpp:182:35: in constexpr expansion of ‘boost::hana::sum_impl::sum_helper((- n), (- m))’ ../boost/hana/range.hpp:187:20: internal compiler error: Segmentation fault
[Bug c/70686] New: -fprofile-generate (not fprofile-use) somehow produces much faster binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70686
Bug ID: 70686
Summary: -fprofile-generate (not fprofile-use) somehow produces
much faster binary
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: alekshs at hotmail dot com
Target Milestone: ---
I have this small benchmark that does 100mn loops of 20 divisions by 2.
Periodically it bumps up the values so that it continues to have something to
divide /2. I time this and see the results.
---
#include
#include
#include
int main()
{
printf("\n");
const double a = 333.3456743289; //initial randomly assigned values to
start halving
const double aa = 555.444334244;
const double aaa = 777.;
const double = 3276.123458;
unsigned int i;
double score;
double g; //the number to be used for making the divisions, so essentially
halving everything each round
double b;
double bb;
double bbb;
double ;
g = 2;
b = a;
bb = aa;
bbb = aaa;
= ;
double total_time;
clock_t start, end;
start = 0;
end = 0;
score = 0;
start = clock();
for (i = 1; i <10001; i++)
{
b=b/g;
b=b/g;
b=b/g;
b=b/g;
b=b/g;
bb=bb/g;
bb=bb/g;
bb=bb/g;
bb=bb/g;
bb=bb/g;
bbb=bbb/g;
bbb=bbb/g;
bbb=bbb/g;
bbb=bbb/g;
bbb=bbb/g;
=/g;
=/g;
=/g;
=/g;
=/g;
if (b< 1.001) {b=b+i+12.432432432;} //just adding more stuff in
order for the number
if (bb < 1.001) {bb=bb+i+15.4324442;} //to return back to larger
values after several
if (bbb < 1.001) {bbb=bbb+i+19.42884;} //rounds of halving
if ( < 1.001) {=+i+34.481;}
}
end = clock();
total_time = ((double) (end - start)) / CLOCKS_PER_SEC * 1000;
score = (1000 / total_time);
printf("\nFinal number: %0.20f", (b+bb+bbb+));
printf("\nTime elapsed: %0.0f msecs", total_time);
printf("\nScore: %0.0f\n", score);
return 0;
}
---
This is run on a quad q8200 @ 1.75ghz
Now notice the times:
gcc Maths4asm.c -lm -O0 => 6224ms
gcc Maths4asm.c -lm -O2 and -O3 => 1527ms
gcc Maths4asm.c -lm -Ofast => 1227ms
gcc Maths4asm.c -lm -Ofast -march=nocona => 1236ms
gcc Maths4asm.c -lm -Ofast -march=core2 => 1197ms (I have a core quad,
technically it's core2 arch)
gcc Maths4asm.c -lm -Ofast -march=core2 -fprofile-generate => 624ms.
gcc Maths4asm.c -lm -Ofast -march=nocona -fprofile-generate => 530ms.
gcc Maths4asm.c -lm -Ofast -march=nocona -fprofile-use => 1258ms (slower than
without PGO, slower than -fprofile-generate)
gcc Maths4asm.c -lm -Ofast -march=core2 -fprofile-use => 1222ms (slower than
without PGO, slower than -fprofile-generate).
So PGO optimization made it worse, but the most mindblowing thing is the
running of the profiler, getting execution times down to 530ms. The profiler
run (-generate) should normally take this to 4000-5000ms or above, as it
monitors the process to create a log file.
I have never run into a -fprofile-generate build that wasn't at least 2-3 times
slower than a normal build - let alone 2-3 times faster. This is totally
absurd.
And then, to top it all, -fprofile-use (using the logfile to create the best
binary) created worse binaries.
Oh, and "nocona" (pentium4+) suddenly became ...the better architecture instead
of core2.
This stuff is almost unbelievable. I thought initially that the profiler must
be activating multithreading, but no. I scripted simultaneous use of 4 runs,
they all give the same time - that means, there was no extra cpu use in other
threads.
The implication of all these is that if -fprofile-generate can somehow give
code that is executing at 500ms, and the non -fprofile-generate binaries are
running at 1200ms, then serious performance is left on the table on normal
builds.
[Bug c++/70685] [6/7 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70685
--- Comment #1 from Markus Trippelsdorf ---
markus@x4 tmp % cat sum.ii
namespace std {
template struct A { static constexpr _Tp value = __v;
};
typedef A false_type;
template using conditional_t = _Iftrue;
namespace hana {
template struct is_default : false_type {};
template struct tag_of;
struct deleted_implementation;
namespace detail {
namespace operators {
template struct adl {};
}
}
template struct B;
template struct G : std::A {};
template G integral_c;
template using int_ = G;
template int_ int_c;
template struct C;
template struct D {
template auto operator()(X... x) {
return C::apply(x...);
}
};
template D make;
template struct unpack_impl;
struct Foldable {
using Tag = int;
static constexpr int value = is_default>::value;
};
struct range_tag;
auto make_range = make;
template struct sum_impl;
template struct F;
template > F sum;
template
struct range : detail::operators::adl> {};
template struct tag_of> {
using type = range_tag;
};
template <> struct C {
template static auto apply(From, To) {
using T = int;
constexpr T from(From::value);
constexpr T to(To::value);
return range{};
}
};
template <> struct sum_impl {
template static constexpr I sum_helper(I m, I n) {
if (m == n)
return 0;
return sum_helper(0, 0);
}
template static auto apply(range) {
integral_c;
}
};
template struct F {
template auto operator()(Xs xs) {
using S = typename tag_of::type;
using Sum =
conditional_t, deleted_implementation>;
Sum::apply(xs);
}
};
}
auto __hana_tmp_22 =
(hana::sum<>(hana::make_range(hana::int_c<-3>, hana::int_c<-2>)),
hana::sum<>(hana::make_range(hana::int_c<3>, hana::int_c<7>)),
hana::int_c<6>);
}
[Bug c/20562] no unused warning for static const arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20562 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||6.0 Resolution|--- |DUPLICATE Known to fail||4.0.0, 4.5.3, 4.8.3, 4.9.3, ||5.3.0 --- Comment #9 from Martin Sebor --- This has been resolved in 6.0 via the -Wunused-const-variable option (see bug 28901). *** This bug has been marked as a duplicate of bug 28901 ***
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 Martin Sebor changed: What|Removed |Added CC||mueller at kde dot org --- Comment #38 from Martin Sebor --- *** Bug 20562 has been marked as a duplicate of this bug. ***
[Bug c/69960] "initializer element is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-04-15 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #11 from Martin Sebor --- Seems like there is agreement that this would be a useful enhancement so I'll mark this enhancement request as accepted by changing its Status to New (and its Severity to Enhancement).
[Bug c/54823] string literal characters not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54823 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Last reconfirmed||2016-4-15 CC||msebor at gcc dot gnu.org Resolution|--- |DUPLICATE Summary|string literal characters |string literal characters |not constant|not a constant expression Severity|normal |enhancement --- Comment #6 from Martin Sebor --- I think this request is a duplicate of bug 69960 (or rather the other way around). Since, based on the feedback of other GCC developers, I've just confirmed the request in the other bug I'll close this one as a duplicate of the other. *** This bug has been marked as a duplicate of bug 69960 ***
[Bug c/69960] "initializer element is not constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960 Martin Sebor changed: What|Removed |Added CC||devel at fresse dot org --- Comment #12 from Martin Sebor --- *** Bug 54823 has been marked as a duplicate of this bug. ***
[Bug ipa/70646] [4.9/5/6/7 Regression] Corrupt truncated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70646 --- Comment #22 from Martin Jambor --- (In reply to Jan Hubicka from comment #18) > Jakub: There is indeed aliasing issue, but with -fno-strict-aliasing the bug > is the same. > > Apparently this is ipa-prop bug, because ipa-prop does not track size of > accesses and thus it does not know there is a mismatch. The value produced > is thus not INT_MAX as intended but 255. This is Martin's area. ipa-prop does not track accesses or their sizes, inlining predicate conditions do. Anyway, I checked the two places where access sizes need to be checked (i.e. ipcp_modif_dom_walker::before_dom_children in ipa-prop.c and evaluate_conditions_for_known_args in ipa-inline-analysis.c) and they actually are checked, with one exception causing this bug. The exception is evaluating IS_NOT_CONSTANT and CHANGED types of conditions in evaluate_conditions_for_known_args, which does not check access size for them because the size is not even tracked for them (for normal conditions, size is the size of the stored value to compare with). I suppose the easiest fix is to overload the value field to store the size of the access for these two codes and then add the missing check.
[Bug c/59976] Spurious warning on converting const int variable to unsigned long (Also inconsistency between O0 and O1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59976
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-04-15
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.9.3, 5.3.0, 6.0
--- Comment #2 from Martin Sebor ---
Confirmed. The warning is also inconsistent between C and C++ modes, likely
because G++ treats the constant b as a constant expression regardless of
optimization while GCC treats it as an ordinary variable with an unknown value
(i.e., it doesn't fold its value without optimization).
This would be solved by making GCC more aggressive about constant folding and
treating more expressions as constant expressions, as requested for example in
bug 69960. It might be worth to collect the kinds of expressions that could be
considered constant so that they can all be considered at the same time if/when
someone decides to put together a patch for one (or more) of these bugs.
$ cat v.c && gcc -S -Wconversion -xc v.c
unsigned g;
void fn1() {
int a;
const unsigned char b = 0;
a = b & g;
}
v.c: In function ‘fn1’:
v.c:5:7: warning: conversion to ‘int’ from ‘unsigned int’ may change the sign
of the result [-Wsign-conversion]
a = b & g;
^
