[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #3 from Andrew Pinski --- (In reply to Nicolas Lesser from comment #2) > Huh, interesting. TIL. Where's that rule in the standard? Because I can't > find it in [class.mem]. Is it somewhere else or did I just overlook it? C++98 paragraph numbers: See 3.3.6/1 [...] 2) A name N used in a class S shall refer to the same declaration in its context and when reevaluated in the completed scope of S. No diagnostic is required for a violation of this rule. I think that is the same as [basic.scope.class].
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #5 from Andrew Pinski --- [basic.scope.class] p2: "A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule."
[Bug c++/87035] Can't shadow global const int with unnamed enum in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035 --- Comment #4 from Nicolas Lesser --- Nice, thank you!
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org --- Comment #18 from Segher Boessenkool --- I have a patch.
[Bug target/86987] ICE in simplify_binary_operation_1, at simplify-rtx.c:3515 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86987 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug target/86832] [8/9 Regression] GCC v8.2.0 tries to use native TLS with -fstack-protector-strong on Windows (mingw-w64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86832 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-21 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener --- Has this been fixed? If so please close.
[Bug tree-optimization/86835] [8 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/86836] internal compiler error on structured bindings with shadow parameter on templated function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86836 Richard Biener changed: What|Removed |Added Known to work||9.0 --- Comment #9 from Richard Biener --- Fixed on trunk(?). Is this a regression?
[Bug middle-end/86840] __attribute__((optimize("exceptions"))) is silently ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86840 Richard Biener changed: What|Removed |Added Keywords||wrong-code --- Comment #2 from Richard Biener --- Hmm, we have DECL_FUNCTION_PERSONALITY which is used for keying. I guess "late" processing of -fexceptions doesn't cause that to be "set". So likely the optimize attributes are not processed at the time the personality is set.
[Bug tree-optimization/86844] [8/9 regression] wrong code caused by store merging pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86844 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug other/87036] New: -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036
Bug ID: 87036
Summary: -O1/-O2 affects floating point precision on at least
i686 and ppc64el
Product: gcc
Version: 6.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at debian dot org
Target Milestone: ---
[forwarded from http://bugs.debian.org/906753]
no difference in the results on x86_64-linux-gnu, the bug submitter claims that
clang 6.0 is working as expected. Seen on at least i686 and ppc64el. Same
behaviour down to GCC 5 on both archs.
on ppc64el:
$ g++ -O0 tst.cc && ./a.out
$ g++ -O2 tst.cc && ./a.out
different mass sq values: 2.42 2.42
difference is : 3.55271e-15
on i686:
$ g++ -O0 tst.cc && ./a.out
$ g++ -O2 tst.cc && ./a.out
different mass sq values: 2.42 2.42
difference is : 1.77636e-15
$cat tst.cc
#include
#include // for swap
#include
namespace HepMC {
class FourVector {
public:
double m_x, m_y, m_z, m_t;
FourVector( double xin, double yin, double zin, double tin=0) : m_x(xin),
m_y(yin), m_z(zin), m_t(tin) {}
inline double m2() const {
return m_t*m_t - (m_x*m_x + m_y*m_y + m_z*m_z);
}
inline double m() const {
double mm = m2();
return mm < 0.0 ? -std::sqrt(-mm) : std::sqrt(mm);
}
};
} // HepMC
int main()
{
double eps = 1.e-15; // allowed differnce between doubles
// FourVector
HepMC::FourVector vector(1.1,2.2,3.3,4.4);
HepMC::FourVector v4(1.1,2.2,3.3,4.4);
//vector = v4;
double masssq1 = v4.m2();
double mass1 = v4.m();
double masssq2 = vector.m2();
double mass2 = vector.m();
if( fabs( masssq1 - masssq2 ) > eps ) {
std::cout << "different mass sq values: " << masssq1 << " " << masssq2 <<
std::endl;
std::cout << "difference is : " << ( masssq1 - masssq2 ) << std::endl;
}
return 0;
}
[Bug jit/86845] libgccjit.so.0.0.1 build error with in-tree isl: relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86845
Richard Biener changed:
What|Removed |Added
Keywords||build
CC||dmalcolm at gcc dot gnu.org
--- Comment #1 from Richard Biener ---
Well, looks like all the static libs of the in-tree prerequesites have to be
compiled with -fPIC. We have
host_modules= { module= mpfr; lib_path=src/.libs; bootstrap=true;
extra_configure_flags='--disable-shared
@extra_mpfr_configure_flags@';
extra_make_flags='AM_CFLAGS="-DNO_ASM"';
no_install= true; };
host_modules= { module= mpc; lib_path=src/.libs; bootstrap=true;
extra_configure_flags='--disable-shared
@extra_mpc_gmp_configure_flags@ @extra_mpc_mpfr_configure_flags@
--disable-maintainer-mode';
no_install= true; };
host_modules= { module= isl; lib_path=.libs; bootstrap=true;
extra_configure_flags='--disable-shared
@extra_isl_gmp_configure_flags@';
extra_make_flags='V=1';
no_install= true; };
David? This is really only required for libjit ... :/
[Bug other/87036] -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 --- Comment #1 from Andrew Pinski --- For powerpc at least this is due to fma. Use -ffp-contract=off to turn it off.
[Bug other/86834] [9 regression] several tests fail with ICE starting with r263245
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86834 Thomas Preud'homme changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Thomas Preud'homme --- As pointed by Jakub, commit was reverted in r263252. New iteration of the patch (currently still in testing) has been checked it doesn't have this regression. Best regards, Thomas
[Bug other/87036] -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- For x86, this is due to using 80bit fp. See PR 323 for that one.
[Bug other/87036] -O1/-O2 affects floating point precision on at least i686 and ppc64el
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 --- Comment #3 from Matthias Klose --- On 21.08.2018 09:53, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87036 > > --- Comment #1 from Andrew Pinski --- > For powerpc at least this is due to fma. Use -ffp-contract=off to turn it off. yes, -ffp-contract=off helps.
[Bug libstdc++/87037] New: vector :: erase return value should be marked "must use"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87037
Bug ID: 87037
Summary: vector :: erase return value should be marked "must
use"
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Given the following C++ source code
# include
using namespace std;
void f( vector < int > & vec)
{
for (auto i = vec.begin(); i != vec.end(); ++i)
{
vec.erase( i);
}
}
then there is an obvious bug that the return value from the erase
isn't used for loop control. gcc seems strangely silent on the issue:
$ ~/gcc/results.263644/bin/gcc -c -g -O2 -Wall -Wextra aug21a.cc
$
[Bug libstdc++/87037] vector :: erase return value should be marked "must use"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87037
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Jonathan Wakely ---
There's nothing strange about that at all. There are plenty of uses for erase
where it's totally fine to ignore the return value.
auto iter = std::find(v.begin(), v.end(), val);
if (iter != v.end())
{
do_something(*iter);
v.erase(iter);
}
How do you propose to mark it so it only complains when you have a bug?
[Bug c++/87035] Add "note: used here" to permerror about redeclaration changing the meaning of a name at class scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87035
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|RESOLVED|NEW
Last reconfirmed||2018-08-21
Resolution|INVALID |---
Summary|Can't shadow global const |Add "note: used here" to
|int with unnamed enum in|permerror about
|class |redeclaration changing the
||meaning of a name at class
||scope
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #6 from Jonathan Wakely ---
Yup, this is ill-formed; no diagnostic required.(In reply to Andrew Pinski from
comment #1)
> Actually no this is invalid code at least according to the standard. Since
Yup, ill-formed; no diagnostic required. GCC has been getting smarter about
diagnosing these cases.
> Maybe just the use of N is not in the error message.
Yes, maybe a note pointing to the use of the name would be useful.
t8.cc:5:10: error: declaration of ‘N’ [-fpermissive]
enum { N }; // fails, redeclaration
^
t8.cc:1:11: error: changes meaning of ‘N’ from ‘const int N’ [-fpermissive]
const int N = 5;
^
t8.cc:4:13: note: used here
int Array[N]; // int[5]
^
Re-opening as a diagnostic bug.
[Bug middle-end/86121] [9 Regression] missing -Wstringop-overflow on strcpy followed by strcat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86121 --- Comment #4 from Bernd Edlinger --- Author: edlinger Date: Tue Aug 21 08:56:11 2018 New Revision: 263693 URL: https://gcc.gnu.org/viewcvs?rev=263693&root=gcc&view=rev Log: 2018-08-21 Bernd Edlinger PR middle-end/86121 * tree-ssa-strlen.c (adjust_last_stmt): Avoid folding away undefined behaviour. testsuite: 2018-08-21 Bernd Edlinger PR middle-end/86121 * gcc.dg/Wstringop-overflow-6.c: Remove xfail. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-6.c trunk/gcc/tree-ssa-strlen.c
[Bug c/87038] New: diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
Bug ID: 87038
Summary: diagnostics: Please add warning for jumping over
initializers with switch/case in C mode
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: steinar+gcc at gunderson dot no
Target Milestone: ---
The other day, I had to debug (production!) code that essentially did this:
void func(int x) {
switch (x) {
case 1: {
int foo = 3;
case 0:
printf("foo is %d\n", foo);
}
}
}
If func is called with 0, “foo” is uninitialized, even though it doesn't look
like it. There's a similar construction with goto:
void func2(int x) {
if (x == 0) goto lbl;
int foo = 3;
lbl:
printf("foo is %d\n", foo);
}
In C++ mode, both constructs are rightfully rejected as an error. However, when
compiling as C, there's not even a warning; sometimes, control flow analysis
may detect that foo is used uninitialized, but not always.
Would it be possible to have a warning in C mode that mirrors the C++ error?
Ie. “jump to case label crosses initialization of 'int foo'”.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-21
Ever confirmed|0 |1
Severity|normal |enhancement
--- Comment #1 from Jonathan Wakely ---
Confirmed. Clang warns consistently, even at -O0:
87038.c:5:30: warning: variable 'foo' is used uninitialized whenever switch
case is taken [-Wsometimes-uninitialized]
case 0:
^
87038.c:6:55: note: uninitialized use occurs here
printf("foo is %d\n", foo);
^~~
87038.c:4:25: note: variable 'foo' is declared here
int foo = 3;
^
1 warning generated.
[Bug c/87038] diagnostics: Please add warning for jumping over initializers with switch/case in C mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87038
--- Comment #2 from Jonathan Wakely ---
And for the goto case Clang says:
87038.c:2:13: warning: variable 'foo' is used uninitialized whenever 'if'
condition is true [-Wsometimes-uninitialized]
if (x == 0) goto lbl;
^~
87038.c:5:31: note: uninitialized use occurs here
printf("foo is %d\n", foo);
^~~
87038.c:2:9: note: remove the 'if' if its condition is always false
if (x == 0) goto lbl;
^~~~
87038.c:3:9: note: variable 'foo' is declared here
int foo = 3;
^
1 warning generated.
[Bug tree-optimization/86847] [9 Regression] Switch code size growth
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86847 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-21 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Can you post a backtrace? Probably vectorizer code.
[Bug tree-optimization/86853] [7/8 Regression] sprintf optimization for wide strings doesn't account for conversion failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86853 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||9.0 Target Milestone|--- |7.4 Summary|sprintf optimization for|[7/8 Regression] sprintf |wide strings doesn't|optimization for wide |account for conversion |strings doesn't account for |failure |conversion failure Known to fail|9.0 | --- Comment #3 from Richard Biener --- I assume trunk is fixed. This is a regression.
[Bug libstdc++/86860] Reject valid overloads of subclass ostream operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86860 --- Comment #3 from Richard Biener --- So INVALID?
[Bug debug/87039] New: [8/9 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87039
Bug ID: 87039
Summary: [8/9 Regression] DW_OP_fbreg used without a frame base
on a C++ code w/ -fopenmp
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Starting from r257510, GCC emits debug info about which elfutils is not happy
about:
$ cat filter.ii
template void e(a, d, b);
template void g(double[][f]) {
for (int c; c;)
;
}
template
void i(int, int, int, int, int, int, int, int, double[], double[], double *[],
int) {
#pragma omp parallel
{
int j;
double k[1][h];
e(j, h, k);
g(k);
}
}
double *l;
int m;
double n[1], o[1];
void p() { i(0, 0, 1, 0, 0, 1, 0, 0, n, o, &l, m); }
$ g++ filter.ii -c -g -O2 -fopenmp &&
/home/marxin/Programming/elfutils/tests/varlocs -e filter.o
module 'filter.o'
[b] CU 'filter.ii'@0
[229] inlined function 'i'@20
[24e] parameter ''
[254] parameter ''
[25a] parameter ''
[260] parameter ''
[266] parameter ''
[26c] parameter ''
[272] parameter ''
[278] parameter ''
[27e] parameter ''
[20,30) {addr(0x38), stack_value}
[28e] parameter ''
[20,30) {addr(0x30), stack_value}
[29e] parameter ''
[20,30) {addr(0x48), stack_value}
[2ae] parameter ''
[20,2f) {addr(0x40)}
[18f] function '_Z1iIcLi1ELi0EEvPdS0_PS0_i._omp_fn.0'@0
frame_base: XXX zero address
[1a6] parameter ''
[0,b) {reg5}
[b,1a) {GNU_entry_value(1) {reg5}, stack_value}
[13d] inlined function 'g<1>'@15
[162] parameter ''
[15,1a) {/home/marxin/Programming/elfutils/tests/varlocs: DW_OP_fbreg
used without a frame base
The test-case is isolated from Inkscape program.
[Bug middle-end/86864] [9 Regression] ICE in commit_one_edge_insertion, at cfgrtl.c:2025 since r261795
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86864 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|ASSIGNED|NEW Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug debug/87039] [8/9 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87039 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org, ||mark at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/87040] New: ICE in extract_constrain_insn_cached, at recog.c:2218
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87040
Bug ID: 87040
Summary: ICE in extract_constrain_insn_cached, at recog.c:2218
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu
Following ICEs:
$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c
-fif-conversion2 -Og
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c:
In function ‘set_bh_page’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c:12:1:
error: insn does not satisfy its constraints:
12 | }
| ^
(insn 25 0 0 (set (reg:DI 121)
(const_int 4095 [0xfff])) 441 {*movdi_internal64}
(nil))
during RTL pass: ce3
/home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/compile/20030605-1.c:12:1:
internal compiler error: in extract_constrain_insn_cached, at recog.c:2218
0xfa3b95 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:108
0xfa3bf9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/rtl-error.c:118
0xf47798 extract_constrain_insn_cached(rtx_insn*)
/home/marxin/Programming/gcc/gcc/recog.c:2218
0x17b165d insn_default_length(rtx_insn*)
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.md:6831
0xb90531 get_attr_length_1
/home/marxin/Programming/gcc/gcc/final.c:407
0xb90566 get_attr_length(rtx_insn*)
/home/marxin/Programming/gcc/gcc/final.c:425
0x14fb201 rs6000_insn_cost
/home/marxin/Programming/gcc/gcc/config/rs6000/rs6000.c:34085
0xfb2b71 insn_cost(rtx_insn*, bool)
/home/marxin/Programming/gcc/gcc/rtlanal.c:5435
0xb574bb canonicalize_comparison(machine_mode, rtx_code*, rtx_def**)
/home/marxin/Programming/gcc/gcc/expmed.c:6249
0xeab7af prepare_cmp_insn
/home/marxin/Programming/gcc/gcc/optabs.c:3816
0xeafb35 gen_cond_trap(rtx_code, rtx_def*, rtx_def*, rtx_def*)
/home/marxin/Programming/gcc/gcc/optabs.c:5288
0x1a5960f find_cond_trap
/home/marxin/Programming/gcc/gcc/ifcvt.c:4657
0x1a58840 find_if_header
/home/marxin/Programming/gcc/gcc/ifcvt.c:4282
0x1a5b381 if_convert
/home/marxin/Programming/gcc/gcc/ifcvt.c:5405
0x1a5b801 execute
/home/marxin/Programming/gcc/gcc/ifcvt.c:5599
[Bug target/86869] ICE when taking address of array member of __memx struct pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86869 --- Comment #1 from Richard Biener --- #ifndef POINTERS_EXTEND_UNSIGNED gcc_assert (GET_MODE (x) == to_mode || GET_MODE (x) == VOIDmode); return x; #else /* defined(POINTERS_EXTEND_UNSIGNED) */ scalar_int_mode pointer_mode, address_mode, from_mode; rtx temp; So clearly avr has to define POINTERS_EXTEND_UNSIGNED in the correct way and/or the assert needs to be ajdusted for pointer/address_mode of as.
[Bug rtl-optimization/86990] [9 Regression] wrong code at -O2 on x86_64-linux-gnu in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86990 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||8.2.0 Version|unknown |9.0 Keywords||wrong-code Last reconfirmed||2018-08-21 CC||ebotcazou at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Summary|wrong code at -O2 on|[9 Regression] wrong code |x86_64-linux-gnu in 64-bit |at -O2 on x86_64-linux-gnu |mode|in 64-bit mode Target Milestone|--- |9.0 Known to fail||9.0 --- Comment #1 from Martin Liška --- Confirmed, started with r261089.
[Bug c++/86875] [8/9 Regression] ICE in tsubst_copy, at cp/pt.c:15478
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86875 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug target/86877] ICE in vectorizable_load, at tree-vect-stmts.c:8038
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86877 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Blocks||53947 Target Milestone|9.0 |--- Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |8.3 Summary|internal compiler error: in |[8/9 Regression] ICE in |vectorizable_reduction, at |vectorizable_reduction, at |tree-vect-loop.c:6919 |tree-vect-loop.c:6919 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r250382.
[Bug libstdc++/86860] Reject valid overloads of subclass ostream operator<
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86860 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- Yep, let's close it.
[Bug middle-end/87041] New: GCC 8 regression: -Wformat "reading through null pointer" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87041
Bug ID: 87041
Summary: GCC 8 regression: -Wformat "reading through null
pointer" on unreachable code
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: achurch+gcc at achurch dot org
Target Milestone: ---
In GCC 8, the following code compiled with -O1 -Wformat warns about passing
NULL to a %s format token even though the call can never be executed:
extern int printf(const char *, ...);
void foo(void) {
const char * const s = 0;
if (s) printf("%s\n", s);
}
foo.c: In function 'foo':
foo.c:4:5: warning: reading through null pointer (argument 2) [-Wformat=]
if (s) printf("%s\n", s);
^~
This breaks testing macros of the following style, which worked fine through
GCC 7.3.0:
#define CHECK_STREQUAL(value, expected) do { \
const char * const _value = value;\
const char * const _expected = expected; \
if (!_value && _expected) FAIL("Got NULL, expected [%s]", _expected); \
if (_value && !_expected) FAIL("Got [%s], expected NULL", _value);\
if (_value && _expected && strcmp(_value, _expected) != 0)\
FAIL("Got [%s], expected [%s]", _value, _expected); \
} while (0)
Here, passing NULL for the value of "expected" triggers the warning on the
final FAIL() invocation, even though that case will never be executed when
"expected" is NULL.
The warning disappears at -O0 or if the variable is not const (e.g., "const
char *s" instead of "const char * const s").
[Bug tree-optimization/86891] [9 Regression] wrong code with -O -frerun-cse-after-loop -fno-tree-dominator-opts -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86891 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug middle-end/87041] GCC 8 regression: -Wformat "reading through null pointer" on unreachable code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87041 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started on trunk in r254930 to report the warning.
[Bug c++/86900] [8/9 Regression] -gdwarf-5 -O2 -ffunction-sections = assembler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug target/86902] [9 Regression] ICE: in as_a, at machmode.h:356 at -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86902 Richard Biener changed: What|Removed |Added Target Milestone|--- |9.0
[Bug c++/86905] [6/7/8/9 Regression] g++ ICE on valid code: verify_cgraph_node failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86905 Richard Biener changed: What|Removed |Added Keywords||ice-checking Known to work||4.9.4 Version|unknown |9.0 Target Milestone|--- |6.5 Summary|g++ ICE on valid code: |[6/7/8/9 Regression] g++ |verify_cgraph_node failed |ICE on valid code: ||verify_cgraph_node failed Known to fail||5.1.0
[Bug fortran/86907] [9 Regression] bogus warning "No location in expression near"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |9.0 Summary|[9.0 regression] bogus |[9 Regression] bogus |warning "No location in |warning "No location in |expression near"|expression near"
[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 --- Comment #2 from David Binderman --- Indeed it does look like vectorizer code. Here are 20 frames, found by using the UBSAN_OPTIONS=print_stacktrace=1 option: ../../trunk/gcc/vec.h:1688:5: runtime error: member call on null pointer of type 'struct vec' #0 0x2be4a24 in vec<_slp_tree*, va_heap, vl_ptr>::splice(vec<_slp_tree*, va_ heap, vl_ptr> const&) ../../trunk/gcc/vec.h:1688 #1 0x2be4a24 in vect_build_slp_tree_2 ../../trunk/gcc/tree-vect-slp.c:1492 #2 0x2bd779e in vect_build_slp_tree ../../trunk/gcc/tree-vect-slp.c:1105 #3 0x2bdba6c in vect_build_slp_tree_2 ../../trunk/gcc/tree-vect-slp.c:1257 #4 0x2bd779e in vect_build_slp_tree ../../trunk/gcc/tree-vect-slp.c:1105 #5 0x2bdba6c in vect_build_slp_tree_2 ../../trunk/gcc/tree-vect-slp.c:1257 #6 0x2bd779e in vect_build_slp_tree ../../trunk/gcc/tree-vect-slp.c:1105 #7 0x2bf1e80 in vect_analyze_slp_instance ../../trunk/gcc/tree-vect-slp.c:19 56 #8 0x2bfa002 in vect_analyze_slp(vec_info*, unsigned int) ../../trunk/gcc/tr ee-vect-slp.c:2154 #9 0x2bfaf63 in vect_slp_analyze_bb_1 ../../trunk/gcc/tree-vect-slp.c:2839 #10 0x2bfaf63 in vect_slp_bb(basic_block_def*) ../../trunk/gcc/tree-vect-slp .c:2973 #11 0x2c0d5bc in execute ../../trunk/gcc/tree-vectorizer.c:1271 #12 0x1b4e1ac in execute_one_pass(opt_pass*) ../../trunk/gcc/passes.c:2446 #13 0x1b51cf7 in execute_pass_list_1 ../../trunk/gcc/passes.c:2535 #14 0x1b51d3e in execute_pass_list_1 ../../trunk/gcc/passes.c:2536 #15 0x1b51d3e in execute_pass_list_1 ../../trunk/gcc/passes.c:2536 #16 0x1b51e18 in execute_pass_list(function*, opt_pass*) ../../trunk/gcc/pas ses.c:2546 #17 0xc9d9da in cgraph_node::expand() ../../trunk/gcc/cgraphunit.c:2116 #18 0xca2db4 in expand_all_functions ../../trunk/gcc/cgraphunit.c:2254 #19 0xca2db4 in symbol_table::compile() ../../trunk/gcc/cgraphunit.c:2605 #20 0xcaca6a in symbol_table::finalize_compilation_unit() ../../trunk/gcc/cg raphunit.c:2698
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- (In reply to Jonathan Wakely from comment #1) > No, your program has undefined behaviour. To make it valid you either need > to use std::launder, or use the pointer that is returned by the placement > new. > > The compiler is allowed to assume that the dynamic type of &strategy does > not change (that's why you need to use std::launder). You need to use std::launder at every use of the object, right? I wonder why static_cast() isn't a good enough "hint" here that the type of strategy changed (from QOI perspective, std::launder is new). I guess a better testcase would be to declare strategy as AStrategy and placement-new BaseStrategy over it or does the standard guaranteee that AStrategy fits in the storage of BaseStrategy?
[Bug target/86771] [9 Regression] gfortran.dg/actual_array_constructor_1.f90 fails on arm after combine 2 insns to 2 insns patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86771 --- Comment #19 from Wilco --- (In reply to Segher Boessenkool from comment #16) > (In reply to Wilco from comment #14) > > Note there is also an issue with costs, if the cost is zero then it seems to > > behave like infinite cost. > > 0 means unknown cost. Any known cost is treated as at least as good as > unknown cost. > > > It would be better to properly cost an > > instruction sequence given there is a new interface for this now. > > Yup. > > > If the > > cost is still zero, it could get the default cost rather than being treated > > like infinite cost, resulting in non-optimal replacements. > > Treating unknown cost as minimal cost is still non-optimal. It might work > better for your case of course. But it means for example that combine will > modify parallels less often. Well insn_cost() uses COSTS_N_INSNS (1) for instructions with unknown (zero) costs. That's a reasonable default and gives more accurate cost comparisons, eg. 0 + 4 vs 0 + 8 now becomes 4 + 4 vs 4 + 8. With insn_cost() the ldm's get cost 8+8, so the comparison is 4 + 16 vs 8 + 8, and thus the substitution will happen (though it's not clear it's useful for the selected CPU). With those changes I think there will be far fewer cases with unknown costs. There will be cases where target insn_cost needs to be improved to more accurately model complex instructions, but that will result in even better code.
[Bug tree-optimization/86850] ubsan: runtime error: member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 --- Comment #3 from rguenther at suse dot de --- On Tue, 21 Aug 2018, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86850 > > --- Comment #2 from David Binderman --- > Indeed it does look like vectorizer code. Here are 20 frames, > found by using the UBSAN_OPTIONS=print_stacktrace=1 option: OK, I suppose we're creating a SLP node for a PHI where there are zero operands and thus no children and SLP_TREE_CHILDREN (node).create (nops); will not create a vector but a splice of an empty vector will barf when splicing into it. Index: gcc/tree-vect-slp.c === --- gcc/tree-vect-slp.c (revision 263656) +++ gcc/tree-vect-slp.c (working copy) @@ -1489,7 +1489,9 @@ fail: node = vect_create_new_slp_node (stmts); SLP_TREE_TWO_OPERATORS (node) = two_operators; - SLP_TREE_CHILDREN (node).splice (children); + gcc_assert (children.length () == nops); + if (!children.is_empty ()) +SLP_TREE_CHILDREN (node).splice (children); return node; }
[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86997 --- Comment #2 from Martin Liška --- (In reply to Jonathan Wakely from comment #1) > Looks like a dup of PR 59389 Any easy workaround for it?
[Bug c++/86997] error: call of overloaded ‘NoDestructor()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86997
--- Comment #3 from Jonathan Wakely ---
Don't write weird code?
Either of these works fine and is obvious what it is supposed to do:
NoDestructor b;
NoDestructor b{};
The original is weird. Is it trying to construct an 'a' object and pass that to
the NoDestructor? Or just default construct the NoDestructor object?
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #7 from Jonathan Wakely --- (In reply to Richard Biener from comment #6) > (In reply to Jonathan Wakely from comment #1) > > No, your program has undefined behaviour. To make it valid you either need > > to use std::launder, or use the pointer that is returned by the placement > > new. > > > > The compiler is allowed to assume that the dynamic type of &strategy does > > not change (that's why you need to use std::launder). > > You need to use std::launder at every use of the object, right? Or just launder the pointer once and then use that: auto laundered = std::launder(&strategy); laundered->doIt(); // > I wonder > why static_cast() isn't a good enough "hint" here that > the type of strategy changed (from QOI perspective, std::launder is new). Casting from type X* to Y* where X and Y happen to be the same type can happen in generic code that was already written years ago, and doesn't play these sort of dirty tricks. It would be a shame to prevent useful optimisations because of a no-op cast. We don't need to make it easier to play nasty games with the type system. There are ways to do this sanely, without undefined behaviour, even without std::launder (just using the pointer returned by the placement new-expression should be good enough, instead of accessing through &strategy every time). > I guess a better testcase would be to declare strategy as AStrategy > and placement-new BaseStrategy over it or does the standard guaranteee > that AStrategy fits in the storage of BaseStrategy? For these types, with the Itanium ABI, it fits, and you could add a static_assert to verify it. Either way you need to placement new the original type back again, otherwise the wrong destructor gets called on scope exit, which adds more undefined behaviour.
[Bug middle-end/86909] Missing common subexpression elimination for types other than int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86909 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-08-21 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Similar "bad" code for using 'unsigned int'. With 'int' the reassoc pass combines the repetitive checks to [local count: 840525100]: _8 = (unsigned int) _9; _15 = _8 <= 7; if (_15 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 532808861]: iftmp.1_6 = &in_3(D)->a; [local count: 1073741824]: # _1 = PHI return _1; with char or unsigned int it fails to do that which is because we are testing different vars: [local count: 840525100]: i_36 = (int) _9; if (i_36 == 0) goto ; [50.00%] else goto ; [50.00%] [local count: 420262550]: if (_9 == 0) goto ; [71.00%] else goto ; [29.00%] [local count: 532808861]: iftmp.1_6 = &in_3(D)->a; goto ; [100.00%] [local count: 303654184]: if (i_36 == 1) goto ; [67.33%] else goto ; [32.67%] [local count: 182536110]: if (_9 == 1) goto ; [43.66%] else goto ; [56.34%] same for char. We're somehow not seeing the equivalence _9 = MEM[(unsigned int *)in_3(D) + 4B]; i_36 = (int) _9; when we know either is of a specific value. Jump threading and/or CSE should do this job. Btw, the initial code is quite convoluted and needs lot of threading to get to the above "nice" state. EVRP figures out the equivalencies but is confused by the initial : _24 = MEM[(unsigned int *)in_5(D) + 4B]; if (_24 != 4294967295) goto ; [78.28%] else goto ; [21.72%] : iftmp.0_20 = (long long unsigned int) _24; : # iftmp.0_18 = PHI <18446744073709551615(2), iftmp.0_20(3)> i_7 = (int) iftmp.0_18; which has to be jump-threaded away first with later : if (_24 != 4294967295) goto ; [78.28%] else goto ; [21.72%] : if (_24 == 6) goto ; [55.78%] else goto ; [44.22%] : or alternatively the initial sequence needs to be phi-opted earlier. In the end it appears to be a pass-ordering issue.
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 Joshua Green changed: What|Removed |Added CC||jvg1981 at aim dot com --- Comment #17 from Joshua Green --- "But if we don't know which pointer is greater, it gets more complicated: ..." I'm not sure that this is true. For types that are larger than 1 byte, it seems that one can do the subtraction after any division(s), hence only costing an additional division (or shift): T * p; T * q; . . . intptr_t pVal = ((uintptr_t) p)/(sizeof *p); intptr_t qVal = ((uintptr_t) q)/(sizeof *q); ptrdiff_t p_q = pVal - qVal; This should work in well-defined cases, for if p and q are pointers into the same array then (presumably) ((uintptr_t) p) and ((uintptr_t) q) must have the same remainder modulo sizeof(T). Of course, even an additional shift may be too expensive in some cases, so it's not entirely clear that this change should be made.
[Bug tree-optimization/86914] [8/9 Regression] -O2 generates wrong code with strlen() of pointers within one-element arrays of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #18 from joseph at codesourcery dot com --- On Tue, 21 Aug 2018, jvg1981 at aim dot com wrote: > intptr_t pVal = ((uintptr_t) p)/(sizeof *p); > intptr_t qVal = ((uintptr_t) q)/(sizeof *q); Note that this can be expanded like an exact division (right shift and multiply by reciprocal). See bug 67999 comment 24 and bug 81801 comment 4.
[Bug c++/86917] [6/7/8/9 Regression] ICE in verify_ctor_sanity, at cp/constexpr.c:2798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86917 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |6.5
[Bug c/63303] Pointer subtraction is broken when using -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63303 --- Comment #19 from Marc Glisse --- This seems fixed in gcc-8, no?
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #8 from Kostya Frumkin --- > Either way you need to placement new the original type back again, otherwise > the wrong destructor gets called on scope exit, which adds more undefined > behaviour. There should not be undefined behavior because the size of both classes is same and destructors executes same code (in the case it is noop). So the memory to be freed up is same. The behavior must be defined by ISO committee because it is counterintuitive when the base methods are being called. (where to ask?) At the same time this design pattern (strategy) with placement-new is more efficient than with common new. So it has no rationale if the base methods are used when using placement-new. At the same time other compilers generates code where the derived method is callsed after placement-new. So I see two ways: - Ask the community to define behavior. or - Define behavior in gcc itself.
[Bug tree-optimization/86919] strlen of a multidimensional array element with non-constant offset not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86919
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-08-21
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. But you'll have a hard time here since in
_6 = (sizetype) j_3(D);
_1 = &b + _6;
_2 = __builtin_strlen (_1);
the fact that you access a different dimension is lost. Consider
const char b[][3] = { "123", "2" };
where the "123" string overflows into the next dimension when you
ask for strlen (b).
[Bug c++/86922] Invoking templated PTMF on subclass gives false strict-aliasing warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86922 Richard Biener changed: What|Removed |Added Keywords||diagnostic, wrong-code --- Comment #1 from Richard Biener --- It warns about dereferencing (int (*) () * *) &((const struct B *) obj)->D.2305 which is built via #2 0x00b585af in cp_build_indirect_ref_1 ( ptr=, errorstring=RO_NULL, complain=3, do_fold=true) at /tmp/trunk/gcc/cp/typeck.c:3155 #3 0x00b58938 in cp_build_fold_indirect_ref ( pointer=) at /tmp/trunk/gcc/cp/typeck.c:3232 #4 0x00b59a5e in get_member_function_from_ptrfunc ( instance_ptrptr=0x7fffc868, function=, complain=3) at /tmp/trunk/gcc/cp/typeck.c:3565 #5 0x0097aabd in build_offset_ref_call_from_tree ( fn=, args=0x7fffc958, complain=3) at /tmp/trunk/gcc/cp/decl2.c:5095 #6 0x00ab9d26 in tsubst_copy_and_build (t=, args=, complain=3, in_decl=, function_p=false, integral_constant_expression_p=false) at /tmp/trunk/gcc/cp/pt.c:18485 the fnptr type has an alias-set that isn't compatible with that of struct B. Not sure where that int return type comes from ... Fishy. And possibly wrong-code afterwards because of that alias set.
[Bug tree-optimization/86924] tree-slp-vectorize may create unaligned memory access, causing segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86924 Richard Biener changed: What|Removed |Added Target||x86_64-w64-mingw32 Status|UNCONFIRMED |WAITING Last reconfirmed||2018-08-21 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- The question is where rcx comes from and why it isn't suitably aligned. This is very likely an issue in chromium, not gcc. The workaround patch shows the things to look at, namely the type declarations of *cpi and ordered_bwd and where they are allocated. Please attach preprocessed source for encoder.c as you use it when compiling for x86_64-w64-mingw32 (just add -save-temps to the compile that reproduces the failure).
[Bug c++/86926] [8/9 Regression] ICE for a recursive generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86926 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |8.3
[Bug c++/86932] [8/9 Regression] Empty non-type template parameter pack not considered for SFINAE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86932 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.3
[Bug c++/86908] static_cast(&derivedClassObject)->virtualMehod() calls base version of virtualMethod()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86908 --- Comment #9 from Jonathan Wakely --- (In reply to Kostya Frumkin from comment #8) > At the same time this design pattern (strategy) with placement-new is more > efficient than with common new. That's fine, but you can't use &strategy to access the AStrategy object you created at that position. You have several choices: - use an untyped buffer and create objects in there: alignas(AStrategy) unsigned char buf[sizeof(AStrategy)]; - use std::launder - use the pointer returned by the placement new-expression, which has the right type There are ways to do this safely in C++ today, but your original code is not one of those ways. You should fix your code. > So it has no rationale if the base methods > are used when using placement-new. At the same time other compilers > generates code where the derived method is callsed after placement-new. It's undefined behaviour, so anything can happen.
[Bug tree-optimization/87042] New: UBSAN: poly-int.h:1095:5: runtime error: signed integer overflow: 9223372036854775807 * 8 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87042
Bug ID: 87042
Summary: UBSAN: poly-int.h:1095:5: runtime error: signed
integer overflow: 9223372036854775807 * 8 cannot be
represented in type 'long int'
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Blocks: 63426
Target Milestone: ---
Maybe a dup of PR85164, but:
$ cat strlen.i
const char a[] = {};
b() { '\0' == a[9223372036854775807]; }
$ UBSAN_OPTIONS=print_stacktrace=1 ./xgcc -B. strlen.i -O1
strlen.i:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
2 | b() { '\0' == a[9223372036854775807]; }
| ^
../../gcc/poly-int.h:1095:5: runtime error: signed integer overflow:
9223372036854775807 * 8 cannot be represented in type 'long int'
#0 0xb98b74 in poly_int<1u, poly_result::is_poly>::type, poly_coeff_pair_traits::is_poly>::type>::result_kind>::type>
operator*<1u, long, int>(poly_int_pod<1u, long> const&, int const&)
../../gcc/poly-int.h:1095
#1 0x23cc1c9 in fully_constant_vn_reference_p(vn_reference_s*)
../../gcc/tree-ssa-sccvn.c:1373
#2 0x23d61f7 in vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool) ../../gcc/tree-ssa-sccvn.c:2540
#3 0x23e1b38 in visit_reference_op_load ../../gcc/tree-ssa-sccvn.c:3798
#4 0x23e34a3 in visit_use ../../gcc/tree-ssa-sccvn.c:4163
#5 0x23e43e2 in process_scc ../../gcc/tree-ssa-sccvn.c:4346
#6 0x23e5812 in extract_and_process_scc_for_name
../../gcc/tree-ssa-sccvn.c:4467
#7 0x23e5bc4 in DFS ../../gcc/tree-ssa-sccvn.c:4517
#8 0x23ea154 in sccvn_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-sccvn.c:4956
#9 0x3ada486 in dom_walker::walk(basic_block_def*) ../../gcc/domwalk.c:353
#10 0x23ead4e in run_scc_vn(vn_lookup_kind) ../../gcc/tree-ssa-sccvn.c:5063
#11 0x23f2aa0 in execute ../../gcc/tree-ssa-sccvn.c:6044
#12 0x1a2a1fc in execute_one_pass(opt_pass*) ../../gcc/passes.c:2446
#13 0x1a2ab8d in execute_pass_list_1 ../../gcc/passes.c:2535
#14 0x1a2ac42 in execute_pass_list_1 ../../gcc/passes.c:2536
#15 0x1a2ace1 in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2546
#16 0x1a251da in do_per_function_toporder(void (*)(function*, void*),
void*) ../../gcc/passes.c:1688
#17 0x1a2d2b4 in execute_ipa_pass_list(opt_pass*) ../../gcc/passes.c:2894
#18 0xdb3593 in ipa_passes ../../gcc/cgraphunit.c:2407
#19 0xdb434b in symbol_table::compile() ../../gcc/cgraphunit.c:2543
#20 0xdb522e in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2788
#21 0x1e2d777 in compile_file ../../gcc/toplev.c:480
#22 0x1e349df in do_compile ../../gcc/toplev.c:2170
#23 0x1e3500d in toplev::main(int, char**) ../../gcc/toplev.c:2305
#24 0x3f49d8a in main ../../gcc/main.c:39
#25 0x75ca3fea in __libc_start_main ../csu/libc-start.c:308
#26 0x84a529 in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x84a529)
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug tree-optimization/86936] strnlen() of a constant not folded due to laddress transformation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86936 --- Comment #3 from Richard Biener --- Note to GIMPLE &a[1][i_3(D)] is just address-computation and carries no semantics so you can't assume that i_3(D) isn't negative and thus ends up accessing "123". For the C testcase you of course can, but once we're in GIMPLE you cannot. If there's a load like _7 = a[1][i_3(D)]; you _can_ assume that i_3(D) fits in the respective array types domain.
[Bug c++/86943] [8/9 Regression] Wrong code when converting stateless generic lambda to function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86943 Richard Biener changed: What|Removed |Added Keywords||wrong-code Target Milestone|9.0 |8.3
[Bug fortran/87043] New: maybe-uninitialized warning for initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87043
Bug ID: 87043
Summary: maybe-uninitialized warning for initialized variable
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pvitt at posteo dot de
Target Milestone: ---
We have a MWE that provokes a "may be uninitialized" warning despite the value
being initialized in all cases. Additionally, this warning is only created with
-O[1,2,3,s,fast}, but not with -O{g}. The gcc is from Arch Linux.
$ gfortran -v -save-temps -O3 -Wmaybe-uninitialized uninitialized.f90
Driving: gfortran -v -save-temps -O3 -Wmaybe-uninitialized uninitialized.f90 -l
gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 8.1.1 20180531 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-Wmaybe-uninitialized'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/f951 uninitialized.f90 -quiet -dumpbase
uninitialized.f90 -mtune=generic -march=x86-64 -auxbase uninitialized -O3
-Wmaybe-uninitialized -version -fintrinsic-modules-path
/usr/lib/gcc/x86_64-pc-linux-gnu/8.1.1/finclude -o uninitialized.s
GNU Fortran (GCC) version 8.1.1 20180531 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.1 20180531, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 8.1.1 20180531 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.1.1 20180531, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.19-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
uninitialized.f90:20:0:
max_err_len = maxval(len_trim(error_messages))
Warning: ‘error_messages.dim[0].ubound’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
[stripped assembler output...]
$ cat uninitialized.f90
module m
implicit none
integer, parameter :: error_buflen = 80
integer :: world_rank, world_size
contains
subroutine test()
character(len=error_buflen), allocatable :: error_messages(:)
integer :: allocstat, max_err_len
max_err_len = 0
if (world_rank == 0 ) then
allocate(error_messages(world_size), stat=allocstat)
else
allocate(error_messages(0))
end if
if (world_rank == 0) then
max_err_len = maxval(len_trim(error_messages))
end if
if (max_err_len > error_buflen-10) then
write(*,'(a)') 'Note...'
end if
end subroutine test
end module
program uninitialized
use m
implicit none
read(*,*) world_rank
world_size = 2
call test()
end program
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 Richard Biener changed: What|Removed |Added Priority|P4 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- Confirmed. Likely caused by CFG cleanup convert_single_case_switch which generates a range test which is done in a signed type: : id.8_1 = CHAIN.11->id; _3 = id.8_1 - -2147483648; _4 = (unsigned int) _3; if (_4 <= 2147483647) when forwprop then combines this we fold (unsigned int) _3 <= 2147483647 to _3 >= 2147483647 which then is folded as id.8_1 - -2147483648 >= 2147483647 which is then folded to id.8_1 >= 2147483647 + -2147483648. But something goes wrong end we end up simplifying it as true.
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945 --- Comment #7 from Richard Biener --- With -fsanitize=undefined we get even at -O0 id= 1 : runtime error: signed integer overflow: 1 - -2147483647 cannot be represented in type 'integer(kind=4)' ierr1, OK =0 T : runtime error: signed integer overflow: 1 - -2147483648 cannot be represented in type 'integer(kind=4)' ierr2, OK =0 T so both foo1 and foo2 do not "work".
[Bug tree-optimization/86924] tree-slp-vectorize may create unaligned memory access, causing segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86924 --- Comment #2 from Mario Rohkrämer --- Unfortunately, I do not have much experience in running a compile manually. I only let the "media-autobuild suite" batch run. https://github.com/jb-alvarado/media-autobuild_suite/ I would not know for sure where to manipulate these batch/shell files to add the requested argument, or how to manually run the compilation for one specific file. It's all automated. But I will ask around and try to get advice.
[Bug fortran/86945] [8/9 Regression] BUG with optimisation of select case statement in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86945
--- Comment #8 from Richard Biener ---
C testcase:
void __attribute__((noinline,noipa))
foo(int id)
{
switch (id)
{
case (-__INT_MAX__ - 1)...-1:
__builtin_abort ();
default:;
}
}
int main()
{
foo(1);
return 0;
}
[Bug tree-optimization/86924] tree-slp-vectorize may create unaligned memory access, causing segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86924 --- Comment #3 from Mario Rohkrämer --- Created attachment 44567 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44567&action=edit Zipped temp output encoder.i by lupo... This is the "-save-temps" output which user lupo... attached in comment 12 to the Chromium bug report I linked above.
[Bug libstdc++/87044] New: stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044
Bug ID: 87044
Summary: stl_construct.h not interoperable with allocators with
custom reference types
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barmie.brace at outlook dot com
Target Milestone: ---
Created attachment 44568
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44568&action=edit
Custom allocator with custom reference object type.
STL containers don't seem to be interoperable with allocators with custom
reference types due to stl_construct.h's use of std::__addressof() instead of
the allocator's address() member.
Attached is a simple example using an allocator with a custom reference type.
[xiii@ea1c9ec7dba3 custom_allocator_test]$ make
g++ test.cpp -o test -std=gnu++14 -O3
In file included from /usr/include/c++/8.2.0/vector:62,
from test.cpp:1:
/usr/include/c++/8.2.0/bits/stl_construct.h: In instantiation of 'void
std::_Destroy(_ForwardIterator, _ForwardIterator, _Allocator&) [with
_ForwardIterator = custom_ptr; _Allocator = custom_allocator]':
/usr/include/c++/8.2.0/bits/stl_vector.h:567:15: required from
'std::vector<_Tp, _Alloc>::~vector() [with _Tp = int; _Alloc =
custom_allocator]'
test.cpp:12:43: required from here
/usr/include/c++/8.2.0/bits/stl_construct.h:198:46: error: cannot bind
non-const lvalue reference of type 'custom_ref&' to an rvalue of type
'custom_ptr::reference' {aka 'custom_ref'}
__traits::destroy(__alloc, std::__addressof(*__first));
^~~~
In file included from /usr/include/c++/8.2.0/bits/stl_pair.h:59,
from /usr/include/c++/8.2.0/bits/stl_algobase.h:64,
from /usr/include/c++/8.2.0/vector:60,
from test.cpp:1:
/usr/include/c++/8.2.0/bits/move.h:47:5: note: initializing argument 1 of
'constexpr _Tp* std::__addressof(_Tp&) [with _Tp = custom_ref]'
__addressof(_Tp& __r) _GLIBCXX_NOEXCEPT
^~~
make: *** [Makefile:2: test] Error 1
[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65043 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Aug 21 15:25:17 2018 New Revision: 263739 URL: https://gcc.gnu.org/viewcvs?rev=263739&root=gcc&view=rev Log: PR c++/65043 * call.c (standard_conversion): Set check_narrowing. * typeck2.c (check_narrowing): Use CP_INTEGRAL_TYPE_P rather than comparing with INTEGER_TYPE. * g++.dg/concepts/pr67595.C: Add dg-warning. * g++.dg/cpp0x/Wnarrowing11.C: New test. * g++.dg/cpp0x/Wnarrowing12.C: New test. * g++.dg/cpp0x/rv-cast5.C: Add static_cast. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing11.C trunk/gcc/testsuite/g++.dg/cpp0x/Wnarrowing12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/typeck2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/concepts/pr67595.C trunk/gcc/testsuite/g++.dg/cpp0x/rv-cast5.C
[Bug c++/65043] Expected narrowing conversion during list initialization of bool from double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65043 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/86981] Add Clang's -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86981 --- Comment #1 from Marek Polacek --- Author: mpolacek Date: Tue Aug 21 15:38:36 2018 New Revision: 263741 URL: https://gcc.gnu.org/viewcvs?rev=263741&root=gcc&view=rev Log: PR c++/86981, Implement -Wpessimizing-move. * c.opt (Wpessimizing-move): New option. * typeck.c (decl_in_std_namespace_p): New. (is_std_move_p): New. (maybe_warn_pessimizing_move): New. (can_do_nrvo_p): New, factored out of ... (check_return_expr): ... here. Warn about potentially harmful std::move in a return statement. * doc/invoke.texi: Document -Wpessimizing-move. * g++.dg/cpp0x/Wpessimizing-move1.C: New test. * g++.dg/cpp0x/Wpessimizing-move2.C: New test. * g++.dg/cpp0x/Wpessimizing-move3.C: New test. * g++.dg/cpp0x/Wpessimizing-move4.C: New test. * g++.dg/cpp1z/Wpessimizing-move1.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move1.C trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move2.C trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move3.C trunk/gcc/testsuite/g++.dg/cpp0x/Wpessimizing-move4.C trunk/gcc/testsuite/g++.dg/cpp1z/Wpessimizing-move1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c.opt trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug fortran/87045] New: pointer to array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045 Bug ID: 87045 Summary: pointer to array of character Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: valeryweber at hotmail dot com Target Milestone: --- hi all i m getting a weird error with the following code. many thanks v cat t2.f90 program test character(:), dimension(:), allocatable, target :: t character(:), pointer, dimension(:) :: p allocate( character(3) :: t(2) ) t(1) = "abc" t(2) = "123" write(*,*) t p => t write(*,*) p(1) write(*,*) p(2) end program test gfortran-8.1.0 t2.f90 -g -fcheck=all ./a.out abc123 At line 8 of file t2.f90 Fortran runtime error: Unequal character lengths (-3262553545697656832/3) in pointer assignment Error termination. Backtrace: #0 0x402548 in test at /home/vwe/work/axv/pkg/build/t2.f90:8 #1 0x402724 in main at /home/vwe/work/axv/pkg/build/t2.f90:11
[Bug c++/86981] Add Clang's -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86981 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Done for GCC 9.
[Bug tree-optimization/87046] New: Incorrect vectorization of fma with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046 Bug ID: 87046 Summary: Incorrect vectorization of fma with -O3 Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: yates at cscs dot ch Target Milestone: --- Created attachment 44569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44569&action=edit Stripped preprocessed source of minimal test case. In some circumstances, vectorization of fma at -O3 on broadwell and haswell incorrectly uses the wrong data for the addition component. While the sample code was tested with gcc version 7.3.0 with -march=haswell, the same problem arises with gcc 6.4.0. Disabling tree-slp-vectorize restores correct behaviour. I've attached a stripped down preprocessed source that demonstrates the bug. gcc -v output: Using built-in specs. COLLECT_GCC=/opt/gcc/7.3.0/bin/../snos/bin/gcc COLLECT_LTO_WRAPPER=/opt/gcc/7.3.0/snos/libexec/gcc/x86_64-suse-linux/7.3.0/lto-wrapper Target: x86_64-suse-linux Configured with: ../cray-gcc-7.3.0-201801270210.d61239fc6000b/configure --prefix=/opt/gcc/7.3.0/snos --disable-nls --libdir=/opt/gcc/7.3.0/snos/lib --enable-languages=c,c++,fortran --with-gxx-include-dir=/opt/gcc/7.3.0/snos/include/g++ --with-slibdir=/opt/gcc/7.3.0/snos/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl --with-cloog --disable-multilib Thread model: posix gcc version 7.3.0 20180125 (Cray Inc.) (GCC) Compilation command line and program output: $ gcc -O3 -march=haswell fma-reduced-bug.i $ ./a.out Aborted (core dumped)
[Bug tree-optimization/87046] Incorrect vectorization of fma with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87046
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
Component|target |tree-optimization
--- Comment #1 from Alexander Monakov ---
This appears recently fixed, gcc-8.1 still got this wrong but gcc-8.2 is ok.
Possibly went away with PR 85597 fix, but not sure about that.
On gcc-8.1 SLP incorrectly produced
vectp.1_29 = u_4(D);
vect__26.2_27 = MEM[(const double *)vectp.1_29];
_65 = MEM[(const double *)u_4(D) + 24B];
vectp.4_22 = v_7(D);
vect__28.5_17 = MEM[(const double *)vectp.4_22];
_67 = MEM[(const double *)v_7(D) + 24B];
vectp.7_64 = w_10(D);
vect__30.8_66 = MEM[(const double *)vectp.7_64];
_69 = MEM[(const double *)w_10(D) + 24B];
_68 = {_26, _39, _52, _65};
vect_cst__15 = _68;
vect__31.9_25 = vect__26.2_27 * vect__28.5_17 + vect_cst__15;
[Bug libstdc++/87044] stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044 --- Comment #1 from Jonathan Wakely --- This is correct: custom reference types are not supported at all, and never will be. And that's not a bug. The container requirements in the standard require X::reference to be X::value_type&, and the allocator requirements do not have any reference/const_reference member types at all.
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 21 16:17:35 2018 New Revision: 263743 URL: https://gcc.gnu.org/viewcvs?rev=263743&root=gcc&view=rev Log: x86: Always update EH return address in word_mode On x86, return address is always popped in word_mode. eh_return needs to put EH return address in word_mode on stack. gcc/ Backport from mainline PR target/87014 * config/i386/i386.md (eh_return): Always update EH return address in word_mode. gcc/testsuite/ Backport from mainline PR target/87014 * g++.dg/torture/pr87014.C: New file. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/torture/pr87014.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/config/i386/i386.md branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug libstdc++/87044] stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Jonathan Wakely --- The address() member was removed from the allocator requirements for C++11, so it's wrong to expect it to be used. https://en.cppreference.com/w/cpp/named_req/Allocator#Requirements
[Bug libstdc++/87044] stl_construct.h not interoperable with allocators with custom reference types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87044 --- Comment #3 from Jonathan Wakely --- See also https://cplusplus.github.io/LWG/lwg-closed.html#1318 which requested that custom references be put back, and was closed as Not A Defect.
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #9 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 21 16:27:22 2018 New Revision: 263744 URL: https://gcc.gnu.org/viewcvs?rev=263744&root=gcc&view=rev Log: x86: Always update EH return address in word_mode On x86, return address is always popped in word_mode. eh_return needs to put EH return address in word_mode on stack. gcc/ Backport from mainline PR target/87014 * config/i386/i386.md (eh_return): Always update EH return address in word_mode. gcc/testsuite/ Backport from mainline PR target/87014 * g++.dg/torture/pr87014.C: New file. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/torture/pr87014.C Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/config/i386/i386.md branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 --- Comment #10 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Aug 21 16:38:17 2018 New Revision: 263745 URL: https://gcc.gnu.org/viewcvs?rev=263745&root=gcc&view=rev Log: x86: Always update EH return address in word_mode On x86, return address is always popped in word_mode. eh_return needs to put EH return address in word_mode on stack. gcc/ Backport from mainline PR target/87014 * config/i386/i386.md (eh_return): Always update EH return address in word_mode. gcc/testsuite/ Backport from mainline PR target/87014 * g++.dg/torture/pr87014.C: New file. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/torture/pr87014.C Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/i386/i386.md branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug target/87014] [x32] __builtin_eh_return should use 64-bit mov to set return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87014 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|unknown |9.0 Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #11 from H.J. Lu --- Fixed for GCC 9 and on GCC 6/7/8 branches.
[Bug middle-end/87047] New: gcc 7 & 8 - performance regression because of if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87047
Bug ID: 87047
Summary: gcc 7 & 8 - performance regression because of
if-conversion
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: already5chosen at yahoo dot com
Target Milestone: ---
Created attachment 44570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44570&action=edit
demonstrate performance regression because of if-conversion
Very significant performance regression from gcc 6.x to 7.x and 8.x cause by
if-conversion of predictable branch.
Compilation flags: -O2 -Wall
Target: x86-64 (my test machine is IvyBridge)
It is possible that the problem is specific to x86-64 target. I tested (by
observing compiler output) aarch64 target and it looks o.k.
The problem occurs here:
if ((i & 15)==0) {
const uint64_t PROD_ONE = (uint64_t)(1) << 19;
uint64_t prod = umulh(invRange, range);
invRange = umulh(invRange, (PROD_ONE*2-1-prod)<<44)<<1;
}
The condition has low probability and is easily predicted by branch predictor,
while code within if has relatively high latency.
gcc, starting from gcc.7.x and up to the latest, is convinced that always
executing the inner part of the if is a bright idea. Measurements, on my
real-world code, do not agree and show 30% slowdown. I'm sure that on
artificial sequences I can demonstrate a slowdown of 100% and more.
What is special about this case is that compiler is VERY confident in its
stupid decision. It does not change its mind even when I replace
if ((i & 15)==0) {
by
if (__builtin_expect((i & 15)==0, 0)) {
I found only two ways of forcing sane code generation:
1. -fno-if-conversion
2.
if ((i & 15)==0) {
asm volatile("");
...
}
[Bug c++/86499] lambda-expressions with capture-default are allowed at namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86499 --- Comment #2 from Marek Polacek --- Author: mpolacek Date: Tue Aug 21 18:37:23 2018 New Revision: 263749 URL: https://gcc.gnu.org/viewcvs?rev=263749&root=gcc&view=rev Log: PR c++/86499 * parser.c (cp_parser_lambda_introducer): Give error if a non-local lambda has a capture-default. * g++.dg/cpp0x/lambda/lambda-non-local.C: New test. * g++.dg/cpp0x/lambda/lambda-this10.C: Adjust dg-error. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-non-local.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this10.C
[Bug c++/86499] lambda-expressions with capture-default are allowed at namespace scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86499 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug fortran/25829] [F03] Asynchronous IO support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #55 from Nicolas Koenig --- Author: koenigni Date: Tue Aug 21 18:48:59 2018 New Revision: 263750 URL: https://gcc.gnu.org/viewcvs?rev=263750&root=gcc&view=rev Log: 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * gfortran.texi: Add description of asynchronous I/O. * trans-decl.c (gfc_finish_var_decl): Treat asynchronous variables as volatile. * trans-io.c (gfc_build_io_library_fndecls): Rename st_wait to st_wait_async and change argument spec from ".X" to ".w". (gfc_trans_wait): Pass ID argument via reference. 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * gfortran.dg/f2003_inquire_1.f03: Add write statement. * gfortran.dg/f2003_io_1.f03: Add wait statement. 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * Makefile.am: Add async.c to gfor_io_src. Add async.h to gfor_io_headers. * Makefile.in: Regenerated. * gfortran.map: Add _gfortran_st_wait_async. * io/async.c: New file. * io/async.h: New file. * io/close.c: Include async.h. (st_close): Call async_wait for an asynchronous unit. * io/file_pos.c (st_backspace): Likewise. (st_endfile): Likewise. (st_rewind): Likewise. (st_flush): Likewise. * io/inquire.c: Add handling for asynchronous PENDING and ID arguments. * io/io.h (st_parameter_dt): Add async bit. (st_parameter_wait): Correct. (gfc_unit): Add au pointer. (st_wait_async): Add prototype. (transfer_array_inner): Likewise. (st_write_done_worker): Likewise. * io/open.c: Include async.h. (new_unit): Initialize asynchronous unit. * io/transfer.c (async_opt): New struct. (wrap_scalar_transfer): New function. (transfer_integer): Call wrap_scalar_transfer to do the work. (transfer_real): Likewise. (transfer_real_write): Likewise. (transfer_character): Likewise. (transfer_character_wide): Likewise. (transfer_complex): Likewise. (transfer_array_inner): New function. (transfer_array): Call transfer_array_inner. (transfer_derived): Call wrap_scalar_transfer. (data_transfer_init): Check for asynchronous I/O. Perform a wait operation on any pending asynchronous I/O if the data transfer is synchronous. Copy PDT and enqueue thread for data transfer. (st_read_done_worker): New function. (st_read_done): Enqueue transfer or call st_read_done_worker. (st_write_done_worker): New function. (st_write_done): Enqueue transfer or call st_read_done_worker. (st_wait): Document as no-op for compatibility reasons. (st_wait_async): New function. * io/unit.c (insert_unit): Use macros LOCK, UNLOCK and TRYLOCK; add NOTE where necessary. (get_gfc_unit): Likewise. (init_units): Likewise. (close_unit_1): Likewise. Call async_close if asynchronous. (close_unit): Use macros LOCK and UNLOCK. (finish_last_advance_record): Likewise. (newunit_alloc): Likewise. * io/unix.c (find_file): Likewise. (flush_all_units_1): Likewise. (flush_all_units): Likewise. * libgfortran.h (generate_error_common): Add prototype. * runtime/error.c: Include io.h and async.h. (generate_error_common): New function. 2018-08-21 Nicolas Koenig Thomas Koenig PR fortran/25829 * testsuite/libgomp.fortran/async_io_1.f90: New test. * testsuite/libgomp.fortran/async_io_2.f90: New test. * testsuite/libgomp.fortran/async_io_3.f90: New test. * testsuite/libgomp.fortran/async_io_4.f90: New test. * testsuite/libgomp.fortran/async_io_5.f90: New test. * testsuite/libgomp.fortran/async_io_6.f90: New test. * testsuite/libgomp.fortran/async_io_7.f90: New test. Added: trunk/libgfortran/io/async.c trunk/libgfortran/io/async.h trunk/libgomp/testsuite/libgomp.fortran/async_io_1.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_2.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_3.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_4.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_5.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_6.f90 trunk/libgomp/testsuite/libgomp.fortran/async_io_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2003_inquire_1.f03 trunk/gcc/testsuite/gfortran.dg/f2003_io_1.f03 trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/gf
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #1 from Marc Glisse ---
struct A { double a, b; };
struct B : A {};
templatevoid cp(T&a,T const&b){a=b;}
double f(B x){
B y; cp(y,x);
B z; cp(z,x);
return y.a - z.a;
}
This is not quite equivalent because RTL manages to optimize this case, but
gimple, with -Ofast, still gets the ugly:
ISRA.1 = MEM[(const struct A &)&x];
SR.9_9 = MEM[(struct A *)&ISRA.1];
ISRA.1 = MEM[(const struct A &)&x];
SR.8_10 = MEM[(struct A *)&ISRA.1];
_3 = SR.9_9 - SR.8_10;
return _3;
Writing cp instead of cp makes it work, and the main difference starts in
SRA. I expect (didn't check) this is another victim of r255510 .
[Bug libfortran/87048] New: [9 Regression] array_constructor_8.f90 failure on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87048 Bug ID: 87048 Summary: [9 Regression] array_constructor_8.f90 failure on armeb Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- Since r263082, array_constructor_8.f90 fails on armeb. PR 25829 contains debugging info on that, see also https://gcc.gnu.org/ml/fortran/2018-08/msg00010.html and the following discussion.
[Bug libfortran/87048] [9 Regression] array_constructor_8.f90 failure on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87048 Thomas Koenig changed: What|Removed |Added Blocks||25829 Target Milestone|--- |9.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 [Bug 25829] [F03] Asynchronous IO support
[Bug c/87049] New: __clear_cache() prototype confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87049
Bug ID: 87049
Summary: __clear_cache() prototype confusion
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bunk at stusta dot de
Target Milestone: ---
$ cat test.cc
extern "C" void __clear_cache(char *beg, char *end);
$ g++-5 -c test.cc
test.cc:1:51: warning: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
extern "C" void __clear_cache(char *beg, char *end);
^
$ g++-7 -c test.cc
test.cc:1:17: warning: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
[-Wbuiltin-declaration-mismatch]
extern "C" void __clear_cache(char *beg, char *end);
^
$ g++-8 -c test.cc
test.cc:1:17: error: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
[-fpermissive]
extern "C" void __clear_cache(char *beg, char *end);
^
$
The bug is not that g++ became more strict, the bug is that the built-in
declaration differs from the documented declaration.
Relevant part of the gcc sources:
gcc/builtins.def:DEF_EXT_LIB_BUILTIN(BUILT_IN_CLEAR_CACHE, "__clear_cache",
BT_FN_VOID_PTR_PTR, ATTR_NOTHROW_LEAF_LIST)
gcc/doc/extend.texi:@deftypefn {Built-in Function} void __builtin___clear_cache
(char *@var{begin}, char *@var{end})
libgcc/libgcc2.h:extern void __clear_cache (char *, char *);
Doesn't seem to be a new issue:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130513/079828.html
[Bug debug/79342] [6 Regression] ICE in output_index_string, at dwarf2out.c:25635 with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79342 H.J. Lu changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #8 from H.J. Lu --- *** Bug 70578 has been marked as a duplicate of this bug. ***
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 H.J. Lu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 79342 ***
[Bug tree-optimization/87008] [8/9 Regression] gimple mem-to-mem assignment badly optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87008
--- Comment #2 from Marc Glisse ---
Or just:
struct A { double a, b; };
struct B : A {};
double f(B x){
B y;
A*px=&x;
A*py=&y;
*py=*px;
return y.a;
}
MEM[(struct A *)&y] = MEM[(const struct A &)&x];
y_6 = MEM[(struct A *)&y];
y ={v} {CLOBBER};
return y_6;
where y_6 should be read directly from x. SRA doesn't dare touch it. SCCVN does
see that reading from y is equivalent to reading from x, but unless something
else is already reading from x, it keeps the read from y.
