[Bug target/64691] Suboptimal register allocation for bytes comparison on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64691 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-25 Severity|normal |enhancement Status|UNCONFIRMED |NEW --- Comment #3 from Andrew Pinski --- Confirmed: .L3: movl%edx, %ecx movzbl (%eax), %edx addl$1, %eax movb%cl, -1(%eax) movl%esi, %ecx cmpb%dl, %cl jne .L3
[Bug tree-optimization/30128] byte independent store not done in some cases due to truncation of addition too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30128
Andrew Pinski changed:
What|Removed |Added
Summary|Strange code generated |byte independent store not
||done in some cases due to
||truncation of addition too
||early
--- Comment #3 from Andrew Pinski ---
These two functions should produce the same code but only foo1 produces one
store and one add.
#define GSF_LE_SET_GUINT32(p, dat) \
((*((char *)(p) + 0) = (char) ((dat)) & 0xff),\
(*((char *)(p) + 1) = (char) ((dat) >> 8) & 0xff),\
(*((char *)(p) + 2) = (char) ((dat) >> 16) & 0xff),\
(*((char *)(p) + 3) = (char) ((dat) >> 24) & 0xff))
void bar (void *);
void
foo (unsigned i)
{
char buffer[4];
unsigned len = i + 1;
GSF_LE_SET_GUINT32 (buffer, len + 1);
bar (buffer);
}
void
foo1 (unsigned i)
{
char buffer[4];
unsigned len = i + 1;
len += 1;
GSF_LE_SET_GUINT32 (buffer, len);
bar (buffer);
}
[Bug tree-optimization/61481] Poor optimization of simple small-sized matrix routines with constant data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61481 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |10.0 --- Comment #4 from Andrew Pinski --- The original testcase is all optimized in GCC 10. The second testcase is undefined and gets optimized down to __builtin_unreachable. File a well defined testcase for the other one and we can see what needs to be optimized. So closing as fixed for GCC 10, the late FRE which was added is exactly what optimizes this case.
[Bug tree-optimization/59986] Unnecessary edges in the CFG due to setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59986 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |9.0 --- Comment #4 from Andrew Pinski --- Fixed for GCC 9 by r9-6254, gcc.dg/torture/pr57147-2.c testcase which was changed in that revision to not expect a setjmp is a similar testcase where we have a noreturn function followed by a setjmp function. So we create the unnecessary edges but then clean them up.
[Bug tree-optimization/59786] GIMPLE invariant motion misses opportunity to reduce register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59786 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/59786] GIMPLE invariant motion misses opportunity to reduce register pressure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59786 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-25 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug rtl-optimization/34653] operation performed unnecessarily in 64-bit mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34653
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #10 from Andrew Pinski ---
For the original testcase here is what other compilers do:
LLVM trunk:
movzbl (%rdi), %eax
shrq%rax
andl$120, %eax
movqtable(%rax), %rax
retq
ICC 2021.3.0:
movzbl(%rdi), %eax #5.29
shrq $4, %rax #6.23
movq table(,%rax,8), %rax #6.10
ret
MSVC:
movzx eax, BYTE PTR [rcx]
lea rcx, OFFSET FLAT:unsigned long * table; table
shr rax, 4
mov eax, DWORD PTR [rcx+rax*4]
ret 0
GCC trunk:
movzbl (%rdi), %eax
shrq$4, %rax
movqtable(,%rax,8), %rax
Trying 7 -> 8:
7: r89:DI=zero_extend([r92:DI])
REG_DEAD r92:DI
8: {r90:DI=r89:DI 0>>0x4;clobber flags:CC;}
REG_DEAD r89:DI
REG_UNUSED flags:CC
Failed to match this instruction:
(parallel [
(set (reg:DI 90)
(zero_extract:DI (mem:QI (reg:DI 92) [0 *p_4(D)+0 S1 A8])
(const_int 4 [0x4])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
])
Failed to match this instruction:
(set (reg:DI 90)
(zero_extract:DI (mem:QI (reg:DI 92) [0 *p_4(D)+0 S1 A8])
(const_int 4 [0x4])
(const_int 4 [0x4])))
Failed to match this instruction:
(set (reg:DI 90)
(and:DI (subreg:DI (lshiftrt:QI (mem:QI (reg:DI 92) [0 *p_4(D)+0 S1 A8])
(const_int 4 [0x4])) 0)
(const_int 15 [0xf])))
[Bug target/35926] Pushing / Poping ebx without using it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35926 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |5.0 Status|NEW |RESOLVED Known to work||5.1.0 --- Comment #9 from Andrew Pinski --- Fixed in GCC 5+. I know comment #8 said it was fixed in GCC 4.8.0 but I could reproduce the missed optimization in released GCC 4.8.1 through 4.9.4.
[Bug tree-optimization/40168] finding common subexpressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
--- Comment #22 from Andrew Pinski ---
With the trunk on the second testcase, SLP works but we get stuff like:
_2 = (*b_420(D))[80];
_4 = (*b_420(D))[79];
_538 = {_2, _4};
_980 = _538 * vect__1.182_559;
Shouldn't that just be loading a vector from (*b_420(D))[79] and then doing an
VEC_PERM?
In a reduced C testcase we get the correct thing:
typedef double array[1000];
void f(array *a, array *b, array *c)
{
double t = (*a)[1] * (*b)[0];
double t1 = (*a)[0] * (*b)[0];
double t2 = (*a)[3] * (*b)[1];
double t3 = (*a)[2] * (*b)[1];
(*c)[0] = t;
(*c)[1] = t1;
(*c)[2] = t2;
(*c)[3] = t3;
}
[Bug tree-optimization/28850] missed call -> jmp transformation; redundant unwind stuff with empty finally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28850
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2006-08-25 21:59:14 |2021-12-24
Keywords|patch |EH
--- Comment #6 from Andrew Pinski ---
When we get to tailc pass we have the following IR still:
;; Function bar (_Z3barPFvvE, funcdef_no=7, decl_uid=4010, cgraph_uid=8,
symbol_order=7)
void bar (void (*) (void) f)
{
;; basic block 2, loop depth 0
;;pred: ENTRY
f_2(D) ();
;;succ: 4
;;3
;; basic block 3, loop depth 0
;;pred: 2
return;
;;succ: EXIT
;; basic block 4, loop depth 0
;;pred: 2
:
resx 2
;;succ:
}
And the resx is removed while in resx pass while we might as well remove it
before hand really because the bb is empty otherwise.
[Bug ipa/39298] Optimize away only set but not used variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39298 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |5.0 Status|NEW |RESOLVED Resolution|--- |FIXED Component|middle-end |ipa CC||marxin at gcc dot gnu.org --- Comment #8 from Andrew Pinski --- Fixed in GCC 5 by r5-657.
[Bug rtl-optimization/91721] Missed optimization for checking nan and comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91721 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2019-09-11 00:00:00 |2021-12-24
[Bug rtl-optimization/86892] RTL CSE commoning trivial constants across call and/or too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892 Andrew Pinski changed: What|Removed |Added Build|powerpc64le-unknown-linux-g | |nu | Target|powerpc64le-unknown-linux-g |powerpc*-*-* aarch64-*-* |nu | Last reconfirmed|2018-08-08 00:00:00 |2021-12-24 Host|powerpc64le-unknown-linux-g | |nu | --- Comment #2 from Andrew Pinski --- s/0/1 and you will see the effect on aarch64 as mentioned in comment #1 . Though I notice LLVM does the same thing.
[Bug middle-end/38518] Excessive compile time with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38518 Andrew Pinski changed: What|Removed |Added Host|suse-linux-x86_64 | Component|rtl-optimization|middle-end Target||x86_64-*-* --- Comment #16 from Andrew Pinski --- > callgraph functions expansion : 38.69 ( 98%) 0.88 ( 83%) 39.60 ( > 97%) 431M ( 93%) I know the above is a catch all though. At least one issue is this for the trunk: machine dep reorg : 7.23 ( 18%) 0.00 ( 0%) 7.23 ( 18%) 0 ( 0%) This is with checking enabled but with -fno-checking. So the x86 maintainer should look into why for that. Note the trunk with -O2 -fno-checking (compiled with --enable-checking=yes) is faster than 7.3 compiled with --enable-checking=release :). Nothing else stands out for the trunk even though -O3 is 39s while -O2 is 8s.
[Bug rtl-optimization/48064] Optimizer produces suboptimal code for e.g. x = x ^ (x >> 1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48064 Andrew Pinski changed: What|Removed |Added Target|windows 32 |i686-*-* x86_64-*-* Severity|normal |enhancement Status|UNCONFIRMED |NEW Keywords||ra Ever confirmed|0 |1 Last reconfirmed||2021-12-25 --- Comment #1 from Andrew Pinski --- Confirmed, it looks like a register allocation issue. Though I don't know how much it matters these days with some register renaming and mov instructions becoming issue latency of 0.
[Bug c++/24314] Extra "template<>" in partial specialization is compiled successfuly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24314 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/24314] Extra "template<>" in partial specialization is compiled successfuly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24314 Andrew Pinski changed: What|Removed |Added CC||glisse at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- *** Bug 63809 has been marked as a duplicate of this bug. ***
[Bug c++/63809] Missing warning on extra template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 24314. *** This bug has been marked as a duplicate of bug 24314 ***
[Bug c++/63809] Missing warning on extra template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63809
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
template
struct binary_traits{};
template <>
template
struct binary_traits
{
typedef int result_type;
};
- CUT
This is rejected since GCC 8 with:
:6:8: error: too many template-parameter-lists
struct binary_traits
^
I suspect there is a dup now.
[Bug c++/65923] False positive for warning about literal operator suffix and using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65923 Andrew Pinski changed: What|Removed |Added CC||mferoldif at gmail dot com --- Comment #10 from Andrew Pinski --- *** Bug 84435 has been marked as a duplicate of this bug. ***
[Bug c++/84435] -Wliteral-suffix warns on a using-directive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84435 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 65923 which is fixed in GCC 8. *** This bug has been marked as a duplicate of bug 65923 ***
[Bug c++/50986] weak static data members with constant initializers emitted in .rodata, leading to segfault on startup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50986 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from Andrew Pinski --- How clang fixes this is by putting the global initializer for U::k (in TU2) in the same comdat section as the non-readonly case.
[Bug c++/81557] Detect unused const char * and STL string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81557 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-25 Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Confirmed, even though this might be useful warning, I don't see how it can be implemented.
[Bug tree-optimization/79517] using a deque supresses compiler warning for undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79517
--- Comment #2 from Andrew Pinski ---
Confirmed, though with a reduced testcase, I got the opposite effect of having
the constructor/deconstructor causing the warning to show up while not having
it causes it not to show.
struct g
{
g();
~g();
};
[[gnu::always_inline]]
inline void nowarning_data(float *data, int &n)
{
for(int i=0; i<4800; ++i)
data[i] = n++;
}
[[gnu::always_inline]]
inline void warning_data(float *data, int &n)
{
for(int i=0; i<4800; ++i)
data[i] = n++;
}
void nowarning()
{
float data[4800];
int n { 0 };
for(int i=0; i<80; ++i) {
nowarning_data(data, n);
}
}
void warning()
{
struct g d;
float data[4800];
int n { 0 };
for(int i=0; i<80; ++i) {
warning_data(data, n);
}
}
[Bug c++/39992] cc1plus exhausts memory with deeply nested unclosed constructor parens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39992 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug c++/39992] cc1plus exhausts memory with deeply nested unclosed constructor parens
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39992 Andrew Pinski changed: What|Removed |Added CC||terra at gnome dot org --- Comment #2 from Andrew Pinski --- *** Bug 63295 has been marked as a duplicate of this bug. ***
[Bug c++/63295] Insane memory use on invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63295 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 39992. *** This bug has been marked as a duplicate of bug 39992 ***
[Bug c++/72768] Potential bug about the order of destructors of static objects and atexit() callbacks in C++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72768 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #9 from Andrew Pinski --- clang and ICC do have the same behavior as GCC here ...
[Bug c++/7748] Static objects in dynamic library with non-default priority not initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7748 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Andrew Pinski --- Yes moving the attrribute fixed the issue. Note a few other things: * I needed to add -fPIC to the command line while building the shared libraries. * I needed to add -Wl,--no-as-needed while linking the executable due to Ubuntu's gcc defaulting to --as-needed. Other than that, it seems like it works and seems to have worked since GCC 4 or earlier.
[Bug c++/7748] Static objects in dynamic library with non-default priority not initialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7748 --- Comment #8 from Andrew Pinski --- First problem looks like: S.C:16:50: error: attributes after parenthesized initializer ignored [-fpermissive] 16 | S s2 (65534) __attribute__((init_priority(65534))); | ^ S.C:17:46: error: attributes after parenthesized initializer ignored [-fpermissive] 17 | S s3 (101) __attribute__((init_priority(101))); | ^ Makefile:5: recipe for target 'libS.so' failed Where the comment in the source is: /* The old parser allows attributes to appear after a parenthesized initializer. Mark Mitchell proposed removing this functionality on the GCC mailing lists on 2002-08-13. This parser accepts the attributes -- but ignores them. Made a permerror in GCC 8. */ Let me swap around the order to see if that fixes the issue.
[Bug c++/67324] Failures in Assignable concept's requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67324
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Keywords||rejects-valid
Resolution|--- |FIXED
Target Milestone|--- |10.0
--- Comment #2 from Andrew Pinski ---
Note this is a fixed up testcase for GCC 10 with -std=c++17 -fconcepts (I don't
know how to fix it up to C++20 syntax though):
template< typename T, typename U >
concept bool
Same( )
{
return __is_same_as(T, U);
}
template< class T >
struct remove_reference { using type = T; };
template< class U >
struct remove_reference { using type = U; };
template< class U >
struct remove_reference { using type = U; };
template< class T >
using remove_reference_t = typename remove_reference::type;
template< typename T >
constexpr T&&
forward( remove_reference_t& t) noexcept
{ return static_cast(t); }
template< typename T >
constexpr T&&
forward( remove_reference_t&& t) noexcept
{ return static_cast(t); }
template< class T, class U = T >
concept bool
Assignable( )
{
return
requires( T&& a, U&& b ) {
{ forward(a) = forward(b) } -> Same;// #1
requires Same(a) = forward(b))>(); // #2
};
}
template< typename T, typename U = T >
constexpr bool
test( ) { return false; }
template< typename T, typename U = T >
requires Assignable()
constexpr bool
test( ) { return true; }
struct A { };
struct B { B& operator = ( B const& ) = delete; };
struct C { C& operator = ( C&& ) = delete; };
struct D { D& operator = ( D const& ) = delete; D& operator = ( D&& ) =
default; };
struct E { E& operator = ( E const & ); };
struct F { A& operator = ( F const & ); };
int
main( )
{
static_assert( not test(), "" );
static_assert( test(), "" );
static_assert( not test(), "" );
static_assert( test(), "" );
static_assert( test(), "" );
static_assert( not test(), "" );
static_assert( test(), "" );
static_assert( test(), "" );
static_assert( test(), "" );
static_assert( test(), "" );
static_assert( test(), "" );
static_assert( not test(), "" );
static_assert( not test(), "" );
static_assert( not test(), "" );
static_assert( not test(), "" );
static_assert( test(), "" );
static_assert( test(), "" );
static_assert( not test(), "" );
return 0;
}
Oh and it is fixed in GCC 10+, most likely by the rewrite of concepts to be
complaint with the C++20 standard.
[Bug c++/66472] -Wshadow gets confused by using statements in template classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66472
--- Comment #7 from Andrew Pinski ---
GCC even warns for:
template struct Foo : T {
typedef T Base;
Foo(int size) : Base(size) {}
using Base::size;
};
While clang does not even warn for this case:
struct Foo {
Foo(int size) {}
int size;
};
clang does not warn for constructors but do for normal methods:
struct Foo {
void g(int size) {}
int size;
};
I don't know if it is a good idea to warn for constructors after all
[Bug c++/37667] Initialization of global variables and functions with constructor attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37667 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski --- (In reply to Michael Uleysky from comment #2) > The priority must not be same. The only method to interact constructor > function with main is global variables. It is no reason to initialize global > variables after constructor function. Anyway, > > Test ex_t __attribute__ ((init_priority(102))); > void Init() __attribute__ ((constructor(101))); Because you have the wrong order, lower number is a higher priority which means 101/Init will always be first. From https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Common-Function-Attributes.html#index-constructor-function-attribute: "However, at present, the order in which constructors for C++ objects with static storage duration and functions decorated with attribute constructor are invoked is unspecified. In mixed declarations, attribute init_priority can be used to impose a specific ordering." "A constructor with a smaller priority number runs before a constructor with a larger priority"
[Bug c++/103825] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-25 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98043 --- Comment #1 from Andrew Pinski --- Confirmed, the ICE is not a regression or rather it is hard to tell if it is a regression or not just using godbolt as it even ICEs in GCC 6.1.0 with -fchecking, GCC 5 didn't have -fchecking.
[Bug c++/103825] New: [12 Regression] ICE on switch on enum class in bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103825
Bug ID: 103825
Summary: [12 Regression] ICE on switch on enum class in
bitfield
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
enum class Type { Pawn };
struct Piece {
Type type : 4;
};
void foo() {
switch (Piece().type)
case Type::Pawn:;
}
The above causes an ICE on GCC 12.0.0 20211222, no compile flags needed. It
compiles without warnings on GCC 11, Clang, and MSVC.
Compiler Explorer: https://godbolt.org/z/GdG6ovEzz
: In function 'void foo()':
:5:6: error: type precision mismatch in switch statement
5 | void foo() {
| ^~~
switch (retval.0) , case 0: >
:5:6: internal compiler error: 'verify_gimple' failed
0x2115089 internal_error(char const*, ...)
???:0
0x11603ed verify_gimple_in_seq(gimple*)
???:0
0xdda0d1 gimplify_body(tree_node*, bool)
???:0
0xdda397 gimplify_function_tree(tree_node*)
???:0
0xbe6a57 cgraph_node::analyze()
???:0
0xbeaf6d symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug middle-end/89543] Don't modify TREE_NO_WARNING during folding in place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89543 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Andrew Pinski --- Testing the obvious patch to remove the special handling in fold_checksum_tree.
[Bug middle-end/89543] Don't modify TREE_NO_WARNING during folding in place
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89543 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-24 Ever confirmed|0 |1 Target Milestone|--- |12.0 --- Comment #1 from Andrew Pinski --- Fixed for GCC 12 by r12-1805-ge9e2bad7251477 which removes all uses of TREE_NO_WARNING from fold-const.c and builtin* and move over to location based warning supression system. Except the usage in fold_checksum_tree was moved over too incorrectly and should have been removed instead.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #47 from Lewis Hyatt --- (In reply to Manuel López-Ibáñez from comment #46) > If you don't get much attention to the patch, it may be worth pinging it. > But before that, I would also suggest submitting all the cleanups separately > as their own, easy-to-review patch. For example, the bits about > cp_token_is_module_directive. Thank you for the note, I have resubmitted it to gcc-patches in two parts: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587358.html The cp_token_is_module_directive that you highlighted clearly should be in its own patch, yes. I looked through the rest though and wasn't able to identify anything else that seemed to make sense when split out on its own, so that ended up being the only thing I factored out.
[Bug c++/100084] using enum lookup isn't type-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100084 Andrew Pinski changed: What|Removed |Added CC||luizfvalle at pm dot me --- Comment #4 from Andrew Pinski --- *** Bug 103824 has been marked as a duplicate of this bug. ***
[Bug c++/103824] Enum class shadowed by class member in using-enum-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103824 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 100084. *** This bug has been marked as a duplicate of bug 100084 ***
[Bug tree-optimization/84214] recip and slp passes conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84214 --- Comment #2 from Andrew Pinski --- I am almost want to say the new testsuite failure that just happened on the trunk is caused by this too: https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587355.html
[Bug c++/103824] New: Enum class shadowed by class member in using-enum-declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103824 Bug ID: 103824 Summary: Enum class shadowed by class member in using-enum-declaration Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: luizfvalle at pm dot me Target Milestone: --- Created attachment 52056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52056&action=edit Input file (test.cpp) A global enum class is shadowed by a class member of the same name in a using-enum-declaration. Lookup finds the enum class correctly when referred outside the using-enum-declaration. Command and error: g++ -std=c++20 -c test.cpp test.cpp: In member function ‘void C::F()’: test.cpp:7:20: error: ‘E’ is not a type 7 | using enum E; | System type: x86_64-pc-linux-gnu All options given when GCC was configured/built: --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc Error also happens in godbolt.org's trunk build, and is absent from other compilers.
[Bug tree-optimization/84083] [missed optimization] loop-invariant strlen() not hoisted out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84083 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization Keywords||alias Severity|normal |enhancement
[Bug middle-end/61562] Compiler crash when combining -Wstrict-overflow=4 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61562 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #2 from Andrew Pinski --- Fixed in GCC 6 by removal of the warning via r6-1114.
[Bug target/55277] [4.8 regression] ICE in assign_by_spills, at lra-assigns.c:1217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55277 Bug 55277 depends on bug 32647, which changed state. Bug 32647 Summary: spill failures with hard-register variable https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32647 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/32647] spill failures with hard-register variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32647 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Known to work||11.1.0, 4.8.1, 5.1.0, 9.1.0 Target Milestone|--- |4.8.0 Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=55277 Keywords||ice-on-valid-code --- Comment #4 from Andrew Pinski --- Fixed back in GCC 4.8.0 (most likely by the patch which fixed PR 55277).
[Bug middle-end/35696] Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35696 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.3.0 --- Comment #7 from Andrew Pinski --- Worked for me back in GCC 4.3 so closing.
[Bug target/103785] [12 Regression] Ada bootstrap ICEs on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103785
--- Comment #10 from H.J. Lu ---
Before
(insn 8 5 70 2 (set (reg:SI 1 dx [92])
(const_int 714200473 [0x2a91d599]))
"/export/gnu/import/git/gitlab/x86-gcc-test/gcc/ada/sem_type.adb":2563:7 70
{*movsi_internal}
(expr_list:REG_EQUIV (const_int 714200473 [0x2a91d599])
(nil)))
(insn 70 8 9 2 (set (reg:SI 0 ax [105])
(reg:SI 0 ax [orig:89 k ] [89]))
"/export/gnu/import/git/gitlab/x86-gcc-test/gcc/ada/sem_type.adb":2563:7 70
{*movsi_internal}
(nil))
(insn 9 70 10 2 (parallel [
(set (reg:SI 1 dx [91])
(smul_highpart:SI (reg:SI 0 ax [105])
(reg:SI 1 dx [92])))
(clobber (reg:SI 0 ax [105]))
(clobber (reg:CC 17 flags))
])
"/export/gnu/import/git/gitlab/x86-gcc-test/gcc/ada/sem_type.adb":2563:7 383
{smulsi3_highpart}
(expr_list:REG_DEAD (reg:SI 0 ax [105])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_UNUSED (reg:SI 0 ax [105])
(expr_list:REG_EQUAL (smul_highpart:SI (reg/v:SI 3 bx [orig:89
k ] [89])
(const_int 714200473 [0x2a91d599]))
(nil))
After
(insn 95 5 96 2 (set (reg:SI 0 ax [105])
(const_int 714200473 [0x2a91d599]))
"/export/gnu/import/git/gitlab/x86-gcc-test/gcc/ada/sem_type.adb":2563:7 -1
(nil))
(insn 96 95 10 2 (parallel [
(set (reg:SI 1 dx [91])
(smul_highpart:SI (reg:SI 0 ax [105])
(reg:SI 0 ax [orig:89 k ] [89])))
(clobber (reg:SI 0 ax [105]))
(clobber (reg:CC 17 flags))
])
"/export/gnu/import/git/gitlab/x86-gcc-test/gcc/ada/sem_type.adb":2563:7 -1
(nil))
[Bug target/103785] [12 Regression] Ada bootstrap ICEs on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103785 --- Comment #9 from H.J. Lu --- (In reply to H.J. Lu from comment #8) > Created attachment 52055 [details] > Good and bad asm > > --- good.s2021-12-24 11:24:26.531365375 -0800 > +++ bad.s 2021-12-24 11:24:30.769344666 -0800 > @@ -10,7 +10,6 @@ sem_type__interp_map__setX: > .cfi_def_cfa_offset 8 > .cfi_offset 7, -8 > movl%edx, %edi > - movl$714200473, %edx > pushl %esi > .cfi_def_cfa_offset 12 > .cfi_offset 6, -12 > @@ -18,7 +17,8 @@ sem_type__interp_map__setX: > .cfi_def_cfa_offset 16 > .cfi_offset 3, -16 > movl%eax, %ebx > - imull %edx > + movl$714200473, %eax This is wrong since EAX is an implicit input operand. > + imull %eax > movl%ebx, %eax > sarl$31, %eax > sarl$9, %edx
[Bug target/103785] [12 Regression] Ada bootstrap ICEs on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103785 --- Comment #8 from H.J. Lu --- Created attachment 52055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52055&action=edit Good and bad asm --- good.s 2021-12-24 11:24:26.531365375 -0800 +++ bad.s 2021-12-24 11:24:30.769344666 -0800 @@ -10,7 +10,6 @@ sem_type__interp_map__setX: .cfi_def_cfa_offset 8 .cfi_offset 7, -8 movl%edx, %edi - movl$714200473, %edx pushl %esi .cfi_def_cfa_offset 12 .cfi_offset 6, -12 @@ -18,7 +17,8 @@ sem_type__interp_map__setX: .cfi_def_cfa_offset 16 .cfi_offset 3, -16 movl%eax, %ebx - imull %edx + movl$714200473, %eax + imull %eax movl%ebx, %eax sarl$31, %eax sarl$9, %edx @@ -2161,9 +2161,8 @@ sem_type__get_first_interp: cmpb$71, %al je .L242 .L226: - movl%ebx, %eax - movl$714200473, %edx - imull %edx + movl$714200473, %eax + imull %ebx movl%ebx, %eax sarl$31, %eax sarl$9, %edx @@ -10929,9 +10928,8 @@ sem_type__save_interps: cmpb$71, %al je .L1375 .L1358: - movl%ebx, %eax - movl$714200473, %edx - imull %edx + movl$714200473, %eax + imull %ebx movl%ebx, %eax sarl$31, %eax sarl$9, %edx
[Bug target/103785] [12 Regression] Ada bootstrap ICEs on i?86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103785 --- Comment #7 from H.J. Lu --- sem_type.adb is miscompiled.
[Bug c/100854] TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854 Eric Gallager changed: What|Removed |Added Last reconfirmed||2021-12-24 CC||egallager at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #4 from Eric Gallager --- (In reply to Francois-Xavier Coudert from comment #2) > This affects x86_64-apple-darwin: > https://gcc.gnu.org/pipermail/gcc/2021-December/237959.html > > The system header errors out on any value of __FLT_EVAL_METHOD__ > that is not -1, 0, 1, or 2. Taking this as confirmation.
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 --- Comment #18 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8f921393e339090566c1589d81009caa954de90d commit r12-6113-g8f921393e339090566c1589d81009caa954de90d Author: Uros Bizjak Date: Fri Dec 24 17:09:36 2021 +0100 i386: Add V2SFmode DIV insn pattern [PR95046, PR103797] Use V4SFmode "DIVPS X,Y" with [y0, y1, 1.0f, 1.0f] as a divisor to avoid division by zero. 2021-12-24 Uroš Bizjak gcc/ChangeLog: PR target/95046 PR target/103797 * config/i386/mmx.md (divv2sf3): New instruction pattern. gcc/testsuite/ChangeLog: PR target/95046 PR target/103797 * gcc.target/i386/pr95046-1.c (test_div): Add. (dg-options): Add -mno-recip.
[Bug target/95046] Vectorize V2SFmode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95046 --- Comment #15 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:8f921393e339090566c1589d81009caa954de90d commit r12-6113-g8f921393e339090566c1589d81009caa954de90d Author: Uros Bizjak Date: Fri Dec 24 17:09:36 2021 +0100 i386: Add V2SFmode DIV insn pattern [PR95046, PR103797] Use V4SFmode "DIVPS X,Y" with [y0, y1, 1.0f, 1.0f] as a divisor to avoid division by zero. 2021-12-24 Uroš Bizjak gcc/ChangeLog: PR target/95046 PR target/103797 * config/i386/mmx.md (divv2sf3): New instruction pattern. gcc/testsuite/ChangeLog: PR target/95046 PR target/103797 * gcc.target/i386/pr95046-1.c (test_div): Add. (dg-options): Add -mno-recip.
[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823 --- Comment #4 from Iain Sandoe --- if that is not viable you could prune it locally to the specific test, or add the prune to the general set in testsuite/lib (perhaps making it darwin-specific).
[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823 --- Comment #3 from Francois-Xavier Coudert --- Any reason not to move the test to the lto testsuite?
[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-24 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Very similar to PR 47334 really. That is the problem is lto.exp prunes out this message but since this is in g++.dg/torture rather than the lto testsuite, there is no pruning happening.
[Bug lto/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=47334 --- Comment #1 from Andrew Pinski --- Very similar to PR 47334 really.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #7 from Andrew Pinski --- (In reply to Francois-Xavier Coudert from comment #6) > At the same time, they appear to show up only intermittently in linux test > results, and haven't been fixed on the 11 branch either. Are C++ modules > considered experimental, or generally buggy? I think it is considered very experimental and also generally buggy. This is from all of the bug reports against it which are just trying it with the libstdc++ header files even.
[Bug other/78766] GCC Awk scripts use the non-POSIX /^{/ regex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78766 Andrew Pinski changed: What|Removed |Added CC||skunk at iskunk dot org --- Comment #4 from Andrew Pinski --- *** Bug 53607 has been marked as a duplicate of this bug. ***
[Bug bootstrap/53607] opt-functions.awk --> "awk: There is a regular expression error."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53607 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- So this was fixed in GCC 7 by r7-5331 (aka PR 78766) so I am going to close this as a dup of bug 78766. *** This bug has been marked as a duplicate of bug 78766 ***
[Bug other/78766] GCC Awk scripts use the non-POSIX /^{/ regex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78766 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0 Keywords||build
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #6 from Francois-Xavier Coudert --- At the same time, they appear to show up only intermittently in linux test results, and haven't been fixed on the 11 branch either. Are C++ modules considered experimental, or generally buggy?
[Bug lto/103823] New: g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823 Bug ID: 103823 Summary: g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs" Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: fxcoudert at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- g++.dg/torture/pr31863.C fails on *-apple-darwin with: FAIL: g++.dg/torture/pr31863.C -O2 -flto (test for excess errors) Excess errors: lto-wrapper: warning: using serial compilation of 2 LTRANS jobs Not sure if the message is expected or not, if there is a bug to fix (or if we need to find a way to silence the testcase on darwin).
[Bug testsuite/80552] Make consecutive relative line numbers more maintainable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80552 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-24 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 --- Comment #5 from Andrew Pinski --- (In reply to Francois-Xavier Coudert from comment #4) > Currently still fails on x86_64-apple-darwin21 > (https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html), > as well as the future aarch64-apple-darwin21. Looks like a front-end issue. It is, there are a few (many) C++ modules issues that are not target/host dependent.
[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948 --- Comment #9 from Martin Jambor --- (In reply to Roger Sayle from comment #7) > A default expansion for MULT_HIGHPART_EXPR was proposed as part of > https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551316.html > I'll split off just that part of the patch and resubmit it for review. Roger, thanks for your effort. While I believe your patch series will be generally useful, as far as this bug is concerned, I do not think it makes sense to complicate things because of it. HSA has been removed in GCC 11 and since your patch is unlikely to be a candidate for backport to GCC 10 or earlier, it is unlikely to fix this. HSA almost certainly does not have any users anyway, there is little need to bother about it too. Still, thanks for looking into the general issue.
[Bug c++/99936] [modules] FAIL: g++.dg/modules/xtreme-header* on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99936 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #4 from Francois-Xavier Coudert --- Currently still fails on x86_64-apple-darwin21 (https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/743901.html), as well as the future aarch64-apple-darwin21. Looks like a front-end issue. $ g++ testsuite/g++.dg/modules/xtreme-header-5_a.H -std=c++2a -fmodule-header -S testsuite/g++.dg/modules/xtreme-header-5_a.H: internal compiler error: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have namespace_decl in get_merge_kind, at cp/module.cc:10074 * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 4.1 * frame #0: 0x00010186bc24 cc1plus`internal_error(char const*, ...) [inlined] auto_diagnostic_group::auto_diagnostic_group(this=) at diagnostic.c:2018:14 frame #1: 0x00010186bc24 cc1plus`internal_error(gmsgid="tree check: %s, have %s in %s, at %s:%d") frame #2: 0x00010193d07c cc1plus`tree_check_failed(node=, file=, line=, function=) at tree.c:8702:18 frame #3: 0x00010192064c cc1plus`template_info_decl_check(t=, f=, l=, fn=) at cp-tree.h:651:21 frame #4: 0x000100199f24 cc1plus`trees_out::get_merge_kind(this=, decl=0x0001239bb738, dep=) at cp-tree.h:639:3 frame #5: 0x0001001b1338 cc1plus`trees_out::decl_value(this=0x00016fdfeaf0, decl=0x0001239bb738, dep=0x) at module.cc:7501:34 frame #6: 0x0001001b31bc cc1plus`trees_out::decl_node(this=0x00016fdfeaf0, decl=0x0001239bb738, ref=) at module.cc:8536:18 frame #7: 0x0001001b3dcc cc1plus`trees_out::tree_node(this=0x00016fdfeaf0, t=0x0001239bb738) at module.cc:9092:32 frame #8: 0x0001001b43d4 cc1plus`trees_out::chained_decls(this=0x00016fdfeaf0, decls=0x0001239bb738) at module.cc:4840:17 frame #9: 0x0001001b4ffc cc1plus`trees_out::core_vals(this=0x00016fdfeaf0, t=0x00012392a160) at module.cc:6060:21 frame #10: 0x0001001ba1b0 cc1plus`trees_out::tree_value(tree_node*) [inlined] trees_out::tree_node_vals(t=0x00012392a160, this=0x00016fdfeaf0) at module.cc:7062:13 frame #11: 0x0001001ba1a4 cc1plus`trees_out::tree_value(this=0x00016fdfeaf0, t=0x00012392a160) frame #12: 0x0001001b3cd8 cc1plus`trees_out::tree_node(this=0x00016fdfeaf0, t=) at module.cc:9097:14 frame #13: 0x0001001ba318 cc1plus`trees_out::write_function_def(this=0x00016fdfeaf0, decl=0x000123995d00) at module.cc:11354:13 frame #14: 0x0001001bd2d0 cc1plus`depset::hash::find_dependencies(this=0x00010231, module=) at module.cc:13130:31 frame #15: 0x0001001bd7cc cc1plus`module_state::write(this=0x0001040445b0, to=0x00016fdfee30, reader=) at module.cc:17617:27 frame #16: 0x0001001bee2c cc1plus`finish_module_processing(reader=0x00010380d200) at module.cc:19873:21 frame #17: 0x0001001253a0 cc1plus`c_parse_final_cleanups() at decl2.c:5310:28 frame #18: 0x00010130669c cc1plus`::compile_file() at toplev.c:452:25 frame #19: 0x0001019433ac cc1plus`toplev::main(this=0x00016fdff1f8, argc=, argv=) at toplev.c:2156:24 frame #20: 0x0001019442dc cc1plus`main(argc=21, argv=0x00016fdff368) at main.c:39:23 frame #21: 0x0001030510f4 dyld`start + 520 The tree that triggers the check is: > external in_system_header VOID /private/tmp/irun/include/c++/12.0.0/chrono:2097:34 align:1 warn_if_not_align:0 context abstract_origin module 0:./testsuite/g++.dg/modules/xtreme-header-5_a.H purview chain >
[Bug lto/58203] memset/memcpy are discarded with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203 Andrew Pinski changed: What|Removed |Added CC||goswin-v-b at web dot de --- Comment #6 from Andrew Pinski --- *** Bug 65199 has been marked as a duplicate of this bug. ***
[Bug lto/65199] Linker failure with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65199 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 58203. *** This bug has been marked as a duplicate of bug 58203 ***
[Bug lto/58203] memset/memcpy are discarded with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58203 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-24 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- .
[Bug lto/48983] No diagnostic message about no space left on device with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48983 Andrew Pinski changed: What|Removed |Added CC||andi-gcc at firstfloor dot org --- Comment #5 from Andrew Pinski --- *** Bug 50666 has been marked as a duplicate of this bug. ***
[Bug lto/50666] bad error reporting for TMPDIR full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50666 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 48983. *** This bug has been marked as a duplicate of bug 48983 ***
[Bug lto/85047] cdd2a01 (and others) FAIL with -flto (VLA type in struct causes issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85047 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking, ||ice-on-valid-code --- Comment #7 from Andrew Pinski --- testsuite/gcc.dg/nested-func-9.c (which is similar to comment 4 but with return types) ICEs also when -flto is added.
[Bug lto/85047] cdd2a01 (and others) FAIL with -flto (VLA type in struct causes issues)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85047 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #6 from Andrew Pinski --- *** Bug 87499 has been marked as a duplicate of this bug. ***
[Bug lto/87499] VLA in struct, nested functions and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87499 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 85047. *** This bug has been marked as a duplicate of bug 85047 ***
[Bug lto/50676] Partitioning may fail with presence of static variables referring to function labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676
--- Comment #9 from Andrew Pinski ---
Simple testcase from the other bug:
/* { dg-do link } */
/* { dg-options "-flto-partition=max -flto -O2" } */
/* { dg-require-effective-target lto } */
/* Test for putting static with label references into same LTO partition */
int x, y;
void f(int i)
{
typedef void *ptr;
static ptr data[] = {&&l1,&&l2,&&l3,&&l4};
goto *data[i];
l1:
x++;
l2:
y++;
l3:
x--;
l4:
y--;
}
int main(void)
{
f(x);
return 0;
}
[Bug lto/50676] Partitioning may fail with presence of static variables referring to function labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50676 --- Comment #8 from Andrew Pinski --- *** Bug 83375 has been marked as a duplicate of this bug. ***
[Bug lto/83375] partitioner partitions static arrays with label references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83375 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Andrew Pinski --- Dup of bug 50676. *** This bug has been marked as a duplicate of bug 50676 ***
[Bug hsa/86948] Internal compiler error compiling brig.dg/test/gimple/mulhi.hsail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86948 --- Comment #8 from Alexander Monakov --- How does your patch expand 64-bit highpart multiply (i.e. with 128-bit full product) on 32-bit targets?
[Bug lto/94150] Improve LTO diagnosis for LTO triggered warnings/error: print source.o or source.a(lib.o) when printing location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94150 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug lto/94150] Improve LTO diagnosis for LTO triggered warnings/error: print source.o or source.a(lib.o) when printing location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94150 --- Comment #4 from Andrew Pinski --- There is a nice testcase in bug 96969 comment #1.
[Bug lto/94150] Improve LTO diagnosis for LTO triggered warnings/error: print source.o or source.a(lib.o) when printing location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94150 Andrew Pinski changed: What|Removed |Added CC||alan at octopull dot co.uk --- Comment #3 from Andrew Pinski --- *** Bug 96969 has been marked as a duplicate of this bug. ***
[Bug lto/96969] ODR violations do not list the translation unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96969 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 94150. *** This bug has been marked as a duplicate of bug 94150 ***
[Bug lto/86490] lto1: fatal error: multiple prevailing defs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490 Andrew Pinski changed: What|Removed |Added Severity|normal |minor --- Comment #19 from Andrew Pinski --- The first example still fails if used with ld from binutils 2.30 and with -fcommon (which is not the default any more). Moving down to a minor issue as -fno-common is now default since GCC 10.
[Bug lto/67357] -Wodr warnings from types in anonymous namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67357 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66180 Target Milestone|--- |6.0 Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- It does look all have been fixed in at least 7.3.0. I did try the single file example in GCC 6 and it was fixed there too. So I am going to close as fixed for GCC 6 and put PR 66180 as the see also since I think that is the patch which fixed the issue.
[Bug lto/61052] g++ generated code segfaults when using LTO together with "extern template", non-LTO compiled files, and gold linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61052 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME Target Milestone|--- |7.4 --- Comment #2 from Andrew Pinski --- Works in GCC 7.4.0 without any error both with and without gold. So what ever it was it has been fixed. Most likely a binutils bug.
[Bug lto/43581] exception handling broken across shared libraries with -fuse-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #9 from Andrew Pinski --- Closing as moved as it was reported a newer version of binutils (gold) fixed the issue.
[Bug middle-end/61192] Conflict between global register and function name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192 Andrew Pinski changed: What|Removed |Added CC||cnsun at uwaterloo dot ca --- Comment #5 from Andrew Pinski --- *** Bug 100888 has been marked as a duplicate of this bug. ***
[Bug ipa/100888] ICE: symtab_node::verify failed, symtab_node::verify()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100888 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- (In reply to Martin Liška from comment #1) > Started with my r9-6392-g606711a1671cc637. It didn't exactly start with patch as it was failing with LTO before that. Dup of bug 61192. *** This bug has been marked as a duplicate of bug 61192 ***
[Bug middle-end/61192] Conflict between register and function name for lto on sparc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61192
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-12-24
Known to fail||9.1.0
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords|lto |ice-checking,
||ice-on-valid-code
Component|lto |middle-end
--- Comment #4 from Andrew Pinski ---
Confirmed here is a testcase for x86_64:
register int hh __asm__("r14");
int jj;
__getreent() {
int cpu_self = hh;
jj = cpu_self;
}
int r14() {}
- CUT
Here is the ICE we get on the trunk (and all the way down to GCC 9, GCC 8 does
not to ICE with -fchecking):
:9:1: error: assembler name hash list corrupted
9 | int r14() {}
| ^~~
*r14/0 (hh) @0x7f0e412d1000
Type: variable definition analyzed
Visibility: force_output semantic_interposition no_reorder public
References:
Referring: __getreent/2 (read)
Availability: not-ready
Varpool flags:
:9:1: internal compiler error: symtab_node::verify failed
0x1e454c9 internal_error(char const*, ...)
???:0
0x900b69 symtab_node::verify()
???:0
0x9020e7 symtab_node::verify_symtab_nodes()
???:0
0x91e9bf symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libbacktrace/103822] libbacktrace make check fails with GNU Make 3.81
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103822
--- Comment #1 from Francois-Xavier Coudert ---
Oops wrong type of quotes, needs double quotes:
diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 8874f41338a..d200e3a9433 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -145,18 +145,18 @@ endif HAVE_OBJCOPY_DEBUGLINK
endif HAVE_ELF
elf_%.c: elf.c
+ nlinit=`echo 'nl="'; echo '"'`; eval "$$nlinit"; \
SEARCH='#error "Unknown BACKTRACE_ELF_SIZE"'; \
- REPLACE='#undef BACKTRACE_ELF_SIZE\
- #define BACKTRACE_ELF_SIZE'; \
+ REPLACE="#undef BACKTRACE_ELF_SIZE\\$${nl}#define BACKTRACE_ELF_SIZE";
\
$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
$< \
> $@.tmp
mv $@.tmp $@
xcoff_%.c: xcoff.c
+ nlinit=`echo 'nl="'; echo '"'`; eval "$$nlinit"; \
SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
- REPLACE='#undef BACKTRACE_XCOFF_SIZE\
- #define BACKTRACE_XCOFF_SIZE'; \
+ REPLACE="#undef BACKTRACE_XCOFF_SIZE\\$${nl}#define
BACKTRACE_XCOFF_SIZE"; \
$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
$< \
> $@.tmp
[Bug libbacktrace/103822] New: libbacktrace make check fails with GNU Make 3.81
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103822
Bug ID: 103822
Summary: libbacktrace make check fails with GNU Make 3.81
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
The failure is observed on macOS (*-apple-darwin21), where the system make is
GNU Make 3.81. But I think it would occur on all platforms that are not ELF and
use GNU Make 3.81. Running `make check` leads to this failure:
elf_32.c:144:26: error: extra tokens at end of #undef directive [-Werror]
144 | #undef BACKTRACE_ELF_SIZE#define BACKTRACE_ELF_SIZE 32
| ^
where the invalid elf_32.c is generated by this command:
SEARCH='#error "Unknown BACKTRACE_ELF_SIZE"'; \
REPLACE='#undef BACKTRACE_ELF_SIZE\
#define BACKTRACE_ELF_SIZE'; \
/usr/bin/sed "s/^$SEARCH\$/$REPLACE 32/" \
/tmp/gcc-darwin-arm64/libbacktrace/elf.c \
> elf_32.c.tmp
mv elf_32.c.tmp elf_32.c
This tries to have a newline inside the REPLACE string, and pass it to sed.
This fails with GNU Make < 4. And GCC requires "GNU make version 3.80 (or
later)".
The portable solution is given in the autoconf manual:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Newlines-in-Make-Rules.html
The patch to fix it is this:
diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
index 8874f41338a..180a3b1a809 100644
--- a/libbacktrace/Makefile.am
+++ b/libbacktrace/Makefile.am
@@ -145,18 +145,18 @@ endif HAVE_OBJCOPY_DEBUGLINK
endif HAVE_ELF
elf_%.c: elf.c
+ nlinit=`echo 'nl="'; echo '"'`; eval "$$nlinit"; \
SEARCH='#error "Unknown BACKTRACE_ELF_SIZE"'; \
- REPLACE='#undef BACKTRACE_ELF_SIZE\
- #define BACKTRACE_ELF_SIZE'; \
+ REPLACE='#undef BACKTRACE_ELF_SIZE\\$${nl}#define BACKTRACE_ELF_SIZE';
\
$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
$< \
> $@.tmp
mv $@.tmp $@
xcoff_%.c: xcoff.c
+ nlinit=`echo 'nl="'; echo '"'`; eval "$$nlinit"; \
SEARCH='#error "Unknown BACKTRACE_XCOFF_SIZE"'; \
- REPLACE='#undef BACKTRACE_XCOFF_SIZE\
- #define BACKTRACE_XCOFF_SIZE'; \
+ REPLACE='#undef BACKTRACE_XCOFF_SIZE\\$${nl}#define
BACKTRACE_XCOFF_SIZE'; \
$(SED) "s/^$$SEARCH\$$/$$REPLACE $*/" \
$< \
> $@.tmp
[Bug testsuite/63997] gcc.dg/lto/pr61526 failing on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63997 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Iain Sandoe --- not on i686, powerpc darwin9 or x86-64-darwin[10-21] as of r12-6053 so closing.
[Bug lto/52722] ICE in lto_output_varpool_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52722 Andrew Pinski changed: What|Removed |Added Keywords||link-failure Target Milestone|--- |4.8.0
[Bug lto/52634] multiple definition error when using alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |4.8.0 Status|ASSIGNED|RESOLVED --- Comment #11 from Andrew Pinski --- Fixed.
[Bug driver/81829] [7 Regression] /usr/bin/gcc-{ar,nm,ranlib} segfault without arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81829 Andrew Pinski changed: What|Removed |Added CC||theivorytower at gmail dot com --- Comment #12 from Andrew Pinski --- *** Bug 80717 has been marked as a duplicate of this bug. ***
[Bug lto/80717] LTO wrappers segfault if run with absolute path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80717 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.3 Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Even though PR 81829 is newer, it is what is recorded as the bug report in the changelog so closing this one as a dup of bug 81829. *** This bug has been marked as a duplicate of bug 81829 ***
[Bug testsuite/63997] gcc.dg/lto/pr61526 failing on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63997 Andrew Pinski changed: What|Removed |Added Component|lto |testsuite Keywords||testsuite-fail --- Comment #6 from Andrew Pinski --- Does this testcase still fail?
[Bug middle-end/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 Andrew Pinski changed: What|Removed |Added Component|lto |middle-end See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=54314 --- Comment #4 from Andrew Pinski --- I wonder if we should emit the warning for visibility not being supported in a different location rather than while creating the assembly in varasm.c. The C++ front-end sets DECL_VISIBILITY hidden even on non-user code.
