[Bug target/98799] [10 Regression] vector_set_var ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799
luoxhu at gcc dot gnu.org changed:
What|Removed |Added
CC||luoxhu at gcc dot gnu.org
--- Comment #5 from luoxhu at gcc dot gnu.org ---
(In reply to David Edelsohn from comment #4)
> Created attachment 50043 [details]
> patch
>
> Updated patch, but the entire rs6000_expand_set_var() logic seems to be
> incomplete and missing some scenarios, i.e., P9 and P8 that assume PPC64 are
> not sufficient.
The ICE is caused by UNSPEC_SI_FROM_SF not supported when
TARGET_DIRECT_MOVE_64BIT
is false.
Thank for the patch, but also need below change to fix the ICE in
gcc.target/powerpc/fold-vec-insert-float-p8.c when build with -m32 to avoid
generate IFN VEC_SET for P8BE-32bit.
Not sure about the meaning of "P9 and P8 that assume PPC64 are not sufficient"?
diff --git a/gcc/config/rs6000/rs6000-c.c b/gcc/config/rs6000/rs6000-c.c
index f6ee1e6..656cdb3 100644
--- a/gcc/config/rs6000/rs6000-c.c
+++ b/gcc/config/rs6000/rs6000-c.c
@@ -1600,7 +1600,7 @@ altivec_resolve_overloaded_builtin (location_t loc, tree
fndecl,
stmt = build1 (COMPOUND_LITERAL_EXPR, arg1_type, stmt);
}
- if (TARGET_P8_VECTOR)
+ if (TARGET_P8_VECTOR && TARGET_DIRECT_MOVE_64BIT)
{
stmt = build_array_ref (loc, stmt, arg2);
stmt = fold_build2 (MODIFY_EXPR, TREE_TYPE (arg0), stmt,
[Bug c++/98814] New: Add fix-it hints for missing asterisk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98814
Bug ID: 98814
Summary: Add fix-it hints for missing asterisk
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Iterators and pointers are quite common in C++ code but newbies tend to forget
to dereference them:
struct my_vector { void push_back(int); };
struct my_iterator { int operator*(); };
void sample(my_vector& vec, my_iterator it) {
vec.push_back(it);
}
A fix-it hint would be helpful for cases when no matching function found but
the argument has an operator*() that returns a matching type.
More examples via godbolt playground: https://godbolt.org/z/dsrqj8
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #20 from Richard Biener --- Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a local symbol. Not sure why we end up with a .reloc then. ld $25,%got_disp(.LTHUNK5.lto_priv.0)($28) .LEHB26 = . .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 1: jalr$25 this seems to be in _ZN4Sass6Parser16parse_parametersEv Maybe it's possible to reduce the testcase by bisecting the object files necessary to produce the bogus LTRANS assembly? From that one can start reducing the source of the necessary object files. Another interesting bit would be to see the IPA dumps of the broken LTRANS unit. If you add -fdump-ipa-all-details to the link command you should get dump files alongside the ltrans temp files.
[Bug tree-optimization/98815] New: Redundant free_dominance_info in cgraph_node::analyze()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98815 Bug ID: 98815 Summary: Redundant free_dominance_info in cgraph_node::analyze() Product: gcc Version: tree-ssa Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: fxue at os dot amperecomputing.com Target Milestone: --- Since "execute_pass_list ()" has an action of clearing dominance information, two free_dominance_info() after the line "execute_pass_list (cfun, g->get_passes ()->all_lowering_passes)" seems to be redundant, and could be removed.
[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:75d3d65641e1724d492816bd380587df486209c0 commit r10-9295-g75d3d65641e1724d492816bd380587df486209c0 Author: Paul Thomas Date: Tue Dec 29 17:37:25 2020 + Fortran: Fix deferred character lengths in array constructors [PR93833]. 2020-12-29 Paul Thomas gcc/fortran PR fortran/93833 * trans-array.c (get_array_ctor_var_strlen): If the character length backend_decl cannot be found, convert the expression and use the string length. Clear up some minor white space issues in the rest of the file. gcc/testsuite/ PR fortran/93833 * gfortran.dg/deferred_character_36.f90 : New test. (cherry picked from commit feae0af82753e06fbff6103da5fbb3b28e1ddbd7)
[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 --- Comment #12 from CVS Commits --- The releases/gcc-9 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:f6adbc3702edb4b6931731282fe4b2350eba1e0d commit r9-9201-gf6adbc3702edb4b6931731282fe4b2350eba1e0d Author: Paul Thomas Date: Tue Dec 29 17:37:25 2020 + Fortran: Fix deferred character lengths in array constructors [PR93833]. 2020-12-29 Paul Thomas gcc/fortran PR fortran/93833 * trans-array.c (get_array_ctor_var_strlen): If the character length backend_decl cannot be found, convert the expression and use the string length. Clear up some minor white space issues in the rest of the file. gcc/testsuite/ PR fortran/93833 * gfortran.dg/deferred_character_36.f90 : New test. (cherry picked from commit feae0af82753e06fbff6103da5fbb3b28e1ddbd7)
[Bug fortran/93833] [8/9/10/11 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93833 Paul Thomas changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Paul Thomas --- Fixed on 9-, 10- and 11-branches. Thanks for the report. Paul
[Bug testsuite/98771] [10/11 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b7a0507ad9f07492a37325a2f494ed933b217a9a
commit r11-6885-gb7a0507ad9f07492a37325a2f494ed933b217a9a
Author: Jakub Jelinek
Date: Mon Jan 25 10:03:40 2021 +0100
fold: Fix up strn{case,}cmp folding [PR98771]
As mentioned in the PR, the compiler behaves differently during strncmp
and strncasecmp folding between 32-bit and 64-bit hosts targeting 64-bit
target. I think that is highly undesirable.
The culprit is the host_size_t_cst_p predicate that is used by
fold_const_call, which punts if the target size_t constants don't fit into
host size_t. This patch gets rid of that behavior, instead it punts the
same when it doesn't fit into uhwi.
The predicate was used for strncmp and strncasecmp folding and for bcmp,
memcmp and
memchr folding.
The constant is in all cases compared to 0, we can do that whether it fits
into size_t or unsigned HOST_WIDE_INT, then it is used in s2 <= s0 or
s2 <= s1 comparisons where s0 and s1 already have uhwi type and represent
the sizes of the objects.
The important difference is for strn{,case}cmp folding, we pass that s2
value as the last argument to the host functions comparing the c_getstr
results. If s2 fits into size_t, then my patch makes no difference,
but if it is larger, we know the 2 c_getstr objects need to fit into the
host address space, so larger s2 should just act essentially as strcmp
or strcasecmp; as none of those objects can occupy 100% of the address
space, using MIN (SIZE_MAX, s2) achieves that.
2021-01-25 Jakub Jelinek
PR testsuite/98771
* fold-const-call.c (host_size_t_cst_p): Renamed to ...
(size_t_cst_p): ... this. Check and store unsigned HOST_WIDE_INT
value rather than host size_t.
(fold_const_call): Change type of s2 from size_t to
unsigned HOST_WIDE_INT. Use size_t_cst_p instead of
host_size_t_cst_p. For strncmp calls, pass MIN (s2, SIZE_MAX)
instead of s2 as last argument.
[Bug testsuite/98771] [10 regression] gcc.dg/strcmpopt_8.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98771 Jakub Jelinek changed: What|Removed |Added Summary|[10/11 regression] |[10 regression] |gcc.dg/strcmpopt_8.c FAILs |gcc.dg/strcmpopt_8.c FAILs --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/98816] New: The thread_local specifier appear on the declaration of static member function is compilied by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98816
Bug ID: 98816
Summary: The thread_local specifier appear on the declaration
of static member function is compilied by gcc
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xmh970252187 at gmail dot com
Target Milestone: ---
struct A{
thread_local void static fun(){};
};
int main(){
}
This code can be compiled on all versions of GCC compilers. However, the
standard says:
>The thread_local specifier indicates that the named entity has thread storage
>duration. It shall be applied only to the names of variables of namespace or
>block scope and to the names of static data members.
That means the `thread_local` specifier can be applied to static data members
rather than static member functions. In this example, the declaration of `fun`
should be ill-formed.
[Bug middle-end/98817] New: Optimize if (a != b) a = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817
Bug ID: 98817
Summary: Optimize if (a != b) a = b;
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
void arithmetic(int& result, int value) {
if (result != value) {
result = value;
}
}
GCC generates the following assembly:
arithmetic(int&, int):
cmp DWORD PTR [rdi], esi
je .L1
mov DWORD PTR [rdi], esi
.L1:
ret
The assembly seems suboptimal, because
1) cmov could be used
2) conditional jump could be totally removed, reducing the binary size and
leaving only one mov instruction:
arithmetic(int&, int):
mov DWORD PTR [rdi], esi
ret
Godbolt playground https://godbolt.org/z/Pdz7eP with above sample and
std::vector::clear() sample that would also benefit from the above
optimization.
[Bug libbacktrace/98818] New: [libbacktrace] Don't throw fatal error for unsupported dwarf version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818
Bug ID: 98818
Summary: [libbacktrace] Don't throw fatal error for unsupported
dwarf version
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: vries at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
I have several gcc versions installed. I use this f.i. for running gdb
testsuite with different gcc versions.
Consequently, I have libgcc 11 installed in my system, to be able to support
the latest gcc compiler.
After installing the libgcc 11 debuginfo package, gcc-go9 started to given me
problems:
...
$ ./outputs/gdb.go/handcall/handcall
fatal error: unrecognized DWARF version in .debug_info at 40
goroutine 1 [running, locked to thread]:
fatal error: unrecognized DWARF version in .debug_info at 40
panic during panic
goroutine 1 [running, locked to thread]:
fatal error: unrecognized DWARF version in .debug_info at 40
stack trace unavailable
...
The root cause for this is that libgcc's .debug_info contains dwarf5 units, and
that causes:
...
dwarf_buf_error (&unit_buf, "unrecognized DWARF version");
...
where we do:
...
static void
dwarf_buf_error (struct dwarf_buf *buf, const char *msg)
{
char b[200];
snprintf (b, sizeof b, "%s in %s at %d",
msg, buf->name, (int) (buf->buf - buf->start));
buf->error_callback (buf->data, b, 0);
}
...
which gets us to libgo's error_callback:
...
(gdb) l
161 /* Error callback. */
162
163 static void
164 error_callback (void *data __attribute__ ((unused)),
165 const char *msg, int errnum)
166 {
167 if (errnum == -1)
168 {
169 /* No debug info available. Carry on as best we can. */
170 return;
(gdb) l
171 }
172 if (errnum != 0)
173 runtime_printf ("%s errno %d\n", msg, errnum);
174 runtime_throw (msg);
175 }
...
ISTM that dwarf info that has a newer version than the libbacktrace reader
supports is not that different from missing debug info, so I wonder if we
should call the error_callback here with -1 instead.
[Bug middle-end/98817] Optimize if (a != b) a = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I'm not sure about this. Turning it into an unconditional store would mean that the memory the reference points to must be writable, that might not be always the case. E.g. if it refers to a .rodata object, or an object within something mapped PROT_READ only etc.
[Bug middle-end/98817] Optimize if (a != b) a = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817 --- Comment #2 from Antony Polukhin --- (In reply to Jakub Jelinek from comment #1) > I'm not sure about this. Turning it into an unconditional store would mean > that the memory the reference points to must be writable, that might not be > always the case. Fair pint. How about emitting cmov instead of cmp+je?
[Bug middle-end/98801] Request for a conditional move built-in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801 Richard Biener changed: What|Removed |Added Component|c++ |middle-end Severity|normal |enhancement Last reconfirmed||2021-01-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Richard Biener --- Slight complication arises because people will want to have cmoves with a memory destination. So possibly void __builtin_cmov (T *dest, bool, T, T, void *); preferably usable in a type-generic way. The void * is at least internally required to carry type-based alias info of the destination. That won't solve the eventual request to have cmov _from_ memory ... (if we leave all of the memory combining to RTL people will again complain that it's subject to compilers discretion).
[Bug middle-end/98817] Optimize if (a != b) a = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817 --- Comment #3 from Andrew Pinski --- This cannot be done due to race conditions too: https://gcc.gnu.org/wiki/Atomic/GCCMM/DataRaces
[Bug c++/98803] [C++20] ICE on invalid code with checked build [in synthesize_implicit_template_parm, at cp/parser.c:45335]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98803 Richard Biener changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code --- Comment #1 from Richard Biener --- yes, we even have a proper classification for this
[Bug target/98807] [11 Regression] wrong code with -O2 -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug bootstrap/98809] sem_util.adb:885:30: "T" conflicts with declaration at line 881
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98809 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-01-25 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from Richard Biener --- This was fixed with g:8bad25eb56bd16f3482f856a75b1c1ae5cfe1c4f aka PR98773 I think.
[Bug middle-end/98817] Optimize if (a != b) a = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817 --- Comment #4 from Jakub Jelinek --- cmov has the exact same problem as the unconditional store. At least on x86 a cmov for one doesn't have a MEM destination and so the conditionally assigned register then needs to be unconditionally stored. You'd need an instruction that would store only if the condition is true (something like SSE/AVX masked stores, but for scalars).
[Bug c++/98810] [C++20] ICE in tsubst_copy, at cp/pt.c:16771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98810 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-01-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-valid-code --- Comment #1 from Richard Biener --- clang accepts it with -std=c++17, GCC rejects it there with t.C:2:41: error: non-type template parameters of class type only available with '-std=c++20' or '-std=gnu++20'
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I can reproduce that on Fedora 33 too (but it works in the Fedora 34 builds where we have binutils 2.35.1 + various dwarf5 patches).
[Bug middle-end/98817] Optimize if (a != b) a = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817 --- Comment #5 from Antony Polukhin --- Please, close as invalid
[Bug tree-optimization/98813] loop is sub-optimized if index is unsigned int with offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813 Richard Biener changed: What|Removed |Added Blocks||53947 Keywords||missed-optimization Ever confirmed|0 |1 Severity|normal |enhancement CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-25 --- Comment #3 from Richard Biener --- Confirmed. While niter analysis produces 'assumptions' there's no such capability in SCEV analysis. In particular we have accesses like _54 = (unsigned int) n_24(D); ... _2 = l_m_34 + _54; _3 = (long unsigned int) _2; _4 = _3 * 8; _5 = C_25(D) + _4; _6 = *_5; where SCEV analysis could "look through" the (long unsigned int) cast in case _2 >= 0 && _2 <= INT_MAX / 8, it could, similar to niter analysis, record this somewhere. The overflow analysis there possibly also has similar issues as the split_constant_offset_1 one (which might also benefit from tracking 'assumptions'). Btw, tracking 'assumptions' not as GENERIC tree expression but in a form that would be nicer to collect & simplify later would be nice. Maybe for tracking purposes just note the SSA name _4 telling it's producer is assumed to not overflow, leaving combining & producing of versioning conditions to other helpers. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/98537] [11 Regression] ICE in emit_move_insn since r11-5839
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98537 --- Comment #8 from Hongtao.liu --- Created attachment 50045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50045&action=edit Fix ICE: Don't generate integer mask comparision for 128/256-bits vector when op_true/op_false are NULL or constm1_rtx/const0_rtx [PR98537] I'm retesting this patch which is supposed to fix all performance and correctness regressions caused by r10-5250. in ix86_expand_sse_cmp/ix86_expand_int_sse_cmp - if (ix86_valid_mask_cmp_mode (cmp_ops_mode)) + if (GET_MODE_SIZE (mode) == 64 + || (ix86_valid_mask_cmp_mode (cmp_ops_mode) + /* When op_true and op_false is NULL, vector dest is required. */ + && op_true && op_false + /* Gimple sometimes transforms vec_cmpmn to vcondmn with +op_true/op_false as constm1_rtx/const0_rtx. +Don't generate integer mask comparison then. */ + && !((vector_all_ones_operand (op_true, GET_MODE (op_true)) + && CONST0_RTX (GET_MODE (op_false)) == op_false) + || (vector_all_ones_operand (op_false, GET_MODE (op_false)) + && CONST0_RTX (GET_MODE (op_true)) == op_true
[Bug middle-end/98817] Optimize if (a != b) a = b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98817 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Richard Biener --- .
[Bug libbacktrace/98818] [libbacktrace] Don't throw fatal error for unsupported dwarf version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- Hmm, I guess we might want to build (some) target libraries with -gdwarf-4. Maybe the switch to default to -gdwarf-5 is a bit premature given all the fallout we see? I wonder if we can have a configure-time decision so for old distros can at least default to an old version.
[Bug ipa/98815] Redundant free_dominance_info in cgraph_node::analyze()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98815
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Martin Liška ---
Thanks for the report.
It's likely more complicated as execute_pass_list calls free_dominance_info
conditionally.
if (cfun && fn->cfg)
{
free_dominance_info (CDI_DOMINATORS);
free_dominance_info (CDI_POST_DOMINATORS);
}
Moreover, there are more callers of execute_pass_list than the only
cgraph_node::analyze. That said, I tend to close it as invalid.
[Bug libbacktrace/98818] [libbacktrace] Don't throw fatal error for unsupported dwarf version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98818 --- Comment #2 from Jakub Jelinek --- DWARF5 is 4 years old in a few days, and if we didn't switch nothing would be fixed in the next year either.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #21 from Xi Ruoyao --- (In reply to Richard Biener from comment #20) > Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a > local symbol. Not sure why we end up with a .reloc then. > > ld $25,%got_disp(.LTHUNK5.lto_priv.0)($28) > .LEHB26 = . > .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 > 1: jalr$25 > > this seems to be in _ZN4Sass6Parser16parse_parametersEv > > Maybe it's possible to reduce the testcase by bisecting the object files > necessary to produce the bogus LTRANS assembly? From that one can start > reducing the source of the necessary object files. > > Another interesting bit would be to see the IPA dumps of the broken LTRANS > unit. If you add -fdump-ipa-all-details to the link command you should get > dump files alongside the ltrans temp files. I can confirm that the workaround in gas (released in binutils-2.36) "fixes" the problem. Some function aliases named ".LTHUNK%d" are created in C++ FE (cp/method.c, L232). With LTO those are cloned as ".LTHUNK%d.lto_priv.%d". Functions aliases should not be named ".xxx" IMO. Perhaps names like __gcc_lthunk.%d is better.
[Bug c++/98798] Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
Martin Liška changed:
What|Removed |Added
Last reconfirmed||2021-01-25
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
CC||marxin at gcc dot gnu.org
--- Comment #1 from Martin Liška ---
Confirmed, reduced test-case:
$ cat pr98798.C
#include
#include
class alignas(32) Foo
{
public :
char x;
void * operator new[ ] (size_t s, std::align_val_t a)
{
__builtin_printf ("s: %d, a: %d\n", s, a);
return aligned_alloc(static_cast(a), s);
}
void operator delete[ ] (void *p, size_t s, std::align_val_t a)
{
}
};
int main()
{
auto p = std::make_unique(3);
}
I'm going to take a look.
[Bug target/98807] [11 Regression] wrong code with -O2 -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807
--- Comment #3 from Richard Biener ---
Hmm, OK, as I feared. We use TImode (not BLKmode) for
vector(2) . I wonder if we can simplify vector_element_bits
with the constraints we now have in place for bool vector build. That is,
unsigned int
vector_element_bits (const_tree type)
{
gcc_checking_assert (VECTOR_TYPE_P (type));
if (VECTOR_BOOLEAN_TYPE_P (type))
return TYPE_PRECISION (TREE_TYPE (type));
return tree_to_uhwi (TYPE_SIZE (TREE_TYPE (type)));
}
looks like it should work and it avoids fragile checking of the mode.
[Bug c++/98802] [10/11 Regression] class template argument deduce guide leads infinite recursive since r10-4719-g9b41ebbcdf9e3328
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98802 Martin Liška changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |10.3 Last reconfirmed||2021-01-25 Summary|class template argument |[10/11 Regression] class |deduce guide leads infinite |template argument deduce |recursive. |guide leads infinite ||recursive since ||r10-4719-g9b41ebbcdf9e3328 --- Comment #2 from Martin Liška --- Started with r10-4719-g9b41ebbcdf9e3328.
[Bug c++/98819] New: -Wall -Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
Bug ID: 98819
Summary: -Wall -Wformat-signedness suggests %u for %u
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Reproduced in latest Godbolt trunk
%u is suggested for %u
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:6:19: warning: format '%u' expects argument of type 'unsigned int',
but argument 2 has type 'int' [-Wformat=]
6 | std::printf("%u", CURRENT_YEAR);
| ~^
| |
| unsigned int
| %u
Compiler returned: 0
#include
#define CURRENT_YEAR 2021
int main()
{
std::printf("%u", CURRENT_YEAR);
}
[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 --- Comment #6 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c6b0e33febbf73abfcc2bb0e28f0b62afe3b0f2a commit r11-6887-gc6b0e33febbf73abfcc2bb0e28f0b62afe3b0f2a Author: Paul Thomas Date: Mon Jan 25 10:27:51 2021 + Fortran: Fix deferred character lengths in array constructors [PR98517]. 2021-01-25 Steve Kargl gcc/fortran PR fortran/98517 * resolve.c (resolve_charlen): Check that length expression is present before testing for scalar/integer.. gcc/testsuite/ PR fortran/98517 * gfortran.dg/charlen_18.f90 : New test.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #22 from Richard Biener --- There is target specific sanitizing of symbol names - if the name is really the issue then it should be _much_ more prevalent since all IPA cloning uses dots as well. clone_function_name produces them and ASM_FORMAT_PRIVATE_NAME is the "sanitizer" that's supposed to mangle it to correct form. But as the name suggests the definition of a local private symbol isn't supposed to go away without all of its uses so the real issue must be elsewhere in optimization. (thus asking for IPA dumps, specifically the .000i.cgraph dump which should mention when the compiler thinks the .LTHUNK5.lto_priv.0 goes away)
[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:039ac05206397227b68436cd1572ac667820c915 commit r10-9297-g039ac05206397227b68436cd1572ac667820c915 Author: Paul Thomas Date: Mon Jan 25 10:27:51 2021 + Fortran: Fix deferred character lengths in array constructors [PR98517]. 2021-01-25 Steve Kargl gcc/fortran PR fortran/98517 * resolve.c (resolve_charlen): Check that length expression is present before testing for scalar/integer.. gcc/testsuite/ PR fortran/98517 * gfortran.dg/charlen_18.f90 : New test. (cherry picked from commit c6b0e33febbf73abfcc2bb0e28f0b62afe3b0f2a)
[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 --- Comment #8 from CVS Commits --- The releases/gcc-9 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:504159b44da4adbea75047da0ad06c6d4223caec commit r9-9202-g504159b44da4adbea75047da0ad06c6d4223caec Author: Paul Thomas Date: Mon Jan 25 10:27:51 2021 + Fortran: Fix deferred character lengths in array constructors [PR98517]. 2021-01-25 Steve Kargl gcc/fortran PR fortran/98517 * resolve.c (resolve_charlen): Check that length expression is present before testing for scalar/integer.. gcc/testsuite/ PR fortran/98517 * gfortran.dg/charlen_18.f90 : New test. (cherry picked from commit c6b0e33febbf73abfcc2bb0e28f0b62afe3b0f2a)
[Bug fortran/98517] gfortran segfault on character array initialization from parameter value since r8-5900-g266404a8d62b99ab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98517 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Paul Thomas --- Closed as blindingly obvious on 9-, 10- and 11-branches. Thanks for the fix, Steve. Paul
[Bug c++/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 --- Comment #1 from Andrew Pinski --- I think you misunderstood the diagnostic. It is saying unsigned int is for %u. The type you have is int.
[Bug c++/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
--- Comment #2 from Jonny Grant ---
(In reply to Andrew Pinski from comment #1)
> I think you misunderstood the diagnostic. It is saying unsigned int is for
> %u. The type you have is int.
Ah, is that "%u" not the suggestion?
Change it to %f and it gives the clear "%d" suggestion I expected for my int
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:6:19: warning: format '%f' expects argument of type 'double', but
argument 2 has type 'int' [-Wformat=]
6 | std::printf("%f", CURRENT_YEAR);
| ~^
| |
| double
| %d
Compiler returned: 0
[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Andrew Pinski changed: What|Removed |Added Component|target |lto CC||pinskia at gcc dot gnu.org --- Comment #23 from Andrew Pinski --- (In reply to Richard Biener from comment #20) > Indeed already the name, .LTHUNK5.lto_priv.0, hints at that this should be a > local symbol. Not sure why we end up with a .reloc then. > > ld $25,%got_disp(.LTHUNK5.lto_priv.0)($28) > .LEHB26 = . > .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 > 1: jalr$25 > > this seems to be in _ZN4Sass6Parser16parse_parametersEv So 64bit MIPS n64 ABI with -mxgot does all function calls via loading an address from the GOT, the .reloc there is to say to the linker to see if it can relax it to be a direct jump (with link) rather than the indirect jump. Looking into the cp/method.c code, I see we are creating an alias called .LTHUNK5 for a function which seems to be fine. So either we are not outputing the correct name or the way local aliases are not being handled correctly when splitting up the LTO partitions; -flto-partition=none is a hint there.
[Bug c++/98820] New: Placeholder (auto) non-type template parameter wrongly deduced to 'const' for class type arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98820
Bug ID: 98820
Summary: Placeholder (auto) non-type template parameter wrongly
deduced to 'const' for class type arguments
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davveston at gmail dot com
Target Milestone: ---
As per [temp.param]/6 in N4861, for non-template parameters (including a type
that contains a placeholder type):
"[...] The top-level cv-qualifiers on the template-parameter are ignored when
determining its type."
and as per [dcl.type.decltype]/1.2:
"For an expression E, the type denoted by decltype(E) is defined as follows:
- [...] naming a non-type template-parameter, decltype(E) is the type of the
template-parameter after performing any necessary type deduction [...]"
Thus, the following example should arguably be well-formed:
#include
struct A{};
template
void f() {
static_assert(std::is_same_v);
}
template
void g() {
static_assert(std::is_same_v);
}
int main() {
constexpr A a{};
f();
g();
}
However GCC rejects it as `decltype(a)` resolves to `A const` rather than `A`.
---
We may note that:
1) Clang accepts the program, and
2) Both Clang and GCC accepts the program when using a structural type directly
instead of a placeholder type for the non-type template parameter; replacing
the definitions of `f` and `g` above with:
template
void f() {
static_assert(std::is_same_v);
}
template
void g() {
static_assert(std::is_same_v);
}
3) Both clang and GCC accepts the program when using a placeholder type but
with a non-class type as template argument to it; replacing the definitions of
`f` and `g` above with:
template
void f() {
static_assert(std::is_same_v);
}
template
void g() {
static_assert(std::is_same_v);
}
and calling them as f<0>() and g<0>();
---
These standard rules are arguably somewhat confusing given that the template
parameter object itself (associated with the class-type non-type template
parameter) is `const` ([temp.param]/8).
[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683 --- Comment #3 from Florian Weimer --- Thanks. The -Werror failure you reported is due to PR98512. Martin has posted a patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564060.html Should I open a binutils bug with the generated .s file?
[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #24 from Xi Ruoyao --- (In reply to Richard Biener from comment #22) > There is target specific sanitizing of symbol names - if the name is really > the issue then it should be _much_ more prevalent since all IPA cloning uses > dots as well. clone_function_name produces them and ASM_FORMAT_PRIVATE_NAME > is the "sanitizer" that's supposed to mangle it to correct form. But as the > name suggests the definition of a local private symbol isn't supposed to go > away without all of its uses so the real issue must be elsewhere in > optimization. > (thus asking for IPA dumps, specifically the .000i.cgraph dump which should > mention when the compiler thinks the .LTHUNK5.lto_priv.0 goes away) IPA dumps (along with .ltrans* files) are uploaded: https://bf.mengyan1223.wang/assets/gcc-97787/libsass_lto_ipa_dump.tar.xz
[Bug target/95646] [GCC 9/10] arm-none-eabi function attribute 'cmse_nonsecure_entry' wipes register values with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95646 avieira at gcc dot gnu.org changed: What|Removed |Added Summary|arm-none-eabi function |[GCC 9/10] arm-none-eabi |attribute |function attribute |'cmse_nonsecure_entry' |'cmse_nonsecure_entry' |wipes register values with |wipes register values with |-Os |-Os --- Comment #4 from avieira at gcc dot gnu.org --- Changed title to reflect that this still needs backports to GCC 9 and 10.
[Bug c++/98816] The invalid use of a thread_local specifier that appears on the declaration of static member functions can be accepted by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98816 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-25
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||nickc at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- So, I've traced this to libgcc.a (morestack.o). When built against binutils 2.35, we assemble that with: /home/jakub/src/gcc/obj76/./gcc/xgcc -B/home/jakub/src/gcc/obj76/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -fchecking=1 -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -I../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o morestack.o -MT morestack.o -MD -MP -MF morestack.dep -c -xassembler-with-cpp -include morestack.vis ../../../libgcc/config/i386/morestack.S and that invokes gas with --gdwarf-5 option, as HAVE_AS_GDWARF_5_DEBUG_FLAG is defined (but HAVE_AS_WORKING_DWARF_N_FLAG is not because it doesn't contain the needed bugfixes). The line table looks sane, at least trunk binutils readelf is happy about it, and .debug_abbrev too: /usr/src/binutils-gdb/obj/binutils/readelf -wa morestack.o Contents of the .debug_abbrev section: Number TAG (0x0) 1 DW_TAG_compile_unit[no children] DW_AT_stmt_listDW_FORM_data4 DW_AT_low_pc DW_FORM_addr DW_AT_high_pc DW_FORM_data8 DW_AT_name DW_FORM_strp DW_AT_comp_dir DW_FORM_strp DW_AT_producer DW_FORM_strp DW_AT_language DW_FORM_data2 DW_AT value: 0 DW_FORM value: 0 but .debug_info section is total garbage: /usr/src/binutils-gdb/obj/binutils/readelf -wi morestack.o Contents of the .debug_info section: readelf: Error: .debug_abbrev section not zero terminated readelf: Warning: Invalid pointer size (0) in compunit header, using 4 instead Compilation Unit @ offset 0x0: Length:0x2a (32-bit) Version: 5 Unit Type: ??? (0) Abbrev Offset: 0x108 Pointer Size: 4 readelf: Warning: CU at offset 0 contains corrupt or unsupported unit type: 0. eu-readelf --debug-dump=info morestack.o DWARF section [17] '.debug_info' at offset 0x2fa: [Offset] Compilation unit at offset 0: Version: 5, Abbreviation section offset: 0, Address size: 8, Offset size: 4 Unit type: ??? (0) (0) eu-readelf: unknown version (5) or unit type (0) So, I think we need to add a check that --gdwarf-5 actually works properly on assembly sources and not define HAVE_AS_GDWARF_5_DEBUG_FLAG otherwise. Minimal testcase: .text nop as --gdwarf-5 test.s -o test.o readelf -wi test.o Guess it would be nice to bisect which binutils change fixed this and write a reliable check. I'd think binutils 2.34 and earlier would be fine, as they wouldn't claim --gdwarf-5 support at all. If I with the buggy binutils do as --gdwarf-4 test.s -o test.o vs. as --gdwarf-5 test.s -o test.o and objdump -s -j .debug_info test.o in each case, the only difference between the two sections is the version 5 vs. 4 in the section. But DWARF5 .debug_info header is different between DWARF4 and DWARF5. So, my guess it is https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=a3b3e8586d80204660e203d05edfe88418c394a2 aka https://sourceware.org/pipermail/binutils/2020-August/112684.html
[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #10 from bin cheng ---
hmm,
For below basic block:
128 ;; basic block 4, loop depth 2, maybe hot
129 ;;prev block 3, next block 9, flags: (NEW, VISITED)
130 ;;pred: 3 (FALLTHRU,EXECUTABLE)
131 ;;7 (FALLTHRU,DFS_BACK,EXECUTABLE)
132 # RANGE [0, 2147483647] NONZERO 2147483647
133 # c_5 = PHI <0(3), c_17(7)>
134 # .MEM_8 = PHI <.MEM_7(3), .MEM_9(7)>
135 if (_2 < c_5)
136 goto ; [INV]
137 else
138 goto ; [INV]
139 ;;succ: 8 (TRUE_VALUE,EXECUTABLE)
140 ;;9 (FALSE_VALUE,EXECUTABLE)
Code in :
4276
4277 basic_block *body = get_loop_body (loop);
4278 exits = get_loop_exit_edges (loop, body);
4279 likely_exit = single_likely_exit (loop, exits);
4280 FOR_EACH_VEC_ELT (exits, i, ex)
4281 {
4282 if (ex == likely_exit)
4283 {
4284 gimple *stmt = last_stmt (ex->src);
4285 if (stmt != NULL)
4286 {
gets three exit edges, one of which is bb1>, as a result, 0 niter is
computed for this exit in function number_of_iterations_exit_assumptions. This
seems strange, is it a fake edge added for some reason?
Thanks
[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #25 from Richard Biener --- OK, so it's read as *.LTHUNK5.lto_priv.0/2880 (*.LTHUNK5) @0xfff1163840 Type: function definition analyzed alias Visibility: in_other_partition used_from_other_partition prevailing_def_ironly external public visibility_specified visibility:hidden artificial References: _ZN4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE/2879 (alias) Referring: Read from file: libsass.so.1.0.0.ltrans16.o Unit id: 3 Function flags: Called by: _ZThn64_N4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE/349153 (can throw external) _ZThn64_N4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE/2881 (can throw external) Calls: and thus indeed "external" (in_other_partition). Defined in ltrans1.s as .globl .LTHUNK5.lto_priv.0 .hidden .LTHUNK5.lto_priv.0 .LTHUNK5.lto_priv.0 = _ZN4Sass10Parameters20adjust_after_pushingENS_10SharedImplINS_9ParameterEEE which I think means that possibly the process of bringing a symbol local needs to mangle the assembler name before using it more thoroughly or the mips target in particular needs to introduce the extern symbol to the assembler to not confuse it with a local label. I think the latter is more likely - Honza should know if other targets (like AIX ...) are affected similarly and what we have to do here. Honza?
[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #11 from bin cheng ---
(In reply to bin cheng from comment #10)
> hmm,
> For below basic block:
> 128 ;; basic block 4, loop depth 2, maybe hot
> 129 ;;prev block 3, next block 9, flags: (NEW, VISITED)
> 130 ;;pred: 3 (FALLTHRU,EXECUTABLE)
> 131 ;;7 (FALLTHRU,DFS_BACK,EXECUTABLE)
> 132 # RANGE [0, 2147483647] NONZERO 2147483647
> 133 # c_5 = PHI <0(3), c_17(7)>
> 134 # .MEM_8 = PHI <.MEM_7(3), .MEM_9(7)>
> 135 if (_2 < c_5)
> 136 goto ; [INV]
> 137 else
> 138 goto ; [INV]
> 139 ;;succ: 8 (TRUE_VALUE,EXECUTABLE)
> 140 ;;9 (FALSE_VALUE,EXECUTABLE)
>
> Code in :
> 4276
> 4277 basic_block *body = get_loop_body (loop);
> 4278 exits = get_loop_exit_edges (loop, body);
> 4279 likely_exit = single_likely_exit (loop, exits);
> 4280 FOR_EACH_VEC_ELT (exits, i, ex)
> 4281 {
> 4282 if (ex == likely_exit)
> 4283 {
> 4284 gimple *stmt = last_stmt (ex->src);
> 4285 if (stmt != NULL)
> 4286 {
>
> gets three exit edges, one of which is bb1>, as a result, 0 niter is
> computed for this exit in function number_of_iterations_exit_assumptions.
> This seems strange, is it a fake edge added for some reason?
>
> Thanks
Right, it's added by connect_infinite_loops_to_exit.
[Bug c++/97627] [9/10/11 Regression] loop end condition missing - endless loop with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627 --- Comment #12 from bin cheng --- a. why the loop is considered as infinite b. we need to skip fake exit edges in niter analysis?
[Bug target/98807] [11 Regression] wrong code with -O2 -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:defc40db9e09ecceb2d71727031fe9579bce1b11 commit r11-6890-gdefc40db9e09ecceb2d71727031fe9579bce1b11 Author: Richard Biener Date: Mon Jan 25 11:22:28 2021 +0100 middle-end/98807 - more vector_element_bits fixes This simplifies vector_element_bits further, avoiding any mode dependence and instead relying on boolean vector construction to populate element precision accordingly. 2021-01-25 Richard Biener PR middle-end/98807 * tree.c (vector_element_bits): Always use precision of the element type for boolean vectors. * gcc.dg/pr98807.c: New testcase.
[Bug target/98807] [11 Regression] wrong code with -O2 -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98807 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug gcov-profile/98739] -fprofile-reproducible is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:5089df534b85b795bfcdca8f4f1957ad15a60558 commit r11-6891-g5089df534b85b795bfcdca8f4f1957ad15a60558 Author: Martin Liska Date: Fri Jan 22 11:27:16 2021 +0100 Restore profile reproducibility. gcc/ChangeLog: PR gcov-profile/98739 * common.opt: Add missing sign symbol. * value-prof.c (get_nth_most_common_value): Restore handling of PROFILE_REPRODUCIBILITY_PARALLEL_RUNS and PROFILE_REPRODUCIBILITY_MULTITHREADED. libgcc/ChangeLog: PR gcov-profile/98739 * libgcov-merge.c (__gcov_merge_topn): Mark when merging ends with a dropped counter. * libgcov.h (gcov_topn_add_value): Add return value.
[Bug gcov-profile/98739] -fprofile-reproducible is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:e05a117dc4b98f3ac60851608f532ba7cee7343a commit r11-6892-ge05a117dc4b98f3ac60851608f532ba7cee7343a Author: Martin Liska Date: Fri Jan 22 15:36:11 2021 +0100 Enable -fprofile-reproducible=parallel-runs for profiledbootstrap. ChangeLog: PR gcov-profile/98739 * Makefile.in: Enable -fprofile-reproducible=parallel-runs for profiledbootstrap.
[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98563 Jakub Jelinek changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- That change included an important bugfix for the simd handling of addressable locals, when they escape they would be then mishandled during vectorization. I think the current representation is right, represent them as if each simd lane has its own copy of the variable. The reason why this isn't vectorized is I think PR91020, that SRA doesn't split those real and imag parts as separate (simd array) vars.
[Bug c++/98821] New: modules : c++tools configures with CC but code fragments assume CXX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98821 Bug ID: 98821 Summary: modules : c++tools configures with CC but code fragments assume CXX. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- On at least Darwin, c++tools misconfigures because of things like: configure:4019: x86_64-apple-darwin16-gcc -c -g -O2 conftest.c >&5 conftest.c: In function 'main': conftest.c:30:1: error: unknown type name 'sockaddr_un'; use 'struct' keyword to refer to the type 30 | sockaddr_un un; Which leads to the server missing support for networking on Darwin. Patching the configure fragments to be C-friendly fixes the problem, but perhaps you intend that the configure should be run with C++?
[Bug debug/98811] [11 regression] All Go tests FAIL with abbrev offset out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98811 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:fe5cb7f94d4e9b6fc932017d4ee74ba4f9f417b9 commit r11-6893-gfe5cb7f94d4e9b6fc932017d4ee74ba4f9f417b9 Author: Jakub Jelinek Date: Mon Jan 25 14:20:05 2021 +0100 configure: Add workaround for buggy binutils 2.35 [PR98811] binutils since https://sourceware.org/bugzilla/show_bug.cgi?id=25612 changes from March last year until the https://sourceware.org/pipermail/binutils/2020-August/112684.html fix in early August emits incorrect .debug_info when assembling files with --gdwarf-5. Instead of emitting proper DWARF 5 .debug_info header, it emits DWARF 4 .debug_info header with 5 as the dwarf version instead of 4. This results e.g. in libgcc.a (morestack.o) having garbage in its .debug_info sections and e.g. libbacktrace during pretty much all libgo tests fails miserably. The following patch adds a workaround for that, don't set HAVE_AS_GDWARF_5_DEBUG_FLAG if readelf can't read the .debug_info back. Built tested on x86_64-linux against both binutils 2.35 (buggy ones) and latest binutils trunk, the former with the patch now has DWARF 3 .debug_line and DWARF 2 .debug_info in morestack.o, while the latter as before correct DWARF 5 .debug_line and .debug_info. 2021-01-25 Jakub Jelinek PR debug/98811 * configure.ac (HAVE_AS_GDWARF_5_DEBUG_FLAG): Only define if readelf -wi is able to read the emitted .debug_info back. * configure: Regenerated.
[Bug middle-end/98689] [11 Regression] FAIL: gcc.dg/torture/stackalign/builtin-return-1.c -O1 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98689 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 CC|rsandifo at sources dot redhat.com |rsandifo at gcc dot gnu.org
[Bug c++/98822] New: Rejects-valid: instantiation of class template instantiates (all) constrained non-template friend definitions (, even those) with unsatisfied constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98822
Bug ID: 98822
Summary: Rejects-valid: instantiation of class template
instantiates (all) constrained non-template friend
definitions (, even those) with unsatisfied
constraints
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: davveston at gmail dot com
Target Milestone: ---
(All standard references below refer to N4861).
Constrained hidden non-template friends was added as per NS US115 of P2103R0
(adding [temp.friend]/9), meaning the following program is (afaict)
well-formed:
template
struct S {
friend void f(int) requires (N == 0) { }
operator int() const { return 0; }
};
int main() {
f(S<0>{});
}
whereas the following is ill-formed, as overload resolution rejects the friend
due to unsatisfied constraints:
template
struct S {
friend void f(int) requires (N == 0) { }
operator int() const { return 0; }
};
int main() {
f(S<1>{});
// error: no matching function for call to 'f'
// candidate function not viable: constraints not satisfied
}
and GCC correctly accepts and rejects these two examples, respectively.
However, the following program is also rejected by GCC:
template
struct S {
friend void f(int) requires (N == 0) { }
operator int() const { return 0; }
};
S<1> s1{};
S<2> s2{};
// error: redefinition of 'void foo(int) requires N == 0'
implying that GCC, for each instantiation of the class template S, also
instantiates its constrained friend definitions, even those where the
associated constraints are not satisfied, meaning more than a single
instantiation in a single TU fails due to and ODR-violation
([basic.def.odr]/1). It basically acts the same way as for hidden friend
definitions prior to constrained (non-templated) friends.
I have not been able to sort out whether the final example above is actually
well-formed as per N4861, but it's arguably weird if US115 added support for
constrained non-template (hidden) friends whilst not allowing overloading
solely on the constraint. As per [temp.friend]/9 each constrained hidden friend
is indeed unique (to its specialization), which is also supported by
[defns.signature.friend].
Constraint satisfaction should arguably be checked in the context of the
template instantiation and not only during overload resolution.
---
(MSVC accepts the final example above, but fails with ambiguous call errors
during overload resolution if we start overloading constrainded non-template
friends solely on their constraints. Clang has fails this feature for other
reasons; failing [defns.signature.friend] w.r.t. unique mangled names if we add
another overload with another constraint).
[Bug c++/98767] Function signature lost in concept diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98767 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- The parameter list is printed by `pp_cxx_parameter_declaration_clause` defined in gcc/cp/cxx-pretty-print.c (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/cp/cxx-pretty-print.c;h=a22eea5239c33ed946abe46539e588b04e7beca7;hb=HEAD#l1538 ), where the parameter types are printed in a loop that starts with: >for (; args; args = TREE_CHAIN (args), types = TREE_CHAIN (types)) Here `args` was initialized with: > args = type_p ? NULL : FUNCTION_FIRST_USER_PARM (t); It seems that when a type is passed to `pp_cxx_parameter_declaration_clause`, `args` is always set to NULL, and the loop is never entered.
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #8 from Paul Thomas ---
(In reply to Steve Kargl from comment #7)
> On Sat, Jan 02, 2021 at 04:12:27AM +, jvdelisle at charter dot net wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490
> >
> > --- Comment #5 from Jerry DeLisle ---
> > Patch regresses several test cases.
> >
>
> This regresses okay.
>
> diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
> index 14361a10f68..b860f7eaa26 100644
> --- a/gcc/fortran/trans-expr.c
> +++ b/gcc/fortran/trans-expr.c
> @@ -2537,7 +2537,9 @@ gfc_conv_substring (gfc_se * se, gfc_ref * ref, int
> kind,
>if (!CONSTANT_CLASS_P (tmp) && !DECL_P (tmp))
> end.expr = gfc_evaluate_now (end.expr, &se->pre);
>
> - if (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
> + if ((gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
> + && (ref->u.ss.start->symtree
> + && !ref->u.ss.start->symtree->n.sym->attr.implied_index))
> {
>tree nonempty = fold_build2_loc (input_location, LE_EXPR,
>
> My test program without the dejagnu stuff.
>
> program test
>
>implicit none
>
>call sub('Lorem ipsum')
>
>contains
>
> subroutine sub( text )
> character(len=*), intent(in) :: text
> character(len=1), allocatable ::c(:)
> integer :: i
> c = [ ( text(i:i), i = 1, len(text) ) ]
> if (c(1) /= 'L') stop 1
> end subroutine sub
>
> end program test
Hi Steve and Jerry,
This is OK to commit to master. I would suggest cherry-picking to 9- and
10-branches too.
Cheers
Paul
[Bug c++/96645] [9/10/11 Regression] std::variant default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96645 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- If I pass tf_error instead of tf_none in constructible_expr's build_special_member call, I get: pr96645.C: In instantiation of ‘struct is_default_constructible’: pr96645.C:22:36: required from here pr96645.C:12:17: error: default member initializer for ‘testVarStruct()::DataWithStruct::A::number’ required before the end of its enclosing class 12 | : bool_constant<__is_constructible(T)> | ^ so I guess the reason for the failure is that tsubst hasn't processed the nsdmis yet.
[Bug tree-optimization/97164] [8/9/10 Regression] incorrect offset on structure member where type of that member has aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97164 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |incorrect offset on |incorrect offset on |structure member where type |structure member where type |of that member has aligned |of that member has aligned |attribute |attribute --- Comment #11 from Jakub Jelinek --- Fixed on the trunk, probably undesirable for backporting.
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org CC||pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- This is a case of a gcc_assert too many. Deleting the following cures the problem: if (ss_expr != expr) /* Elemental function. */ gcc_assert ((expr->value.function.esym != NULL && expr->value.function.esym->attr.elemental) || (expr->value.function.isym != NULL && expr->value.function.isym->elemental) || gfc_inline_intrinsic_function_p (expr)); else gcc_assert (ss_type == GFC_SS_INTRINSIC); The preceeding if statement, has if (ss_expr != expr || ss_type != GFC_SS_FUNCTION) so the second assert is redundant. I am disinclined to add any more clauses to the first :-) This change regtests OK. However adding: || (gfc_expr_attr (expr).proc_pointer && gfc_expr_attr (expr).elemental) does the job and regtests too. Paul
[Bug c++/98800] [8/9/10/11 Regression] ICE on invalid use of non-static member function in trailing return type since r8-2724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-01-25 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Confirmed.
[Bug fortran/98472] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:7352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98472 Dominique d'Humieres changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug c++/98803] [10/11 Regression] [C++20] ICE on invalid code with checked build [in synthesize_implicit_template_parm, at cp/parser.c:45335]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98803 Marek Polacek changed: What|Removed |Added Summary|[C++20] ICE on invalid code |[10/11 Regression] [C++20] |with checked build [in |ICE on invalid code with |synthesize_implicit_templat |checked build [in |e_parm, at |synthesize_implicit_templat |cp/parser.c:45335] |e_parm, at ||cp/parser.c:45335] Target Milestone|--- |10.3 Last reconfirmed||2021-01-25 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r276764.
[Bug go/98823] New: go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 Bug ID: 98823 Summary: go testsuite and timeouts Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: jakub at gcc dot gnu.org CC: cmang at google dot com Target Milestone: --- Is there something in the libgo testsuite (as well as go.test) that should be killing tests if they are stuck? Normally in dejagnu driven tests there is a timeout and if a test for whatever reason doesn't finish within that timeout, dejagnu kills it. But I think go testing bypasses that. E.g. today we've seen on armv7hl the gcc/testsuite/go/issue19182.x test getting stuck for several hours, but there was nothing that would just kill the test, so manual killall -9 on it was needed to make the build finish.
[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98463 --- Comment #11 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:94ff4c9dd98f39280fba22d1ad0958fb25a5363b commit r11-6895-g94ff4c9dd98f39280fba22d1ad0958fb25a5363b Author: Jason Merrill Date: Fri Jan 22 13:17:10 2021 -0500 c++: [[no_unique_address]] in empty base [PR98463] In this testcase, cxx_eval_store_expression got confused trying to build up CONSTRUCTORs for initializing a subobject because the subobject is a member of an empty base. In C++14 mode and below we don't build FIELD_DECLs for empty bases, so the CONSTRUCTOR skipped the empty base, and treated the member as a member of the derived class, which breaks. Fixed by recognizing this situation and giving up on trying to build a CONSTRUCTOR for the inner target at that point; since it doesn't have any data, we don't need to actually store anything. gcc/cp/ChangeLog: PR c++/98463 * constexpr.c (get_or_insert_ctor_field): Add check. (cxx_eval_store_expression): Handle discontinuity of refs. gcc/testsuite/ChangeLog: PR c++/98463 * g++.dg/cpp2a/no_unique_address8.C: New test.
[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-01-25 --- Comment #4 from H.J. Lu --- (In reply to sandra from comment #2) > I'm pretty sure this is a gas bug. I used git bisect to track it down to > binutils commit ae9d2233e61a98ff8dba56be10219aa5306ffc9a which caused gcc to > start passing --gdwarf-5 on the gas command line. The DWARF-5 support was > present in gas before that and I think it's likely that's disagreeing with > something nios2-specific, perhaps mistakenly adding the size of the dwarf > directive data to the code length or something like that. The differences > in the .s file generated by GCC for the test case between that binutils > revision with --gdwarf-5 and the one before it without that option don't > seem to be significant. I opened: https://sourceware.org/bugzilla/show_bug.cgi?id=27243
[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683 Florian Weimer changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=27243 Resolution|--- |MOVED Status|NEW |RESOLVED --- Comment #5 from Florian Weimer --- Marking as moved.
[Bug tree-optimization/97260] [9/10/11 regression] memcmp of constant string and local constant array not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97260
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
So, can't we just restore back the folding in the FE to get rid of the
regression, e.g. by (completely untested so far):
--- gcc/varpool.c.jj2021-01-04 10:25:37.347250651 +0100
+++ gcc/varpool.c 2021-01-25 16:35:58.475198684 +0100
@@ -412,6 +412,12 @@ ctor_for_folding (tree decl)
if (!TREE_STATIC (decl) && !DECL_EXTERNAL (decl))
{
gcc_assert (!TREE_PUBLIC (decl));
+ /* Unless this is called during FE folding. */
+ if (!in_gimple_form
+ && TREE_READONLY (decl)
+ && !TREE_SIDE_EFFECTS (decl)
+ && DECL_INITIAL (decl))
+ return DECL_INITIAL (decl);
return error_mark_node;
}
As for strlen pass, it has currently infrastructure only for tracking 0 vs.
non-zero byte length, not exact constant bytes pointed by each pointer, that
would make the pass significantly more expensive.
Sure, we could have some hacks to handle some common cases where a variable is
initialized just once by some string literal or other constant byte sequence
and then never modified later, but that doesn't look like GCC 11 material.
[Bug bootstrap/98616] Compile gcc 10.2.0 error for loongson 2f CPU use MIPS n32 ABI on Gentoo OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98616
--- Comment #3 from Mikael Pettersson ---
> cat mips64el-unknown-linux-gnu/libgcc/config.log
...
configure:3778: checking for suffix of object files
configure:3800: /var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/
-B/usr/mips64el-unknown-linux-gnu/bin/ -B/usr/mips64el-unknown-linux-gnu/lib/
-isystem /usr/mips64el-unknown-linux-gnu/include -isystem
/usr/mips64el-unknown-linux-gnu/sys-include -fno-checking -c -g
-march=loongson2f -Wa,-mfix-loongson2f-nop -pipe -fPIC -O2 -minterlink-mips16
conftest.c >&5
/usr/mips64el-unknown-linux-gnu/bin/as: unrecognized option '-mloongson-mmi'
configure:3804: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3818: error: in
`/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/mips64el-unknown-linux-gnu/libgcc':
configure:3820: error: cannot compute suffix of object files: cannot compile
You have a clear discrepancy between gcc and binutils. As you're using Gentoo
sources and build procedure I suggest you report the bug to them.
[Bug c++/98463] [11 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:5491 by r11-2720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98463 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Jason Merrill --- Fixed.
[Bug c++/98824] New: [C++-20] function template non-type-class-arg deduction fails with a reason that looks bogus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98824
Bug ID: 98824
Summary: [C++-20] function template non-type-class-arg
deduction fails with a reason that looks bogus
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimitri.gorokhovik at free dot fr
Target Milestone: ---
The code:
template struct a {};
template v> constexpr auto f (a ) { return true; };
constexpr a <1> b;
auto const p = f (a {});
when compiled with 'g++ -std=c++20 -c bug-14.cpp' (g++ (GCC) 11.0.0 20210123
(experimental)), produces:
bug-14.cpp:5:27: error: no matching function for call to ‘f(a()>)’
5 | auto const p = f (a {});
| ^
bug-14.cpp:2:42: note: candidate: ‘template v> constexpr auto
f(a<((const a)v)>)’
2 | template v> constexpr auto f (a ) { return true; };
| ^
bug-14.cpp:2:42: note: template argument deduction/substitution failed:
bug-14.cpp:5:27: note: types ‘a’ and ‘const a<1>’ have incompatible
cv-qualifiers
5 | auto const p = f (a {});
clang-12 seems to accept it (hits a non-implemented feature in a subsequent
pass).
The diagnostics looks confusing/misleading:
-- compiler is aware of the constness of 'a ' -- see the signature of f() in
the note for line 2. And then it seemingly removes 'const' from 'const a ',
maybe expecting a certain strictness level in 'unify()'. However, unify() is
called with strict=UNIFY_ALLOW_NONE.
[Bug target/95095] Feature request: support -fno-unique-section-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095 --- Comment #6 from Segher Boessenkool --- I was under the impression this unique section thing needed the trailing dot thing. This probably is not true. I still think the old "%" thing is much superior to the trailing dot thing, but that then is orthogonal to the "unique section" thing, so let's ignore it now :-) It still remains that this flag needs a name that says what it *does*, as I mentioned at the end of Comment 4.
[Bug c++/97474] [8/9/10/11 Regression] produces wrong code with references to another field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97474 --- Comment #12 from Jason Merrill --- Yeah, adding restrict there is just wrong; the constructor is called outside the function, and could e.g. stash a pointer to the object in a global variable. What we actually want is to treat this reference parameter like a value parameter. Is that information actually useful to the optimizers?
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-01-25
Ever confirmed|0 |1
Component|c++ |c
CC||msebor at gcc dot gnu.org
--- Comment #3 from Martin Sebor ---
The comments in the code that chooses to use the 'u' conversion specifier in
the hint suggest this might indeed be due to a bug:
if (conversion_char)
/* We found a match, using the given conversion char - the
length modifier was incorrect (or absent).
Provide a suggestion using the conversion char with the
correct length modifier for the type. */
return xasprintf ("%s%c", len_modifier, conversion_char);
The "match" refers to the type for the specifier that matches the type of the
argument (i.e., 'i' for 2021). No length modifier was provided but that's not
incorrect. What is "incorrect" (but not unsafe) is the provided conversion
specifier.
But I'm surprised the warning triggers to begin with in this case, when the
signed argument is representable in the unsigned type without change.
Ordinarily GCC avoids issuing warnings for code that's demonstrably safe (e.g.,
-Wchar-subscripts when the char subscript is in the non-negative range).
It seems to me the warning should not be issued in this case; when it is
issued, the hint should be corrected to match the type of the provided
argument.
[Bug libfortran/98825] New: Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 Bug ID: 98825 Summary: Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$' Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: max.pd at gmx dot de Target Milestone: --- Created attachment 50046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50046&action=edit commented FORTRAN77 code for bug reproduction !> given a format statement like this: 10 FORMAT (I3,$) !> the program should suppress a new line !> on formatting data for format expressions !> ending with ',$'. This works well for !> single values: WRITE (*,10) 1 !> The unexpected behavior occurs !> When multiple values are given: WRITE (*,10) 2,3,4,5 !> Now the program will suppress !> only the last new line. This is !> unexpected behavior, as the whole format !> expression should apply to each value, !> not only to the last one. !> You can reproduce the unexpected behavior !> compiling this bug report. !> A copy of this source code is attached. PRINT * PRINT *,' correct output should look like this:' PRINT *,' 1 2 3 4 5' END
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #18 from Marius Hillenbrand --- The fix looks good -- bootstrap succeeded on s390x, both regular and the 4-stage profiledbootstrap-lean. Still running the test suite...
[Bug c/98819] Wall Wformat-signedness suggests %u for %u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98819 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #4 from David Malcolm --- In comment #0, the bottom-most "%u" is a fix-it hint, giving the nonsensical suggestion to the user that they replace the "%u" with itself. Clearly we shouldn't issue such a fix-it hint. I'm not able to reproduce the warning with the given reproducer. What flags are you using? Do you have a URL for your godbolt example?
[Bug target/95095] Feature request: support -fno-unique-section-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095 --- Comment #7 from Fangrui Song --- (In reply to Segher Boessenkool from comment #6) > I was under the impression this unique section thing needed the trailing > dot thing. This probably is not true. > > I still think the old "%" thing is much superior to the trailing dot thing, > but that then is orthogonal to the "unique section" thing, so let's ignore > it now :-) > > It still remains that this flag needs a name that says what it *does*, as I > mentioned at the end of Comment 4. -ffunction-sections -fno-unique-section-names => .text.% .text.startup.% .text.hot.% .text.cold.% ... ? I agree that it is superior. If GCC wants to support this scheme, that looks fine to me. It is likely that I can migrate Clang to this scheme as well. I think .text% .text.startup% .text.hot% .text.cold% ... is slightly worse.
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 Dominique d'Humieres changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-01-25 Status|UNCONFIRMED |WAITING --- Comment #1 from Dominique d'Humieres --- AFAIU $ fin format is a DEC(?) extension: see e.g. http://www.gf.uns.ac.rs/~hidro/download/CVF_LREF.PDF Thi is not implemented in gfortran.
[Bug c/98826] New: [gcc vs g++] qualified type of members of anonymous struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98826
Bug ID: 98826
Summary: [gcc vs g++] qualified type of members of anonymous
struct
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ndesaulniers at google dot com
CC: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Consider the following code:
struct dummy {
const struct {
int a;
volatile struct { int b; };
};
int c;
};
extern void fn(const int *);
extern void fn2(volatile int *);
void test(struct dummy *a) {
fn(&a->b);
fn2(&a->b);
a->a = a->c;
}
I noticed that g++ does not produce any diagnostics for the above, but gcc will
produce 3 diagnostics:
bar.c: In function ‘test’:
bar.c:13:6: warning: passing argument 1 of ‘fn’ discards ‘volatile’ qualifier
from pointer target type [-Wdiscarded-qualifiers]
13 | fn(&a->b);
| ^
bar.c:9:16: note: expected ‘const int *’ but argument is of type ‘const
volatile int *’
9 | extern void fn(const int *);
|^~~
bar.c:14:7: warning: passing argument 1 of ‘fn2’ discards ‘const’ qualifier
from pointer target type [-Wdiscarded-qualifiers]
14 | fn2(&a->b);
| ^
bar.c:10:17: note: expected ‘volatile int *’ but argument is of type ‘const
volatile int *’
10 | extern void fn2(volatile int *);
| ^~
bar.c:15:8: error: assignment of member ‘a’ in read-only object
15 | a->a = a->c;
|^
So it seems that the members of the anonymous struct are inheriting the
qualifications of the containing anonymous struct? This also seems to apply
recursively for nested anonymous structs.
Is this an intentional difference between C and C++?
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #1 from Ian Lance Taylor --- The Go testsuite is intended to have timeouts for all tests. The test gcc/testsuite/go.test/test/fixedbugs/issue19182.go is just passed off to the TCL function go-torture-execute. Running the executable gcc/testsuite/go/issue19182.x is the "execute" part of the test. go-torture-execute calls the TCL function go_load to run the test. My assumption, which may well be wrong, is that a TCL function like go_load applies a timeout by default. I'm not even sure where go_load is defined, but it clearly does exist. I'm still baffled by how all the DejaGNU code works. It's odd that issue19182.x keeps running. The test itself is intended to be self-limiting. I'm not sure what is going on there.
[Bug c/98826] [gcc vs g++] qualified type of members of anonymous struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98826 --- Comment #1 from joseph at codesourcery dot com --- As I said on the WG14 reflector, I think the natural handling of anonymous structs and unions for C is that anonymity provides only a shorthand for name lookup (member access, designated initializers, offsetof) with everything else being exactly as if the anonymous member were named.
[Bug target/95095] Feature request: support -fno-unique-section-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95095 --- Comment #8 from Segher Boessenkool --- I say nothing like that. I say that .text.hot. is nasty (is easily mistaken for .text.hot). I also say that and that named-per-function sections are better as .text%name than as .text.name (just as they were long ago), because this doesn't conflict with things like .text.hot (and there is a very long history of such conflicts giving real-world problems).
[Bug fortran/97345] FE passes do_subscript leaks gmp memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97345 Thomas Koenig changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-01-25 Status|UNCONFIRMED |ASSIGNED
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #2 from Andreas Schwab --- go_load is defined in lib/gcc-dg.exp.
[Bug fortran/97031] the content of a comment line breaks compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97031 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |INVALID --- Comment #7 from Thomas Koenig --- I think the documentation for this is adequate: 1.3 Preprocessing and conditional compilation = Many Fortran compilers including GNU Fortran allow passing the source code through a C preprocessor (CPP; sometimes also called the Fortran preprocessor, FPP) to allow for conditional compilation. In the case of GNU Fortran, this is the GNU C Preprocessor in the traditional mode. If the C preprocessor is used, then C preprocessor rules apply. Closing.
[Bug middle-end/98801] Request for a conditional move built-in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #5 from Peter Cordes --- (In reply to Richard Biener from comment #4) > Slight complication arises because people will want to have cmoves with a > memory destination. Do we even want to provide this? Most ISAs can't branchlessly conditionally store, except via an RMW (which wouldn't be thread-safe for the no-store case if not atomic) or something really clunky. (Like x86 rep stos with count=0 or 1.) ARM predicated instructions allow branchless load or store that doesn't disturb the memory operand (and won't even fault on a bad address). I guess another option to emulate it could be to make a dummy local and cmov to select a store address = dummy : real. But that's something users can build in the source using a non-memory conditional-select builtin that exposes the much more widely available ALU conditional-select functionality like x86 CMOV, AArch64 CSEL, MIPS MVN, etc. > That won't solve the eventual request to have cmov _from_ memory ... (if we > leave all of the memory combining to RTL people will again complain that > it's subject to compilers discretion). It might be sufficient for most use-cases like defending against timing side-channels to not really try to allow conditional loads (from maybe-invalid pointers). I'm not sure if the motivation for this includes trying to make code without data-dependent branching, to defend against timing side-channels. But if we do provide something like this, people are going to want to use it that way. That's one case where best-effort behaviour at the mercy of the optimizer for a ternary (or having to manually check the asm) is not great. Stack Overflow has gotten a few Q&As from people looking for guaranteed CMOV for reasons like that. So I think we should be wary of exposing functionality that most ISAs don't have. OTOH, failing to provide a way to take advantage of functionality that some ISAs *do* have is not great, e.g. ISO C failing to provide popcnt and bit-scan (clz / ctz) has been a problem for C for a long time. But for something like __builtin_clz, emulating on machines that don't have hardware support still works. If we're trying to support a guarantee of no data-dependent branching, that limits the emulation possibilities or makes them clunkier. Especially if we want to support ARM's ability to not fault / not access memory if the condition is false. The ALU-select part can be emulated with AND/OR, so that's something we can provide on any target. Folding memory operands into a predicated load on ARM could actually introduce data-dependent cache access, vs. an unconditional load and a predicated reg-reg MOV. So this becomes somewhat thorny, and some design work to figure out what documented guarantees to provide will be necessary. Performance use-cases would certainly rather just have a conditional load in one instruction.
[Bug fortran/96843] gfortran rejects as shape mismatch rank one logical array arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96843 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- The test case works, I have committed it as https://gcc.gnu.org/pipermail/gcc-cvs/2021-January/341018.html to make sure it does not regress. Thanks for the bug report!
[Bug fortran/96386] Internal compiler error in ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96386 Thomas Koenig changed: What|Removed |Added Resolution|--- |FIXED CC||tkoenig at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #2 from Thomas Koenig --- The code has been fixed in the meantime. I have committed the test case as r11-6899-g7d54cccad332074d5fb81123796239f0f61b11a7 to make sure there is no regression. Thanks for the bug report!
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823
--- Comment #3 from Ian Lance Taylor ---
I'm sure I'm missing something, but what I see in lib/gcc-dg.exp is code that
says "if ${tool}_load already exists, then wrap it." I don't see the original
implementation of ${tool}_load.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #4 from Andreas Schwab --- That's standard part of dejagnu. /usr/share/dejagnu/standard.exp
[Bug fortran/94660] Wrong subroutine called at runtime than the one called in the source code with deferred subroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94660 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING CC||tkoenig at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- I just ran this through nagfor, and it agrees with gfortran. Nagfor is usually quite picky. xlf, on the other hand, agrees with you, so it does not seem to be straightforward, at least. This will take some further analysis.
[Bug c++/98646] [11 Regression] A static_cast confuses -Wnonnull, causing false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98646 --- Comment #14 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:d6f1cf644c45b76a27b6a6869dedaa030e3c7570 commit r11-6900-gd6f1cf644c45b76a27b6a6869dedaa030e3c7570 Author: Martin Sebor Date: Mon Jan 25 12:41:28 2021 -0700 PR c++/98646 - spurious -Wnonnull calling a member on the result of static_cast gcc/c-family/ChangeLog: PR c++/98646 * c-common.c (check_nonnull_arg): Adjust warning text. gcc/cp/ChangeLog: PR c++/98646 * cvt.c (cp_fold_convert): Propagate TREE_NO_WARNING. gcc/ChangeLog: PR c++/98646 * tree-ssa-ccp.c (pass_post_ipa_warn::execute): Adjust warning text. gcc/testsuite/ChangeLog: PR c++/98646 * g++.dg/warn/Wnonnull5.C: Adjust text of an expected warning. * g++.dg/warn/Wnonnull10.C: New test. * g++.dg/warn/Wnonnull9.C: New test.
[Bug go/98823] go testsuite and timeouts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98823 --- Comment #5 from Andreas Schwab --- And for the unix board, its implementation is in /usr/share/dejagnu/config/unix.exp.
