[Bug middle-end/93041] GCC 10 removes an infinite loop and causes a null pointer to dereferenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041 fxue at gcc dot gnu.org changed: What|Removed |Added CC||fxue at gcc dot gnu.org --- Comment #3 from fxue at gcc dot gnu.org --- For gcc10, by default, a loop containing an exit, although it might not be a real exit, is considered as finite, which is controlled by a newly introduced option -finite-loops. To be compatible with old behavior, you can explicitly add -fno-finite-loops.
[Bug c/93047] New: frename-registers does not work well with __builtin_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047
Bug ID: 93047
Summary: frename-registers does not work well with
__builtin_return
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: guojiufu at gcc dot gnu.org
Target Milestone: ---
There is a case builtin-return-1.c which is checking __builtin_return and
__builtin_apply. Which this case fail with -frename-registers.
It seems rnreg rename a register to 'return register' after function call.
gcc $GCC_SRC/gcc/testsuite/gcc.dg/torture/stackalign/builtin-return-1.c -O3
-frename-registers -o ./builtin-return-1.exe
./builtin-return-1.exe
Aborted (core dumped)
[Tested on powerpc64le.]
Dump asm code, there is code like:
bl foo
addi 3,31,128 #this line is using r3 which should be return reg of
previous call foo
addi 12,31,304
addi 10,31,336
addi 6,31,352
xxpermdi 0,1,1,2
xxpermdi 9,35,35,2
std 3,96(31) #here r3 (return value of foo) is saved
Without -frename-registers
bl foo
addi 0,31,128
addi 11,31,240
addi 4,31,256
addi 5,31,272
std 3,96(31) #here
xxpermdi 1,1,1,2
xxpermdi 2,2,2,2
rnreg should not rename r0 for instruction "addi 0,31,128" to r3.
r3 should not be used as 'rename source register' after "bl xx" untill "std
3,..."
source code:
#ifdef __MMIX__
/* No parameters on stack for bar. */
#define STACK_ARGUMENTS_SIZE 0
#else
#define STACK_ARGUMENTS_SIZE 64
#endif
extern void abort(void);
int foo(int n)
{
return n+1;
}
int bar(int n)
{
__builtin_return(__builtin_apply((void (*)(void))foo, __builtin_apply_args(),
STACK_ARGUMENTS_SIZE));
}
int main(void)
{
/* Allocate 64 bytes on the stack to make sure that __builtin_apply
can read at least 64 bytes above the return address. */
char dummy[64];
__asm__ ("" : : "" (dummy));
if (bar(1) != 2)
abort();
return 0;
}
[Bug c/90677] [9 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 Eric Botcazou changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ebotcazou at gcc dot gnu.org Resolution|FIXED |--- --- Comment #14 from Eric Botcazou --- The fix breaks the build of earlier GCCs with the C++ compiler: extern void foo (int, int, const char *, ...) __attribute__ ((__format__ (__gcc_tdiag__, 3, 4))); struct cgraph_node; extern void bar (struct cgraph_node *); t.cpp:2:52: error: 'cgraph_node' is not defined as a type 2 | __attribute__ ((__format__ (__gcc_tdiag__, 3, 4))); |
[Bug c++/93048] New: ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
Bug ID: 93048
Summary: ICE in verify_gimple
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pilarlatiesa at gmail dot com
Target Milestone: ---
The (valid) code bellow trigger an ICE:
In member function 'TCoefs TExprDiv
>::CalcCoefs(std::size_t) const [with long unsigned int d = 2; long unsigned
int r = 1; TRest = {}; T = TCampo]':
:79:1: error: incorrect sharing of tree nodes
79 | TExprDiv>::CalcCoefs(std::size_t) const
| ^~
*
->aP = aP;
during GIMPLE pass: cfg
:79:1: internal compiler error: verify_gimple failed
Started ICEing with 10.0.0 20191222 (x86_64-pc-linux-gnu). It compiled fine
with 10.0.0 20191126.
I could not reduce the testcase any further. Sorry.
#include
#include
template
struct TTensor
{};
template
struct TCoefs
{
double aP;
std::valarray aF;
TTensor b;
};
template
class TExprBase {};
template typename T>
class TExprBase>
{
public:
decltype(auto)
CalcCoefs(std::size_t i) const
{ return static_cast const *>(this)->CalcCoefs(i); }
operator T const &() const
{ return static_cast const &>(*this); }
};
template
class TBinExpr: public TExprBase>
{
private:
T const &lhs;
U const &rhs;
[[no_unique_address]] TOp const Op = {};
public:
TBinExpr() = delete;
TBinExpr(T const &lhs_, U const &rhs_) :
lhs(lhs_), rhs(rhs_) {}
decltype(auto)
CalcCoefs(std::size_t i) const
{ return Op(lhs.CalcCoefs(i), rhs.CalcCoefs(i)); }
};
template
class TCampo : public TExprBase> {};
template
class TExprDiv {};
template typename T>
class TExprDiv> : public TExprBase>>
{
private:
TCampo const &U;
TCampo const &φ;
public:
TExprDiv(TExprBase> const &U_, TCampo const
&φ_):
U(U_), φ(φ_) {}
TCoefs
CalcCoefs(std::size_t) const;
};
template typename T>
TCoefs
TExprDiv>::CalcCoefs(std::size_t) const
{
double aP = 0.0;
std::valarray aF;
TTensor b = {};
return {aP, aF, b};
}
template typename T>
TExprDiv>
div(TExprBase> const &U, TCampo const &φ)
{ return {U, φ}; }
int main()
{
TCampo<2u, 1u> U;
auto bar = div(U, U).CalcCoefs(0);
return 0;
}
[Bug c++/92789] Non-obvious ?: behaviour with structurally equivalent types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789 --- Comment #1 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Mon Dec 23 09:43:46 2019 New Revision: 279717 URL: https://gcc.gnu.org/viewcvs?rev=279717&root=gcc&view=rev Log: [C++] Make same_type_p return false for gnu_vector_type_p differences (PR 92789) As Jason pointed out in the review of the C++ gnu_vector_type_p patch: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00173.html the real fix for the XFAILs in acle/general-c++/gnu_vectors_*.C is to make same_type_p return false for two types if one is gnu_vector_type_p and the other isn't. This patch does that and fixes the fallout. Originally I'd tried to make it so that "X *" and "Y *" are interconvertible whenever X and Y are, and similarly for "X &" and "Y &". That doesn't fall out naturally though, and is different from how -flax-vector-conversions works. The patch therefore accepts all the consequences of making X and Y !same_type_p instead of trying to work around them. 2019-12-23 Richard Sandiford gcc/cp/ PR c++/92789 * typeck.c (structural_comptypes): Make sure that two vector types agree on gnu_vector_type_p. gcc/testsuite/ PR c++/92789 * g++.dg/ext/sve-sizeless-2.C (statements): Expect pointer difference and comparisons between GNU and non-GNU types to be rejected. Expect __is_same to be false for such pairs. * g++.target/aarch64/sve/acle/general-c++/gnu_vectors_1.C: Remove XFAILs. Expect conversions between SVE vector pointers and GNU vector pointers to be rejected. Test references. * g++.target/aarch64/sve/acle/general-c++/gnu_vectors_2.C: Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/sve-sizeless-2.C trunk/gcc/testsuite/g++.target/aarch64/sve/acle/general-c++/gnu_vectors_1.C trunk/gcc/testsuite/g++.target/aarch64/sve/acle/general-c++/gnu_vectors_2.C
[Bug other/93049] New: limits.h generated by fixincludes breaks cross-compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049 Bug ID: 93049 Summary: limits.h generated by fixincludes breaks cross-compilation Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: svante.signell at gmail dot com Target Milestone: --- Created attachment 47542 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47542&action=edit fix for glimits.h Hello, Cross-compiling from x86_64-linux-gnu to i686-gnu breaks for example the builds of sed-4.7 and coreutils-8.31, as well as Linux-PAM-1.3.1. The first two failures are due to that the fixed limits.h #define MB_LEN_MAX 1 while the system one has #define MB_LEN_MAX 16. The third error is due to that #ifdef __USE_POSIX2 # include #endif is chopped off the generated limits.h, leaving LINE_MAX undefined. The problem seems to be in the file gcc-9.2.0/gcc/glimits.h causing the generated gcc-9.2.0.obj/gcc/include-fixed/limits.h. The attached patch fixinc_glimits.h.diff fixes that problem.
[Bug c++/93048] ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
--- Comment #1 from Pilar Latiesa ---
Reduced:
#include
template
class valarray {};
template
struct TTensor
{};
template
struct TCoefs
{
double aP;
std::valarray aF;
TTensor b;
};
template
class TCampo {};
template
class TExprDiv
{
private:
TCampo const &U;
TCampo const &fi;
public:
TExprDiv(TCampo const &U_, TCampo const &fi_):
U(U_), fi(fi_) {}
TCoefs
CalcCoefs(int) const;
};
template
TCoefs
TExprDiv::CalcCoefs(int) const
{
double aP = 0.0;
std::valarray aF;
TTensor b = {};
return {aP, aF, b};
}
int main()
{
TCampo<2u, 1u> U;
auto bar = TExprDiv<2u, 1u>(U, U).CalcCoefs(0);
return 0;
}
I could not remove the dependency on the valarray header. It seems that TCoefs
needs to have this members for the ICE to happen.
[Bug c++/93048] ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
--- Comment #2 from Pilar Latiesa ---
Even more reduced:
#include
template
struct TTensor {};
template
struct TCoefs
{
double aP;
std::valarray aF;
TTensor b;
};
template
class TExprDiv
{
public:
TCoefs
CalcCoefs(int) const;
};
template
TCoefs
TExprDiv::CalcCoefs(int) const
{
double aP = 0.0;
return {aP, {}, {}};
}
int main()
{
auto bar = TExprDiv<2u, 1u>().CalcCoefs(0);
return 0;
}
[Bug c++/93048] ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #3 from Arseny Solokha --- It is likely a duplicate of PR93033.
[Bug other/93049] limits.h generated by fixincludes breaks cross-compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049 --- Comment #1 from Andreas Schwab --- Make sure you have sysroot properly set up so that the gcc Makefile finds the system limits.h.
[Bug tree-optimization/92644] [9 Regression] ICE in wide_int_to_tree_1, at tree.c:1530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92644 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- .
[Bug c++/93048] ICE in verify_gimple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
--- Comment #4 from Pilar Latiesa ---
Minimal testcase ;-)
#include
struct TTensor {};
struct TCoefs
{
double aP;
std::valarray aF;
TTensor b;
};
TCoefs CalcCoefs()
{
double aP = 0.0;
return {aP, {}, {}};
}
I still don't understand why one of the members must be std::valarray. With a
contrived valarray class with the same constructors and noexcept qualifiers as
the std version the code compiles fine.
[Bug c++/93050] New: throw within constructor initialisation list causes invalid free in destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93050
Bug ID: 93050
Summary: throw within constructor initialisation list causes
invalid free in destructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: db0451 at gmail dot com
Target Milestone: ---
I've come across this error at least twice when trying to throw from
constructor initialisation lists, so I don't *think* I'm uniquely at fault
here...
All I want to do is move/copy an argument into a member if suitable, and throw
if not, while not having to use the constructor body, instead the ctor
init-list
The below code, compiled with...
* g++ --version: `g++.exe (Rev2, Built by MSYS2 project) 9.2.0`
* compiler args: `g++ -std=c++17 -Wall -Wextra -Wpedantic test.cpp`
...correctly throws when Test() is called with an empty string, but with a
non-empty string is crashes in free() via ~Test().
source:
```cpp
#include
#include
struct Test final {
std::string m_string;
Test(std::string string)
: m_string{ !string.empty() ? std::move(string)
: throw std::invalid_argument{"string cannot be empty"} }
{}
};
auto
main() -> int
{
auto test = Test{"2"};
return 0;
}
```
gdb log, run on
```
Reading symbols from ./a.exe...done.
(gdb) run
Starting program: /tmp/Atm/build/a.exe
[New Thread 3880.0x3c38]
[New Thread 3880.0x2b68]
[New Thread 3880.0x5624]
[New Thread 3880.0x4a14]
warning: Critical error detected c374
Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x7ffdca4391f3 in ntdll!RtlIsNonEmptyDirectoryReparsePointAllowed () from
/c/WINDOWS/SYSTEM32/ntdll.dll
(gdb) bt
#0 0x7ffdca4391f3 in ntdll!RtlIsNonEmptyDirectoryReparsePointAllowed ()
from /c/WINDOWS/SYSTEM32/ntdll.dll
#1 0x7ffdca441622 in ntdll!RtlpNtMakeTemporaryKey () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#2 0x7ffdca44192a in ntdll!RtlpNtMakeTemporaryKey () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#3 0x7ffdca44a8e9 in ntdll!RtlpNtMakeTemporaryKey () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#4 0x7ffdca38088d in ntdll!RtlGetCurrentServiceSessionId () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#5 0x7ffdca37fc11 in ntdll!RtlFreeHeap () from
/c/WINDOWS/SYSTEM32/ntdll.dll
#6 0x7ffdc8fd9cfc in msvcrt!free () from /c/WINDOWS/System32/msvcrt.dll
#7 0x00402ef8 in Test::~Test() ()
#8 0x004015d2 in main ()
(gdb)
```
Copying instead of `std::move()`ing the `string` doesn't seem to change
anything
Moving the check/throw into the constructor body works but shouldn't be needed.
[Bug fortran/92961] [8/9/10 Regression] ICE in gfc_zero_size_array, at fortran/arith.c:1680
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92961 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-12-23 CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/93051] New: Wrong optimizations for pointers: `if (p == q) use p` -> `if (p == q) use q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
Bug ID: 93051
Summary: Wrong optimizations for pointers: `if (p == q) use p`
-> `if (p == q) use q`
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
The optimizer sometimes changes `if (p == q) use p` to `if (p == q) use q` if
it can track the provenance of `q` but not of `p`. This is wrong when the
actual provenance of `p` differs from that of `q`.
Examples demonstrate the problem in different cases:
- with integers and with live pointers (to show that the problem is not in
casts to integers);
- with past-the-end pointers and without them (to show that even changing the
standard to make their comparisons UB will not help);
- with two allocations and with only one (to show that it's not related to how
memory is allocated by the compiler/libc).
Plus, all examples behaves quite well:
- respect provenance of pointers including via casts to integers (so this bug
is not about (im)possibility to clear provenance by casts to integers or
something);
- use only one comparison (so the question of its stability is not touched).
There is some previous analysis of propagation of conditional equivalences in
other bugs, e.g., pr65752#c52, pr61502#c25.
Somewhat more general clang bug -- https://bugs.llvm.org/show_bug.cgi?id=44313.
Previous lengthy discussion is in https://bugs.llvm.org/show_bug.cgi?id=34548.
Example with a past-the-end pointer (the wrong optimization seems to be applied
in vrp1):
--
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
int main()
{
int x[5];
int y[1];
int *p = x;
int *q = y + 1;
int *r = opaque(p); // hide provenance of p
if (r == q) {
*p = 1;
*r = 2;
printf("result: %d\n", *p);
}
opaque(q);
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes test.c && ./a.out
result: 2
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
test.c: In function ‘main’:
test.c:17:9: warning: array subscript 1 is outside array bounds of ‘int[1]’
[-Warray-bounds]
17 | *r = 2;
| ^~
test.c:9:9: note: while referencing ‘y’
9 | int y[1];
| ^
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
The warning nicely illustrates the problem:-)
Based on the example from Harald van Dijk in pr61502#c4.
[Bug tree-optimization/93051] Wrong optimizations for pointers: `if (p == q) use p` -> `if (p == q) use q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
--- Comment #1 from Alexander Cherepanov ---
Example with a restricted pointer (dom2):
--
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
__attribute__((noipa)) // imagine it in a separate TU
static void f(int *restrict p, int *restrict q)
{
int *r = opaque(p); // hide provenance of p
if (r == q) {
*p = 1;
*r = 2;
printf("result: %d\n", *p);
}
opaque(q);
}
int main()
{
int x;
f(&x, &x);
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes test.c && ./a.out
test.c: In function ‘main’:
test.c:22:7: warning: passing argument 1 to ‘restrict’-qualified parameter
aliases with argument 2 [-Wrestrict]
22 | f(&x, &x);
| ^~ ~~
result: 2
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
test.c: In function ‘main’:
test.c:22:7: warning: passing argument 1 to ‘restrict’-qualified parameter
aliases with argument 2 [-Wrestrict]
22 | f(&x, &x);
| ^~ ~~
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
Strictly speaking this example is not about provenance (both pointers have the
same provenance) but, for the optimizer, different restricted pointers probably
play similar roles.
Despite the warning, equal restricted pointers are fine per se -- see, e.g.,
Example 3 in C11, 6.7.3.1p10.
[Bug tree-optimization/93051] Wrong optimizations for pointers: `if (p == q) use p` -> `if (p == q) use q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93051
--- Comment #2 from Alexander Cherepanov ---
Example with a dead malloc (not in tree-opt):
--
#include
#include
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
int main()
{
int *q = malloc(sizeof(int));
uintptr_t iq = (uintptr_t)(void *)q;
free(q);
int *p = malloc(sizeof(int));
uintptr_t ir = (uintptr_t)(void *)opaque(p); // hide provenance of p
if (ir == iq) {
*p = 1;
*(int *)ir = 2;
printf("result: %d\n", *p);
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes test.c && ./a.out
result: 2
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
[Bug tree-optimization/93052] Wrong optimizations for pointers: `p == q ? p : q` -> `q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #1 from Alexander Cherepanov ---
Example with a past-the-end pointer (vrp1, similar to but 93051, comment 0 but
this time with PHI):
--
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
static int been_there = 0;
static int *f(int *p, int *q)
{
if (p == q) {
been_there = 1;
return p;
} else {
been_there = 0;
return q;
}
}
int main()
{
int x[5];
int y[1];
int *p = x;
int *q = y + 1;
opaque(q);
int *p1 = opaque(p); // prevents early optimization of x==y+1
int *r = f(p1, q);
if (been_there) {
*p = 1;
*r = 2;
printf("result: %d\n", *p);
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes test.c && ./a.out
result: 2
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
test.c: In function ‘main’:
test.c:33:9: warning: array subscript 1 is outside array bounds of ‘int[1]’
[-Warray-bounds]
33 | *r = 2;
| ^~
test.c:22:9: note: while referencing ‘y’
22 | int y[1];
| ^
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
[Bug tree-optimization/93052] New: Wrong optimizations for pointers: `p == q ? p : q` -> `q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
Bug ID: 93052
Summary: Wrong optimizations for pointers: `p == q ? p : q` ->
`q`
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ch3root at openwall dot com
Target Milestone: ---
Similar to pr93051.
The optimizer sometimes changes `p == q ? p : q` to `q`. This is wrong when the
actual provenance of `p` differs from that of `q`.
There are two forms -- with the actual conditional operator and with the `if`
statement.
The ideal example would be constructed with the help of restricted pointers but
it's run into a theoretical problem -- see the first testcase in pr92963.
My other examples require two conditionals to eliminate the possibility of UB.
Comparison of integers should give stable results, hopefully that would be
enough to demonstrate the problem.
Example with the conditional operator and with dead malloc (the wrong
optimization seems to be applied before tree-opt):
--
#include
#include
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
int main()
{
int *q = malloc(sizeof(int));
opaque(q);
uintptr_t iq = (uintptr_t)(void *)q;
free(q);
int *p = malloc(sizeof(int));
opaque(p);
uintptr_t ip = (uintptr_t)(void *)p;
uintptr_t ir = ip == iq ? ip : iq;
if (ip == iq) {
*p = 1;
*(int *)(void *)ir = 2;
printf("result: %d\n", *p);
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes test.c && ./a.out
result: 2
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
[Bug tree-optimization/93052] Wrong optimizations for pointers: `p == q ? p : q` -> `q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #2 from Alexander Cherepanov ---
Example with a dead malloc (phiopt2):
--
#include
#include
#include
__attribute__((noipa,optnone)) // imagine it in a separate TU
static void *opaque(void *p) { return p; }
static int been_there = 0;
static uintptr_t f(uintptr_t ip, uintptr_t iq)
{
if (ip == iq) {
been_there = 1;
return ip;
} else {
been_there = 0;
return iq;
}
}
int main()
{
int *q = malloc(sizeof(int));
opaque(q);
uintptr_t iq = (uintptr_t)(void *)q;
free(q);
int *p = malloc(sizeof(int));
opaque(p);
uintptr_t ip = (uintptr_t)(void *)p;
uintptr_t ir = f(ip, iq);
if (been_there) {
*p = 1;
*(int *)(void *)ir = 2;
printf("result: %d\n", *p);
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes test.c && ./a.out
result: 2
$ gcc -std=c11 -pedantic -Wall -Wextra -Wno-attributes -O3 test.c && ./a.out
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502 --- Comment #34 from Alexander Cherepanov --- It seems to me that problems with the optimization `if (p == q) use p` -> `if (p == q) use q` (comment 4 etc.) are not specific to past-the-end pointers. So I filed a separated bug for it with various testcases -- see pr93051. The same for the optimization `p == q ? p : q` -> `q` (comment 30) -- see pr93052.
[Bug tree-optimization/65752] Too strong optimizations int -> pointer casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752 --- Comment #60 from Alexander Cherepanov --- It seems to me that problems with the optimization `p == q ? p : q` -> `q` (comment 15, comment 38, comment 56 etc.) are not specific to past-the-end pointers. So I filed a separated bug for it with various testcases -- see pr93052. The same for the optimization `if (p == q) use p` -> `if (p == q) use q` (comment 49, comment 52) -- see pr93051.
[Bug tree-optimization/93052] Wrong optimizations for pointers: `p == q ? p : q` -> `q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052 --- Comment #3 from Andrew Pinski --- There is a C defect report about these cases.
[Bug libgcc/93053] New: libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 Bug ID: 93053 Summary: libgcc build failure with old binutils on aarch64 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org Target Milestone: --- On cfarm gcc115 machine (aarch64): using trunk source (r279717), running "./configure --prefix=... --enable-languages=c,c++,fortran; make -j3" got: /home/zhroma/build/base/./gcc/xgcc -B/home/zhroma/build/base/./gcc/ -B/home/zhroma/inst/base/aarch64-unknown-linux-gnu/bin/ -B/home/zhroma/inst/base/aarch64-unknown-linux-gnu/lib/ -isystem /home/zhroma/inst/base/aarch64-unknown-linux-gnu/include -isystem /home/zhroma/inst/base/aarch64-unknown-linux-gnu/sys-include -fno-checking -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../.././gcc -I../../../../src/base/libgcc -I../../../../src/base/libgcc/. -I../../../../src/base/libgcc/../gcc -I../../../../src/base/libgcc/../include -DHAVE_CC_TLS -o cas_4_1.o -MT cas_4_1.o -MD -MP -MF cas_4_1.dep -DL_cas -DSIZE=4 -DMODEL=1 -c ../../../../src/base/libgcc/config/aarch64/lse.S ../../../../src/base/libgcc/config/aarch64/lse.S: Assembler messages: ../../../../src/base/libgcc/config/aarch64/lse.S:52: Error: unknown architectural extension `lse' ../../../../src/base/libgcc/config/aarch64/lse.S:149: Error: unknown mnemonic `casb' -- `casb w0,w1,[x2]' $ cat stage_current stage1 $/usr/bin/as --version GNU assembler (GNU Binutils for Ubuntu) 2.24 Copyright 2013 Free Software Foundation, Inc. I think it should happen since r275967, but haven't actually checked that.
[Bug tree-optimization/93054] New: ICE in gimple_set_lhs, at gimple.c:1820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054
Bug ID: 93054
Summary: ICE in gimple_set_lhs, at gimple.c:1820
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.0.0-alpha20191215 snapshot (r279712), 9.2, 8.3, 7.3 ICE when compiling
the following testcase:
__attribute__ ((returns_twice)) int
bp (int);
__attribute__ ((noreturn)) int
cb (void)
{
return bp (cb ());
}
% gcc-10.0.0-alpha20191215 -w -c zb7r2q8j.c
zb7r2q8j.c: In function 'cb':
zb7r2q8j.c:7:10: internal compiler error: in gimple_set_lhs, at gimple.c:1820
7 | return bp (cb ());
| ^~
0x611d38 gimple_set_lhs(gimple*, tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimple.c:1820
0xa8f8cf gimplify_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:14427
0xa91595 gimplify_call_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:3485
0xa8709f gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:13340
0xa9c8e1 gimplify_modify_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:5753
0xa85bd5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:13368
0xa89430 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:6810
0xa90e35 gimplify_and_add(tree_node*, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:482
0xa90e35 gimplify_return_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:1655
0xa8663b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:13629
0xa89430 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:6810
0xa8a1e5 gimplify_bind_expr
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:1420
0xa870ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:13569
0xa9de54 gimplify_stmt(tree_node**, gimple**)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:6810
0xa9de54 gimplify_body(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:14616
0xa9e29c gimplify_function_tree(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/gimplify.c:14760
0x8f0ab2 cgraph_node::analyze()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/cgraphunit.c:669
0x8f33ae analyze_functions
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/cgraphunit.c:1212
0x8f3fa8 symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/cgraphunit.c:2958
[Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37377 --- Comment #17 from Richard Earnshaw --- last patch was for pr37577.
[Bug libgcc/93053] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #1 from Roman Zhuykov --- Now I can confirm it started with r275967.
Re: [Bug other/93049] limits.h generated by fixincludes breaks cross-compilation
On Mon, 2019-12-23 at 10:09 +, sch...@linux-m68k.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049 > > --- Comment #1 from Andreas Schwab --- > Make sure you have sysroot properly set up so that the gcc Makefile finds the > system limits.h. Do you mean this: tmp/src/gcc-9.2.0/configure --help|grep sysroot --with-build-sysroot=SYSROOT use sysroot as the system root during the build or this: sed-4.7/configure --help|grep sysroot coreutils-8.31/configure --help|grep sysroot Linux-PAM-1.3.1/configure --help|grep sysroot --with-sysroot[=DIR]Search for dependent libraries within DIR (or the compiler's sysroot if not specified). The cross-built gcc, generating code for i686-pc-gnu was created with a a little hairy bootstrap procedure: binutils gnumach headers hurd headers first gcc mig first glibc full gcc full glibc <- This is the gcc built for building the Hurd-executable packages. (and cross-building these packages is even more hairy) Back to the fixinclude version of limits.h. Is there any specific reason to set MB_LEN_MAX to 1, when the system version use 16? Furthermore, in my understanding fixincludes was/is mainly used to convert non-posix header files? Why then chop off the end of the system limits.h: #ifdef __USE_POSIX /* POSIX adds things to . */ # include #endif #ifdef __USE_POSIX2 # include #endif #ifdef __USE_XOPEN # include #endif It seem like the only file modified by fixincludes is limits.h. Is that file not-posix compliant enough?
[Bug ada/70786] Missing "not" breaks Ada.Text_IO.Get_Immediate(File, Item, Available)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70786 --- Comment #9 from Richard Earnshaw --- comment 8 should be for pr70876.
[Bug tree-optimization/93054] ICE in gimple_set_lhs, at gimple.c:1820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added CC||prathamesh3492 at gcc dot gnu.org --- Comment #1 from prathamesh3492 at gcc dot gnu.org --- I wonder if we should emit an error in the front-end if a noreturn function has non-void return type ? For above test-case, the function cb() is marked with noreturn attribute but has return-type int. Thanks, Prathamesh
[Bug tree-optimization/93052] Wrong optimizations for pointers: `p == q ? p : q` -> `q`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052 --- Comment #4 from Alexander Cherepanov --- Could you please provide a bit more specific reference? If you mean various discussions about C provenance semantics then they are not about these cases. All examples in pr93051 and in this pr fully respect provenance -- it's the compiler who changes the provenance. In some sense dealing with these bugs is a prerequisite for a meaningful discussion of C provenance semantics: it's hard to reason about possible boundaries of provenance when there are problems with cases where provenance is definitely right.
[Bug libgcc/93053] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #2 from Andrew Pinski --- Yes for aarch64, a 6 old binutils is too old. A 5 year old one is not though.
[Bug libgcc/93053] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #3 from Andrew Pinski --- I think https://gcc.gnu.org/install/specific.html#aarch64-x-x should be updated rather than anything else.
[Bug tree-optimization/93054] ICE in gimple_set_lhs, at gimple.c:1820
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054 --- Comment #2 from Andrew Pinski --- (In reply to prathamesh3492 from comment #1) > I wonder if we should emit an error in the front-end if a noreturn function > has non-void return type ? For above test-case, the function cb() is marked > with noreturn attribute but has return-type int. There is a warning emitted from the front-end about the noreturn but with a return: t9.c: In function ‘cb’: t9.c:7:10: warning: function declared ‘noreturn’ has a ‘return’ statement 7 | return bp (cb ()); | ^~
[Bug tree-optimization/93055] New: accumulation loops in stepanov_vector benchmark use more instruction level parpallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055 Bug ID: 93055 Summary: accumulation loops in stepanov_vector benchmark use more instruction level parpallelism Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hubicka at gcc dot gnu.org Target Milestone: --- stepanov_vector benchmark form https://gitlab.com/chriscox/CppPerformanceBenchmarks gets poor codegen on TestOneType Built with -march=bdver1 -O3 (but the regression happens on core too) Clang compiles accumulation loops for testOneType as follows: │vpxor %xmm0,%xmm0,%xmm0 │vpxor %xmm1,%xmm1,%xmm1 │vpxor %xmm2,%xmm2,%xmm2 0.05 │vpxor %xmm3,%xmm3,%xmm3= │data16 nopw %cs:0x0(%rax,%rax,1) 6.95 │ 300:┌─→vpaddd 0x5f0(%rsp,%rcx,4),%xmm0,%xmm0 0.05 │ │ vpaddd 0x600(%rsp,%rcx,4),%xmm1,%xmm1 7.13 │ │ vpaddd 0x610(%rsp,%rcx,4),%xmm2,%xmm2 0.16 │ │ vpaddd 0x620(%rsp,%rcx,4),%xmm3,%xmm3 │ │ add$0x10,%rcx │ │ cmp$0x7dc,%rcx 7.04 │ └──jne300 0.07 │vpaddd %xmm0,%xmm1,%xmm0 1.61 │vpaddd %xmm0,%xmm2,%xmm0 │vpaddd %xmm0,%xmm3,%xmm0 │vpshuf $0x4e,%xmm0,%xmm1 0.07 │vpaddd %xmm1,%xmm0,%xmm0 0.02 │vpshuf $0xe5,%xmm0,%xmm1 while GCC10 does: │ 1c0: vxorps %xmm0,%xmm0,%xmm0 │mov%rbx,%rax │nop 2.25 │ 1d0:┌─→vpaddd (%rax),%xmm0,%xmm0 0.01 │ │ lea0x2100(%rsp),%rdi 0.95 │ │ add$0x10,%rax 1.04 │ │ cmp%rax,%rdi 2.24 │ └──jne1d0 Which runs slower: testdescription absolute operations ratio with numbertime per second test0 0 "int32_t accumulate pointer verify2" 1.06 sec 12440.17 M 1.00 1 "int32_t accumulate vector iterator" 1.06 sec 12458.15 M 1.00 2 "int32_t accumulate pointer reverse reverse" 1.06 sec 12440.34 M 1.00 3 "int32_t accumulate vector reverse_iterator reverse" 1.05 sec 12602.74 M 0.99 4 "int32_t accumulate vector iterator reverse reverse" 1.04 sec 12749.27 M 0.98 5 "int32_t accumulate array Riterator reverse reverse" 1.06 sec 12486.26 M 1.00 Total absolute time for int32_t Vector Accumulate: 6.32 sec int32_t Vector Accumulate Penalty: 0.99 compared to: testdescription absolute operations ratio with numbertime per second test0 0 "int32_t accumulate pointer verify2" 2.29 sec 5773.60 M 1.00 1 "int32_t accumulate vector iterator" 2.27 sec 5806.96 M 0.99 2 "int32_t accumulate pointer reverse reverse" 2.26 sec 5830.72 M 0.99 3 "int32_t accumulate vector reverse_iterator reverse" 2.27 sec 5827.45 M 0.99 4 "int32_t accumulate vector iterator reverse reverse" 2.27 sec 5821.29 M 0.99 5 "int32_t accumulate array Riterator reverse reverse" 2.27 sec 5826.58 M 0.99 Total absolute time for int32_t Vector Accumulate: 13.62 sec int32_t Vector Accumulate Penalty: 0.99
[Bug tree-optimization/93056] New: Poor codegen for heapsort in stephanov_vector benchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Bug ID: 93056
Summary: Poor codegen for heapsort in stephanov_vector
benchmark
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
Created attachment 47543
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47543&action=edit
preprocessed benchmark with other tests disabled.
heap sort test in stepanov_vector benchmark runs about 50% slower when built
with GCC10 compared to clang8 (with -O3 -march=native, on bdver1 hardware)
Clang profile is:
33.19% stepanov_vector stepanov_vector[.]
benchmark::heapsort > > >
15.61% stepanov_vector stepanov_vector[.] benchmark::heapsort
15.61% stepanov_vector stepanov_vector[.]
benchmark::heapsort > >
while GCC profile is:
32.90% stepanov_vector stepanov_vector[.]
benchmark::__sift_in >,
double>
16.01% stepanov_vector stepanov_vector[.]
benchmark::__sift_in
15.73% stepanov_vector stepanov_vector[.]
benchmark::__sift_in<__gnu_cxx::__normal_iterator > >, double>
In the hottest function the internal iterator loop leads to worse code:
Clang:
│ xor%edx,%edx
│ if ( *(begin+(i-1)) < *(begin+i))
0.88 │180:┌─→vmovsd (%rax,%rsi,8),%xmm1
6.16 ││ xor%edi,%edi
6.45 ││ vucomi -0x8(%rax,%rsi,8),%xmm1
22.87 ││ seta %dil
6.74 ││ or %rsi,%rdi
││*(begin + free) = *(begin+(i-1));
7.62 ││ mov-0x8(%rax,%rdi,8),%rcx
14.08 ││ mov%rcx,(%rax,%rdx,8)
0.59 ││ lea-0x1(%rdi),%rdx
││for ( i = 2*(free+1); i < count; i += i) {
0.59 ││ add%rdi,%rdi
2.05 ││ mov%rdi,%rsi
2.05 ││ cmp%r11,%rdi
0.29 │└──jl 180
│ if (i == count) {
GCC:
│ nop
1.81 │18:┌─→mov%rax,%r10
│ │if ( *(begin+(i-1)) < *(begin+i))
1.21 │1b:│ lea-0x1(%rcx),%rax
│ │_ZNK9__gnu_cxx17__normal_iteratorIPdSt6vectorIdSaIdEEEplEl():
2.02 │ │ lea0x0(,%rax,8),%r9
0.40 │ │ lea(%rsi,%r9,1),%r8
0.40 │ │ lea0x8(%rsi,%r9,1),%r9
│
│_ZN9benchmark9__sift_inISt16reverse_iteratorIS1_IN9__gnu_cxx17__normal_iteratorIPdSt6vectorIdSaIdEEdEEvlT_lT0_():
3.23 │ │ vmovsd (%r8),%xmm1
7.66 │ │ vmovsd (%r9),%xmm2
0.40 │ │ vcomis %xmm1,%xmm2
8.67 │ │↓ jbe4d
4.64 │ │ vmovap %xmm2,%xmm1
│ │i++;
18.55 │ │ mov%rcx,%rax
│ │ mov%r9,%r8
1.01 │ │ inc%rcx
│ │for ( i = 2*(free+1); i < count; i += i) {
4.64 │4d:│ add%rcx,%rcx
│ │*(begin + free) = *(begin+(i-1));
19.76 │ │ vmovsd %xmm1,(%rsi,%r10,8)
│ │for ( i = 2*(free+1); i < count; i += i) {
8.06 │ │ cmp%rcx,%rdi
│ └──jg 18
│free = i-1;
│}
The code is:
void __sift_in(ptrdiff_t count, RandomAccessIterator begin, ptrdiff_t free_in,
T next)
{
ptrdiff_t i;
ptrdiff_t free = free_in;
// sift up the free node
for ( i = 2*(free+1); i < count; i += i) {
if ( *(begin+(i-1)) < *(begin+i))
i++;
*(begin + free) = *(begin+(i-1));
free = i-1;
}
// special case in sift up if the last inner node has only 1 child
if (i == count) {
*(begin + free) = *(begin+(i-1));
free = i-1;
}
// sift down the new item next
i = (free-1)/2;
while( (free > free_in) && *(begin+i) < next) {
*(begin + free) = *(begin+i);
free = i;
i = (free-1)/2;
}
*(begin + free) = next;
}
[Bug c++/86238] No diagnostic for virtual base class with inaccessible destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86238 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #4 from TC --- Dup of bug 55120?
[Bug lto/93057] New: -flto=64 -o "t#o" leads to an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93057
Bug ID: 93057
Summary: -flto=64 -o "t#o" leads to an error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When generating the internal makefile in lto-wrapper we need to avoid or escape
characters in filenames which are special for make.
jan@skylake:~> cat t.c
main() { }
jan@skylake:~> gcc -O2 t.c -o "t#o" -flto=64
t.c:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
1 | main() { }
| ^~~~
/tmp/cc6loZ7P.mk:1: *** missing separator. Stop.
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: error:
lto-wrapper failed
collect2: error: ld returned 1 exit status
[Bug testsuite/93058] New: FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058 Bug ID: 93058 Summary: FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors) Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at inbox dot ru Target Milestone: --- Noticed asan test failure: $ make check-c++ -j9 RUNTESTFLAGS='asan.exp=asan_test.C' FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors) Executing on host: /home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../xg++ -B/home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g -I/home/slyfox/dev/git/gcc/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -I/home/slyfox/dev/git/gcc/libstdc++-v3/include/backward -I/home/slyfox/dev/git/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 -msse2 -D__NO_INLINE__ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/ -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/.libs -lm -o ./asan_test.exe(timeout = 300) spawn -ignore SIGHUP /home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../xg++ -B/home/slyfox/dev/git/gcc-clean/gcc/testsuite/g++2/../../ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.C -fsanitize=address -g -I/home/slyfox/dev/git/gcc/gcc/testsuite/../../libsanitizer/include -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/libstdc++-v3/include -I/home/slyfox/dev/git/gcc/libstdc++-v3/libsupc++ -I/home/slyfox/dev/git/gcc/libstdc++-v3/include/backward -I/home/slyfox/dev/git/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -O2 -std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl -DASAN_NEEDS_SEGV=1 -DASAN_AVOID_EXPENSIVE_TESTS=1 -msse2 -D__NO_INLINE__ /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_globals_test-wrapper.cc -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/ -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libsanitizer/asan/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libstdc++-v3/src/.libs -B/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/ -L/home/slyfox/dev/git/gcc-clean/x86_64-pc-linux-gnu/./libitm/.libs -lm -o ./asan_test.exe In file included from /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.C:14: /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc: In function 'void AddressSanitizer_PvallocTest_fn()': /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:129:22: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:127:27: note: at offset 4197 to an object with size 4196 allocated by 'pvalloc' here /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:134:10: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] /home/slyfox/dev/git/gcc/gcc/testsuite/g++.dg/asan/asan_test.cc:132:21: note: at offset 101 to an object with size 0 allocated by 'pvalloc' here cc1plus: all warnings being treated as errors compiler exited with status 1 Executing on host: /home/slyfox/dev/git/gcc-clean/gcc/testsu
[Bug libstdc++/93059] New: char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
Bug ID: 93059
Summary: char and char8_t does not talk with each other with
memcpy. std::copy std::copy_n, std::fill, std::fill_n,
std::uninitialized_copy std::uninitialized_copy_n,
std::fill, std::uninitialized_fill_n fails to convert
to memxxx functions
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: euloanty at live dot com
Target Milestone: ---
https://godbolt.org/z/SPktTz
All these functions should generate exactly the same assembly but they do not.
GCC does not treat char and char8_t the same because libstdc++ does not do this
check. I did my native manually fix and it works. (does not do mul_overflow
something)
//g++ -S copy.cc -Ofast -std=c++2a
#include
#include
#include
#include
#include
auto copy_char8_t_array(char* out,std::array const& bits)
{
return std::copy_n(bits.data(),bits.size(),out);
}
auto memcpy_char8_t_array(char* out,std::array const& bits)
{
std::memcpy(out,bits.data(),bits.size());
return bits.size();
}
auto copy_char_array(char* out,std::array const& bits)
{
return std::copy_n(bits.data(),bits.size(),out);
}
auto memcpy_char_array(char* out,std::array const& bits)
{
std::memcpy(out,bits.data(),bits.size());
return bits.size();
}
auto copy_char_array_chars(char8_t* out,std::array const& bits)
{
return std::copy_n(bits.data(),bits.size(),out);
}
auto memcpy_char_array_array_chars(char8_t* out,std::array const&
bits)
{
std::memcpy(out,bits.data(),bits.size());
return bits.size();
}
auto copy_char_array(char8_t* out,std::array const& bits)
{
return std::copy_n(bits.data(),bits.size(),out);
}
auto memcpy_char_array(char8_t* out,std::array const& bits)
{
std::memcpy(out,bits.data(),bits.size());
return bits.size();
}
template
inline constexpr output_iter my_copy_n(input_iter first,std::size_t
count,output_iter result)
{
if constexpr(std::contiguous_iterator&&
std::contiguous_iterator&&
std::is_trivially_copyable_v::value_type>&&
std::is_trivially_copyable_v::value_type>)
{
if constexpr(sizeof(std::is_trivially_copyable_v::value_type>)
==sizeof(std::is_trivially_copyable_v::value_type>))
{
memcpy(std::to_address(result),std::to_address(first),
sizeof(typename
std::iterator_traits::value_type)*count);
return result+count;
}
}
return std::copy_n(first,count,result);
}
auto my_copy_char_array(char8_t* out,std::array const& bits)
{
return my_copy_n(bits.data(),bits.size(),out);
}
auto my_copy_char_array(char* out,std::array const& bits)
{
return my_copy_n(bits.data(),bits.size(),out);
}
auto uninit_copy_char_array(char8_t* out,std::array const& bits)
{
return std::uninitialized_copy_n(bits.data(),bits.size(),out);
}
_Z29memcpy_char_array_array_charsPDuRKSt5arrayIDuLm2EE:
movzwl (%rsi), %eax
movw%ax, (%rdi)
movl$2, %eax
ret
std::copy_n generates more assembly than it should
_Z15copy_char_arrayPDuRKSt5arrayIcLm2EE:
movzbl (%rsi), %eax
movb%al, (%rdi)
movzbl 1(%rsi), %eax
movb%al, 1(%rdi)
leaq2(%rdi), %rax
ret
[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058
--- Comment #1 from Sergei Trofimovich ---
Th important bits seems to be:
gcc/testsuite/g++.dg/asan/asan_test.cc:129:22: error: writing 1 byte into a
region of size 0 [-Werror=stringop-overflow=]
I think it happens because glibc marks pvalloc() as malloc()-like function.
Test explicitly assumes that granularity is page-wide:
char *a = (char*)pvalloc(kPageSize + 100);
EXPECT_EQ(0U, (uintptr_t)a % kPageSize);
/* 129 */ a[kPageSize + 101] = 1; // we should not report an error here.
free(a);
As build fails due to -Werror what would be a reasonable fix here?
I tested adding -Wno-stringop-overflow as and it seems to work:
$ git diff -U0 | cat
diff --git a/gcc/testsuite/g++.dg/asan/asan_test.C
b/gcc/testsuite/g++.dg/asan/asan_test.C
index f3f7626ef3b..8e18744c7c6 100644
--- a/gcc/testsuite/g++.dg/asan/asan_test.C
+++ b/gcc/testsuite/g++.dg/asan/asan_test.C
@@ -5 +5 @@
-// { dg-options "-std=c++11 -fsanitize=address -fno-builtin -Wall -Werror -g
-DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1 -DASAN_HAS_BLACKLIST=0
-DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" }
+// { dg-options "-std=c++11 -fsanitize=address -fno-builtin -Wall -Werror
-Wno-stringop-overflow -g -DASAN_UAR=0 -DASAN_HAS_EXCEPTIONS=1
-DASAN_HAS_BLACKLIST=0 -DSANITIZER_USE_DEJAGNU_GTEST=1 -lasan -lpthread -ldl" }
[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033
zwen7 at binghamton dot edu changed:
What|Removed |Added
CC||zwen7 at binghamton dot edu
--- Comment #5 from zwen7 at binghamton dot edu ---
I am also having the same problem.
My code is here:
https://github.com/zyddnys/PatchyVideo-autocomplete
compile command line: g++ -O3 -std=c++2a -o autocomplete.app autocomplete.cpp
compiler is compiled from latest pull from github.
In file included from autocomplete.cpp:7:
tree.h: In function ‘void AddTag(uint32_t, uint32_t, uint32_t)’:
tree.h:151:6: error: incorrect sharing of tree nodes
151 | void AddTag(std::uint32_t id, std::uint32_t count, std::uint32_t
category)
| ^~
MEM[(struct Tag *)D.232969]
MEM[(struct Tag *)D.232969].count = count;
tree.h:151:6: error: incorrect sharing of tree nodes
MEM[(struct Tag *)D.232969]
MEM[(struct Tag *)D.232969].category = category;
tree.h:151:6: error: incorrect sharing of tree nodes
MEM[(struct Tag *)D.232969]
MEM[(struct Tag *)D.232969].lang_keywords = {};
tree.h:151:6: error: incorrect sharing of tree nodes
MEM[(struct Tag *)D.232969]
MEM[(struct Tag *)D.232969].alias_keywords = {};
during GIMPLE pass: cfg
tree.h:151:6: internal compiler error: verify_gimple failed
0x1013f4a verify_gimple_in_cfg(function*, bool)
../.././gcc/tree-cfg.c:5445
0xefad8f execute_function_todo
../.././gcc/passes.c:1983
0xefbbcc do_per_function
../.././gcc/passes.c:1638
0xefbbcc execute_todo
../.././gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
gcc -v:
sing built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --with-pkgversion=somegcc --disable-multilib
--enable-languages=c,c++,lto --disable-bootstrap : (reconfigured) ./configure
--with-pkgversion=somegcc --disable-multilib --enable-languages=c,c++,lto
--disable-bootstrap : (reconfigured) ./configure --with-pkgversion=patchygcc
--disable-multilib --enable-languages=c,c++,lto --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20191223 (experimental) (somegcc)
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #1 from fdlbxtqi --- I am going to rewrite these functions by C++20 concepts + if constexpr for C++20 for you, Jwakely. I do not believe these enable-if/ overloading functions would not be a problem.
[Bug target/93047] frename-registers does not work well with __builtin_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- I cannot reproduce this problem. What am I missing?
[Bug tree-optimization/93023] give preference to address iv without offset in ivopts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93023 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #1 from Wilco --- (In reply to Feng Xue from comment #0) > Analysis into ivopts shows that those address IVs have same in-loop cost, > and IV w/o offset does have smaller pre-loop setup cost. But since the setup > cost will be averaged to each iteration, the minor cost difference will go > due to round-off by integer division. To fix this round-off error, cost can > be represented in a more accurate way, such as adding a fraction part to > make it a fixpoint number. It would be easy to adjust the costs. There are a few places where address costs (multiples of 1) are incorrectly mixed with rtx costs (multiples of 4), so adjusting address costs should improve things. However I suspect the problem is also caused by using overly high iteration estimates and not taking codesize into account. If the loop costs are identical then you obviously choose the variant with the fewest instructions.
[Bug target/93047] frename-registers does not work well with __builtin_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047 --- Comment #2 from Jiu Fu Guo --- Sorry for missing -fpic gcc builtin-return-1.c -O3 -fpic -frename-registers -o ./builtin-return-1.exe and this issue can be reproduced on gcc7.4, gcc6.4 is ok.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #2 from fdlbxtqi ---
Also find a bug of __memmove
/*
* A constexpr wrapper for __builtin_memmove.
* @param __num The number of elements of type _Tp (not bytes).
*/
template
_GLIBCXX14_CONSTEXPR
inline void*
__memmove(_Tp* __dst, const _Tp* __src, size_t __num)
{
#ifdef __cpp_lib_is_constant_evaluated
if (std::is_constant_evaluated())
{
for(; __num > 0; --__num)
{
if constexpr (_IsMove)
*__dst = std::move(*__src);
else
*__dst = *__src;
++__src;
++__dst;
}
return __dst;
}
else
#endif
return __builtin_memmove(__dst, __src, sizeof(_Tp) * __num);
return __dst;
}
The last 2nd line return __dst is wrong. It should not exist.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059 --- Comment #3 from fdlbxtqi --- https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algobase.h I have found out the problem. 1. libstdc++ does not use memmove for different trivially copyable objects. It only uses it for the same type which is clearly incorrect. The performance lost is HUGE in my benchmarks for losing at least 50% of performance in some critical path. https://godbolt.org/z/ouNiHn For vector, the performance lost is even worse. It generates 96 lines of assembly for different types since it does not call memmove. 2. memmove should not be used for different types unless the source and dest have char*, char const* and std::byte* for trivially copyable types. It should call memcpy because of the strict-aliasing rule. However, I do not know whether it is possible to detect the strict-aliasing context for libstdc++ in GCC. It should add some magic here to make it faster.
[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #4 from fdlbxtqi ---
A demo fix would be like this i think:
template
inline constexpr output_iter my_copy_n(input_iter first,std::size_t
count,output_iter result)
{
using input_value_type = typename
std::iterator_traits::value_type;
using output_value_type = typename
std::iterator_traits::value_type;
if constexpr
(std::contiguous_iterator&&
std::contiguous_iterator&&
std::is_trivially_copyable_v&&
std::is_trivially_copyable_v&&
(std::same_as||(std::integral&&
std::integral&&sizeof(std::is_trivially_copyable_v)==sizeof(std::is_trivially_copyable_v
{
if (std::is_constant_evaluated())
{
for(;count--;)
{
*result=*first;
++first;
++result;
}
}
else
__builtin_memmove(std::to_address(result),std::to_address(first),
sizeof(typename
std::iterator_traits::value_type)*count);
return result+count;
}
return std::copy_n(first,count,result);
}
[Bug go/93020] Final patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020 --- Comment #3 from ian at gcc dot gnu.org --- Author: ian Date: Tue Dec 24 05:05:32 2019 New Revision: 279724 URL: https://gcc.gnu.org/viewcvs?rev=279724&root=gcc&view=rev Log: PR go/93020 libgo: Hurd portability patches By Svante Signell. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/212409 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/internal/poll/errno_unix.go trunk/libgo/go/os/export_unix_test.go trunk/libgo/go/runtime/os_hurd.go trunk/libgo/go/syscall/export_unix_test.go
[Bug go/93020] Final patches to build gcc-10 on GNU/Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Ian Lance Taylor --- Patches committed.
[Bug libstdc++/93060] New: __uint128_t is not an std::integral/std::unsigned_integral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060 Bug ID: 93060 Summary: __uint128_t is not an std::integral/std::unsigned_integral Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: euloanty at live dot com Target Milestone: --- Host: GCC 10 https://en.cppreference.com/w/cpp/types/is_integral :5:20: error: static assertion failed 5 | static_assert(std::unsigned_integral<__uint128_t>); | ~^~ :5:20: note: constraints not satisfied The cppreference said, "or any implementation-defined extended integer types". Checks whether T is an integral type. Provides the member constant value which is equal to true, if T is the type bool, char, char8_t, char16_t, char32_t, wchar_t, short, int, long, long long, or any implementation-defined extended integer types, including any signed, unsigned, and cv-qualified variants. Otherwise, value is equal to false. https://godbolt.org/z/vm68cj
[Bug libstdc++/93060] __uint128_t is not an std::integral/std::unsigned_integral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060 --- Comment #1 from Andrew Pinski --- >extended integer types Because it is not an extended integer type.
[Bug libstdc++/93060] __uint128_t is not an std::integral/std::unsigned_integral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060 fdlbxtqi changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from fdlbxtqi --- (In reply to Andrew Pinski from comment #1) > >extended integer types > > Because it is not an extended integer type. Ok. Thank you for your answer
[Bug libstdc++/93060] __uint128_t is not an std::integral/std::unsigned_integral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060 --- Comment #2 from fdlbxtqi --- (In reply to Andrew Pinski from comment #1) > >extended integer types > > Because it is not an extended integer type. Ok. Thank you for your answer
[Bug libstdc++/93060] __uint128_t is not an std::integral/std::unsigned_integral
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060 --- Comment #4 from Andrew Pinski --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595#c11 : The implementation-defined extended integer types are documented alongside the other implementation-defined behavior in implement-c.texi: "GCC does not support any extended integer types.".
[Bug rtl-optimization/93061] New: Optimising for size -Os causes segfault with AES-NI reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061 Bug ID: 93061 Summary: Optimising for size -Os causes segfault with AES-NI reference Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mutex at fastmail dot co.uk Target Milestone: --- Created attachment 47544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47544&action=edit Example code that causes bug. The function AES_256_Key_Expansion from the reference AES-NI causes a segfault (on Ubuntu 16.10) when gcc -Os optimisation is used.
[Bug target/93061] Optimising for size -Os causes segfault with AES-NI reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061 Andrew Pinski changed: What|Removed |Added Target||x86_64-linux-gnu Component|rtl-optimization|target --- Comment #1 from Andrew Pinski --- GCC 5.x is no longer supported, Can you try GCC 8.3 or 9.2?
[Bug target/93062] New: Failed to generate indirect branch for long branches on risc-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062
Bug ID: 93062
Summary: Failed to generate indirect branch for long branches
on risc-v
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: adrien.sf.wu at gmail dot com
Target Milestone: ---
When compiling for RISC-V targets, if the program contains a branch across 2^19
bytes of code or more (for example, an `if` block containing 2^18
instructions), the compiler does not generate an indirect branch. This results
in an immediate overflow in JAL instruction and makes the file unlinkable.
For example,
$ riscv64-linux-gnu-gcc -O0 -c test.c -o test.o
generates the following code for the `if` branch:
$ objdump -d test.o
...
2e: 00e7d463 bge a5,a4,36
32: 8551606f jfff16886 <.L2+0xffe0>
...
If trying to link this file, the following error is produced:
$ riscv64-linux-gnu-gcc test.o main.o
test1.o: in function `a':
test1.c:(.text+0x32): relocation truncated to fit: R_RISCV_JAL against `.L2'
collect2: error: ld returned 1 exit status
Source code of test.c:
int a(int c) {
if (c < 12345) {
#define A \
{ int d = c % 12345; \
int e = c ^ d * 12345; \
int f = c * d % e % 12345; \
c = f; }
#define B A A A A A A
#define C B B B B B B
#define D C C C C C C
#define E D D D D D D
E E E E E
}
return c;
}
[Bug ipa/83411] function multiversioning should clone the entire sub-callgraph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83411 Yury Gribov changed: What|Removed |Added CC||ygribov at gcc dot gnu.org --- Comment #5 from Yury Gribov --- (In reply to Martin Liška from comment #4) > So finding > a point like your 'loop' and using flatten attribute can guarantee the > call-chain is fully optimized. Would be interesting to come up with more > examples from real applications. As this is not immediately obvious and/or googleable, perhaps we could add a note to docs for pragma target and target/target_clones attributes?
[Bug target/93061] Optimising for size -Os causes segfault with AES-NI reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061 --- Comment #2 from Mutex --- Created attachment 47545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47545&action=edit Updated example Made a mistake in the first update which might've introduced a non-relevant segfault. This fixes it.
[Bug target/93061] Optimising for size -Os causes segfault with AES-NI reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061 --- Comment #3 from Mutex --- Repeated with gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0 The latest I have access to. Same thing. $ gcc -maes -Os *.c *.s $ ./a.out Segmentation fault (core dumped) $ gcc -maes *.c *.s $ ./a.out $
