[Bug debug/101452] [debug, dwarf-5] undefined static member removed by -feliminate-unused-debug-symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101452 --- Comment #1 from Richard Biener --- do you have an idea why it works with -gdwarf-4 but not -gdwarf-5?
[Bug middle-end/101457] [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug other/101459] Mismatch in description of option "-falign-functions" between source code and documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101459 Richard Biener changed: What|Removed |Added Resolution|--- |WORKSFORME Status|UNCONFIRMED |RESOLVED Keywords||documentation --- Comment #2 from Richard Biener --- The flag, -falign-functions is only enabled at -O2+ (but not -Os), but the actual alignment is recorded in the 'align_functions' data which is only populated when -falign-functions is specified so I think it works as documented.
[Bug other/101459] Mismatch in description of option "-falign-functions" between source code and documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101459
--- Comment #3 from ashimida ---
(In reply to Richard Biener from comment #2)
> The flag, -falign-functions is only enabled at -O2+ (but not -Os), but the
> actual alignment is recorded in the 'align_functions' data which is only
> populated when -falign-functions is specified so I think it works as
> documented.
I tested this option in gcc 7.5.0 and 9.2.0, with the source code:
int func1(void)
{
return 0;
}
int func2(void)
{
return 0;
}
int main (void)
{
return 1;
}
and the result is like:
ashimida@ubuntu:~/test1$ aarch64-linux-gnu-gcc -falign-functions=128 -O0 test.c
-o test
ashimida@ubuntu:~/test1$ readelf -s test|grep fun
63: 0780 8 FUNCGLOBAL DEFAULT 13 func1
78: 0800 8 FUNCGLOBAL DEFAULT 13 func2
ashimida@ubuntu:~/test1$ aarch64-linux-gnu-gcc -O0 test.c -o test
ashimida@ubuntu:~/test1$ readelf -s test|grep fun
63: 06e4 8 FUNCGLOBAL DEFAULT 13 func1
78: 06ec 8 FUNCGLOBAL DEFAULT 13 func2
so I think this flag is also worked at -O0
[Bug debug/101452] [debug, dwarf-5] undefined static member removed by -feliminate-unused-debug-symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101452
--- Comment #2 from Tom de Vries ---
(In reply to Richard Biener from comment #1)
> do you have an idea why it works with -gdwarf-4 but not -gdwarf-5?
If we do with n == 4 and n == 5:
...
$ rm -f *.c.* ; ./install/bin/g++ test.c -c -g -gdwarf-$n -fdump-tree-all
-fno-eliminate-unused-debug-symbols
...
we find in test.c.t.earlydebug for n == 4:
...
DIE0: DW_TAG_member (0x7f5303154140)
abbrev id: 0 offset: 0 mark: 0
DW_AT_name: "sa"
DW_AT_decl_file: "test.c" (0)
DW_AT_decl_line: 3
DW_AT_decl_column: 14
DW_AT_type: die -> 0 (0x7f53031540f0)
DW_AT_external: 1
DW_AT_declaration: 1
...
and for n == 5:
...
DIE0: DW_TAG_variable (0x7fa1cdced140)
abbrev id: 0 offset: 0 mark: 0
DW_AT_name: "sa"
DW_AT_decl_file: "test.c" (0)
DW_AT_decl_line: 3
DW_AT_decl_column: 14
DW_AT_linkage_name: "_ZN1a2saE"
DW_AT_type: die -> 0 (0x7fa1cdced0f0)
DW_AT_external: 1
DW_AT_declaration: 1
...
So we have DW_TAG_member vs DW_TAG_variable.
There's some piece of code here in prune_unused_types_walk that mentions this
difference:
...
/* For static data members, the declaration in the class is supposed
to have DW_TAG_member tag in DWARF{3,4} but DW_TAG_variable in
DWARF5. DW_TAG_member will be marked, so mark even such
DW_TAG_variables in DWARF5, as long as it has DW_AT_const_value
attribute. */
if (dwarf_version >= 5
&& class_scope_p (die->die_parent)
&& get_AT (die, DW_AT_const_value))
break;
...
and also removing the DW_AT_const_value part of this clause fixes it.
Looking at the log message for that change:
...
In DWARF4 and earlier, static data members were represented as DW_TAG_member
and the pruning code wouldn't prune those, but in DWARF5 they are represented
as DW_TAG_variable with the class parent and the pruning code prunes those by
default unless they are referenced from a separate definition without the class
parent (out of class definition).
C++17 inline vars have the definitions in the class though and even before
if the static data member isn't ODR used, it doesn't need to be defined, so we
could just never describe those static data members in the debug info.
This change stops the pruning of DW_TAG_variable with DW_AT_const_value
attribute with a class parent for -gdwarf-5 and later.
...
Well, that explains it, but I'm not sure I understand why it's ok not to
describe an undefined static data member. It changes the appearance of the
type and suggest an odr error when comparing with a CU where the static data
member is defined. Note that this also makes dwz's job harder.
[Bug debug/101452] [debug, dwarf-5] undefined static member removed by -feliminate-unused-debug-symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101452 --- Comment #3 from Richard Biener --- I agree the pruning doesn't make much sense and that it's bad from a QOI perspective. So it looks like fixing this part would be better then.
[Bug debug/101452] [debug, dwarf-5] undefined static member removed by -feliminate-unused-debug-symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101452 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The point was that if it is referenced somewhere, the definition needs to be in some TU and that TU will then have debug info for it, similarly to what we do with namespace scope extern decls. The DW_AT_const_value check is there because if it has a const initializer, it might not have a definition at all even when it is used (when not odr used).
[Bug ipa/54569] Compiling code with -O3 results to segfault in MAME/MESS binary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54569 Alexander Grund changed: What|Removed |Added CC||alexander.grund@tu-dresden. ||de --- Comment #3 from Alexander Grund --- Created attachment 51154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51154&action=edit preprocessed TBB source Might have a related issue: https://github.com/oneapi-src/oneTBB/issues/489 The test segfaults when compiled with -O3 but works when compiled with -fno-ipa-cp-clone UBSAN reports "runtime error: execution reached an unreachable program point", but only for the crashing version and Valgrind reports an invalid read, also only for the crashing version. Most notably the crash disappears when the direct call to the template function is replaced by getting a pointer to it first and calling the function through that on the next line, which shouldn't make any difference.
[Bug middle-end/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f6dde32b9d487dd6e343d0a1e1d1f60783f5e735 commit r12-2320-gf6dde32b9d487dd6e343d0a1e1d1f60783f5e735 Author: Jakub Jelinek Date: Thu Jul 15 10:17:06 2021 +0200 gimplify: Fix endless recursion on volatile empty type reads/writes [PR101437] Andrew's recent change to optimize away during gimplification not just assignments of zero sized types, but also assignments of empty types, caused infinite recursion in the gimplifier. If such assignment is optimized away, we gimplify separately the to_p and from_p operands and throw away the result. When gimplifying the operand that is volatile, we run into the gimplifier code below, which has different handling for types with non-BLKmode mode, tries to gimplify those as vol.N = expr, and for BLKmode just throws those away. Zero sized types will always have BLKmode and so are fine, but for the non-BLKmode ones like struct S in the testcase, the vol.N = expr gimplification will reach again the gimplify_modify_expr code, see it is assignment of empty type and will gimplify again vol.N separately (non-volatile, so ok) and expr, on which it will recurse again. The following patch breaks that infinite recursion by ignoring bare volatile loads from empty types. If a volatile load or store for aggregates are supposed to be member-wise loads or stores, then there are no non-padding members in the empty types that should be copied and so it is probably ok. 2021-07-15 Jakub Jelinek PR middle-end/101437 * gimplify.c (gimplify_expr): Throw away volatile reads from empty types even if they have non-BLKmode TYPE_MODE. * gcc.c-torture/compile/pr101437.c: New test.
[Bug middle-end/101437] [12 Regression] ICE: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101437 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #9 from Christophe Lyon --- Note that we still have failures on arm similar to what you mention on aarch64. FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 34) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 37) FAIL: gcc.dg/Wstringop-overflow-47.c pr97027 (test for warnings, line 42)
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448
--- Comment #4 from Xinliang ---
Looking into the relocation code[1] of ld.
I'm very curious why ld can't handle long call here.
[1]:
```
2976 static enum elf_aarch64_stub_type
2977 aarch64_type_of_stub (asection *input_sec,
2978 const Elf_Internal_Rela *rel,
2979 asection *sym_sec,
2980 unsigned char st_type,
2981 bfd_vma destination)
2982 {
2983 bfd_vma location;
2984 bfd_signed_vma branch_offset;
2985 unsigned int r_type;
2986 enum elf_aarch64_stub_type stub_type = aarch64_stub_none;
2987
2988 if (st_type != STT_FUNC
2989 && (sym_sec == input_sec))
2990 return stub_type;
2991
2992 /* Determine where the call point is. */
2993 location = (input_sec->output_offset
2994 + input_sec->output_section->vma + rel->r_offset);
2995
2996 branch_offset = (bfd_signed_vma) (destination - location);
2997
2998 r_type = ELFNN_R_TYPE (rel->r_info);
2999
3000 /* We don't want to redirect any old unconditional jump in this way,
3001 only one which is being used for a sibcall, where it is
3002 acceptable for the IP0 and IP1 registers to be clobbered. */
3003 if ((r_type == AARCH64_R (CALL26) || r_type == AARCH64_R (JUMP26))
3004 && (branch_offset > AARCH64_MAX_FWD_BRANCH_OFFSET
3005 || branch_offset < AARCH64_MAX_BWD_BRANCH_OFFSET))
3006 {
3007 stub_type = aarch64_stub_long_branch;
3008 }
3009
3010 return stub_type;
3011 }
```
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/elfnn-aarch64.c;h=097a275990f1d350be8f68943093926a5c66157a;hb=07f9ddfeba5b572451471f905473f7ddbba1d472#l2316
FYI, there is a similar bug with the same error msg:
https://sourceware.org/bugzilla/show_bug.cgi?id=18668
[Bug target/101346] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101346 Uroš Bizjak changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 Last reconfirmed||2021-07-15 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Uroš Bizjak --- Created attachment 51155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51155&action=edit Proposed patch ix86_hard_regno_mode_ok allows TDmode values in general registers, but 32bit targets do not support 128bit values in general registers natively. Also allow TDmode values in SSE registers.
[Bug c++/96286] Unhelpful errors after a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-15
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This is a major pain the backside for trying to give good diagnostics for
std::get(tuple&). I want to stop with a "clear" static assertion
like:
In file included from
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/tuple/element_access/101427.cc:3:
/home/jwakely/gcc/12/include/c++/12.0.0/tuple: In instantiation of 'constexpr
std::size_t std::__find_uniq_type_in_pack() [with _Tp = long int; _Types =
{float, int, int}; std::size_t = long unsigned int]':
/home/jwakely/gcc/12/include/c++/12.0.0/tuple:1452:63: required from
'constexpr _Tp& std::get(std::tuple<_UTypes ...>&) [with _Tp = long int; _Types
= {float, int, int}]'
/home/jwakely/src/gcc/gcc/libstdc++-v3/testsuite/20_util/tuple/element_access/101427.cc:7:22:
required from here
/home/jwakely/gcc/12/include/c++/12.0.0/tuple:1441:27: error: static assertion
failed: the type T in std::get must occur exactly once in the tuple
1441 | static_assert(__idx >= 0,
| ~~^~~~
But G++ insists on continuing past that point, returning an out-of-range index
which causes 200 lines of errors because std::get(t) is invalid.
I know it's invalid, that's why I made the static assertion fail. Just stop.
I now have to jump through ridiculous hoops to add additional code to munge the
invalid value into some other value to stop the 200 lines of noise.
[Bug c++/96286] Unhelpful errors after a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286
--- Comment #2 from Jonathan Wakely ---
It also doesn't help that the compiler thwarts my attempt to trigger errors
earlier like so:
// Return index of _Tp in _Types.
// Ill-formed if _Tp doesn't occur exactly once in _Types.
template
constexpr size_t
__find_uniq_type_in_pack()
{
constexpr ptrdiff_t __idx = std::__find_type_in_pack<_Tp, _Types...>();
static_assert(__idx >= 0,
"the type T in std::get must occur exactly once in the tuple");
return size_t{__idx};
}
The return statement *should* be an ill-formed narrowing conversion, but G++
(and Clang) think that because I'm in a system header we probably wanted to
ignore that, so we return a huge value and get 200 lines of errors again.
Maybe this will work?
{
constexpr ptrdiff_t __idx = std::__find_type_in_pack<_Tp, _Types...>();
static_assert(__idx >= 0,
"the type T in std::get must occur exactly once in the tuple");
if (__idx >= 0)
return __idx;
__builtin_unreachable();
}
No, now I get 200 lines telling me that the I in std::get is not a constant
expression because of __builtin_unreachable.
OK, let's try return enable_if_t<__idx >= 0, size_t>{__idx};
This prints "error: no type named 'type' in 'struct std::enable_if'" as
expected, but then 200 lines telling me std::get is not a constant
expression because it flows off the end of the function.
Why is the compiler even doing overload resolution for std::get if I is an
invalid constant expression?! It's not going to match any overload!
It shouldn't be this hard. Just stop compiling already.
[Bug c++/101460] New: Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460
Bug ID: 101460
Summary: Useless cascade of overload resolution errors for
invalid expression
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template struct enable_if { };
template<> struct enable_if { using type = void; };
template
using enable_if_t = typename enable_if::type;
struct tuple { };
struct pair { };
template enable_if_t get(tuple&) { }
template enable_if_t get(const tuple&) { }
template enable_if_t get(pair&) { }
template enable_if_t get(const pair&) { }
template
constexpr unsigned
frob()
{
static_assert(N == 1, "user-friendly diagnostic");
return unsigned{N}; // narrowing check, reject negative values
}
template void get_n(tuple& t) { get()>(t); }
int main()
{
tuple t;
get_n<-1>(t);
}
This prints a wall of errors:
stupid.C: In instantiation of 'constexpr unsigned int frob() [with int N =
-1]':
stupid.C:23:51: required from 'void get_n(tuple&) [with int N = -1]'
stupid.C:28:12: required from here
stupid.C:19:19: error: static assertion failed: user-friendly diagnostic
19 | static_assert(N == 1, "user-friendly diagnostic");
| ~~^~~~
stupid.C:19:19: note: '(-1 == 1)' evaluates to false
stupid.C:20:20: error: narrowing conversion of '-1' from 'int' to 'unsigned
int' [-Wnarrowing]
20 | return unsigned{N}; // narrowing check, reject negative values
|^
stupid.C:21:1: error: body of 'constexpr' function 'constexpr unsigned int
frob() [with int N = -1]' not a return-statement
21 | }
| ^
stupid.C: In instantiation of 'void get_n(tuple&) [with int N = -1]':
stupid.C:28:12: required from here
stupid.C:23:54: error: no matching function for call to
'get()>(tuple&)'
23 | template void get_n(tuple& t) { get()>(t); }
|~~^~~
stupid.C:10:42: note: candidate: 'template enable_if_t<(N ==
1)> get(tuple&)'
10 | template enable_if_t get(tuple&) { }
| ^~~
stupid.C:10:42: note: template argument deduction/substitution failed:
stupid.C:23:51: error: 'constexpr unsigned int frob() [with int N = -1]' called
in a constant expression
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:17:1: note: 'constexpr unsigned int frob() [with int N = -1]' is not
usable as a 'constexpr' function because:
17 | frob()
| ^~~~
stupid.C:23:51: note: in template argument for type 'unsigned int'
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:11:42: note: candidate: 'template enable_if_t<(N ==
1)> get(const tuple&)'
11 | template enable_if_t get(const tuple&) { }
| ^~~
stupid.C:11:42: note: template argument deduction/substitution failed:
stupid.C:23:51: error: 'constexpr unsigned int frob() [with int N = -1]' called
in a constant expression
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:23:51: note: in template argument for type 'unsigned int'
stupid.C:12:42: note: candidate: 'template enable_if_t<(N ==
1)> get(pair&)'
12 | template enable_if_t get(pair&) { }
| ^~~
stupid.C:12:42: note: template argument deduction/substitution failed:
stupid.C:23:51: error: 'constexpr unsigned int frob() [with int N = -1]' called
in a constant expression
23 | template void get_n(tuple& t) { get()>(t); }
|~~~^~
stupid.C:23:51: note: in template argument for type 'unsigned int'
stupid.C:13:42: note: candidate: 'template enable_if_t<(N ==
1)> get(const pair&)'
13 | template enable_if_t get(const pair&) { }
| ^~~
stupid.C:13:42: note: substitution of deduced template arguments resulted in
errors seen above
This is reduced from libstdc++ where there are more overloads of get and all
of them get tried, and all of them print exactly the same error.
Why are we even attempting overload resolution when the expression is invalid?
Is the invalid non-constant frob<-1>() call going to suddenly become valid if
we keep trying hard enough?
If PR 96286 gets fixed then the static_assert in frob should stop compilation,
but if we remove that from the code above then we'll still get a wall of
unhelpful errors. Constant evaluation of frob<-1>() failed, so stop trying to
use it as a template argument.
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #5 from Kevin Zhao --- Hi Richard, Thanks for your info. Previously it is built without any -O parameters, so it should be -O0 by default. I've tried to use the "-Og" to link, it is quite interesting that use -Og we can link success Also, use -O1, -O2 and -Os, Linking works quite well.
[Bug c++/96286] Unhelpful errors after a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286 --- Comment #3 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #2) > Why is the compiler even doing overload resolution for std::get if I is > an invalid constant expression?! It's not going to match any overload! This part is now PR 101460
[Bug inline-asm/101422] register variable uninitialised before passing to asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101422
--- Comment #8 from Simon Willcocks ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Simon Willcocks from comment #2)
> > That's not an accurate description of the problem; the value of the variable
> > is being passed, not its address. As a register variable, it doesn't have an
> > address.
>
> It is the address of the array that is being passed (I was copying and
> pasting from another bug).
> register uint32_t *cap_and_join asm( "r5" ) = cap_and_join_style;
> Is the same as:
> register uint32_t *cap_and_join asm( "r5" ) = &cap_and_join_style[0];
>
> Because array decays to pointers :).
And, of course, I later came up against this precise problem, at least I knew
what I was looking for, and thanks to you, how to fix it. The final solution is
as follows. I really think that passing a pointer type into an asm should
indicate that the object pointed to is used, though.
void Draw_Stroke( uint32_t *path )
{
// Keep this declaration before the first register variable declaration, or
// -Os will cause the compiler to forget the preceding registers.
// https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101422
uint32_t cap_and_join_style[5] = { 0x0001 }; // Round joints
register uint32_t *draw_path asm( "r0" ) = path;
register uint32_t fill_style asm( "r1" ) = 0x3f;
register uint32_t *matrix asm( "r2" ) = 0;
register uint32_t flatness asm( "r3" ) = 0;
register uint32_t thickness asm( "r4" ) = 8;
register uint32_t *cap_and_join asm( "r5" ) = cap_and_join_style;
register uint32_t dashes asm( "r6" ) = 0;
asm ( "swi 0x60704" :
: "r" (draw_path)
, "r" (fill_style)
, "r" (matrix)
, "r" (flatness)
, "r" (thickness)
, "r" (cap_and_join)
, "r" (dashes)
, "m" (cap_and_join_style) ); // Without this, array is not initialised
}
I wanted to correct the record and thank you (both). I'll shut up, now.
[Bug c++/101460] Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-07-15
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
I suppose the problem here is that the failed constant evaluation of frob<-1>()
only happens as a result of trying to use it as a template argument (where a
constant expression is required) which doesn't happen until overload resolution
is performed. So we have to at least being doing OR before we get a problem.
But maybe we can remember that it failed once, and so stop trying. If it's not
a valid constant expression, *that* is the error, not the fact that none of the
get overloads can be called with an invalid constant expression.
Even if I change the code to do this it keeps trying overload resolution for
get:
template void get_n(tuple& t) {
constexpr unsigned n = frob();
get(t);
}
The constexpr initialization of 'n' failed with a static_assert *and* a
non-constant narrowing conversion, so why do we continue and even attempt
overload resolution for 'get'?
[Bug c++/101460] Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460 --- Comment #2 from Jonathan Wakely --- I know that attempting to continue compiling can be very useful, so that additional errors in the code can still be diagnosed. But in this case, maybe we should mark 'n' as "tainted" so that we don't keep showing diagnostics caused by trying to use it as if it was valid.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #237 from The Written Word --- (In reply to John Buddery from comment #228) > gcov-tool.c avoids build errors from ftwbuf differences on HP, apply if you > hit errors but may need tidying up. Instead of this patch, try the patch for PR66319 instead.
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #13 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a0128f11e9dadc3cc3ed0ad0edb36593b16f72e8 commit r11-8754-ga0128f11e9dadc3cc3ed0ad0edb36593b16f72e8 Author: H.J. Lu Date: Fri Jul 9 09:16:01 2021 -0700 x86: Don't enable UINTR in 32-bit mode UINTR is available only in 64-bit mode. Since the codegen target is unknown when the the gcc driver is processing -march=native, to properly handle UINTR for -march=native: 1. Pass "arch [32|64]" and "tune [32|64]" to host_detect_local_cpu to indicate 32-bit and 64-bit codegen. 2. Change ix86_option_override_internal to enable UINTR only in 64-bit mode for -march=CPU when PTA_CPU includes PTA_UINTR. gcc/ PR target/101395 * config/i386/driver-i386.c (host_detect_local_cpu): Check "arch [32|64]" and "tune [32|64]" for 32-bit and 64-bit codegen. Enable UINTR only for 64-bit codegen. * config/i386/i386-options.c (ix86_option_override_internal::DEF_PTA): Skip PTA_UINTR if not in 64-bit mode. * config/i386/i386.h (ARCH_ARG): New. (CC1_CPU_SPEC): Pass "[arch|tune] 32" for 32-bit codegen and "[arch|tune] 64" for 64-bit codegen. gcc/testsuite/ PR target/101395 * gcc.target/i386/pr101395-1.c: New test. * gcc.target/i386/pr101395-2.c: Likewise. * gcc.target/i386/pr101395-3.c: Likewise. (cherry picked from commit cc11b924bfe7752edbba052ca71653f46a60887a)
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from H.J. Lu --- Fixed for GCC 12 and 11.2.
[Bug c++/101458] An invalid covaraint return type is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101458 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 99664 ***
[Bug c++/99664] Overriding virtual function with different return type (and not covariant) is allowed to compile, when it shouldn’t be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664 Jonathan Wakely changed: What|Removed |Added CC||xmh970252187 at gmail dot com --- Comment #3 from Jonathan Wakely --- *** Bug 101458 has been marked as a duplicate of this bug. ***
[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by H.J. Lu : https://gcc.gnu.org/g:ba3b30cf70990f4aadb393b64b76ff490bb0bd0f commit r11-8755-gba3b30cf70990f4aadb393b64b76ff490bb0bd0f Author: H.J. Lu Date: Fri Jun 11 07:31:29 2021 -0700 x86: Replace ix86_red_zone_size with ix86_red_zone_used Add red_zone_used to machine_function to track if red zone is used. When expanding function prologue, set red_zone_used to true if red zone is used. gcc/ PR target/101023 * config/i386/i386.c (ix86_expand_prologue): Set red_zone_used to true if red zone is used. (ix86_output_indirect_jmp): Replace ix86_red_zone_size with ix86_red_zone_used. * config/i386/i386.h (machine_function): Add red_zone_used. (ix86_red_zone_size): Removed. (ix86_red_zone_used): New. * config/i386/i386.md (peephole2 patterns): Replace ix86_red_zone_size with ix86_red_zone_used. gcc/testsuite/ PR target/101023 * g++.target/i386/pr101023a.C: New test. * g++.target/i386/pr101023b.C: Likewise. (cherry picked from commit 3f04e3782536ad2f9cfbb8cfe6630e9f9dd8af4c)
[Bug target/101023] [11/12 Regression] wrong code with -mstackrealign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101023 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from H.J. Lu --- Fixed for GCC 12 and 11.2.
[Bug libstdc++/101427] [11/12 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427 --- Comment #1 from Jonathan Wakely --- The std::get code stopped working as a result of r11-4693 which implemented a core language change: c++: DR2303, ambiguous base deduction [PR97453] When there are two possible matches and one is a base of the other, choose the derived class rather than fail. We should have had a libstdc++ test verifying the expected error, so that we'd have noticed the library regression. I will push the fix soon.
[Bug demangler/100968] libiberty: stuck in infinite loop in nm-new while demangling rust symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100968 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Created attachment 51156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51156&action=edit Proposed patch I think that this PR is a duplicate of 99935. The patch for that PR (attached here) also fixes this problem.
[Bug driver/101447] Remove legacy external declarations in toplev.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101447 ashimida changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from ashimida --- Submitted at https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575252.html
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #238 from John Buddery --- Thanks, I'll give it a go. It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and later require a 64 bit build for 64 bit objects to work reliably. Was your 11.1 build successful ?
[Bug testsuite/101461] New: [12 regression] gcc.target/powerpc/fold-vec-load-builtin_vec_xl test cases fail after r12-2266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101461 Bug ID: 101461 Summary: [12 regression] gcc.target/powerpc/fold-vec-load-builtin_vec_xl test cases fail after r12-2266 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:063eba7ca73030139a3bf822ed127cf09b2fc226, r12-2266 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-char.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-double.c scan-assembler-times \\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 6 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-float.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 6 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-int.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-longlong.c scan-assembler-times \\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 FAIL: gcc.target/powerpc/fold-vec-load-builtin_vec_xl-short.c scan-assembler-times \\mlxvw4x\\M|\\mlxvd2x\\M|\\mlxvx\\M|\\mp?lvx\\M 12 These failed previously on power 10 too but the patterns were changed in this revision and they still fail. commit 063eba7ca73030139a3bf822ed127cf09b2fc226 (HEAD) Author: Michael Meissner Date: Tue Jul 13 00:36:43 2021 -0400 Deal with prefixed loads/stores in tests, PR testsuite/100166
[Bug target/101456] Unnecessary vzeroupper when upper bits of YMM registers already zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101456 H.J. Lu changed: What|Removed |Added Attachment #51153|0 |1 is obsolete|| --- Comment #4 from H.J. Lu --- Created attachment 51157 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51157&action=edit A new patch
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #239 from The Written Word --- (In reply to John Buddery from comment #238) > Thanks, I'll give it a go. > > It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and > later require a 64 bit build for 64 bit objects to work reliably. > > Was your 11.1 build successful ? Ran out of disk space so had to restart :(
[Bug c++/99664] Overriding virtual function with different return type (and not covariant) is allowed to compile, when it shouldn’t be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99664 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #240 from John Buddery --- Yeah, it sure eats up the space. One question about PR66319 - it's marked as resolved, so is this committed as a patch in the trunk ? I'm hoping that eventually there will be a way to get all the edits here committed so that future versions will build out of the box.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #241 from The Written Word --- (In reply to John Buddery from comment #240) > One question about PR66319 - it's marked as resolved, so is this committed > as a patch in the trunk ? It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed.
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 --- Comment #9 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:ad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0 commit r12-2325-gad5f8ac1d2f2dc92d43663243b52f9e9eb3cf7c0 Author: Bill Schmidt Date: Thu Jul 15 10:16:17 2021 -0500 rs6000: Don't let swaps pass break multiply low-part (PR101129) 2021-07-15 Bill Schmidt gcc/ PR target/101129 * config/rs6000/rs6000-p8swap.c (has_part_mult): New. (rs6000_analyze_swaps): Insns containing a subreg of a mult are not swappable. gcc/testsuite/ PR target/101129 * gcc.target/powerpc/pr101129.c: New.
[Bug tree-optimization/101462] New: [12 regression] ICE on aarch64 after r12-2292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101462
Bug ID: 101462
Summary: [12 regression] ICE on aarch64 after r12-2292
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
After r12-2292 we have an ICE on aarch64:
FAIL: gcc.dg/vect/pr92324-4.c (test for excess errors)
Excess errors:
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/gcc.dg/vect/pr92324-4.c:7:1:
error: incompatible types in 'PHI' argument 1
vector(2) unsigned int
vector(2) int
_91 = PHI <_90(17), _83(11)>
during GIMPLE pass: vect
dump file: ./pr92324-4.c.167t.vect
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/testsuite/gcc.dg/vect/pr92324-4.c:7:1:
internal compiler error: verify_gimple failed
0x142fe6f verify_gimple_in_cfg(function*, bool)
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/tree-cfg.c:5536
0x12701fa execute_function_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:2042
0x126f132 do_per_function
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:1687
0x12703ee execute_todo
/home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/gcc/passes.c:2096
gcc is configured --target=aarch64-none-linux-gnu
cc1 is invoked with:
cc1 -fpreprocessed ./pr92324-4.i -quiet -dumpdir ./ -dumpbase pr92324-4.c
-dumpbase-ext .c -mlittle-endian -mabi=lp64 -O2 -version
-fdiagnostics-color=never -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-urls=never
-fdiagnostics-path-format=separate-events -flto -ffat-lto-objects
-ftree-vectorize -fno-tree-loop-distribute-patterns -fvect-cost-model=unlimited
-fno-common -fdump-tree-vect-details -o ./pr92324-4.s
There is another regression which does not ICE:
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fminnmv
FAIL: gcc.target/aarch64/vect-fmaxv-fminv-compile.c scan-assembler fmaxnmv
Before the patch:
maxv_f32:
.LFB0:
.cfi_startproc
ldr q1, [x0, 4]
ld1r{v3.4s}, [x0]
ldr d0, [x0, 20]
ldr s2, [x0, 28]
fmaxnm v1.4s, v1.4s, v3.4s
fmaxnmv s1, v1.4s
dup v1.2s, v1.s[0]
fmaxnm v0.2s, v0.2s, v1.2s
fmaxnmp s0, v0.2s
fmaxnm s0, s2, s0
ret
After the patch:
maxv_f32:
.LFB0:
.cfi_startproc
ldr q1, [x0, 4]
ld1r{v3.4s}, [x0]
ldr d2, [x0, 20]
ldr s0, [x0, 28]
fmaxnm v1.4s, v1.4s, v3.4s
dup d3, v1.d[1]
fmaxnm v1.2s, v1.2s, v3.2s
fmaxnm v1.2s, v1.2s, v2.2s
fmaxnmp s1, v1.2s
fmaxnm s0, s0, s1
ret
[Bug target/101129] [11/12 Regression] wrong code at -O1 since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101129 Bill Schmidt changed: What|Removed |Added Known to fail|12.0| Known to work||12.0 --- Comment #10 from Bill Schmidt --- Fixed on trunk, but will require backports.
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #242 from dave.anglin at bell dot net --- On 2021-07-15 11:01 a.m., bugzilla-gcc at thewrittenword dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #241 from The Written Word com> --- > (In reply to John Buddery from comment #240) >> One question about PR66319 - it's marked as resolved, so is this committed >> as a patch in the trunk ? > It's resolved for HP-UX/PA but my HP-UX/IA patch was never committed. Patch for PR66319 needs submission to gcc-patches list with cc to ia64 and/or hpux maintainer. Patch must be submitted by someone with copyright assignment or DOC. See: https://gcc.gnu.org/contribute.html
[Bug libstdc++/101429] __replacement_assert should be marked as noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101429 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1f7182d68c24985dace2a94422c671ff987c262c commit r12-2326-g1f7182d68c24985dace2a94422c671ff987c262c Author: Jonathan Wakely Date: Wed Jul 14 12:25:11 2021 +0100 libstdc++: Add noexcept to __replacement_assert [PR101429] This results in slightly smaller code when assertions are enabled when either using Clang (because it adds code to call std::terminate when potentially-throwing functions are called in a noexcept function) or a freestanding or non-verbose build (because it doesn't use printf). Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101429 * include/bits/c++config (__replacement_assert): Add noexcept. [!_GLIBCXX_VERBOSE] (__glibcxx_assert_impl): Use __builtin_trap instead of __replacement_assert.
[Bug c++/101460] Useless cascade of overload resolution errors for invalid expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101460 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:17855eed7fc76b2cee7fbbc26f84d3c8b99be13c commit r12-2327-g17855eed7fc76b2cee7fbbc26f84d3c8b99be13c Author: Jonathan Wakely Date: Wed Jul 14 20:14:14 2021 +0100 libstdc++: Fix std::get for std::tuple [PR101427] The std::get functions relied on deduction failing if more than one base class existed for the type T. However the implementation of Core DR 2303 (in r11-4693) made deduction succeed (and select the more-derived base class). This rewrites the implementation of std::get to explicitly check for more than one occurrence of T in the tuple elements, making it ill-formed again. Additionally, the large wall of overload resolution errors described in PR c++/101460 is avoided by making std::get use __get_helper directly instead of calling std::get, and by adding a deleted overload of __get_helper for out-of-range N. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101427 * include/std/tuple (tuple_element): Improve static_assert text. (__get_helper): Add deleted overload. (get(tuple&&), get(const tuple&&)): Use __get_helper directly. (__get_helper2): Remove. (__find_uniq_type_in_pack): New constexpr helper function. (get): Use __find_uniq_type_in_pack and __get_helper instead of __get_helper2. * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust expected errors. * testsuite/20_util/tuple/element_access/101427.cc: New test.
[Bug libstdc++/101427] [11/12 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:17855eed7fc76b2cee7fbbc26f84d3c8b99be13c commit r12-2327-g17855eed7fc76b2cee7fbbc26f84d3c8b99be13c Author: Jonathan Wakely Date: Wed Jul 14 20:14:14 2021 +0100 libstdc++: Fix std::get for std::tuple [PR101427] The std::get functions relied on deduction failing if more than one base class existed for the type T. However the implementation of Core DR 2303 (in r11-4693) made deduction succeed (and select the more-derived base class). This rewrites the implementation of std::get to explicitly check for more than one occurrence of T in the tuple elements, making it ill-formed again. Additionally, the large wall of overload resolution errors described in PR c++/101460 is avoided by making std::get use __get_helper directly instead of calling std::get, and by adding a deleted overload of __get_helper for out-of-range N. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/101427 * include/std/tuple (tuple_element): Improve static_assert text. (__get_helper): Add deleted overload. (get(tuple&&), get(const tuple&&)): Use __get_helper directly. (__get_helper2): Remove. (__find_uniq_type_in_pack): New constexpr helper function. (get): Use __find_uniq_type_in_pack and __get_helper instead of __get_helper2. * testsuite/20_util/tuple/element_access/get_neg.cc: Adjust expected errors. * testsuite/20_util/tuple/element_access/101427.cc: New test.
[Bug libstdc++/101429] __replacement_assert should be marked as noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101429 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jonathan Wakely --- Fixed on trunk. I've just notice the changelog is wrong, as I used __builtin_abort not __builtin_trap.
[Bug libstdc++/101427] [11 Regression] std::get should refuse to compile if type is provided and it is duplicated in std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101427 Jonathan Wakely changed: What|Removed |Added Summary|[11/12 Regression] std::get |[11 Regression] std::get |should refuse to compile if |should refuse to compile if |type is provided and it is |type is provided and it is |duplicated in std::tuple|duplicated in std::tuple --- Comment #3 from Jonathan Wakely --- Fixed on trunk for now.
[Bug c++/101463] New: Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463
Bug ID: 101463
Summary: Using a constexpr variable template specialization as
default argument for non-type template parameter of
reference type leads gcc to reject function call
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following code will reproduce the issue:
extern const int a;
template
constexpr const int& blub = a;
template >
void f() {}
int main()
{
f(); // error: no matching function for call to
'f()'
f>(); // ok
}
Note: gcc will accept the function call when the exact same template argument
is explicitly specified instead.
godbolt link: https://godbolt.org/z/jd3EGWEfo
[Bug libstdc++/101307] Variable templates for type traits—corrections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101307 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-07-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Jonathan Wakely --- (In reply to Christopher Yeleighton from comment #0) > 2. The general description (is_foovalue) should be (is_foo ::value) This is another doxygen bug, the :: is present in the source.
[Bug fortran/100949] [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100949 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:ba66193c2966ff7106245e23d6b359f7d30bcff7 commit r11-8756-gba66193c2966ff7106245e23d6b359f7d30bcff7 Author: Harald Anlauf Date: Wed Jul 14 17:25:29 2021 +0200 Fortran - ICE in gfc_conv_expr_present initializing non-dummy class variable gcc/fortran/ChangeLog: PR fortran/100949 * trans-expr.c (gfc_trans_class_init_assign): Call gfc_conv_expr_present only for dummy variables. gcc/testsuite/ChangeLog: PR fortran/100949 * gfortran.dg/pr100949.f90: New test. (cherry picked from commit 269ca408e2839d7f3554a91515d73d4d95352f68)
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233
--- Comment #5 from Patrick Palka ---
Looks like the original testcase is indeed valid, but one needs to include
as well (for pmr::polymorphic_allocator).
Reduced:
template
struct A { A(T, U); };
template
using B = A;
using type = decltype(B{0, 0});
[Bug c++/101233] ICE when using ::ranges::v3::to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101233 --- Comment #6 from Jonathan Wakely --- (In reply to Patrick Palka from comment #5) > but one needs to include > as well (for pmr::polymorphic_allocator). For libstdc++ the header only declares the pmr::vector alias, without defining prm::polymorphic_allocator. That means pmr::vector is an incomplete type unless you also include . This is permitted by the standard, and avoids paying to include if you don't plan to use the pmr types.
[Bug c/97548] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:98f1f9f38c45218c06200feb1939c9433a2ab6ca commit r12-2329-g98f1f9f38c45218c06200feb1939c9433a2ab6ca Author: Martin Sebor Date: Thu Jul 15 10:11:23 2021 -0600 Avoid -Wvla-parameter for nontrivial bounds [PR97548]. Resolves: PR c/101289 - bogus -Wvla-paramater warning when using const for vla param PR c/97548 - bogus -Wvla-parameter on a bound expression involving a parameter gcc/c-family/ChangeLog: PR c/101289 PR c/97548 * c-warn.c (warn_parm_array_mismatch): Use OEP_DECL_NAME. gcc/c/ChangeLog: PR c/101289 PR c/97548 * c-decl.c (get_parm_array_spec): Strip nops. gcc/ChangeLog: PR c/101289 PR c/97548 * fold-const.c (operand_compare::operand_equal_p): Handle OEP_DECL_NAME. (operand_compare::verify_hash_value): Same. * tree-core.h (OEP_DECL_NAME): New. gcc/testsuite/ChangeLog: * gcc.dg/Wvla-parameter-12.c: New test.
[Bug c/101289] bogus -Wvla-paramater warning when using const for vla param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:98f1f9f38c45218c06200feb1939c9433a2ab6ca commit r12-2329-g98f1f9f38c45218c06200feb1939c9433a2ab6ca Author: Martin Sebor Date: Thu Jul 15 10:11:23 2021 -0600 Avoid -Wvla-parameter for nontrivial bounds [PR97548]. Resolves: PR c/101289 - bogus -Wvla-paramater warning when using const for vla param PR c/97548 - bogus -Wvla-parameter on a bound expression involving a parameter gcc/c-family/ChangeLog: PR c/101289 PR c/97548 * c-warn.c (warn_parm_array_mismatch): Use OEP_DECL_NAME. gcc/c/ChangeLog: PR c/101289 PR c/97548 * c-decl.c (get_parm_array_spec): Strip nops. gcc/ChangeLog: PR c/101289 PR c/97548 * fold-const.c (operand_compare::operand_equal_p): Handle OEP_DECL_NAME. (operand_compare::verify_hash_value): Same. * tree-core.h (OEP_DECL_NAME): New. gcc/testsuite/ChangeLog: * gcc.dg/Wvla-parameter-12.c: New test.
[Bug c/101289] bogus -Wvla-paramater warning when using const for vla param
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289 Martin Sebor changed: What|Removed |Added Known to fail|12.0| --- Comment #4 from Martin Sebor --- Fixed for GCC 12.0.
[Bug c/97548] bogus -Wvla-parameter on a bound expression involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548 --- Comment #4 from Martin Sebor --- Fixed for GCC 12.0.
[Bug middle-end/101457] [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 --- Comment #2 from CVS Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:b25edf6e6feeadc6a5aa337b8c725786227162dd commit r12-2330-gb25edf6e6feeadc6a5aa337b8c725786227162dd Author: Tamar Christina Date: Thu Jul 15 17:42:10 2021 +0100 testsuite: Fix testisms in scalar tests PR101457 These testcases accidentally contain the wrong signs for the expected values for the scalar code. The vector code however is correct. Committed as a trivial fix. gcc/testsuite/ChangeLog: PR middle-end/101457 * gcc.dg/vect/vect-reduc-dot-17.c: Fix signs of scalar code. * gcc.dg/vect/vect-reduc-dot-18.c: Likewise. * gcc.dg/vect/vect-reduc-dot-22.c: Likewise. * gcc.dg/vect/vect-reduc-dot-9.c: Likewise.
[Bug middle-end/101457] [12 regression] new test cases in r12-2300 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101457 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tamar Christina --- Should be fixed now.
[Bug c++/101443] [9/10/11/12 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7094a69bd62a14dfa311eaa2fea468f221c7c9f3
commit r12-2331-g7094a69bd62a14dfa311eaa2fea468f221c7c9f3
Author: Jakub Jelinek
Date: Thu Jul 15 18:53:20 2021 +0200
c++: Optimize away NULLPTR_TYPE comparisons [PR101443]
Comparisons of NULLPTR_TYPE operands cause all kinds of problems in the
middle-end and in fold-const.c, various optimizations assume that if they
see e.g. a non-equality comparison with one of the operands being
INTEGER_CST and it is not INTEGRAL_TYPE_P (which has TYPE_{MIN,MAX}_VALUE),
they can build_int_cst (type, 1) to find a successor.
The following patch fixes it by making sure they don't appear in the IL,
optimize them away at cp_fold time as all can be folded.
Though, I've just noticed that clang++ rejects the non-equality comparisons
instead, foo () > 0 with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'int')
and foo () > nullptr with
invalid operands to binary expression ('decltype(nullptr)' (aka
'nullptr_t') and 'nullptr_t')
Shall we reject those too, in addition or instead of parts of this patch?
If so, wouldn't this patch be still useful for backports, I bet we don't
want to start reject it on the release branches when we used to accept it.
2021-07-15 Jakub Jelinek
PR c++/101443
* cp-gimplify.c (cp_fold): For comparisons with NULLPTR_TYPE
operands, fold them right away to true or false.
* g++.dg/cpp0x/nullptr46.C: New test.
[Bug c++/101443] [9/10/11 Regression] internal compiler error: in wide_int_to_tree_1, at tree.c:1519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101443 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |internal compiler error: in |internal compiler error: in |wide_int_to_tree_1, at |wide_int_to_tree_1, at |tree.c:1519 |tree.c:1519 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far. The accepts-invalid case is already tracked in PR99701
[Bug target/98667] gcc generates endbr32 invalid opcode on -march=i486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98667 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from H.J. Lu --- Fixed for GCC 11.
[Bug driver/47785] GCC with -flto does not pass -Wa/-Xassembler options to the assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.4 --- Comment #22 from H.J. Lu --- Fix for GCC 10 and GCC 9.4.
[Bug target/101448] Use GCC 9.3.0 to build Ceph crimson-osd on Arm64, linker failed for relocation truncated to fit: R_AARCH64_CALL26 against symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101448 --- Comment #6 from Richard Earnshaw --- (In reply to Kevin Zhao from comment #5) > Hi Richard, > > Thanks for your info. > Previously it is built without any -O parameters, so it should be -O0 by > default. > > I've tried to use the "-Og" to link, it is quite interesting that use -Og we > can link success > > Also, use -O1, -O2 and -Os, Linking works quite well. -O0 generates *very* poor (and large) code. I wouldn't recommend using at all except for basic syntax checking of your application. -Og is pretty minimal optimization and should still be suitable for debugging an application if needed. So I think this is simply a case of you exceeded the limits of the system.
[Bug target/101464] New: Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464
Bug ID: 101464
Summary: Replace zveroupper with vpxor
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: i386, x86-64
[hjl@gnu-cfl-2 pr101456]$ cat y.c
#include
extern __m256d x, y;
void
foo (void)
{
x = y;
}
[hjl@gnu-cfl-2 pr101456]$ gcc -S -O2 -mavx2 y.c
[hjl@gnu-cfl-2 pr101456]$ cat y.s
.file "y.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB5667:
.cfi_startproc
vmovapd y(%rip), %ymm0
vmovapd %ymm0, x(%rip)
vzeroupper
ret
.cfi_endproc
.LFE5667:
.size foo, .-foo
.ident "GCC: (GNU) 11.1.1 20210531 (Red Hat 11.1.1-3)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 pr101456]$
vzeroupper can be replaced by a single pxor.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #243 from The Written Word --- (In reply to John Buddery from comment #238) > It seems binutils 2.32 and earlier works fine in 32 bit mode, but 2.33.1 and > later require a 64 bit build for 64 bit objects to work reliably. I can build up to and including 2.32 with the HP C compiler. Starting with 2.33.1, they add -std=gnu99. Might be possible to fix this but I might retry with 2.32.
[Bug c++/101465] New: Poorly worded error from a call to a pointer-to-member function not wrapped in parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101465
Bug ID: 101465
Summary: Poorly worded error from a call to a pointer-to-member
function not wrapped in parentheses
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: josephcsible at gmail dot com
Target Milestone: ---
Consider this C++ code:
struct foo *x;
void (foo::*myfuncptr)();
void f() {
x->*myfuncptr();
}
This fails to compile, as it should. The problem is that the error I get says I
"must use '.*' or '->*' to call pointer-to-member function", even though I'm
already using '->*'. The actual change I need to make is to add parentheses,
like this: "(x->*myfuncptr)();" We should make the error say this instead.
[Bug analyzer/94713] Analyzer is buggy on uninitialized pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:33255ad3ac14e3953750fe0f2d82b901c2852ff6 commit r12-2337-g33255ad3ac14e3953750fe0f2d82b901c2852ff6 Author: David Malcolm Date: Thu Jul 15 15:07:07 2021 -0400 analyzer: reimplement -Wanalyzer-use-of-uninitialized-value [PR95006 et al] The initial gcc 10 era commit of the analyzer (in 757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of -Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before the release of gcc 10.1 This patch reintroduces the warning, heavily rewritten, with (I hope) a less buggy implementation this time, for GCC 12. gcc/analyzer/ChangeLog: PR analyzer/95006 PR analyzer/94713 PR analyzer/94714 * analyzer.cc (maybe_reconstruct_from_def_stmt): Split out GIMPLE_ASSIGN case into... (get_diagnostic_tree_for_gassign_1): New. (get_diagnostic_tree_for_gassign): New. * analyzer.h (get_diagnostic_tree_for_gassign): New decl. * analyzer.opt (Wanalyzer-write-to-string-literal): New. * constraint-manager.cc (class svalue_purger): New. (constraint_manager::purge_state_involving): New. * constraint-manager.h (constraint_manager::purge_state_involving): New. * diagnostic-manager.cc (saved_diagnostic::supercedes_p): New. (dedupe_winners::handle_interactions): New. (diagnostic_manager::emit_saved_diagnostics): Call it. * diagnostic-manager.h (saved_diagnostic::supercedes_p): New decl. * engine.cc (impl_region_model_context::warn): Convert return type to bool. Return false if the diagnostic isn't saved. (impl_region_model_context::purge_state_involving): New. (impl_sm_context::get_state): Use NULL ctxt when querying old rvalue. (impl_sm_context::set_next_state): Use new sval when querying old state. (class dump_path_diagnostic): Move to region-model.cc (exploded_node::on_stmt): Move to on_stmt_pre and on_stmt_post. Remove call to purge_state_involving. (exploded_node::on_stmt_pre): New, based on the above. Move most of it to region_model::on_stmt_pre. (exploded_node::on_stmt_post): Likewise, moving to region_model::on_stmt_post. (class stale_jmp_buf): Fix parent class to use curiously recurring template pattern. (feasibility_state::maybe_update_for_edge): Call on_call_pre and on_call_post on gcalls. * exploded-graph.h (impl_region_model_context::warn): Return bool. (impl_region_model_context::purge_state_involving): New decl. (exploded_node::on_stmt_pre): New decl. (exploded_node::on_stmt_post): New decl. * pending-diagnostic.h (pending_diagnostic::use_of_uninit_p): New. (pending_diagnostic::supercedes_p): New. * program-state.cc (sm_state_map::get_state): Inherit state for conjured_svalue as well as initial_svalue. (sm_state_map::purge_state_involving): Also support SK_CONJURED. * region-model-impl-calls.cc (call_details::get_uncertainty): Handle m_ctxt being NULL. (call_details::get_or_create_conjured_svalue): New. (region_model::impl_call_fgets): New. (region_model::impl_call_fread): New. * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Return an uninitialized poisoned value for regions that can't have initial values. * region-model-reachability.cc (reachable_regions::mark_escaped_clusters): Handle ctxt being NULL. * region-model.cc (region_to_value_map::purge_state_involving): New. (poisoned_value_diagnostic::use_of_uninit_p): New. (poisoned_value_diagnostic::emit): Handle POISON_KIND_UNINIT. (poisoned_value_diagnostic::describe_final_event): Likewise. (region_model::check_for_poison): New. (region_model::on_assignment): Call it. (class dump_path_diagnostic): Move here from engine.cc. (region_model::on_stmt_pre): New, based on exploded_node::on_stmt. (region_model::on_call_pre): Move the setting of the LHS to a conjured svalue to before the checks for specific functions. Handle "fgets", "fgets_unlocked", and "fread". (region_model::purge_state_involving): New. (region_model::handle_unrecognized_call): Handle ctxt being NULL. (region_model::get_rvalue): C
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:33255ad3ac14e3953750fe0f2d82b901c2852ff6 commit r12-2337-g33255ad3ac14e3953750fe0f2d82b901c2852ff6 Author: David Malcolm Date: Thu Jul 15 15:07:07 2021 -0400 analyzer: reimplement -Wanalyzer-use-of-uninitialized-value [PR95006 et al] The initial gcc 10 era commit of the analyzer (in 757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of -Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before the release of gcc 10.1 This patch reintroduces the warning, heavily rewritten, with (I hope) a less buggy implementation this time, for GCC 12. gcc/analyzer/ChangeLog: PR analyzer/95006 PR analyzer/94713 PR analyzer/94714 * analyzer.cc (maybe_reconstruct_from_def_stmt): Split out GIMPLE_ASSIGN case into... (get_diagnostic_tree_for_gassign_1): New. (get_diagnostic_tree_for_gassign): New. * analyzer.h (get_diagnostic_tree_for_gassign): New decl. * analyzer.opt (Wanalyzer-write-to-string-literal): New. * constraint-manager.cc (class svalue_purger): New. (constraint_manager::purge_state_involving): New. * constraint-manager.h (constraint_manager::purge_state_involving): New. * diagnostic-manager.cc (saved_diagnostic::supercedes_p): New. (dedupe_winners::handle_interactions): New. (diagnostic_manager::emit_saved_diagnostics): Call it. * diagnostic-manager.h (saved_diagnostic::supercedes_p): New decl. * engine.cc (impl_region_model_context::warn): Convert return type to bool. Return false if the diagnostic isn't saved. (impl_region_model_context::purge_state_involving): New. (impl_sm_context::get_state): Use NULL ctxt when querying old rvalue. (impl_sm_context::set_next_state): Use new sval when querying old state. (class dump_path_diagnostic): Move to region-model.cc (exploded_node::on_stmt): Move to on_stmt_pre and on_stmt_post. Remove call to purge_state_involving. (exploded_node::on_stmt_pre): New, based on the above. Move most of it to region_model::on_stmt_pre. (exploded_node::on_stmt_post): Likewise, moving to region_model::on_stmt_post. (class stale_jmp_buf): Fix parent class to use curiously recurring template pattern. (feasibility_state::maybe_update_for_edge): Call on_call_pre and on_call_post on gcalls. * exploded-graph.h (impl_region_model_context::warn): Return bool. (impl_region_model_context::purge_state_involving): New decl. (exploded_node::on_stmt_pre): New decl. (exploded_node::on_stmt_post): New decl. * pending-diagnostic.h (pending_diagnostic::use_of_uninit_p): New. (pending_diagnostic::supercedes_p): New. * program-state.cc (sm_state_map::get_state): Inherit state for conjured_svalue as well as initial_svalue. (sm_state_map::purge_state_involving): Also support SK_CONJURED. * region-model-impl-calls.cc (call_details::get_uncertainty): Handle m_ctxt being NULL. (call_details::get_or_create_conjured_svalue): New. (region_model::impl_call_fgets): New. (region_model::impl_call_fread): New. * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Return an uninitialized poisoned value for regions that can't have initial values. * region-model-reachability.cc (reachable_regions::mark_escaped_clusters): Handle ctxt being NULL. * region-model.cc (region_to_value_map::purge_state_involving): New. (poisoned_value_diagnostic::use_of_uninit_p): New. (poisoned_value_diagnostic::emit): Handle POISON_KIND_UNINIT. (poisoned_value_diagnostic::describe_final_event): Likewise. (region_model::check_for_poison): New. (region_model::on_assignment): Call it. (class dump_path_diagnostic): Move here from engine.cc. (region_model::on_stmt_pre): New, based on exploded_node::on_stmt. (region_model::on_call_pre): Move the setting of the LHS to a conjured svalue to before the checks for specific functions. Handle "fgets", "fgets_unlocked", and "fread". (region_model::purge_state_involving): New. (region_model::handle_unrecognized_call): Handle ctxt being NULL. (region_model::get_rvalue): C
[Bug analyzer/94714] Analyzer: no warning on access of an uninitialized variable of automatic storage duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:33255ad3ac14e3953750fe0f2d82b901c2852ff6 commit r12-2337-g33255ad3ac14e3953750fe0f2d82b901c2852ff6 Author: David Malcolm Date: Thu Jul 15 15:07:07 2021 -0400 analyzer: reimplement -Wanalyzer-use-of-uninitialized-value [PR95006 et al] The initial gcc 10 era commit of the analyzer (in 757bf1dff5e8cee34c0a75d06140ca972bfecfa7) had an implementation of -Wanalyzer-use-of-uninitialized-value, but was sufficiently buggy that I removed it in 78b9783774bfd3540f38f5b1e3c7fc9f719653d7 before the release of gcc 10.1 This patch reintroduces the warning, heavily rewritten, with (I hope) a less buggy implementation this time, for GCC 12. gcc/analyzer/ChangeLog: PR analyzer/95006 PR analyzer/94713 PR analyzer/94714 * analyzer.cc (maybe_reconstruct_from_def_stmt): Split out GIMPLE_ASSIGN case into... (get_diagnostic_tree_for_gassign_1): New. (get_diagnostic_tree_for_gassign): New. * analyzer.h (get_diagnostic_tree_for_gassign): New decl. * analyzer.opt (Wanalyzer-write-to-string-literal): New. * constraint-manager.cc (class svalue_purger): New. (constraint_manager::purge_state_involving): New. * constraint-manager.h (constraint_manager::purge_state_involving): New. * diagnostic-manager.cc (saved_diagnostic::supercedes_p): New. (dedupe_winners::handle_interactions): New. (diagnostic_manager::emit_saved_diagnostics): Call it. * diagnostic-manager.h (saved_diagnostic::supercedes_p): New decl. * engine.cc (impl_region_model_context::warn): Convert return type to bool. Return false if the diagnostic isn't saved. (impl_region_model_context::purge_state_involving): New. (impl_sm_context::get_state): Use NULL ctxt when querying old rvalue. (impl_sm_context::set_next_state): Use new sval when querying old state. (class dump_path_diagnostic): Move to region-model.cc (exploded_node::on_stmt): Move to on_stmt_pre and on_stmt_post. Remove call to purge_state_involving. (exploded_node::on_stmt_pre): New, based on the above. Move most of it to region_model::on_stmt_pre. (exploded_node::on_stmt_post): Likewise, moving to region_model::on_stmt_post. (class stale_jmp_buf): Fix parent class to use curiously recurring template pattern. (feasibility_state::maybe_update_for_edge): Call on_call_pre and on_call_post on gcalls. * exploded-graph.h (impl_region_model_context::warn): Return bool. (impl_region_model_context::purge_state_involving): New decl. (exploded_node::on_stmt_pre): New decl. (exploded_node::on_stmt_post): New decl. * pending-diagnostic.h (pending_diagnostic::use_of_uninit_p): New. (pending_diagnostic::supercedes_p): New. * program-state.cc (sm_state_map::get_state): Inherit state for conjured_svalue as well as initial_svalue. (sm_state_map::purge_state_involving): Also support SK_CONJURED. * region-model-impl-calls.cc (call_details::get_uncertainty): Handle m_ctxt being NULL. (call_details::get_or_create_conjured_svalue): New. (region_model::impl_call_fgets): New. (region_model::impl_call_fread): New. * region-model-manager.cc (region_model_manager::get_or_create_initial_value): Return an uninitialized poisoned value for regions that can't have initial values. * region-model-reachability.cc (reachable_regions::mark_escaped_clusters): Handle ctxt being NULL. * region-model.cc (region_to_value_map::purge_state_involving): New. (poisoned_value_diagnostic::use_of_uninit_p): New. (poisoned_value_diagnostic::emit): Handle POISON_KIND_UNINIT. (poisoned_value_diagnostic::describe_final_event): Likewise. (region_model::check_for_poison): New. (region_model::on_assignment): Call it. (class dump_path_diagnostic): Move here from engine.cc. (region_model::on_stmt_pre): New, based on exploded_node::on_stmt. (region_model::on_call_pre): Move the setting of the LHS to a conjured svalue to before the checks for specific functions. Handle "fgets", "fgets_unlocked", and "fread". (region_model::purge_state_involving): New. (region_model::handle_unrecognized_call): Handle ctxt being NULL. (region_model::get_rvalue): C
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:f0500db3692276f60e0562c17c87a0cb03e34398 commit r12-2338-gf0500db3692276f60e0562c17c87a0cb03e34398 Author: Martin Sebor Date: Thu Jul 15 13:15:03 2021 -0600 Detect buffer overflow by aggregate and vector stores [PR97027]. Resolves: PR middle-end/97027 - missing warning on buffer overflow storing a larger scalar into a smaller array gcc/ChangeLog: PR middle-end/97027 * tree-ssa-strlen.c (handle_assign): New function. (maybe_warn_overflow): Add argument. (nonzero_bytes_for_type): New function. (count_nonzero_bytes): Handle more tree types. Call nonzero_bytes_for_tye. (count_nonzero_bytes): Handle types. (handle_store): Handle stores from function calls. (strlen_check_and_optimize_call): Move code to handle_assign. Call it for assignments from function calls. gcc/testsuite/ChangeLog: PR middle-end/97027 * gcc.dg/Wstringop-overflow-15.c: Remove an xfail. * gcc.dg/Wstringop-overflow-47.c: Adjust xfails. * gcc.dg/torture/pr69170.c: Avoid valid warnings. * gcc.dg/torture/pr70025.c: Prune out a false positive. * gcc.dg/vect/pr97769.c: Initialize a loop control variable. * gcc.target/i386/pr92658-avx512bw-trunc.c: Increase buffer size to avoid overflow. * gcc.target/i386/pr92658-avx512f.c: Same. * gcc.dg/Wstringop-overflow-68.c: New test. * gcc.dg/Wstringop-overflow-69.c: New test. * gcc.dg/Wstringop-overflow-70.c: New test. * gcc.dg/Wstringop-overflow-71.c: New test. * gcc.dg/strlenopt-95.c: New test.
[Bug tree-optimization/101466] New: Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 Bug ID: 101466 Summary: Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://godbolt.org/z/fPdGeKMYM Should fold together and optimize to something like this https://godbolt.org/z/6cooP81xc
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Martin Sebor --- With r12-2338 Wstringop-overflow-47.c passes on aarch64, arm, as well as x86_64, so this can now be fully resolved.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 97027, which changed state. Bug 97027 Summary: missing warning on buffer overflow storing a larger scalar into a smaller array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #1 from cqwrteur --- Created attachment 51158 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51158&action=edit this is the assembly generated from --disable-libstdcxx-verbose The bounds checking is still not folding together, even with this naive case.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1 + --disable-libstdcxx-verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #2 from cqwrteur --- The --enable-libstdcxx-verbose has side effects, not optimizing to vectorization code is correct, although .L12: mov ecx, OFFSET FLAT:.LC1 mov edx, OFFSET FLAT:.LC2 mov esi, 276 mov edi, OFFSET FLAT:.LC3 callstd::__replacement_assert(char const*, int, char const*, char const*) .L13: mov ecx, OFFSET FLAT:.LC1 mov edx, OFFSET FLAT:.LC2 mov esi, 276 mov edi, OFFSET FLAT:.LC3 callstd::__replacement_assert(char const*, int, char const*, char const*) may be merged. However, the __builtin_abort() case can be merged together without any issue I believe.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1 + --disable-libstdcxx-verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #3 from cqwrteur --- > > However, the __builtin_abort() case can be merged together without any issue > I believe. And optimize to vectorized code.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-07-15
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
Keywords||missed-optimization
Summary|Optimizers should fold |Optimizers should fold
|bounds checking for |bounds checking for
|-D_GLIBCXX_ASSERTIONS=1 + |-D_GLIBCXX_ASSERTIONS=1
|--disable-libstdcxx-verbose |
Ever confirmed|0 |1
--- Comment #4 from Andrew Pinski ---
Reduced testcase:
extern void g() __attribute__((noreturn));
void square(int t, int *tt)
{
if (t == 0) g();
tt[0] = 0;
if (t == 1) g();
tt[1] = 0;
if (t == 2) g();
tt[2] = 0;
if (t == 3) g();
tt[3] = 0;
if (t == 4) g();
tt[4] = 0;
}
[Bug analyzer/94713] Analyzer is buggy on uninitialized pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed on trunk for gcc 12 by the above patch.
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 Bug 95006 depends on bug 94713, which changed state. Bug 94713 Summary: Analyzer is buggy on uninitialized pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/94714] Analyzer: no warning on access of an uninitialized variable of automatic storage duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed on trunk for gcc 12 by the above patch.
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 Bug 95006 depends on bug 94714, which changed state. Bug 94714 Summary: Analyzer: no warning on access of an uninitialized variable of automatic storage duration https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94714 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug analyzer/95006] RFE: Reimplement -Wanalyzer-use-of-uninitialized-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95006 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed on trunk for gcc 12 by the above patch.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466 --- Comment #5 from Andrew Pinski --- (In reply to cqwrteur from comment #2) > The --enable-libstdcxx-verbose has side effects, not optimizing to > vectorization code is correct, although Those can be merged still since the arguments to __replacement_assert are all the same, you can change my reduced testcase to do something similar as __replacement_assert really. The problem is the merging of the if don't happen if there is an statement inbetween.
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #6 from cqwrteur ---
(In reply to Andrew Pinski from comment #4)
> Reduced testcase:
> extern void g() __attribute__((noreturn));
>
> void square(int t, int *tt)
> {
> if (t == 0) g();
> tt[0] = 0;
> if (t == 1) g();
> tt[1] = 0;
> if (t == 2) g();
> tt[2] = 0;
> if (t == 3) g();
> tt[3] = 0;
> if (t == 4) g();
> tt[4] = 0;
> }
I think the reduced testcase should be
extern void g() __attribute__((noreturn));
void square(unsigned t, int *tt)
{
if (t<=0) g();
tt[0] = 0;
if (t<=1) g();
tt[1] = 0;
if (t<=2) g();
tt[2] = 0;
if (t<=3) g();
tt[3] = 0;
if (t<=4) g();
tt[4] = 0;
}
[Bug tree-optimization/101466] Optimizers should fold bounds checking for -D_GLIBCXX_ASSERTIONS=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101466
--- Comment #7 from Andrew Pinski ---
(In reply to cqwrteur from comment #6)
> (In reply to Andrew Pinski from comment #4)
> > Reduced testcase:
> > extern void g() __attribute__((noreturn));
> >
> > void square(int t, int *tt)
> > {
> > if (t == 0) g();
> > tt[0] = 0;
> > if (t == 1) g();
> > tt[1] = 0;
> > if (t == 2) g();
> > tt[2] = 0;
> > if (t == 3) g();
> > tt[3] = 0;
> > if (t == 4) g();
> > tt[4] = 0;
> > }
>
> I think the reduced testcase should be
>
> extern void g() __attribute__((noreturn));
>
> void square(unsigned t, int *tt)
> {
> if (t<=0) g();
> tt[0] = 0;
> if (t<=1) g();
> tt[1] = 0;
> if (t<=2) g();
> tt[2] = 0;
> if (t<=3) g();
> tt[3] = 0;
> if (t<=4) g();
> tt[4] = 0;
> }
Yes obvious t should be unsigned. But the <= will become == due to VRP
figuring that out :). So it is either way.
[Bug c++/83596] ['17] can't use member pointer result of a constexpr function as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83596 Jonathan Wakely changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Jonathan Wakely --- Fixed for GCC 9.1 by Jakub's patch: re PR c++/89285 (ICE after casting the this pointer in the constructor in C++17 mode) PR c++/89285 * builtins.c (fold_builtin_arith_overflow): If first two args are INTEGER_CSTs, set intres and ovfres to constants rather than calls to ifn. * constexpr.c (struct constexpr_fundef): Add parms and result members. (retrieve_constexpr_fundef): Adjust for the above change. (register_constexpr_fundef): Save constexpr body with copy_fn, temporarily set DECL_CONTEXT on DECL_RESULT before that. (get_fundef_copy): Change FUN argument to FUNDEF with constexpr_fundef * type, grab body and parms/result out of constexpr_fundef struct and temporarily change it for copy_fn calls too. (cxx_eval_builtin_function_call): For __builtin_FUNCTION temporarily adjust current_function_decl from ctx->call context. Test !potential_constant_expression instead of !is_constant_expression. (cxx_bind_parameters_in_call): Grab parameters from new_call. Undo convert_for_arg_passing changes for TREE_ADDRESSABLE type passing. (cxx_eval_call_expression): Adjust get_fundef_copy caller. (cxx_eval_conditional_expression): For IF_STMT, allow then or else operands to be NULL. (label_matches): Handle BREAK_STMT and CONTINUE_STMT. (cxx_eval_loop_expr): Add support for FOR_STMT, WHILE_STMT and DO_STMT. (cxx_eval_switch_expr): Add support for SWITCH_STMT. (cxx_eval_constant_expression): Handle IF_STMT, FOR_STMT, WHILE_STMT, DO_STMT, CONTINUE_STMT, SWITCH_STMT, BREAK_STMT and CONTINUE_STMT. For SIZEOF_EXPR, recurse on the result of fold_sizeof_expr. Ignore DECL_EXPR with USING_DECL operand. * lambda.c (maybe_add_lambda_conv_op): Build thisarg using build_int_cst to make it a valid constant expression. * g++.dg/ubsan/vptr-4.C: Expect reinterpret_cast errors. * g++.dg/cpp1y/constexpr-84192.C (f2): Adjust expected diagnostics. * g++.dg/cpp1y/constexpr-70265-2.C (foo): Adjust expected line of diagnostics. * g++.dg/cpp1y/constexpr-89285.C: New test. * g++.dg/cpp0x/constexpr-arith-overflow.C (add, sub, mul): Ifdef out for C++11. (TEST_ADD, TEST_SUB, TEST_MUL): Define to Assert (true) for C++11. * g++.dg/cpp0x/constexpr-arith-overflow2.C: New test. From-SVN: r269078 We should add the testcase before closing the bug.
[Bug middle-end/71690] some integer conversions defeat memcpy optimizaton
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 Andrew Macleod changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Andrew Macleod --- Not sure how to create a test case for this that isn't super dependent on debugging output formatting. regardless, the correct ranges are available if you are using ranger, so I will close this PR as "use ranger in your pass" :-) details here: https://gcc.gnu.org/pipermail/gcc/2021-June/236363.html it boils down to replacing your get_range_info calls (or SSA_NAME_RANGE_INFO or whatever is being used) with get_range_query ()->range_of_expr ()
[Bug tree-optimization/85316] [meta-bug] VRP range propagation missed cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316 Bug 85316 depends on bug 71690, which changed state. Bug 71690 Summary: some integer conversions defeat memcpy optimizaton https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71690 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/17459] Spurious message when forgetting parentheses on call of member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17459 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2005-06-13 00:43:47 |2021-7-15 --- Comment #6 from Jonathan Wakely --- (In reply to Manuel López-Ibáñez from comment #5) > The first error could be a bit nicer if it said why it is invalid. Clang > does: > > test.cc:3:16: error: reference to non-static member function must be called; > did you mean to call it with no arguments? I think we should just add a fix-it hint suggesting to add the () > but the thing is that this is not even a valid reference, so the error could > clarify a bit more the problem, no? I don't think mentioning "reference" here is a good idea at all, because that means something specific in C++ (and completely unrelated to this). I prefer GCC's "invalid use" wording. With a fix-it to add the () the error would be fine. If the function can't be called with no arguments, the fix-it would be wrong. I'm not sure what we want to do in that case. Suggest the fix-it anyway, and let the user figure out the next step? Clang just says: 17459-c3.C:3:16: error: reference to non-static member function must be called i.e. it omits the "did you mean to call it with no arguments?" part. So we could do the same and just not provide a fix-it in that case. > ISO C++ forbids taking the address of an unqualified non-static member > function, say ‘&S::foo’ instead; or did you mean to call 'foo()'? Maybe we should remove the -fpermissive extension that allows &foo as a non-standard way to form a pointer-to-member. That simplifies the handling of &foo, because we can just reject it instead of using a permerror. It's more than 20 years since that was acceptable syntax. And that could use a fix-it hint too, to suggest turning &foo into &S::foo. > The last error is bogus, it should be the same as the first one. Agreed.
[Bug target/101346] ICE: maximum number of generated reload insns per insn achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101346 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:f364cdffa47af574f90f671b2dcf5afa91442741 commit r12-2340-gf364cdffa47af574f90f671b2dcf5afa91442741 Author: Uros Bizjak Date: Thu Jul 15 22:34:25 2021 +0200 i386: Fix ix86_hard_regno_mode_ok for TDmode on 32bit targets [PR101346] General regs on 32bit targets do not support 128bit modes, including TDmode. gcc/ 2021-07-15 Uroš Bizjak PR target/101346 * config/i386/i386.h (VALID_SSE_REG_MODE): Add TDmode. (VALID_INT_MODE_P): Add SDmode and DDmode. Add TDmode for TARGET_64BIT. (VALID_DFP_MODE_P): Remove. * config/i386/i386.c (ix86_hard_regno_mode_ok): Do not use VALID_DFP_MODE_P. gcc/testsuite/ 2021-07-15 Uroš Bizjak PR target/101346 * gcc.target/i386/pr101346.c: New test.
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
--- Comment #5 from Jonathan Wakely ---
Since GCC 4.9 we don't perform overload resolution, so I think this is fixed:
50462.C: In function 'void print(V)':
50462.C:13:13: error: invalid use of non-static member function 'int V::size()'
13 | { ostream() << v.size; }
| ~~^
50462.C:9:13: note: declared here
9 | int size() { return 0; };
| ^~~~
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462 --- Comment #6 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #5) > Since GCC 4.9 we don't perform overload resolution, so I think this is fixed: Huh, that's true for the reduced example in comment 4, but the original one from Chris still prints a wall of errors.
[Bug c++/101465] Poorly worded error from a call to a pointer-to-member function not wrapped in parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101465 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-07-15 Status|UNCONFIRMED |NEW --- Comment #1 from Jonathan Wakely --- And we should issue a fix-it suggestion too. I thought this was a dup of an existing bug, but I can't find one, so confirmed.
[Bug c++/50462] poor diagnostics for missing parenthesis in call to method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
--- Comment #7 from Jonathan Wakely ---
Oh, it's the overloaded function thjat makes the difference between saying
"invalid use of non-static member function" and trying to do overload
resolution with an .
Reduced example that actually reproduces the original problem:
struct ostream { };
void operator<<(ostream, int) { }
void operator<<(ostream, void*) { }
void operator<<(ostream, char*) { }
struct V
{
int size() { return 0; };
int size() const { return 0; };
};
void print(V v)
{ ostream() << v.size; }
Which prints this with current trunk:
50462.C: In function 'void print(V)':
50462.C:14:13: error: no match for 'operator<<' (operand types are 'ostream'
and '')
14 | { ostream() << v.size; }
| ~ ^~ ~~
| | |
| ostream
50462.C:3:6: note: candidate: 'void operator<<(ostream, int)'
3 | void operator<<(ostream, int) { }
| ^~~~
50462.C:3:26: note: no known conversion for argument 2 from '' to 'int'
3 | void operator<<(ostream, int) { }
| ^~~
50462.C:4:6: note: candidate: 'void operator<<(ostream, void*)'
4 | void operator<<(ostream, void*) { }
| ^~~~
50462.C:4:26: note: no known conversion for argument 2 from '' to 'void*'
4 | void operator<<(ostream, void*) { }
| ^
50462.C:5:6: note: candidate: 'void operator<<(ostream, char*)'
5 | void operator<<(ostream, char*) { }
| ^~~~
50462.C:5:26: note: no known conversion for argument 2 from '' to 'char*'
5 | void operator<<(ostream, char*) { }
| ^
I don't see why we should treat v.size any differently whether it's overloaded
or not. It's invalid either way, so we should fail similarly.
[Bug tree-optimization/101110] [12 regression] gcc.c-torture/execute/950704-1.c fails after r12-1546
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101110 --- Comment #4 from Andrew Macleod --- Does this still fail? When i look at a cross compiler listing I do not see any differences from ranger in the listing.
[Bug other/101459] Mismatch in description of option "-falign-functions" between source code and documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101459 --- Comment #4 from Andrew Pinski --- (In reply to ashimida from comment #3) > (In reply to Richard Biener from comment #2) > > The flag, -falign-functions is only enabled at -O2+ (but not -Os), but the > > actual alignment is recorded in the 'align_functions' data which is only > > populated when -falign-functions is specified so I think it works as > > documented. > > so I think this flag is also worked at -O0 I think you are misunderstanding the documentation. The documentation is saying it is enabled by default at -O2 and above (but not -Os); not that it will only work at -O2 and above.
[Bug other/101459] Mismatch in description of option "-falign-functions" between source code and documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101459 --- Comment #5 from ashimida --- (In reply to Andrew Pinski from comment #4) > (In reply to ashimida from comment #3) > > (In reply to Richard Biener from comment #2) > > > The flag, -falign-functions is only enabled at -O2+ (but not -Os), but the > > > actual alignment is recorded in the 'align_functions' data which is only > > > populated when -falign-functions is specified so I think it works as > > > documented. > > > > so I think this flag is also worked at -O0 > > I think you are misunderstanding the documentation. The documentation is > saying it is enabled by default at -O2 and above (but not -Os); not that it > will only work at -O2 and above. okey, now I understand, I have misunderstood this option, thank you very much!
[Bug target/101464] Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #1 from Hongtao.liu --- >From the implementation perspective, we need to record all usage of sse registers which is AVX_U128_DIRTY and clear them all.
[Bug target/101464] Replace zveroupper with vpxor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101464 --- Comment #2 from H.J. Lu --- Created attachment 51159 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51159&action=edit A patch
