[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Jeffrey A. Law --- Fixed by patches on the trunk.
[Bug c++/79180] New: Nested lambda-capture causes segfault for parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79180
Bug ID: 79180
Summary: Nested lambda-capture causes segfault for parameter
pack
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: markus at dreseler dot de
Target Milestone: ---
Created attachment 40561
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40561&action=edit
Preprocessed file
The following code compiles but prints garbage and then segfaults under gcc
6.3.0 on OS X:
#include
#include
void foo(const std::string &a) {
std::cout << a << std::endl;
}
template
void bar(Args &&... args) {
[&]() {
[&]() {
foo(args...);
}();
}();
}
int main() {
const std::string x("Hello World!");
bar(x);
}
Expected result: Print "Hello World!" and exit.
Compiling with `-Wextra -Wall` gives this warning:
param.cpp: In function 'int main()':
param.cpp:11:11: warning: 'args#0' is used uninitialized in this
function [-Wuninitialized]
foo(args...);
^~~
param.cpp:16:5: note: 'args#0' was declared here
int main() {
^~~~
Clang and VC++ do not have any issues here. People at StackOverflow seem to
agree that this is valid code and appears to be a bug in GCC:
http://stackoverflow.com/questions/41769851/gcc-causes-segfault-for-lambda-captured-parameter-pack
Additional information:
[:~/tmp] 1 $ g++-6 param.cpp && ./a.out
# Garbage here
Segmentation fault: 11
[:~/tmp] 139 $ g++-6 -v
Using built-in specs.
COLLECT_GCC=g++-6
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/6.3.0_1/libexec/gcc/x86_64-apple-darwin16.3.0/6.3.0/lto-wrapper
Target: x86_64-apple-darwin16.3.0
Configured with: ../configure --build=x86_64-apple-darwin16.3.0
--prefix=/usr/local/Cellar/gcc/6.3.0_1
--libdir=/usr/local/Cellar/gcc/6.3.0_1/lib/gcc/6
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-6
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew GCC 6.3.0_1'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-plugin
--disable-nls --enable-multilib
Thread model: posix
gcc version 6.3.0 (Homebrew GCC 6.3.0_1)
[:~/tmp] 1 $ sw_vers
ProductName:Mac OS X
ProductVersion: 10.12.2
BuildVersion: 16C67
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095 --- Comment #4 from Jeffrey A. Law --- So the simplified tests are interesting, but ultimately too simplified. The VRP prototype which works on the simplified testcases doesn't work on the real testcase for this BZ. The key sequences look like: _13 = (long unsigned int) _12; _121 = ADD_OVERFLOW (_13, 18446744073709551615); _1 = REALPART_EXPR <_121>; _39 = IMAGPART_EXPR <_121>; if (_1 > _13) goto ; [29.56%] else goto ; [70.44%] Which defeat the simplistic prototype for VRP. It's essentially still the same construct, but we'd have to extract stuff out of the COMPLEX_EXPR and recognize the ADD_OVERFLOW.
[Bug c++/79180] Nested lambda-capture causes segfault for parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79180
--- Comment #1 from Markus Dreseler ---
P.S.: Also experienced on Wandbox's GCC 7.0.1 HEAD.
Not passing the parameter pack into bar by universal reference causes an
internal compiler error in gcc 7.0.1 HEAD:
prog.cc: In function 'void bar(Args ...) [with Args =
{std::__cxx11::basic_string, std::allocator
>}]':
prog.cc:14:4: internal compiler error: in make_decl_rtl, at
varasm.c:1304
[&]() {
~~~
[&]() {
~~~
foo(args...);
~
}();
}();
~^~
http://melpon.org/wandbox/permlink/mYtVweIn8zv4t74Y
Thanks to AMA at StackOverflow for finding this.
[Bug lto/79181] New: Not deleting /tmp/cc*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79181 Bug ID: 79181 Summary: Not deleting /tmp/cc* Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: dilyan.palauzov at aegee dot org Target Milestone: --- When the linking process is interrupted, some files of the form /tmp/cc?? or /tmp/cc??.ltrans?.o are left. These files shall be deleted when the linker terminates, even if it has been interrupted.
[Bug c++/79176] [6/7 Regression] ICE in mangle_decl with LTO and Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79176
Markus Trippelsdorf changed:
What|Removed |Added
Keywords||lto
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-01-22
CC||hubicka at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Summary|ICE in mangle_decl with LTO |[6/7 Regression] ICE in
|and Os |mangle_decl with LTO and Os
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf ---
Assert was added in r223633.
markus@x4 tmp % cat tileui.ii
struct A {};
struct Object {
virtual bool m_fn1();
virtual ~Object();
};
struct Item : Object, virtual A {
~Item() {
[] {};
}
bool m_fn1();
};
bool Item::m_fn1() {}
markus@x4 tmp % g++ tileui.ii -flto -Os -r -nostdlib
tileui.ii:8:6: internal compiler error: in mangle_decl, at cp/mangle.c:3845
[] {};
^
0x8060e2 mangle_decl(tree_node*)
/home/markus/gcc/gcc/cp/mangle.c:3844
0x1030c26 decl_assembler_name(tree_node*)
/home/markus/gcc/gcc/tree.c:671
0x10571ee assign_assembler_name_if_neeeded(tree_node*)
/home/markus/gcc/gcc/tree.c:5923
0x10596b9 free_lang_data_in_cgraph
/home/markus/gcc/gcc/tree.c:5972
0x10596b9 free_lang_data
/home/markus/gcc/gcc/tree.c:6009
0x10596b9 execute
/home/markus/gcc/gcc/tree.c:6058
Please submit a full bug repor
[Bug target/79177] use the register keyword with ymm0 register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79177 Alexander Kjäll changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Alexander Kjäll --- Thanks for the pointer to the -mavx2 flag, I didn't realize those registers needed a compiler flag.
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095 --- Comment #5 from Marc Glisse --- (In reply to Jeffrey A. Law from comment #4) > So the simplified tests are interesting, but ultimately too simplified. The > VRP prototype which works on the simplified testcases doesn't work on the > real testcase for this BZ. > > The key sequences look like: > > _13 = (long unsigned int) _12; > _121 = ADD_OVERFLOW (_13, 18446744073709551615); > _1 = REALPART_EXPR <_121>; > _39 = IMAGPART_EXPR <_121>; > if (_1 > _13) > goto ; [29.56%] > else > goto ; [70.44%] > > > Which defeat the simplistic prototype for VRP. It's essentially still the > same construct, but we'd have to extract stuff out of the COMPLEX_EXPR and > recognize the ADD_OVERFLOW. I thought ADD_OVERFLOW would appear in the widening_mul pass, i.e. after all the VRP passes are done? On the other hand, teaching VRP about *_OVERFLOW sounds like a good idea.
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #6 from Jakub Jelinek ---
(In reply to Marc Glisse from comment #5)
> I thought ADD_OVERFLOW would appear in the widening_mul pass, i.e. after all
> the VRP passes are done? On the other hand, teaching VRP about *_OVERFLOW
> sounds like a good idea.
VRP already handles that, see /* Handle extraction of the two results (result
of arithmetics and
a flag whether arithmetics overflowed) from {ADD,SUB,MUL}_OVERFLOW
internal function. */
else if (is_gimple_assign (stmt)
&& (gimple_assign_rhs_code (stmt) == REALPART_EXPR
|| gimple_assign_rhs_code (stmt) == IMAGPART_EXPR)
&& INTEGRAL_TYPE_P (type))
guarded block in extract_range_basic and
if (is_gimple_call (stmt) && gimple_call_internal_p (stmt))
switch (gimple_call_internal_fn (stmt))
{
in vrp_visit_stmt.
IFN_*_OVERFLOW can appear already during gimplification if
__builtin_*_overflow{,_p} is used in the source.
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #7 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #6)
> VRP already handles that,
Nice :-) Thanks and sorry for not checking myself.
> IFN_*_OVERFLOW can appear already during gimplification if
> __builtin_*_overflow{,_p} is used in the source.
Yes, I meant that in the original testcase of this PR, widening_mul is the
first dump that contains OVERFLOW. Otherwise, indeed the builtins, and match.pd
seems to have one transform that can produce IFN_MUL_OVERFLOW.
[Bug fortran/79182] New: when use openmp and link static libgfortran,open function cause SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79182 Bug ID: 79182 Summary: when use openmp and link static libgfortran,open function cause SIGSEGV Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hwliu11 at hotmail dot com Target Milestone: --- Test File program savedata implicit none integer ncpu,thread_num integer OMP_GET_NUM_THREADS external OMP_SET_NUM_THREADS_8_ external OMP_GET_NUM_THREADS open(50,file='/home/test',status='old',form='formatted',err=999) write(*,*) "finish" 999 write(*,*) "open error" ncpu=4 call OMP_SET_NUM_THREADS_8_(ncpu) !$omp parallel !$omp& shared (ncpu) !$omp single thread_num=OMP_GET_NUM_THREADS() write(*,*) "thread num ", thread_num !$omp end single !$omp end parallel end program savedata c -Wall -fopenmp -fbackslash -g -fcray-pointer -fno-sign-zero -fno-underscoring -Wline-truncation -fbacktrace -ffpe-summary=none link options -fopenmp -static-libgfortran -static -static-libgcc runtime error Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x4039DE in _gfortrani_backtrace #1 0x403340 in _gfortrani_backtrace_handler #2 0x43F0BF in __nptl_death_event
[Bug fortran/79182] when use openmp and link static libgfortran,open function cause SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79182 --- Comment #1 from hwliu11 at hotmail dot com --- My platform Unbuntu 16.06 LTS 64Bit
[Bug libstdc++/78420] std::less is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Ville Voutilainen changed: What|Removed |Added CC||ville.voutilainen at gmail dot com --- Comment #9 from Ville Voutilainen --- Patch available: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01688.html
[Bug libstdc++/61580] stoi function unknown on W7/Cygwin/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61580 Jonathan Wakely changed: What|Removed |Added CC||keith.marshall at mailinator dot c ||om --- Comment #6 from Jonathan Wakely --- *** Bug 79178 has been marked as a duplicate of this bug. ***
[Bug libstdc++/79178] Configuration tests for ISO-C99 support use invalid standards compliance specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79178 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |6.0 --- Comment #1 from Jonathan Wakely --- The whole point of the test is to see if those functions are available in C++98 mode. On some targets they are, and so the macro gets set. Using -std=c++11 for the configure tests would completely break things, because we would detect the functions are available, and then when someone compiles with -std=c++98 the functions would be missing and it would fail to compile. At least what happens today is some features are just not supported on MinGW, rather than -std=c++98 being completely unusable. If you look at GCC 6 you'll see separate tests for those functions using -std=c++98 and -std=c++11, defining separate macros _GLIBCXX98_USE_C99_STDLIB and _GLIBCXX11_USE_C99_STDLIB indicating whether the functions are available always, or only for C++11 and higher. So the solution for MinGW would be to use a newer GCC that already works much better for MinGW (and Cygwin too). *** This bug has been marked as a duplicate of bug 61580 ***
[Bug libstdc++/78420] std::less is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 Ville Voutilainen changed: What|Removed |Added Known to work||4.5.4 Known to fail||4.6.4, 4.7.3, 4.8.5, 4.9.3, ||5.3.0, 6.1.0, 7.0 --- Comment #10 from Ville Voutilainen --- Oh well, the patch is using a reinterpret_cast, and I can't fathom how to work around that problem without compiler help. This problem has been with us since 4.6, so I don't think we should fix it for 7 in its stage4.
[Bug translation/79183] New: Hard coded plurals in gimple-ssa-sprintf.c:2050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
Bug ID: 79183
Summary: Hard coded plurals in gimple-ssa-sprintf.c:2050
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
Assignee: unassigned at gcc dot gnu.org
Reporter: fmarchal at perso dot be
Target Milestone: ---
gimple-ssa-sprintf.c contains two hard coded plurals starting from line 2050:
const char* fmtstr
= (info.bounded
? (1 < fmtres.range.min
? G_("%<%.*s%> directive output truncated while writing "
"%wu bytes into a region of size %wu")
: G_("%<%.*s%> directive output truncated while writing "
"%wu byte into a region of size %wu"))
: (1 < fmtres.range.min
? G_("%<%.*s%> directive writing %wu bytes "
"into a region of size %wu")
: G_("%<%.*s%> directive writing %wu byte "
"into a region of size %wu")));
Beside, the plural rules are wrong for English. Plural should be used if
fmtres.range.min is zero.
[Bug c++/79184] New: -Wint-in-bool-context triggered erroneously in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79184
Bug ID: 79184
Summary: -Wint-in-bool-context triggered erroneously in
template parameter
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jagerman at jagerman dot com
Target Milestone: ---
When compiling the following with -Wint-in-bool-context under a recent snapshot
of g++-7:
template void f(int) {}
template void f() {}
int main() {
f<1*1>();
}
`g++ -Wint-in-bool-context t.cpp' produces the warning:
t.cpp: In function 'int main()':
t.cpp:5:8: warning: '*' in boolean context, suggest '&&' instead
[-Wint-in-bool-context]
f<1*1>();
~^~
But this is wrong: the template parameter here is int, not a bool, and is not
in bool context. The existence of the templated overload, despite not being
called in this context, appears to be falsely triggering the warning.
[Bug translation/79183] Hard coded plurals in gimple-ssa-sprintf.c:2050
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79183
--- Comment #1 from Frederic Marchal ---
Yet another hard coded plural in the same file at line 2286:
inform (callloc,
(nbytes + exact == 1
? G_("format output %wu byte into a destination of size %wu")
: G_("format output %wu bytes into a destination of size %wu")),
nbytes + exact, info.objsize);
[Bug c/79185] New: Possible regression in gcc 4.9 and later with the addition of two 128 bit ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185
Bug ID: 79185
Summary: Possible regression in gcc 4.9 and later with the
addition of two 128 bit ints
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: drraph at gmail dot com
Target Milestone: ---
Consider this code:
__int128_t ai (__int128_t x, __int128_t y) {
return x + y;
}
In gcc 4.8.5, clang and icc using -O2 this gives code that is more or less
exactly:
ai:
mov rax, rdx
mov rdx, rcx
add rax, rdi
adc rdx, rsi
ret
However in gcc 4.9 and later you get
ai:
mov r9, rdi
mov r10, rsi
add r9, rdx
adc r10, rcx
mov rax, r9
mov rdx, r10
ret
Interestingly, that is also the code you get in gcc 4.8.5 if you use -O instead
of -O2.
Is this addition of two extra mov's a regression?
[Bug c++/66836] inconsistent unqualified lookup for friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66836 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Well "friend void f();" can't match Outer::f because you can't declare a member function like that except in the class' own scope. What GCC and Clang do is what the standard intended to say but fails to say clearly, which is Core issue 138 https://wg21.link/cwg138
[Bug c++/66836] inconsistent unqualified lookup for friend declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66836
--- Comment #2 from Jonathan Wakely ---
To clarify what I mean, consider:
struct X {
void f();
void g() {
void f();
f();
}
};
The declaration of void f() inside X::g doesn't refer to X::f, because it
declares a (non-member) function called f. And so does "friend void f();"
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #8 from Martin Sebor ---
(In reply to Jeffrey A. Law from comment #4)
> So the simplified tests are interesting, but ultimately too simplified.
You're right, the test case in comment #2 is oversimplified. The one in the
thread on gcc-patches should be closer (it includes the ADD_OVERFLOW):
$ cat t.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.C
typedef __SIZE_TYPE__ size_t;
struct S {
int *p0, *p1, *p2;
size_t size () const { return p1 - p0; }
void f (size_t n) {
if (n > size ()) // can't happen because
foo (n - size ()); // n is in [1, MIN(size() - 1, 3)]
else if (n < size ())
bar (p0 + n);
}
void foo (size_t n)
{
size_t left = (size_t)(p2 - p1);
if (left >= n)
__builtin_memset (p2, 0, n * sizeof *p2);
}
void bar (int*);
};
void f (S &s)
{
size_t n = s.size ();
if (n > 1 && n < 5)
s.f (n - 1);
}
;; Function void f(S&) (_Z1fR1S, funcdef_no=3, decl_uid=2296, cgraph_uid=3,
symbol_order=3)
Removing basic block 9
Removing basic block 10
Removing basic block 11
void f(S&) (struct S & s)
{
long unsigned int _1;
long unsigned int _2;
int * _7;
int * _8;
long int _9;
long int _10;
long int _11;
long int _12;
long unsigned int _13;
long unsigned int _17;
int * _22;
long int _23;
long int _24;
__complex__ long unsigned int _25;
long unsigned int _28;
int * _29;
[100.00%]:
_7 = MEM[(int * *)s_5(D)];
_8 = MEM[(int * *)s_5(D) + 8B];
_9 = (long int) _8;
_10 = (long int) _7;
_11 = _9 - _10;
_12 = _11 /[ex] 4;
_13 = (long unsigned int) _12;
_1 = _13 + 18446744073709551614;
if (_1 <= 2)
goto ; [36.64%]
else
goto ; [63.36%]
[36.64%]:
_25 = ADD_OVERFLOW (_13, 18446744073709551615);
_2 = REALPART_EXPR <_25>;
_17 = IMAGPART_EXPR <_25>;
if (_2 > _13)
goto ; [50.00%]
else
goto ; [50.00%]
[18.32%]:
_22 = MEM[(int * *)s_5(D) + 16B];
_23 = (long int) _22;
_24 = _23 - _9;
if (_24 == -4)
goto ; [33.00%]
else
goto ; [67.00%]
[6.05%]:
__builtin_memset (_22, 0, 18446744073709551612); [tail call]
goto ; [100.00%]
[18.32%]:
if (_17 != 0)
goto ; [36.64%]
else
goto ; [63.36%]
[6.71%]:
_28 = _2 * 4;
_29 = _7 + _28;
S::bar (s_5(D), _29); [tail call]
[100.00%]:
return;
}
In function ‘void S::foo(size_t)’,
inlined from ‘void S::f(size_t)’ at t.C:10:24,
inlined from ‘void f(S&)’ at t.C:29:16:
t.C:19:47: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’:
specified size 18446744073709551612 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
__builtin_memset (p2, 0, n * sizeof *p2);
^
[Bug middle-end/77622] __builtin_object_size incorrect for an out-of-bounds pointer prior to destination object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77622 Yuri Gribov changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||tetra2005 at gmail dot com --- Comment #1 from Yuri Gribov --- Sounds like an important use-case. I did some basic debugging and it turns out that "&d[3] - 10" is represented as POINTER_PLUS_EXPR with (size_t)-10 offset. For some reason tree-object-size.c deliberately skips POINTER_PLUS_EXPRs with offset > offset_limit where offset_limit is (size_t)-1 / 2 so negative offsets are effectively ignored. Added Jakub to maybe comment on this behavior as that's his code.
[Bug libstdc++/78905] Add a macro to determine that the library is implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78905 Eric Gallager changed: What|Removed |Added CC||egall at gwmail dot gwu.edu --- Comment #10 from Eric Gallager --- (In reply to Jonathan Wakely from comment #8) > (In reply to Matt Clarkson from comment #2) > > Because wehen I compile with clang against the libstdc++ the problem will > > still occur and __GNUC__ will not be defined. > > N.B. Clang does define __GNUC__ but it always defines it to 4 (and defines > __GNUC_MINOR__ to 1 and __GNUC_PATCHLEVEL__ to 2, because it identifies as > GCC 4.1.2, the last release Apple shipped for their OS). __GNUC_MINOR__ and __GNUC_PATCHLEVEL__ values are swapped with each other there; last release Apple shipped for their OS was 4.2.1, not 4.1.2
[Bug fortran/68933] ICE when mixing "-fprofile-arcs -ftest-coverage" and "-fcoarray=lib" on gcc-6 only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933 --- Comment #4 from Zaak --- Fabulous, I'll verify soon (for my own satisfaction) On Sun, Jan 22, 2017 at 12:31 PM vehre at gcc dot gnu.org < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68933 > > vehre at gcc dot gnu.org changed: > >What|Removed |Added > > > Known to work||7.0 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug target/79185] [4.9/5/6/7 Regression] register allocation in the addition of two 128 bit ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-22 Known to work||4.8.4 Summary|Possible regression in gcc |[4.9/5/6/7 Regression] |4.9 and later with the |register allocation in the |addition of two 128 bit |addition of two 128 bit |ints|ints Ever confirmed|0 |1 Known to fail||4.9.2, 5.4.0, 6.2.0 --- Comment #1 from Marc Glisse --- Yes, gcc's register allocator tends to be suboptimal near function boundaries (handling the hard registers for input/output) and more attention was paid to optimizing the interior of functions (after sufficient inlining, the rest is usually negligible). There are several related PRs in bugzilla. Still, it would be nice to improve this...
[Bug tree-optimization/79186] New: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault (in VRP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79186
Bug ID: 79186
Summary: ICE on valid code at -O2 and -O3 on x86_64-linux-gnu:
Segmentation fault (in VRP)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It seems to be a recent regression.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170122 (experimental) [trunk revision 244756] (GCC)
$
$ gcc-trunk -Os small.c
$
$ gcc-trunk -O2 small.c
small.c: In function ‘main’:
small.c:4:5: internal compiler error: Segmentation fault
int main ()
^~~~
0xc0cdcf crash_signal
../../gcc-source-trunk/gcc/toplev.c:333
0xc61d17 ssa_default_def(function*, tree_node*)
../../gcc-source-trunk/gcc/tree-dfa.c:305
0xc64400 get_or_create_ssa_default_def(function*, tree_node*)
../../gcc-source-trunk/gcc/tree-dfa.c:362
0xca2dff maybe_replace_use
../../gcc-source-trunk/gcc/tree-into-ssa.c:1771
0xca2dff rewrite_update_stmt
../../gcc-source-trunk/gcc/tree-into-ssa.c:1966
0xca2dff rewrite_update_dom_walker::before_dom_children(basic_block_def*)
../../gcc-source-trunk/gcc/tree-into-ssa.c:2146
0x130db86 dom_walker::walk(basic_block_def*)
../../gcc-source-trunk/gcc/domwalk.c:265
0xc9c099 rewrite_blocks
../../gcc-source-trunk/gcc/tree-into-ssa.c:2210
0xca4544 update_ssa(unsigned int)
../../gcc-source-trunk/gcc/tree-into-ssa.c:3385
0xeb6e55 insert_range_assertions
../../gcc-source-trunk/gcc/tree-vrp.c:6558
0xeb6e55 execute_vrp
../../gcc-source-trunk/gcc/tree-vrp.c:11278
0xeb6e55 execute
../../gcc-source-trunk/gcc/tree-vrp.c:11376
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$
-
int a, b;
unsigned char c, d, e;
int main ()
{
if (b || !a)
{
c = a;
if (!c && !a)
d = 0;
e = -a;
}
return 0;
}
[Bug tree-optimization/79187] New: wrong code at -Os on x86_64-linux-gnu (generated code segfaults)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79187
Bug ID: 79187
Summary: wrong code at -Os on x86_64-linux-gnu (generated code
segfaults)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It seems to be a recent regression.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170122 (experimental) [trunk revision 244756] (GCC)
$
$ gcc-trunk -O1 small.c
$ ./a.out
$
$ gcc-trunk -Os small.c
$ ./a.out
Segmentation fault (core dumped)
$
int printf (const char *, ...);
int a, b = -600, c, d[] = { 0 }, e, f, g = -1, h;
unsigned i = ~0;
int main ()
{
for (; h < 2; h++)
{
if (a > 0)
printf ("%d\n", d[b]);
f = ~(b % i);
c = g | (f && g) && e | b;
a = ~(~g & b);
}
return 0;
}
[Bug fortran/79154] omp declare simd in pure function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sun Jan 22 19:36:57 2017
New Revision: 244763
URL: https://gcc.gnu.org/viewcvs?rev=244763&root=gcc&view=rev
Log:
PR fortran/79154
* parse.c (matchs, matcho, matchds, matchdo): Replace return st;
with { ret = st; goto finish; }.
(decode_omp_directive): Allow declare simd, declare target and
simd directives in PURE/ELEMENTAL procedures. Only call
gfc_unset_implicit_pure on successful match of other procedures.
* gfortran.dg/gomp/pr79154-1.f90: New test.
* gfortran.dg/gomp/pr79154-2.f90: New test.
Added:
trunk/gcc/testsuite/gfortran.dg/gomp/pr79154-1.f90
trunk/gcc/testsuite/gfortran.dg/gomp/pr79154-2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/parse.c
trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/79188] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79188
Bug ID: 79188
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
It appears to be a recent regression.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.1 20170122 (experimental) [trunk revision 244756] (GCC)
$
$ gcc-trunk -O2 small.c
$ ./a.out
$
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$
int a, b, c, d, e, f, h, j, k;
static void fn1 ()
{
int g = 1, i;
if (!f)
{
for (; d < 1; d++)
for (i = 0, j = 1; i < 1; i = j)
a = 2;
for (; e < 1; e++)
{
for (; k; k++)
L:
;
for (c = 0; c < 2; c++)
{
for (i = 0; i < 4; i++)
{
for (; h; h++)
g = 0;
b = 0;
}
if (b)
goto L;
}
a = 0;
}
if (g < 0)
goto L;
}
}
int main ()
{
fn1 ();
if (a != 0)
__builtin_abort ();
return 0;
}
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095 --- Comment #9 from Jeffrey A. Law --- Sigh. I was looking at the wrong dump. We don't need to deal with ADD_OVERFLOW. Looking at the real test for this BZ, the guarding block has the right form: [100.00%]: _7 = MEM[(unsigned int * *)&v]; _8 = MEM[(unsigned int * *)&v + 8B]; _9 = (long int) _8; _10 = (long int) _7; _11 = _9 - _10; _12 = _11 /[ex] 4; _13 = (long unsigned int) _12; _1 = _13 + 18446744073709551615; if (_1 > _13) goto ; [29.56%] else goto ; [70.44%] We can easily see the condition can be rewritten as (_13 == 0) The problem is we don't have enough information about _13 to evaluate that at compile time so my VRP hack doesn't optimize it in vrp_evaluate_conditional. But I would probably claim that simplification from a 2-operand relational to a zero/not-zero test is in and of itself a good thing irrespective of the single_use issues and thus we should go ahead and turn it into an equality test. If I manually transform that test, 2 of the 3 warnings go away. While looking through the dumps I saw another conditional that has the form above, *but* it's obfuscated by ASSERT_EXPRs. I believe if we transform that one as well, there's a good chance the last warning will be eliminated. So when I look at the whole, I think there's really two changes that need to be made. First, a special cased match.pd pattern to detect these overflow tests that collapse into a zero/not-zero comparison and apply them regardless of the single_use property. That should detect both cases in the original testcase and hopefully remove all 3 of the warnings. Second, vrp_evaluate_conditional ought detect when there's a more general simplified form (which wasn't simplified due to the single_use property) and use that simplified form when trying to determine if a conditional is compile-time determinable. I've got a prototype for this. THe question is whether or not it applies often enough to matter in practice. I'll have to do more instrumentation.
[Bug c++/79189] New: Poor code generation when using stateless lambda instead of normal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79189
Bug ID: 79189
Summary: Poor code generation when using stateless lambda
instead of normal function
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldionne.2 at gmail dot com
Target Milestone: ---
When doing an indirect call (through a function pointer), GCC generates
different code depending on whether the function pointer was obtained by
converting a stateless lambda or a normal function. The code generated for a
normal function is vastly superior, and in fact the call can sometimes be
elided.
Code:
#if 1
template
static auto const increment = [](void* self) { ++*static_cast(self); };
#else
template
void increment(void* self) { ++*static_cast(self); }
#endif
struct VTable { void (*increment)(void*); };
template static VTable const vtable{increment};
struct any_iterator {
template
explicit any_iterator(Iterator it)
: vptr_{&vtable}, self_{new Iterator(it)}
{ }
VTable const* vptr_;
void* self_;
};
int main() {
int input[100] = {0};
any_iterator first{&input[0]};
first.vptr_->increment(first.self_);
}
Codegen with the lambda:
increment::{lambda(void*)#1}::_FUN(void*):
add QWORD PTR [rdi], 4
ret
main:
sub rsp, 408
xor eax, eax
mov ecx, 50
mov rdi, rsp
rep stosq
mov edi, 8
calloperator new(unsigned long)
mov QWORD PTR [rax], rsp
mov rdi, rax
call[QWORD PTR vtable[rip]]
xor eax, eax
add rsp, 408
ret
_GLOBAL__sub_I_main:
mov QWORD PTR vtable[rip], OFFSET
FLAT:increment::{lambda(void*)#1}::_FUN(void*)
ret
Codegen with the function:
main:
sub rsp, 8
mov edi, 8
calloperator new(unsigned long)
xor eax, eax
add rsp, 8
ret
Note that Clang (trunk) makes a much better job at optimizing this. Also see
[1] for this example on compiler explorer. See [2] for a larger example that
exhibits the same behavior, and where this results in a ~10x speed difference
because the call is done in a loop.
[1]: https://godbolt.org/g/HQb5Y5
[2]: http://melpon.org/wandbox/permlink/Gs3njR3STPLk2Ecr
[Bug rtl-optimization/79149] bad optimization on MIPS and ARM leading to excessive stack usage in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79149 --- Comment #10 from Arnd Bergmann --- (In reply to Arnd Bergmann from comment #9) > "-fsched-pressure" on mips64 helps a lot > ... > On arm and aarch64, "-fsched-pressure" has no effect I realized later that on arm and aarch64, -fsched-pressure is enabled by default. Disabling it on these two makes it as bad as mips64, which has it disabled by default.
[Bug fortran/79154] omp declare simd in pure function?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79154 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|5.4.0 |7.0 Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed. Not a bug in 6.x and earlier, as those only support OpenMP 4.0 and using any OpenMP directives in PURE/ELEMENTAL is invalid there.
[Bug tree-optimization/79188] [7 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79188 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-22 CC||jakub at gcc dot gnu.org, ||law at gcc dot gnu.org Version|unknown |7.0 Target Milestone|--- |7.0 Summary|wrong code at -O3 on|[7 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r244045.
[Bug target/79185] [5/6/7 Regression] register allocation in the addition of two 128 bit ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Target Milestone|--- |5.5 Summary|[4.9/5/6/7 Regression] |[5/6/7 Regression] register |register allocation in the |allocation in the addition |addition of two 128 bit |of two 128 bit ints |ints| --- Comment #2 from Jakub Jelinek --- Regressed with r204212.
[Bug c++/79184] [7 Regression] -Wint-in-bool-context triggered erroneously in template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79184 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-22 CC||jakub at gcc dot gnu.org, ||nathan at gcc dot gnu.org Target Milestone|--- |7.0 Summary|-Wint-in-bool-context |[7 Regression] |triggered erroneously in|-Wint-in-bool-context |template parameter |triggered erroneously in ||template parameter Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r244101.
[Bug c++/79189] Poor code generation when using stateless lambda instead of normal function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79189 Marc Glisse changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Marc Glisse --- The optimizer has trouble seeing through the dynamic initialization of vtable. Interestingly, compiling with -std=gnu++17 lets the optimizers do their job (constexpr lambda conversion to a pointer?). But it still points at a missing optimization.
[Bug libstdc++/79190] New: [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190 Bug ID: 79190 Summary: [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc" Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: jwakely.gcc at gmail dot com Target Milestone: --- Host: hppa*-*-hpux11.00 Target: hppa*-*-hpux11.00 Build: hppa*-*-hpux11.00 HP-UX 11.00 lacks aligned_alloc, posix_memalign, memalign and _aligned_malloc. This results in aligned_alloc being used as default. As a results, we have hundreds of g++ and libstdc++ testsuite fails. For example, spawn -ignore SIGHUP /home/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++ -B/home/gnu/gcc/objdir/gcc/testsuite/g++/../../ cp_compat_main_tst.o cp_compat_x_tst.o cp_compat_y_tst.o -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc+ + -I/xxx/gnu/gcc/objdir/hppa64-hp-hpux11.00/libstdc++-v3/include/hppa64-hp-hpux11.00 -I/xxx/gnu/gcc/objdir/hppa64-hp-hpux11.00/libstdc++-v3/include -I/xxx/gnu/gcc/gcc/libstdc++-v3/libsupc++ -I/xxx/gnu/gcc/gcc/libstdc++-v3/include/backward - I/xxx/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -w -ansi -pedantic-errors -funsigned-bitfields -L/home/gnu/gcc/objdir/hppa64-hp-hpux11.00/./libstdc++-v3/src/.libs -B/home/gnu/gcc/objdir/hppa64-hp-hpux11.00/./libstdc++-v3/src/.libs -L/home/gnu/gcc/objdir/hppa64-hp-hpux11.00/./libstdc++-v3/src/.libs -lm -o g++-dg-compat-abi-bitfield1-01.exeld: (Warning) Unsatisfied symbol "aligned_alloc" in file /home/gnu/gcc/objdir/hppa64-hp-hpux11.00/./libstdc++-v3/src/.libs/libstdc++.sl1 warnings.output is:ld: (Warning) Unsatisfied symbol "aligned_alloc" in file /home/gnu/gcc/objdir/hp pa64-hp-hpux11.00/./libstdc++-v3/src/.libs/libstdc++.sl1 warnings. FAIL: g++.dg/compat/abi/bitfield1 cp_compat_x_tst.o-cp_compat_y_tst.o link Looking at libstdc++.a, the undefined symbol appears to be in new_opa.o: Symbols from libstdc++.a[new_opa.o]: [Index]Value SizeType Bind O ShndxName [0] | 0| 0|NOTYP|LOCAL|0| UNDEF| [10] | 0| 0|SECT |LOCAL|0|.debug_abbrev| [9] | 0| 0|SECT |LOCAL|0|.debug_info| [8] | 0| 0|SECT |LOCAL|0|.eh_frame| [7] | 0| 0|SECT |LOCAL|0|.debug_frame| [12] | 0| 0|SECT |LOCAL|0|.debug_aranges| [14] | 0| 0|SECT |LOCAL|0|.debug_line| [15] | 0| 0|SECT |LOCAL|0|.debug_str| [17] | 0| 0|SECT |LOCAL|0| .note| [18] | 0| 0|SECT |LOCAL|0|.PARISC.unwind| [19] | 0| 0|SECT |LOCAL|0|.comment| [11] | 0| 0|SECT |LOCAL|0|.debug_loc| [13] | 0| 0|SECT |LOCAL|0|.debug_ranges| [6] | 0| 0|SECT |LOCAL|0|.text._ZnwmSt11align_val_t| [5] | 0| 0|SECT |LOCAL|0|.data.rel.ro| [4] | 0| 0|SECT |LOCAL|0|.bss| [3] | 0| 0|SECT |LOCAL|0| .data| [2] | 0| 0|SECT |LOCAL|0| .text|[16] | 0| 0|NOTYP|LOCAL|0|.data.rel.ro|L$C [20] | 0| 0|FUNC |GLOB |0| UNDEF|_ZNSt9bad_allocD1Ev [23] | 0| 0|FUNC |GLOB |0| UNDEF|_ZSt15get_new_hand lerv [26] | 0| 0|OBJT |GLOB |0| UNDEF|_ZTISt9bad_alloc[25] | 0| 0|OBJT |GLOB |0| UNDEF|_ZTVSt9bad_alloc [21] | 0| 216|FUNC |GLOB |0|.text._ZnwmSt11align_val_t|_ZnwmSt11align_val_t [24] | 0| 0|FUNC |GLOB |0| UNDEF|__cxa_allocate_exc eption [27] | 0| 0|FUNC |GLOB |0| UNDEF|__cxa_throw [22] | 0| 0|FUNC |GLOB |0| UNDEF|aligned_alloc
[Bug fortran/79182] when use openmp and link static libgfortran,open function cause SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79182 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #2 from Jakub Jelinek --- That is a libc issue, statically linking only parts of -lpthread often results in broken programs, unless libpthread.a ensures all of libpthread is linked when linking statically (e.g. what is done in some distributions where libpthread.a contains only libpthread.o - result of ld -r). If your distro isn't doing this, I'm afraid you need to use -static --Wl,--whole-archive -lpthread -Wl,--no-whole-archive.
[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-01-22 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Looks like we do need to create a fall-back implementation after all, as Marc suggested in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00422.html
[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190 --- Comment #2 from John David Anglin --- Looks as if the problem is here: #else // The C library doesn't provide any aligned allocation functions, declare // aligned_alloc and get a link failure if aligned new is used. extern "C" void *aligned_alloc(std::size_t, std::size_t); #endif Possibly, a better solution might be to provide an implementation that aborts.
[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190 --- Comment #3 from John David Anglin --- (In reply to Jonathan Wakely from comment #1) > Looks like we do need to create a fall-back implementation after all, as > Marc suggested in https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00422.html A working backup would be even better if possible.
[Bug libstdc++/79190] [7 Regression] ld: (Warning) Unsatisfied symbol "aligned_alloc"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79190 --- Comment #4 from Jonathan Wakely --- (In reply to John David Anglin from comment #2) > Looks as if the problem is here: > > #else > // The C library doesn't provide any aligned allocation functions, declare > // aligned_alloc and get a link failure if aligned new is used. > extern "C" void *aligned_alloc(std::size_t, std::size_t); > #endif Yep. > Possibly, a better solution might be to provide an implementation that > aborts. Or throws std::bad_alloc to indicate failure to allocate: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00578.html But I think we can provide a fallback.
[Bug libstdc++/78420] [5/6/7 Regression] std::less is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #11 from Ville Voutilainen --- Ah, the plot thickens. Jens Maurer wrote: "Regarding the std::less issue, it seems a bug in the standard to require that it be constexpr and deliver a total order. After all, the addresses of global objects are defined by the linker, so it doesn't seem plausible to get a compile-time answer for std::less that is the same as a later run-time answer." So I could theoretically just drop the constexpr from the pointer specializations and be done with this bugfix. On the other hand, I expect the plot to thicken further, as library wrappers that contain pointers don't establish a total order, but in that regard we have no conformance bugs; the standard doesn't specify that they would.
[Bug tree-optimization/79187] [7 Regression] wrong code at -Os on x86_64-linux-gnu (generated code segfaults)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79187 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-22 CC||jakub at gcc dot gnu.org Version|unknown |7.0 Target Milestone|--- |7.0 Summary|wrong code at -Os on|[7 Regression] wrong code |x86_64-linux-gnu (generated |at -Os on x86_64-linux-gnu |code segfaults) |(generated code segfaults) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Starting with r244520 this with -Os prints 28 instead of nothing.
[Bug tree-optimization/79186] [7 Regression] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: Segmentation fault (in VRP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79186 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-22 CC||jakub at gcc dot gnu.org Version|unknown |7.0 Target Milestone|--- |7.0 Summary|ICE on valid code at -O2|[7 Regression] ICE on valid |and -O3 on |code at -O2 and -O3 on |x86_64-linux-gnu: |x86_64-linux-gnu: |Segmentation fault (in VRP) |Segmentation fault (in VRP) Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r244520.
[Bug libstdc++/78420] [5/6/7 Regression] std::less is not a total order with -O2 enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420 --- Comment #12 from Ville Voutilainen --- ..which is http://cplusplus.github.io/LWG/lwg-active.html#2491
[Bug lto/79061] [7 Regression][LTO][ASAN] LTO plus ASAN fails with "AddressSanitizer: initialization-order-fiasco"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79061 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Jakub Jelinek --- Assuming this is fixed.
[Bug libgcc/70800] libgcc/config/libbid/bid_binarydecimal.c: suspicious comparison ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70800
--- Comment #1 from David Binderman ---
Given the following source code
extern void g(int n);
void f( int n)
{
if ((n & 0x30) == 1)
g( n);
}
Current trunk gcc can't find much wrong:
$ ~/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -Wtype-limits jan22a.cc
$
If it could, then these four known bugs in the gcc source code could be found
$ grep "Expression .* is always" ~/gcc/cppcheck.20170120.out
[trunk/libgcc/config/libbid/bid_binarydecimal.c:143933]: (style) Expression '(X
& 0x) > 0xf423f' is always false.
[trunk/libgcc/config/libbid/bid_binarydecimal.c:144327]: (style) Expression '(X
& 0x) > 0xf423f' is always false.
[trunk/libgcc/config/libbid/bid_binarydecimal.c:144723]: (style) Expression '(X
& 0x) > 0xf423f' is always false.
[trunk/libgcc/config/libbid/bid_binarydecimal.c:145133]: (style) Expression '(X
& 0x) > 0xf423f' is always false.
$
and indeed, six bugs in the linux kernel could also be found:
$ grep "Expression .* is always" ~/linuxKernel/cppcheck.410-rc4.out
[linux-4.10-rc4/arch/mips/include/asm/netlogic/xlr/fmn.h:304]: (style)
Expression '(X & 0x2) == 0x1' is always false.
[linux-4.10-rc4/drivers/block/sx8.c:1077]: (style) Expression '(X & 0x1f) <
0x20' is always true.
[linux-4.10-rc4/drivers/dma/txx9dmac.c:743]: (style) Expression '(X & 0xff) <=
0xff' is always true.
[linux-4.10-rc4/drivers/dma/txx9dmac.c:748]: (style) Expression '(X & 0x7f) <=
0x7f' is always true.
[linux-4.10-rc4/drivers/staging/rts5208/sd.c:4129]: (style) Expression '(X &
0x1e) != 0x3' is always true.
[linux-4.10-rc4/samples/bpf/sockex3_kern.c:268]: (style) Expression '(X & 0xf0)
== 0x4' is always false.
$
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095
--- Comment #10 from Jeffrey A. Law ---
So with a prototype patch to simplify the overflow checks to zero/not zero, we
still get the one warning. The more I look at the code, the more I think the
warning is justified.
Ponder the case where v.size () returns 0 in the test. That'll result in
calling v.resize (-1).
In the resize code we have:
resize(size_type __new_size)
{
if (__new_size > size())
_M_default_append(__new_size - size());
else if (__new_size < size())
_M_erase_at_end(this->_M_impl._M_start + __new_size);
}
Remembering that we're working with size_t (ie, unsigned) objects, we'll go
into the TRUE clause, calling:
std::vector::_M_default_append (&v, 18446744073709551615);
At which point I think we've lost And ISTM that GCC gave a valid warning
for the given inputs.
Thoughts Martin?
[Bug lto/78140] [7 Regression] libxul -flto uses 1GB more memory than gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78140
kugan at gcc dot gnu.org changed:
What|Removed |Added
CC||kugan at gcc dot gnu.org
--- Comment #26 from kugan at gcc dot gnu.org ---
(In reply to Richard Biener from comment #20)
> Look at tree-ssanames.c:range_info_def for "tricks" (make them variable
> size):
>
> /* Value range information for SSA_NAMEs representing non-pointer variables.
> */
>
> struct GTY ((variable_size)) range_info_def {
> /* Minimum, maximum and nonzero bits. */
> TRAILING_WIDE_INT_ACCESSOR (min, ints, 0)
> TRAILING_WIDE_INT_ACCESSOR (max, ints, 1)
> TRAILING_WIDE_INT_ACCESSOR (nonzero_bits, ints, 2)
> trailing_wide_ints <3> ints;
> };
I am working on a patch to change ipa vrp based on the above.
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095 --- Comment #11 from Martin Sebor --- I agree that calling v.resize(v.size() - 0) when v.size() is zero is a bug in the program and diagnosing it should be a good thing (I think that corresponds to the test case I pasted in comment #2 and what I based my patch with the trap on.) If your patch avoids the warning when the if guard in the test case in comment #0 is uncommented that would seem like a fix. As a separate change (in GCC 8) I do think it would be worth considering the idea of inserting the trap, and also having tree-loop-distribution.c issue a better warning when it detects an out of bounds loop like this one.
[Bug tree-optimization/79191] New: potentially truncating unsigned conversion defeats range propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
Bug ID: 79191
Summary: potentially truncating unsigned conversion defeats
range propagation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
As mentioned in a recent discussion
(https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01617.html), a truncating
unsigned conversion such as from unsigned long to unsigned in LP64 appears to
defeat VRP and prevent GCC from emitting optimal code.
In the test case below, the indirect call to abort() in g() is optimized away
because n is known to be less than 3. However, the same indirect call to
abort() is not optimized away in h().
$ cat t.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout t.c
void f (unsigned long n)
{
if (n > 3)
__builtin_abort ();
}
void g (unsigned n)
{
if (n < 3)
f (n);
}
void h (unsigned long m)
{
unsigned n = m;
if (n < 3)
f (n);
}
;; Function f (f, funcdef_no=0, decl_uid=1795, cgraph_uid=0, symbol_order=0)
f (long unsigned int n)
{
[100.00%]:
if (n_1(D) > 3)
goto ; [0.04%]
else
goto ; [99.96%]
[0.04%]:
__builtin_abort ();
[99.96%]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1798, cgraph_uid=1, symbol_order=1)
g (unsigned int n)
{
[100.00%]:
return;
}
;; Function h (h, funcdef_no=2, decl_uid=1801, cgraph_uid=2, symbol_order=2)
Removing basic block 6
Removing basic block 7
h (long unsigned int m)
{
unsigned int n;
long unsigned int _5;
[100.00%]:
n_2 = (unsigned int) m_1(D);
if (n_2 <= 2)
goto ; [54.00%]
else
goto ; [46.00%]
[54.00%]:
_5 = m_1(D) & 4294967295;
if (_5 > 3)
goto ; [0.04%]
else
goto ; [99.96%]
[0.02%]:
__builtin_abort ();
[99.98%]:
return;
}
[Bug tree-optimization/79191] potentially truncating unsigned conversion defeats range propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71690 --- Comment #1 from Martin Sebor --- I suspect this might be the same issue as pointed out in bug 71690.
[Bug c++/79095] [7 regression] spurious stringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79095 --- Comment #12 from Jeffrey A. Law --- With the v.size() > 0 guard enabled and my VRP tweaks I get no warnings. Plan is to either polish up the VRP tweaks or turn them into a match.pd pattern. Not sure which is going to be better yet.
[Bug target/78516] [7 Regression] ICE in lra_assign for e500v2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78516 --- Comment #24 from Peter Bergner --- (In reply to Jeffrey A. Law from comment #23) > Fixed by patches on the trunk. We only have a fix for the ICE in the first comment. We still do not have a proper fix for the ICE in Comment 6. Since you've closed this bug, I assume you prefer a new bugzilla entry for that ICE rather than working on it here?
[Bug c++/79192] New: Angle bracket following typename is treated as template argument delimiter even if the name is not a template name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79192
Bug ID: 79192
Summary: Angle bracket following typename is treated as
template argument delimiter even if the name is not a
template name
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ricilake at gmail dot com
Target Milestone: ---
Sample code:
#include
struct v {};
int main() {
std::cout << __VERSION__ << '\n' << (new v < new v) << '\n';
}
(Or, more simply):
int main() { return new int < new int; }
Standard reference: §14.2 paragraph 3:
After name lookup finds that a name is a template-name or that an operator-
function-id or a literal-operator-id refers to a set of overloaded functions
any member of which is a function template, if this is followed by a <, the <
is always taken as the delimiter of a template-argument-list and never as the
less-than operator.
In this case, however, the name is *not* a template-name, so I believe that the
< should be the less-than operator. Clang also believes this.
Initially ventilated on StackOverflow
http://stackoverflow.com/q/41786026/1566221 where the consensus appears to be
that it's a bug.
As mentioned in the SO post, I also tried it with function names ("&f < &f"),
and in that case GCC does distinguish between template names and non-template
names, so the behaviour of "new v < new v" seems doubly inconsistent.
[Bug libstdc++/79193] New: libstdc++ configure incorrectly decides linking works for cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193
Bug ID: 79193
Summary: libstdc++ configure incorrectly decides linking works
for cross-compiler
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
I've discovered that libstdc++ is being misconfigured for a bare-metal target
that uses newlib. For our toolchains we separately provide board-specific
linker scripts and a library that includes startup code and low-level I/O
support (either GDB semihosting, hooks to Uboot/Yamon/etc, or dummy entry
points for unhosted applications).
Fairly early on, the libstdc++-v3 configure script tries to determine whether
it can link executables by trying to build this test program:
int
main ()
{
;
return 0;
}
It turns out that this program actually is simple enough to link with only a
warning (not an error) about _start being undefined when the linker is invoked
without specifying without a linker script, startup code, or hosting library.
Based on that, the configure script sets gcc_no_link=no and then fails to set
cross_compiling=yes.
I noticed this while tracking down a bug that turned out to be due to this
subsequent check for C99 stdio.h support returning the wrong result:
#include
#include
void foo(char* fmt, ...)
{
va_list args; va_start(args, fmt);
vfscanf(stderr, "%i", args);
vscanf("%i", args);
vsnprintf(fmt, 0, "%i", args);
vsscanf(fmt, "%i", args);
snprintf(fmt, 0, "%i");
}
int
main ()
{
;
return 0;
}
The link command is failing with undefined symbol errors; the C99 functions
it's checking for are present and provided by newlib, but they suck in
low-level primitives that would be provided by the missing BSP hosting library,
so configure is incorrectly deciding that the C99 I/O support isn't present.
For now I am forcing the initial "can we link?" test to fail by adding
"-Wl,--require-defined=_start" to LDFLAGS_FOR_TARGET, which forces the
subsequent check for C99 I/O functions to compile only instead of compile and
link. But this is pretty obscure. Is it possible to fix the configure script
instead? E.g., to have an explicit option to say "don't try to link for this
target", or to make these checks for C99 features always compile-only instead
of link tests? Or to use a non-empty program to check whether linking works at
all?
[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79193 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-01-23 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- # Only do link tests if native. Else, hardcode. So if hardcode is not correct for your target (newlib or otherwise). Then you need to change it
[Bug rtl-optimization/79194] New: [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79194
Bug ID: 79194
Summary: [7 Regression] ICE in rtl_verify_bb_insns, at
cfgrtl.c:2661 (error: flow control insn inside a basic
block)
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu*
gcc-7.0.0-alpha20170122 snapshot ICEs when compiling the following snippet w/
-O3:
int iw, vr;
void
d9 (unsigned int j3, long long int f5, int kp)
{
int *qb = &kp;
if (kp != 0)
{
long long int oq;
unsigned int tl = 0;
for (j3 = 0; j3 < 1; ++j3)
qb = &tl;
goto ed;
l7:
oq = 1;
while (oq < 2)
oq *= j3;
ed:
do
{
oq -= *qb;
if (oq != 0)
{
long long int ie = j3 & f5;
int ws = (j3 != 0 && kp != 0);
tl = ie > ws;
iw = vr = tl;
}
else
tl = (kp != 0 && (0 % 0) != 0);
}
while (tl != 0);
}
goto l7;
}
% powerpc-e300c3-linux-gnu-gcc-7.0.0-alpha20170122 -O3 -w -c rrypxrpr.c
rrypxrpr.c: In function 'd9':
rrypxrpr.c:40:1: error: in basic block 47:
}
^
rrypxrpr.c:40:1: error: flow control insn inside a basic block
(insn 508 347 353 47 (trap_if (const_int 1 [0x1])
(const_int 0 [0])) 824 {trap}
(nil))
rrypxrpr.c:40:1: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.c:2661
0x3177d0db745 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/rtl-error.c:108
0x3177cc9d1e7 rtl_verify_bb_insns
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cfgrtl.c:2661
0x3177cc9d1e7 rtl_verify_flow_info_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cfgrtl.c:2747
0x3177cc8933d verify_flow_info()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cfghooks.c:258
0x3177cca26d7 checking_verify_flow_info
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cfghooks.h:198
0x3177cca26d7 commit_edge_insertions()
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cfgrtl.c:2095
0x3177d7f62a8 bypass_conditional_jumps
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cprop.c:1742
0x3177d7f62a8 one_cprop_pass
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cprop.c:1866
0x3177d7f62a8 execute_rtl_cprop
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cprop.c:1918
0x3177d7f62a8 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-7.0.0_alpha20170122/work/gcc-7-20170122/gcc/cprop.c:1956
