[Bug tree-optimization/71006] [6/7 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71006 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-09 CC||ienkovich at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |6.2 Summary|[7 Regression] ICE: |[6/7 Regression] ICE: |verify_gimple failed|verify_gimple failed |(error: type mismatch in|(error: type mismatch in |conditional expression) w/ |conditional expression) w/ |-O1 -ftree-loop-vectorize |-O1 -ftree-loop-vectorize Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r230098.
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937 --- Comment #15 from Richard Biener --- Author: rguenth Date: Mon May 9 07:42:45 2016 New Revision: 236021 URL: https://gcc.gnu.org/viewcvs?rev=236021&root=gcc&view=rev Log: 2016-05-09 Richard Biener PR fortran/70937 * trans-decl.c: Include gimplify.h for unshare_expr. (gfc_trans_vla_one_sizepos): Unshare exprs before inserting them into the IL. * gfortran.dg/pr70937.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr70937.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/70937] [7 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70937 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Richard Biener --- Fixed.
[Bug c/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71013 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0 --- Comment #1 from Richard Biener --- How do you get LLONG_MAX on hpux? There is HAVE_LONG_LONG[_INT] in auto-host.h, maybe that needs to be used here.
[Bug c/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71013 Richard Biener changed: What|Removed |Added Keywords||build Priority|P3 |P1
[Bug tree-optimization/71006] [6/7 Regression] ICE: verify_gimple failed (error: type mismatch in conditional expression) w/ -O1 -ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71006 Richard Biener changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code Priority|P3 |P2
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-09 CC||rguenth at gcc dot gnu.org Known to work||5.3.0 Target Milestone|--- |6.2 Summary|[6 Regression] |[6/7 Regression] |-fstrict-aliasing breaks|-fstrict-aliasing breaks |Boost's short string|Boost's short string |optimization implementation |optimization implementation Ever confirmed|0 |1 Known to fail||6.1.0 --- Comment #1 from Richard Biener --- Confirmed the testcase fails with -O2 for GCC 6 and trunk but not GCC 5.
[Bug tree-optimization/70986] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in combine_blocks, at tree-if-conv.c:2219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70986
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||6.1.0
Keywords||ice-on-valid-code
Last reconfirmed||2016-05-09
CC||ktkachov at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE on valid code at -O3 on |[7 Regression] ICE on valid
|x86_64-linux-gnu in |code at -O3 on
|combine_blocks, at |x86_64-linux-gnu in
|tree-if-conv.c:2219 |combine_blocks, at
||tree-if-conv.c:2219
Target Milestone|--- |7.0
Known to fail||7.0
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed on aarch64 also.
I have another testcase that ICEs like this.
int a, b;
int
fn1 (int p1)
{
return p1 < 0 ? p1 : a;
}
void
fn2 ()
{
lbl_100:
b = 1;
for (; b != 21; b = fn1 (b))
;
goto lbl_100;
}
caused by the same commit as PR 70964, but I don't know if the bugs are
distinct
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #2 from Richard Biener ---
The issue is similar to that in PR70054 in that for example string::swap_data
copy-initializes repr_t which has the long_raw_t member that is not of the
type that it is modified as (for some odd reason).
(just from looking at the source now, not analyzing what GCC does to it)
Why doesn't boost just use
union repr_t
{
long_t l;
short_t s;
...
?
[Bug tree-optimization/71016] New: [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016
Bug ID: 71016
Summary: [6/7 Regression] Redundant sign extension with
conditional __builtin_clzl
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Consider:
long int foo (long i)
{
return (i == 0) ? 17 : __builtin_clzl (i);
}
On aarch64 with GCC 5 at -O2 we generate:
foo:
mov x2, 17
clz x1, x0
cmp x0, xzr
cselx0, x1, x2, ne
ret
whereas with GCC 6 and trunk we generate:
foo:
mov w1, 17
clz x2, x0
cmp x0, 0
cselw0, w1, w2, eq
sxtwx0, w0 //redundant sign-extend
ret
In GCC 5 the tree structure being expanded is:
i.1_3 = (long unsigned int) i_2(D);
_4 = __builtin_clzl (i.1_3);
iftmp.0_5 = (long int) _4;
;; basic block 4, loop depth 0
;;pred: 3
;;2
# iftmp.0_1 = PHI
return iftmp.0_1;
so the RTL optimisers see the DI mode clz followed by a subreg and
a sign-extend and optimise it away.
However trunk now moves the sign-extend out of the conditional:
i.1_3 = (long unsigned int) i_2(D);
_4 = __builtin_clzl (i.1_3);
;; basic block 4, loop depth 0
;;pred: 3
;;2
# _7 = PHI <_4(3), 17(2)>
prephitmp_8 = (long int) _7;
return prephitmp_8;
So it's very hard for RTL ifcvt or combine or ree to catch it.
[Bug fortran/66328] Wrong initialization of derived-type DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66328 --- Comment #3 from Dominique d'Humieres --- The bug reappears on trunk if I revert r230580.
[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70985 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug tree-optimization/70986] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in combine_blocks, at tree-if-conv.c:2219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70986 --- Comment #3 from Richard Biener --- Same cause as the other PR. 2016-05-03 Jakub Jelinek Richard Biener PR tree-optimization/70916 * tree-if-conv.c: Include cfganal.h. (pass_if_conversion::execute): Call connect_infinite_loops_to_exit and remove_fake_exit_edges around the optimization pass.
[Bug target/71017] New: libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71017 Bug ID: 71017 Summary: libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr Target Milestone: --- When compiling some tests, e.g. gcc.c-torture/compile/2511-1.c -O, using gcc built with -fsanitize=undefined, I get the following error at runtime libgcc/config/i386/cpuinfo.c:346:17: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' This is fixed with the following patch --- ../_clean/gcc/config/i386/cpuid.h 2016-01-04 19:51:13.0 +0100 +++ gcc/config/i386/cpuid.h 2016-05-01 12:49:40.0 +0200 @@ -90,7 +90,7 @@ #define bit_AVX512CD (1 << 28) #define bit_SHA(1 << 29) #define bit_AVX512BW (1 << 30) -#define bit_AVX512VL (1 << 31) +#define bit_AVX512VL (1u << 31) /* %ecx */ #define bit_PREFETCHWT1 (1 << 0)
[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 Richard Biener changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-09 Version|unknown |6.1.0 Ever confirmed|0 |1 Known to fail||4.3.5 --- Comment #1 from Richard Biener --- Confirmed back to GCC 4.3.
[Bug bootstrap/70997] [7 Regression] bootstrap broken on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70997 Richard Biener changed: What|Removed |Added Keywords||build Target Milestone|--- |7.0
[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71015 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug middle-end/70992] Infinite recursion between fold_build2_stat_loc and fold_binary_loc w/ -fwrapv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70992 --- Comment #2 from Richard Biener --- I think the issue is that the associate case treats (0 % 0 + 1) * 2 as constant but that gets further "simplified" when combined with the rest. In the end our refusal to simplify 0 % 0 to 0 causes things to go downhill (we _do_ simplify 0 % a to 0!) (for mod (ceil_mod floor_mod round_mod trunc_mod) /* 0 % X is always zero. */ (simplify (mod integer_zerop@0 @1) /* But not for 0 % 0 so that we can get the proper warnings and errors. */ (if (!integer_zerop (@1)) @0))
[Bug ipa/71015] [7 Regression] ICE in inline_small_functions, at ipa-inline.c:1881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71015 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-09 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70985 --- Comment #3 from Richard Biener --- This wasn't supposed to apply to non-registers even though technically it could. I'm going to disable that on GIMPLE instead [I'm still thinking on how to deal with "memory" stuff in match.pd]
[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70985
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org
--- Comment #4 from ktkachov at gcc dot gnu.org ---
I'm also seeing an ICE on the testcase:
struct {
char f0;
unsigned f2 : 16;
} e;
struct U2 {
char f3;
};
int **a;
int b, c, h, i, j;
int *d, *g, *k;
volatile struct U2 f;
void fn1() {
for (; b;) {
f;
**a = *g = *d = *k != i == h;
if (j)
c = e.f2;
else
for (;;)
;
}
}
at -O3. Given that it contains bitfields too I'm guessing it's the same cause.
mycrash.c:15:6: error: invalid operand in unary operation
void fn1() {
^~~
# VUSE <.MEM_18(D)>
e_f2_lsm0.12_27 = (short unsigned int) MEM[(struct *)&e + 1B];
mycrash.c:15:6: error: invalid operands in binary operation
mycrash.c:15:6: error: incorrect sharing of tree nodes
MEM[(struct *)&e + 1B]
# VUSE <.MEM_22>
_14 = MEM[(struct *)&e + 1B] & 65535;
mycrash.c:15:6: internal compiler error: verify_gimple failed
0xb23a53 verify_gimple_in_cfg(function*, bool)
$SRC/gcc/tree-cfg.c:5166
0xa14349 execute_function_todo
$SRC/gcc/passes.c:1968
0xa14554 do_per_function
$SRC/gcc/passes.c:1652
0xa1469c execute_todo
$SRC/gcc/passes.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug rtl-optimization/66940] ifcvt.c:1907 signed integer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66940 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2016-05-08 00:00:00 |2016-5-9 CC||ktkachov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed also on current trunk by adding: gcc_assert (desired_val != HOST_WIDE_INT_MAX); before the: if (actual_val == desired_val + 1) check
[Bug c++/70984] Templated derived class erroneously allows taking address of private base class member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70984 --- Comment #1 from Jonathan Wakely --- Please check the known bugs linked to from PR 59002 as I'm pretty sure this is a duplicate of one of them.
[Bug c++/26904] A template named the same as its member confuses lookup through inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904 --- Comment #5 from Jonathan Wakely --- For the record, it seems to have first been fixed for GCC 4.5
[Bug c++/70996] regression - infinite compilation of sequence overrided operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70996 Jonathan Wakely changed: What|Removed |Added Severity|critical|normal
[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-09 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug libstdc++/71005] recursive_directory_iterator::operator++(int) incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71005 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-09 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/69523] -Wliteral-suffix should not warn within namespace std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523 --- Comment #6 from Jonathan Wakely --- We already support that flag, but the warning that you get on the declaration of operator""s is not controlled by that flag. The warning should be controlled by *some* flag, but I'm not sure whether or not linking it with -Wliteral-suffix makes sense. I'll prepare a patch and see what people think.
[Bug c++/71010] error: 'begin' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71010
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
No, it's not a bug. Range-based 'for' is not supposed to find std::begin and
std::end unless std is an associated namespace.
Furthermore, your code has undefined behaviour, it is forbidden to add your own
functions to namespace std. The correct way to do it is to write the begin/end
overloads in the same namespace as your type (in this case that's the global
namespace).
class X
{
int m_x[5] = { 0, 1, 2, 3, 4 };
public:
int* first() { return &m_x[0]; }
int* last() { return &m_x[4]; }
};
int* begin(X& x) { return x.first(); }
int* end(X& x) { return x.last(); }
This works with all versions of GCC that support C++11.
[Bug inline-asm/43319] Lack of documentation on asm extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43319 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Richard Biener --- dup. *** This bug has been marked as a duplicate of bug 30527 ***
[Bug inline-asm/39440] User Manual: describe asm ("%a0,%c0"::)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39440 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 30527 ***
[Bug inline-asm/30527] Use of input/output operands in __asm__ templates not fully documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527 Richard Biener changed: What|Removed |Added CC||pi3orama at gmail dot com --- Comment #7 from Richard Biener --- *** Bug 43319 has been marked as a duplicate of this bug. ***
[Bug inline-asm/30527] Use of input/output operands in __asm__ templates not fully documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30527 Richard Biener changed: What|Removed |Added CC||etienne_lorrain at yahoo dot fr --- Comment #6 from Richard Biener --- *** Bug 39440 has been marked as a duplicate of this bug. ***
[Bug libstdc++/71005] recursive_directory_iterator::operator++(int) incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71005 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |5.4 --- Comment #1 from Jonathan Wakely --- It looks like directory_iterator will have the same problem, as both just copy the object, which shares ownership of the underlying representation instead of making a new state. Oops.
[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Mon May 9 10:09:37 2016 New Revision: 236023 URL: https://gcc.gnu.org/viewcvs?rev=236023&root=gcc&view=rev Log: libstdc++/71004 fix recursive_directory_iterator default constructor PR libstdc++/71004 * include/experimental/bits/fs_dir.h (recursive_directory_iterator): Initialize scalar member variables in default constructor. * testsuite/experimental/filesystem/iterators/ recursive_directory_iterator.cc: Teste default construction. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/experimental/bits/fs_dir.h trunk/libstdc++-v3/testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc
[Bug bootstrap/70997] [7 Regression] bootstrap broken on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70997 --- Comment #1 from Matthias Klose --- only seen when configured with --enable-default-pie
[Bug lto/71018] New: lto + ipa-pta causes exception with trivial boost::ptime code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71018 Bug ID: 71018 Summary: lto + ipa-pta causes exception with trivial boost::ptime code. Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: riad93 at mail dot ru Target Milestone: --- Created attachment 38447 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38447&action=edit My code
[Bug target/71019] New: AVX512BW instructions emitted even without AVX512BW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71019
Bug ID: 71019
Summary: AVX512BW instructions emitted even without AVX512BW
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
With -mavx512vl -mno-avx512bw GCC emits vpack{ss,us}{wb,dw} EVEX encoded
instructions even when they are only in the AVX512BW ISA.
[Bug lto/71018] lto + ipa-pta causes exception with trivial boost::ptime code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71018
--- Comment #1 from riad93 at mail dot ru ---
Accidentaly sent before adding info
-v:
Using built-in specs.
COLLECT_GCC=/opt/gcc-6/bin/c++-6.1
COLLECT_LTO_WRAPPER=/opt/gcc-6/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-languages=c,c++ --enable-shared
--enable-threads=posix --program-suffix=-6.1 --with-system-zlib
--prefix=/opt/gcc-6/ --disable-multilib --disable-bootstrap
Thread model: posix
gcc version 6.1.0 (GCC)
Command line:
/opt/gcc-6/bin/c++-6.1 -O2 -fipa-pta -flto=24 flto_test.cpp -o flto_test
-Wl,-rpath,/opt/gcc-6/lib64 -Wall -Wextra -fno-strict-aliasing -fwrapv
-fsanitize=undefined && ./flto_test
Output:
flto_test.cpp: In function ‘time_type {anonymous}::utc_to_local(const
time_type&)’:
flto_test.cpp:18:22: warning: variable ‘dd’ set but not used
[-Wunused-but-set-variable]
date_duration_type dd = t.date() - time_t_start_day;
^~
terminate called after throwing an instance of
'boost::exception_detail::clone_impl
>'
what(): Year is out of valid range: 1400..1
[1]10332 abort ./flto_test
[Bug target/71019] AVX512BW instructions emitted even without AVX512BW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71019 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-05-09 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Created attachment 38448 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38448&action=edit gcc7-pr71019.patch Untested fix.
[Bug lto/71018] lto + ipa-pta causes exception with trivial boost::ptime code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71018 --- Comment #2 from riad93 at mail dot ru --- Created attachment 38449 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38449&action=edit preprocessed code It's in tar.gz since it's too big for upload here as plaintext
[Bug lto/71018] lto + ipa-pta causes exception with trivial boost::ptime code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71018 riad93 at mail dot ru changed: What|Removed |Added Attachment #38449|0 |1 is obsolete|| --- Comment #3 from riad93 at mail dot ru --- Created attachment 38450 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38450&action=edit preprocessed code Fixed preprocessed code
[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-05-09
Target Milestone|--- |6.2
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
So PRE still does the desired tranform:
:
if (i_4(D) != 0)
goto ;
else
goto ;
:
i.1_1 = (long unsigned int) i_4(D);
_2 = __builtin_clzl (i.1_1);
_5 = (long int) _2;
:
# _7 = PHI <_2(3), 17(2)>
# prephitmp_8 = PHI <_5(3), 17(2)>
return prephitmp_8;
but then later phiopt comes along and un-does it:
--- t.c.172t.forwprop4 2016-05-09 13:15:20.830707963 +0200
+++ t.c.173t.phiopt32016-05-09 13:15:20.830707963 +0200
@@ -6,7 +6,7 @@
{
long unsigned int i.1_1;
int _2;
- long int _5;
+ int _7;
long int prephitmp_8;
:
@@ -18,10 +18,10 @@
:
i.1_1 = (long unsigned int) i_4(D);
_2 = __builtin_clzl (i.1_1);
- _5 = (long int) _2;
:
- # prephitmp_8 = PHI <_5(3), 17(2)>
+ # _7 = PHI <_2(3), 17(2)>
+ prephitmp_8 = (long int) _7;
return prephitmp_8;
}
I think this was intended to be an enablement transform of some sort -
obviously
here it mis-fires.
[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/71016] [6/7 Regression] Redundant sign extension with conditional __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71016 Richard Biener changed: What|Removed |Added CC||kuganv at linaro dot org --- Comment #2 from Richard Biener --- PHI prephitmp_8 changed to factor conversion out from COND_EXPR. New stmt with CAST that defines prephitmp_8. Added with 2015-07-12 Kugan Vivekanandarajah PR middle-end/66726 * tree-ssa-phiopt.c(factor_out_conditional_conversion): New function. tree_ssa_phiopt_worker): Call it.
[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |5.4 --- Comment #3 from Jonathan Wakely --- Only fixed on trunk so far.
[Bug lto/71018] lto + ipa-pta causes exception with trivial boost::ptime code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71018 --- Comment #4 from Richard Biener --- Possibly related to PR70760 or PR70785. Can't reproduce with GCC 6 branch head (so I'd say 70785), building GCC 6.1.0 right now.
[Bug tree-optimization/71020] New: SSA corruption: Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71020
Bug ID: 71020
Summary: SSA corruption: Unable to coalesce ssa_names 2 and 13
which are marked as MUST COALESCE.
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pdewacht at gmail dot com
Target Milestone: ---
This function triggers an internal compiler error. Reduced using C-Reduce from
a source file from FMSLogo.
$ cat ssa2.c
binary() {
double b = get();
_setjmp();
b = sqrt(b);
err_logo();
}
$ gcc-6 -O -w -c ssa2.c
Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.
b_2(ab) and b_13(ab)
ssa2.c: In function ‘binary’:
ssa2.c:1:1: internal compiler error: SSA corruption
binary() {
^~
0xa90f9c fail_abnormal_edge_coalesce
../../src/gcc/tree-ssa-coalesce.c:1010
0xa90f9c coalesce_partitions
../../src/gcc/tree-ssa-coalesce.c:1411
0xa90f9c coalesce_ssa_name()
../../src/gcc/tree-ssa-coalesce.c:1895
0xa4798f remove_ssa_form
../../src/gcc/tree-outof-ssa.c:978
0xa4798f rewrite_out_of_ssa(ssaexpand*)
../../src/gcc/tree-outof-ssa.c:1202
0x69b2e0 execute
../../src/gcc/cfgexpand.c:6136
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
$ gcc-6 -v
Using built-in specs.
COLLECT_GCC=gcc-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.1.1-1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.1.1 20160430 (Debian 6.1.1-1)
[Bug c/71013] [7 Regression] c-common.c:12810:37: error: 'LLONG_MAX' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71013 --- Comment #2 from dave.anglin at bell dot net --- On 2016-05-09, at 4:26 AM, rguenth at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71013 > > Richard Biener changed: > > What|Removed |Added > > Target Milestone|--- |7.0 > > --- Comment #1 from Richard Biener --- > How do you get LLONG_MAX on hpux? There is HAVE_LONG_LONG[_INT] in > auto-host.h, > maybe that needs to be used here. LLONG_MAX is not defined in hpux11.11. It comes from fixed limits.h: ./lib/gcc/hppa64-hp-hpux11.11/5.3.1/include-fixed/limits.h:# undef LLONG_MIN ./lib/gcc/hppa64-hp-hpux11.11/5.3.1/include-fixed/limits.h:# define LLONG_MIN (-LLONG_MAX - 1LL) -- John David Anglin dave.ang...@bell.net
[Bug tree-optimization/71020] [6/7 Regression] SSA corruption: Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71020 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-09 Known to work||5.3.0 Target Milestone|--- |6.2 Summary|SSA corruption: Unable to |[6/7 Regression] SSA |coalesce ssa_names 2 and 13 |corruption: Unable to |which are marked as MUST|coalesce ssa_names 2 and 13 |COALESCE. |which are marked as MUST ||COALESCE. Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004 --- Comment #4 from Jonathan Wakely --- (In reply to Eric Fiselier from comment #1) > recursive_directory_iterator it; > assert(it.recursion_pending() == false); > assert(it.recursion_pending() == true); N.B. This test is undefined, those observer functions have preconditions that they are not called on the end iterator.
[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Mon May 9 11:50:01 2016 New Revision: 236028 URL: https://gcc.gnu.org/viewcvs?rev=236028&root=gcc&view=rev Log: libstdc++/71004 fix recent additions to testcase PR libstdc++/71004 * testsuite/experimental/filesystem/iterators/ recursive_directory_iterator.cc: Fix test02 to not call member functions on invalid iterator, and use VERIFY not assert. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc
[Bug tree-optimization/71020] [6/7 Regression] SSA corruption: Unable to coalesce ssa_names 2 and 13 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71020 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rsandifo at gcc dot gnu.org --- Comment #2 from Richard Biener --- b_13(ab) = SQRT (b_1(ab)); DCE_COND_LB.2_15 = b_1(ab); if (DCE_COND_LB.2_15 u>= 0.0) introduced by cdce. Likely triggered by Richards changes. We have : # b_1(ab) = PHI _setjmp (); b_13(ab) = sqrt (b_1(ab)); err_logo (); goto ; where one way to fix this is push b_1(ab) to a non-abnormal temporary before the call and re-use that. Or simply give up for example via checking for abnormal SSA call arguments in an appropriate place.
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002 --- Comment #3 from Tavian Barnes --- Because their long_t is not POD. I don't know why that is though. It could be POD if they removed the default/copy constructors and assignment operator. Actually they're probably worried about custom allocators where the pointer type is not POD. So it couldn't be POD in general, and thus can't appear in a union directly (in C++03).
[Bug target/68945] enable libcilkrts on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68945 Rainer Orth changed: What|Removed |Added Attachment #38221|0 |1 is obsolete|| Attachment #38413|0 |1 is obsolete|| --- Comment #10 from Rainer Orth --- Created attachment 38451 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38451&action=edit Revised patch Here's a version of the patch that is, I believe, ready for upstream submission. It's based on the upstream version as has just been merged into the gcc repo. Compared to the previous sparcv9 support, the assertions are gone to allow for an easier read. I've also replaced the times(3C) based implementation of __cilkrts_getticks by one reading %tick directly, which should work on all UltraSPARC CPUs, independent of O/S. I've replaced the _GNU_SOURCE guard around runtime/sysdep-unix.c (get_runtime_path) around the use dladdr by the result of a configure check. The previous version had been wrong (just defining _GNU_SOURCE) doesn't suddently materialize dladdr), and the function is present in Solaris libc. Perhaps Eric could have a look at the SPARC assembler code to double-check that I got it right: * In runtime/config/sparc/os-unix-sysdep.c (__cilkrts_getticks) I needed different 32- and 64-bit versions. I tested the result in standalone program which just printed the result. * One thing I wonder about is runtime/config/sparc/os-fence.h: when using __sync_synchronize, gcc emits membar #StoreLoad, while Stefan's patch had membar#LoadLoad | #LoadStore | #StoreStore | #StoreLoad. It seems that all but #StoreLoad are no-ops for TSO SPARC CPUs, but I'd better get this right. I also believe that only so little of Stefan's code is left (__cilkrts_short_pause mostly) to not require a separate assignement for upstream submission. If I'm mistaken, we'd better get that ball rolling. Rainer
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002 --- Comment #4 from rguenther at suse dot de --- On Mon, 9 May 2016, tavianator at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002 > > --- Comment #3 from Tavian Barnes --- > Because their long_t is not POD. I don't know why that is though. It could > be > POD if they removed the default/copy constructors and assignment operator. > > Actually they're probably worried about custom allocators where the pointer > type is not POD. So it couldn't be POD in general, and thus can't appear in a > union directly (in C++03). But if it is not POD then assuming it gets copied correctly when init-constructing a POD union where they placed such object is an interesting assumption...
[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70985 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon May 9 12:23:11 2016 New Revision: 236032 URL: https://gcc.gnu.org/viewcvs?rev=236032&root=gcc&view=rev Log: 2016-05-09 Richard Biener PR tree-optimization/70985 * match.pd (BIT_FIELD_REF -> (type)): Disable on GIMPLE when op0 isn't a gimple register. * gcc.dg/torture/pr70985.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr70985.c Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/70985] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70985 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug ipa/70785] LTO bootstrap with IPA PTA is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70785 Richard Biener changed: What|Removed |Added CC||riad93 at mail dot ru --- Comment #6 from Richard Biener --- *** Bug 71018 has been marked as a duplicate of this bug. ***
[Bug lto/71018] lto + ipa-pta causes exception with trivial boost::ptime code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71018 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Richard Biener --- The patch for PR70785 fixed this, thus fixed for GCC 6.2. *** This bug has been marked as a duplicate of bug 70785 ***
[Bug testsuite/70826] [7 regression] many test cases fail starting with r235442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826 --- Comment #10 from Alan Modra --- Author: amodra Date: Mon May 9 12:35:25 2016 New Revision: 236033 URL: https://gcc.gnu.org/viewcvs?rev=236033&root=gcc&view=rev Log: [RS6000] Fragile testcase breaks with -frename-registers PR testsuite/70826 * gcc.target/powerpc/savres.c: Compile with -fno-rename-registers. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/savres.c
[Bug testsuite/70826] [7 regression] many test cases fail starting with r235442
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70826 Alan Modra changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|amodra at gcc dot gnu.org, | |amodra at gmail dot com| Resolution|--- |FIXED --- Comment #11 from Alan Modra --- Fixed, until it breaks next time.
[Bug testsuite/71021] New: [libatomic testsuite] Test program compilation fail (missing -pthread flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021 Bug ID: 71021 Summary: [libatomic testsuite] Test program compilation fail (missing -pthread flag) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Created attachment 38452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38452&action=edit Add "-pthread" flag when compiling libatomic test programs Hi, I am currently building up the Amadeus toolchain and I have trouble running the testsuite with libatomic. All test fails because the compilation of the test program fails. This happens in the specific case of our own toolchain because we build and install glibc/binutils/gcc in a custom prefix "/opt/1A/toolchain/x86_64-2.6.32-v2-6/". It also fails since the default system glibc (found in /lib) is different from the Amadeus toolchain glibc against which we link both binutils and glibc. The toolchain glibc is glibc 2.23 while the system glibc is glibc This happens on Linux x86_64, using gcc 4.9.4. I haven't checked yet if it also happens with gcc 6 but I will check soon. When I run: make check-target-libatomic RUNTESTFLAGS="c.exp=atomic-compare-exchange-1.c -v -v" I can see: Executing on host: /workdir/build/final-system/gcc-build/gcc/xgcc -B/workdir/build/final-system/gcc-build/gcc/ /workdir/src/gcc-4.9.4/libatomic/testsuite/libatomic.c/atomic-compare-exchange-1.c -B/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/ -I/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic -I/workdir/src/gcc-4.9.4/libatomic/testsuite/.. -fmessage-length=0 -fno-inline-atomics -g -L/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/.libs -latomic -lm -o ./atomic-compare-exchange-1.exe(timeout = 300) pid is 23832 -23832 waitres is 23832 exp8 0 1 close result is 23832 exp8 0 1 output is /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `h_errno@GLIBC_PRIVATE' collect2: error: ld returned 1 exit status If I manually run the link phase with "-Wl,-v,-t" I have this: /workdir/build/final-system/gcc-build/gcc/collect-ld -plugin /workdir/build/final-system/gcc-build/gcc/liblto_plugin.so -plugin-opt=/workdir/build/final-system/gcc-build/gcc/lto-wrapper -plugin-opt=-fresolution=/tmp/ccSu6fuN.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib64/ld-linux-x86-64.so.2 -o ./atomic-compare-exchange-1.exe /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crt1.o /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crti.o /workdir/build/final-system/gcc-build/gcc/crtbegin.o -L/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/.libs -L/workdir/build/final-system/gcc-build/gcc -L/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic -L/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64 -L/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib /tmp/cccwFSDA.o -latomic -lm -v -t -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /workdir/build/final-system/gcc-build/gcc/crtend.o /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crtn.o GNU ld (GNU Binutils) 2.26.0.20160501 /opt/1A/toolchain/x86_64-2.6.32-v2-6/x86_64-1a-linux-gnu/bin/ld: mode elf_x86_64 /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crt1.o /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crti.o /workdir/build/final-system/gcc-build/gcc/crtbegin.o /tmp/cccwFSDA.o -latomic (/workdir/build/final-system/gcc-build/x86_64-1a-linux-gnu/./libatomic/.libs/libatomic.so) /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libm.so.6/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libmvec.so.1 /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libmvec.so.1 -lgcc_s (/workdir/build/final-system/gcc-build/gcc/libgcc_s.so) /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libc.so.6 (/opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/libc_nonshared.a)elf-init.oS /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/ld-linux-x86-64.so.2 /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/ld-linux-x86-64.so.2 -lgcc_s (/workdir/build/final-system/gcc-build/gcc/libgcc_s.so) /workdir/build/final-system/gcc-build/gcc/crtend.o /opt/1A/toolchain/x86_64-2.6.32-v2-6/lib/../lib64/crtn.o /lib/x86_64-linux-gnu/libpthread.so.0: undefined reference to `h_errno@GLIBC_PRIVATE' /opt/1A/toolchain/x86_64-2.6.32-v2-6/x86_64-1a-linux-gnu/bin/ld: link errors found, deleting executable `./atomic-compare-exchange-1.exe' collect2: error: ld returned 1 exit status So it clearly shows there is a conflict between the glibc in /opt/1A/toolchain/x86_64-2.6.32-v2-6/ and the one in /lib. The linker
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002 --- Comment #5 from Tavian Barnes --- > But if it is not POD then assuming it gets copied correctly when > init-constructing a POD union where they placed such object is > an interesting assumption... Hrm? They seem to always copy it manually with long_t's copy constructor: ::new(&m_repr.long_repr()) long_t(other.m_repr.long_repr());
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #8 from vries at gcc dot gnu.org --- Created attachment 38453 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38453&action=edit tentative patch
[Bug testsuite/71021] [libatomic testsuite] Test program compilation fail (missing -pthread flag)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71021 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #1 from nsz at gcc dot gnu.org --- i think target lib tests are broken in gcc (other than libstdc++ and libgfortran). if the build-sysroot paths were used then the right libc would be linked. but CC (with all the necessary flags) is not passed from make to the test system, instead dejagnu find_gcc is used and some heuristics to reconstruct the -B etc flags, and thus the build sysroot is missing. (e.g. getenv CC instead of find_gcc would be a correct fix in libatomic.exp.. +export CC in the makefile). others seem to have run into this too, but apparently it was not fixed: https://gcc.gnu.org/ml/gcc-patches/2013-05/msg01181.html (the libstdc++ solution is also less than elegant: it generates a shell script that knows the paths/flags and call that repeatedly from the dejagnu tcl code.. instead of just passing the envvars from make to runtest) all target libs with tests need this fix when --with-build-sysroot is used.
[Bug rtl-optimization/71022] New: GCC prefers register moves over move immediate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71022
Bug ID: 71022
Summary: GCC prefers register moves over move immediate
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
Target Milestone: ---
When assigning the same immediate value to different registers, GCC will always
CSE the immediate and emit a register move for subsequent uses. This creates
unnecessary register dependencies and increases latency. When the cost of an
immediate move is the same as a register move (which should be true for most
targets), it should prefer the former. A register move is better only when the
immediate requires multiple instructions or is larger with -Os.
It's not obvious where this is best done. The various cprop phases before IRA
do the right thing, but cse2 (which runs later) then undoes it. And
cprop_hardreg doesn't appear to be able to deal with immediates.
int f1(int x)
{
int y = 1, z = 1;
while (x--)
{
y += z;
z += x;
}
return y + z;
}
void g(float, float);
void f2(void) { g(1.0, 1.0); g(3.3, 3.3); }
On AArch64 I get:
f1:
sub w1, w0, #1
cbz w0, .L12
mov w0, 1
mov w2, w0 *** mov w2, 1
.p2align 2
.L11:
add w2, w2, w0
add w0, w0, w1
sub w1, w1, #1
cmn w1, #1
bne .L11
add w0, w2, w0
ret
.L12:
mov w0, 2
ret
f2:
fmovs1, 1.0e+0
str x30, [sp, -16]!
fmovs0, s1*** fmov s0, 1.0
bl g
adrpx0, .LC1
ldr x30, [sp], 16
ldr s1, [x0, #:lo12:.LC1]
fmovs0, s1*** ldr s0, [x0, #:lo12:.LC1]
b g
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
--- Comment #6 from rguenther at suse dot de ---
On Mon, 9 May 2016, tavianator at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
>
> --- Comment #5 from Tavian Barnes ---
> > But if it is not POD then assuming it gets copied correctly when
> > init-constructing a POD union where they placed such object is
> > an interesting assumption...
>
> Hrm? They seem to always copy it manually with long_t's copy constructor:
>
> ::new(&m_repr.long_repr()) long_t(other.m_repr.long_repr());
I stand corrected. At least they always read from short_t when
computing is_short() even if that is not the active union member.
Some missed optimizations:
foo::foo(string) (struct foo * const this, struct string & restrict str)
{
...
:
MEM[(struct short_t &)this_2(D)].h.is_short = 1;
MEM[(struct short_t &)this_2(D)].h.length = 0;
MEM[(struct short_t &)this_2(D)].data[0] = 0;
_19 = BIT_FIELD_REF ;
_20 = _19 & 1;
if (_20 != 0)
this is fold-const.c at work replacing the load from h.is_short
with the BIT_FIELD_REF.
But then we go to
short_t short_backup(m_repr.short_repr());
m_repr.short_repr().~short_t();
::new(&m_repr.long_repr()) long_t(other.m_repr.long_repr());
other.m_repr.long_repr().~long_t();
::new(&other.m_repr.short_repr()) short_t(short_backup);
:
short_backup = MEM[(const struct short_t &)this_2(D)];
MEM[(struct long_t *)this_2(D)] = MEM[(const struct long_t *)str_5(D)];
MEM[(struct short_t *)str_5(D)] = short_backup;
short_backup ={v} {CLOBBER};
goto ;
which looks good. But
:
# prephitmp_52 = PHI <_51(10), 0(5)>
goto ;
:
# iftmp.7_13 = PHI
*this_2(D).m_len = iftmp.7_13;
stores zero into the length field. Somehow PRE does this transform.
I'll investigate some more.
[Bug fortran/71023] New: Problem with associate and function returning derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71023 Bug ID: 71023 Summary: Problem with associate and function returning derived type Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- gfortran does not compile the following valid code: module m implicit none type :: t integer :: i end type t contains pure function make_a_t(i) result(at) integer, intent(in) :: i type(t) :: at at%i = i end function make_a_t subroutine s() associate( my_t => make_a_t(5) ) write(*,*) my_t%i end associate end subroutine s end module m $ gfortran -c asb.f90 -o asb.o asb.f90:20:18: write(*,*) my_t%i 1 Error: Symbol »my_t« at (1) has no IMPLICIT type $ gfortran --version GNU Fortran (GCC) 7.0.0 20160422 (experimental)
[Bug c++/71024] New: Missing warning for contradictory attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71024 Bug ID: 71024 Summary: Missing warning for contradictory attributes Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- Observe that on void __attribute ((always_inline)) foo (void); void __attribute ((noinline)) foo (void); $ ./cc1 -quiet q.cc q.cc:2:31: warning: declaration of ‘foo’ with attribute ‘noinline’ follows declaration with attribute ‘always_inline’ [-Wattributes] void __attribute ((noinline)) foo (void); ^~~ q.cc:1:36: note: previous declaration of ‘foo’ was here void __attribute ((always_inline)) foo (void); ^~~ but cc1plus is silent. I think we need to factor out some code out of diagnose_mismatched_decls.
[Bug libstdc++/71004] recursive_directory_iterator does not have a user-provided default ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71004 --- Comment #6 from Eric Fiselier --- (In reply to Jonathan Wakely from comment #4) > (In reply to Eric Fiselier from comment #1) > > recursive_directory_iterator it; > > assert(it.recursion_pending() == false); > > assert(it.recursion_pending() == true); > > N.B. This test is undefined, those observer functions have preconditions > that they are not called on the end iterator. That's true, my mistake.
[Bug libstdc++/71025] New: std::call_once aborts instead of propagating an exception (AIX 6.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71025
Bug ID: 71025
Summary: std::call_once aborts instead of propagating an
exception (AIX 6.1)
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vfried at opentext dot com
Target Milestone: ---
When an exception is thrown inside a function called from std::call_once, the
process is aborted. The exception should be propagated outside std::call_once.
#include
#include
#include
int main()
{
static std::once_flag flag;
printf( "start\n" );
try
{
std::call_once(
flag,
[&]()
{
throw std::runtime_error("thrown from once");
} );
}
catch ( std::runtime_error const& exc )
{
printf( "%s\n", exc.what() );
}
printf( "end\n" );
return 0;
}
bea@stbldap02:~/samples$ g++ -std=c++14 -pthread std_call_once_exception.cxx
bea@stbldap02:~/samples$ ./a.out
start
terminate called after throwing an instance of 'std::runtime_error'
what(): thrown from once
IOT/Abort trap (core dumped)
BTW: the system on which I tested it should be the same as in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67478
[Bug fortran/71023] Problem with associate and function returning derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71023 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres --- I think it is a duplicate of pr60483. *** This bug has been marked as a duplicate of bug 60483 ***
[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 Bill Schmidt changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #7 from Bill Schmidt --- I can no longer reproduce this with a bootstrap compiler, even on the revision where it failed for me before. I'm perplexed. Do you still see it failing?
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #7 from Richard Biener ---
So PRE sees:
:
# .MEM_3 = VDEF <.MEM_1(D)>
MEM[(struct &)this_2(D)] ={v} {CLOBBER};
# .MEM_14 = VDEF <.MEM_3>
MEM[(struct &)this_2(D)] ={v} {CLOBBER};
# .MEM_15 = VDEF <.MEM_14>
MEM[(struct short_t &)this_2(D)].h.is_short = 1;
# .MEM_16 = VDEF <.MEM_15>
MEM[(struct short_t &)this_2(D)].h.length = 0;
# .MEM_17 = VDEF <.MEM_16>
MEM[(struct short_t &)this_2(D)].data[0] = 0;
# VUSE <.MEM_17>
_19 = BIT_FIELD_REF ;
_20 = _19 & 1;
if (_20 != 0)
goto ;
else
goto ;
:
# VUSE <.MEM_17>
_21 = BIT_FIELD_REF ;
_22 = _21 & 1;
if (_22 != 0)
goto ;
else
goto ;
:
# .MEM_34 = VDEF <.MEM_17>
short_backup = MEM[(const struct short_t &)this_2(D)];
# .MEM_35 = VDEF <.MEM_34>
MEM[(struct long_t *)this_2(D)] = MEM[(const struct long_t *)str_5(D)];
# .MEM_36 = VDEF <.MEM_35>
MEM[(struct short_t *)str_5(D)] = short_backup;
# .MEM_37 = VDEF <.MEM_36>
short_backup ={v} {CLOBBER};
goto ;
:
# .MEM_29 = PHI <.MEM_33(13), .MEM_37(5)>
# VUSE <.MEM_29>
_9 = MEM[(const struct short_t &)this_2(D)].h.length;
_10 = (long unsigned int) _9;
goto ;
and it concludes that on the path bb2 -> bb5 -> bb10 nothing can clobber
MEM[(const struct short_t &)this_2(D)].h.length and thus it is safe to
replace it with zero (from the init in bb2). The "obvious" clobbering
candidate is
# .MEM_35 = VDEF <.MEM_34>
MEM[(struct long_t *)this_2(D)] = MEM[(const struct long_t *)str_5(D)];
but that is storing using a different type. So the error must happen earlier.
It might be as early as the BIT_FIELD_REF folding of the is_short read which
does
_19 = BIT_FIELD_REF ;
It is DOM who threads further reads from the above again not considering
the above store clobbering a read via 'struct string' (which does not
include long_t in its alias subsets).
Thus mine (to fix optimize_bit_field_compare).
[Bug fortran/60483] [4.9/5/6/7 Regression] No IMPLICIT type error with: ASSOCIATE( X => derived_type() ) [i.e. w/ structure constructor]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60483 Dominique d'Humieres changed: What|Removed |Added CC||mrestelli at gmail dot com --- Comment #8 from Dominique d'Humieres --- *** Bug 71023 has been marked as a duplicate of this bug. ***
[Bug middle-end/71002] [6/7 Regression] -fstrict-aliasing breaks Boost's short string optimization implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71002 --- Comment #8 from Richard Biener --- Note that ultimatively the error is still that is_short () accesses the wrong union member. I'll still see whether there is a bug in optimize_bit_field_compare.
[Bug target/70957] testsuite/gcc.target/powerpc/vsx-elemrev-4.c fails on power7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70957 --- Comment #8 from Bill Schmidt --- Looks like it also did not fail in the latest gcc-testresults Power7 BE run. Going to stop looking at this unless/until it shows up again.
[Bug fortran/70953] Reallocation on assignment does not work with debug flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70953 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- > It looks like a duplicate of pr52162 (see comment 2). Not challenged, marked as duplicate of pr52162. *** This bug has been marked as a duplicate of bug 52162 ***
[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52162 Dominique d'Humieres changed: What|Removed |Added CC||mrestelli at gmail dot com --- Comment #6 from Dominique d'Humieres --- *** Bug 70953 has been marked as a duplicate of this bug. ***
[Bug libstdc++/71025] std::call_once aborts instead of propagating an exception (AIX 6.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71025 --- Comment #1 from Vojtech Fried --- I am sorry, probably duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146
[Bug fortran/56226] Add support for DEC UNION and MAP extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226 --- Comment #29 from Fritz Reese --- (In reply to Andreas Schwab from comment #25) > FAIL: gfortran.dg/dec_union_4.f90 -O0 execution test > FAIL: gfortran.dg/dec_union_4.f90 -O1 execution test > FAIL: gfortran.dg/dec_union_4.f90 -O2 execution test > FAIL: gfortran.dg/dec_union_4.f90 -O3 -fomit-frame-pointer -funroll-loops > -fpeel-loops -ftracer -finline-functions execution test > FAIL: gfortran.dg/dec_union_4.f90 -O3 -g execution test > FAIL: gfortran.dg/dec_union_4.f90 -Os execution test It was silly of me to disregard endian-ness in this test case. Fixed: https://gcc.gnu.org/ml/fortran/2016-05/msg00018.html
[Bug libstdc++/69699] libstdc++ ABI documentation is out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69699 --- Comment #6 from Jonathan Wakely --- There is no such macro.
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-05-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- WORKSFORME on x86_64-apple-darwin15 from 4.9.3 up to trunk (7.0). With 4.8.5 I get pr71014.f90:19:0: internal compiler error: in omp_add_variable, at gimplify.c:5896 associate (jassoc => j) Could you please post the result of 'gfortran -v'?
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Domani Hannes changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #9 from Domani Hannes --- I've the same behavior on windows as well, even if I remove the ms_abi attribute (probably because it's always ms_abi anyway?).
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #2 from Keith Lindsay --- Created attachment 38454 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38454&action=edit output from gfortran -v
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #3 from Keith Lindsay --- Created attachment 38455 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38455&action=edit output from gfortran -v
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 --- Comment #4 from Keith Lindsay --- Thanks for taking a look. I've attached the output from the command gfortran -v -fopenmp openmp_nested_loops.f90 -o openmp_nested_loops on two different systems where I'm seeing the problem.
[Bug target/70894] ICE when using neon intrinsic with mabi=apcs-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70894 Richard Earnshaw changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-05-09 Ever confirmed|0 |1 Known to fail||7.0 --- Comment #1 from Richard Earnshaw --- Confirmed on trunk. Note that I don't expect that we ever intended to make ACLE extensions work with the old ABI (-mabi=apcs-gnu). Nevertheless, we shouldn't ICE.
[Bug tree-optimization/71026] New: Missing division optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71026
Bug ID: 71026
Summary: Missing division optimizations
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wdijkstr at arm dot com
Target Milestone: ---
With -Ofast GCC doesn't reassociate constant multiplies or negates away from
divisors to allow for more reciprocal division optimizations. It is also
possible to avoid divisions (or multiplies) involving immediates in comparisons
that check for a positive/negative result.
float f1(float x, float y) { return x / (y * y); }// -> x * (1/y) * (1/y)
float f2(float x, float y) { return x / (y * 3.0f); } // -> (x/3) / y
float f3(float x, float y) { return x / -y; } // -> (-x) / y
int f4(float x) { return (1.0f / x) < 0.0f; } // -> x < 0.0f
int f5(float x) { return (x / 2.0f) <= 0.0f; }// -> x <= 0.0f
A quick experiment shows the first transformation could remove almost 100
divisions from SPEC2006, the 2nd 50. The first transformation is only useful if
there is at least one other division by y, so likely best done in the division
reciprocal optimization phase.
[Bug target/70904] ICE: Max. number of generated reload insns per insn is achieved (90) with -fno-split-wide-types @ aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70904
Jiong Wang changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #2 from Jiong Wang ---
(In reply to Zdenek Sojka from comment #0)
> Created attachment 38393 [details]
> reduced testcase
>
> Compiler output:
> $ aarch64-unknown-linux-gnu-gcc -O -fno-split-wide-types testcase.c
> testcase.c: In function 'foo':
> testcase.c:8:1: internal compiler error: Max. number of generated reload
> insns per insn is achieved (90)
>
> }
> ^
> 0x9dafa9 lra_constraints(bool)
> /repo/gcc-trunk/gcc/lra-constraints.c:4440
> 0x9c63dc lra(_IO_FILE*)
> /repo/gcc-trunk/gcc/lra.c:2290
> 0x96de19 do_reload
> /repo/gcc-trunk/gcc/ira.c:5425
> 0x96de19 execute
> /repo/gcc-trunk/gcc/ira.c:5609
From rtl dump, reload is trying to insert the following reload insn
r93:OI = r80:OI
r93 is with general register class and r80 is with vector register
class. r93 was created to meet the constraint inside insn 17, and was to
replace the vector register r80 inside the subreg, as vector register
can't be used as index register.
(insn 17 11 20 2 (set (mem:SI (plus:DI (sign_extract:DI (mult:DI (subreg:DI
(reg:OI 80 [ D.2754 ]) 0)
(const_int 4 [0x4]))
(const_int 34 [0x22])
(const_int 0 [0]))
(reg/f:DI 83)) [1 *_9+0 S4 A32])
(const_int 0 [0])) bug-1.c:7 49 {*movsi_aarch64}
reload here is trying to reload the inner register r80 instead of the whole
subreg,
thus creating a new "OImode (vector register)" to "OImode (general register"
move
which can't be supported in hardware and caused further endless reload.
For mode with size bigger than word_mode, there won't be "mov" between
two registers with different classes, but there normally will be "mov"
which transfers element of vector register into the general register, and
this normally will be a subreg.
So I think we should teach reload about this to reload the whole subreg
if above conditions met.
Comments?
(CCed RA maintainer Vlad)
diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index 14d5f1d..0ca7a7d 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1307,7 +1307,15 @@ process_addr_reg (rtx *loc, bool check_only_p, rtx_insn
**before, rtx_insn **aft
subreg_p = GET_CODE (*loc) == SUBREG;
if (subreg_p)
-loc = &SUBREG_REG (*loc);
+{
+ reg = SUBREG_REG (*loc);
+ mode = GET_MODE (reg);
+
+ if (in_class_p (reg, cl, &new_class)
+ || GET_MODE_SIZE (mode) <= GET_MODE_SIZE (word_mode))
+ loc = &SUBREG_REG (*loc);
+}
+
reg = *loc;
mode = GET_MODE (reg);
if (! REG_P (reg))
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #10 from zenith432 at users dot sourceforge.net --- (In reply to vries from comment #8) > Created attachment 38453 [details] > tentative patch vries, thank you very much. I verified and looks good. Built GCC 6.1.0 with patch from released sources on ftp.gnu.org. [moved the patch to the right place of course] Built a fairly large UEFI-based project with a good number of ms_va_list. Checked the disassembly manually for 1 instance. Code is right + tested it to run ok in various scenarios I know to use __builtin_va_arg. Bug can be changed to resolved as far as I'm concerned. Not sure whether it has to wait for commit, so leaving it to TPTB.
[Bug c++/71010] error: 'begin' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71010 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #2 from Manuel López-Ibáñez --- (In reply to Jonathan Wakely from comment #1) Furthermore, your code has undefined behaviour, it is forbidden to add your > own functions to namespace std. The correct way to do it is to write the > begin/end overloads in the same namespace as your type (in this case that's > the global namespace). I actually did not know that. Would it be possible to warn about this? I guess libstdc++ files are system-headers and can avoid the warning.
[Bug fortran/71027] New: -fsanitize=address catches out of bounds access on assumed size array only with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71027 Bug ID: 71027 Summary: -fsanitize=address catches out of bounds access on assumed size array only with -O0 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- ! -fsanitize=address -O0 catches out of bounds access on assumed size array ! any other optimization level, even -Og, inhibits catching dimension v(10) call sub(v) contains subroutine sub(vv) dimension vv(*) x=vv(20) ! out of bounds access end subroutine end
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #11 from Domani Hannes --- I can confirm that this patch works for windows as well.
[Bug middle-end/71028] New: [7 regression] ICE in redirect_jump, at jump.c:1560
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71028 Bug ID: 71028 Summary: [7 regression] ICE in redirect_jump, at jump.c:1560 Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: vp at gcc dot gnu.org Target Milestone: --- gcc.c-torture/compile/pr37483.c and gcc.dg/20010822-1.c FAILs on arm-none-eabi with: ...: internal compiler error: in redirect_jump, at jump.c:1560 } ^ 0x98314d redirect_jump(rtx_jump_insn*, rtx_def*, int) ../../gcc/gcc/jump.c:1560 0x10b8276 try_optimize_cfg ../../gcc/gcc/cfgcleanup.c:2900 0x10b8276 cleanup_cfg(int) ../../gcc/gcc/cfgcleanup.c:3150 0x10b9646 execute ../../gcc/gcc/cfgcleanup.c:3279 The following commit seem to cause it: https://gcc.gnu.org/viewcvs?rev=235904&root=gcc&view=rev
[Bug fortran/71014] associate statement inside omp parallel do appears to disable default private attribute for inner loop indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71014 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #5 from Harald Anlauf --- (In reply to Keith Lindsay from comment #4) > Thanks for taking a look. I've attached the output from the command > gfortran -v -fopenmp openmp_nested_loops.f90 -o openmp_nested_loops > on two different systems where I'm seeing the problem. Do you still see the problem when you replace the line !$OMP PARALLEL DO by !$OMP PARALLEL DO private(i,j) shared(s) default(none) ? What you see might be a race condition, since you did not declare the inner loop variable i as private.
[Bug libstdc++/71025] std::call_once aborts instead of propagating an exception (AIX 6.1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71025 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Yes this is PR 66146 *** This bug has been marked as a duplicate of bug 66146 ***
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #18 from Jonathan Wakely --- *** Bug 71025 has been marked as a duplicate of this bug. ***
[Bug c++/71029] New: large fold expressions compile slowly with -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029 Bug ID: 71029 Summary: large fold expressions compile slowly with -Wall Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alisdairm at me dot com Target Milestone: --- Created attachment 38456 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38456&action=edit file is very slow compiled with Wall The attached file uses a simple fold expression over a comma operator to consume 'get' on each element of a std::array, so essentially 2047 comma operators separating empty 'sink' function calls. On my current machine, with just with just g++ -std=c++1z file.cpp, this takes around 2.5 seconds to compile. With g++ -std=c++1z -Wall file.cpp it takes 25 seconds, and still reports no warnings. The generated code is also quite large, regardless of warning setting, generating an executable of around 650k. This is less than 5k when compiled -O3. Running the same scenario through Clang, the unoptimized code produced s 90k executable, and consistently gives a 1.5 second compile time, regardless of warning level. I suspect that Clang is getting in an early optimization around the do-nothing function to eliminate a lot of code prior to running warning passes, but that is entirely speculation as I have no idea how either compiler is implemented ;) For the curious, compiling with the latest gcc 7 branch available through MacPorts, this takes around 60% longer again although I am not sure if that compiler is built with the same optimization settings as the released gcc 6.1 compiler.
