[Bug c++/95999] [9/10/11/12 Regression] ICE in tree check: expected integer_cst, have var_decl in get_len, at tree.h:5951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95999 --- Comment #3 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:bae10419f6e07dbde8e66ff4ff70d050f82ad451 commit r12-7574-gbae10419f6e07dbde8e66ff4ff70d050f82ad451 Author: Roger Sayle Date: Thu Mar 10 07:41:12 2022 + PR c++/95999: Improved error recovery in enumeration lists. This patch resolves PR c++/95999 which is an ICE-after-error regression in the g++ front-end. When parsing an enumerator list, the C++ parser assumes that cp_parser_constant_expression always returns either an INTEGER_CST or error_mark_node, but in the testcase reported in the PR, it actually returns a VAR_DECL. The usual (but perhaps controversial) design philosophy is that the routine that reports the error normally has a duty to indicate this to the rest of the compiler (via error_mark_node), but here the return value from calling require_rvalue_constant_expression (parser.cc:10666) is ignored. I initially experimented with setting EXPRESSION to error_mark_node here in cp_parser_constant_expression but (perhaps conveniently) that's insufficient to resolve the problem. The simple fix in this patch is to tweak the two places that require INTEGER_CST to treat all other tree types as though they are error_mark_node. 2022-03-10 Roger Sayle gcc/cp/ChangeLog PR c++/95999 * decl.cc (finish_enum_value_list): If VALUE isn't an INTEGER_CST consider it to be zero (i.e. treat it like error_mark_node). (build_enumerator): Likewise, if PREV_VALUE isn't an INTEGER_CST, set VALUE to error_mark_node. gcc/testsuite/ChangeLog PR c++/95999 * g++.dg/parse/pr95999.C: New test case.
[Bug ada/104861] New: s-oscons.ads should use target_noncanonical
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104861 Bug ID: 104861 Summary: s-oscons.ads should use target_noncanonical Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- It seems that gprbuild uses Target_Name to construct paths to find files of the installed gnat but when you configure GCC with a non-canonical target name like --target=x86_64-suse-linux (omitting -gnu) then make install will use @target_noncanonical@ for the directory. That causes the gprbuild tools to fail to build. A solution might be to do the following and base Target_Name on @target_noncanonical@ instead. diff --git a/gcc/ada/gcc-interface/Makefile.in b/gcc/ada/gcc-interface/Makefile.in index b8a24708280..1e9801a8b96 100644 --- a/gcc/ada/gcc-interface/Makefile.in +++ b/gcc/ada/gcc-interface/Makefile.in @@ -138,6 +138,7 @@ objdir = . target_alias=@target_alias@ target=@target@ +target_noncanonical=@target_noncanonical@ target_cpu=@target_cpu@ target_vendor=@target_vendor@ target_os=@target_os@ @@ -598,7 +599,7 @@ OSCONS_CC=$(subst ./xgcc,../../xgcc,$(subst -B./, -B../../,$(GCC_FOR_TARGET))) # has a header). OSCONS_CPP=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -E -C \ - -DTARGET=\"$(target)\" -iquote $(fsrcpfx)ada $(fsrcpfx)ada/s-oscons-tmplt.c > s-oscons-tmplt.i + -DTARGET=\"$(target_noncanonical)\" -iquote $(fsrcpfx)ada $(fsrcpfx)ada/s-oscons-tmplt.c > s-oscons-tmplt.i OSCONS_EXTRACT=$(OSCONS_CC) $(GNATLIBCFLAGS_FOR_C) -S s-oscons-tmplt.i # Note: if you need to build with a non-GNU compiler, you could adapt the
[Bug c++/39751] [9/10/11/12 Regression] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751 --- Comment #15 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:2185c9734ad977b88c519a4579187a91b3f71edd commit r12-7573-g2185c9734ad977b88c519a4579187a91b3f71edd Author: Roger Sayle Date: Thu Mar 10 07:32:06 2022 + PR c++/39751: ICE-on-invalid parsing regression. This is a fix for PR c++/39751 which is an ICE-on-invalid regression in the C++ parser after encountering the end of file. The one line change is to check that the tokens cached in DECL_PENDING_INLINE_INFO haven't been purged before processing them in cp_parser_late_parsing_for_member. 2022-03-10 Roger Sayle gcc/cp/ChangeLog PR c++/39751 * parser.cc (cp_parser_late_parsing_for_member): Confirm the token stream hasn't been purged before processing DECL_PENDING_INLINE. gcc/testsuite/ChangeLog PR c++/39751 * g++.dg/parse/pr39751.C: New test case.
[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850 --- Comment #4 from Andrew Pinski --- Interesting if I put the definition of the class A::B at the end of the file, the code works I wonder if this is because of some ABI issue where A::A as a base class is created
[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104850 --- Comment #3 from Andrew Pinski --- clang and ICC also reject this for the same reason as GCC. MSVC on the other hand accepts this.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #15 from Jason Merrill --- (In reply to Jonathan Wakely from comment #14) From https://sourceware.org/gdb/current/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html#Skipping-Over-Functions-and-Files it looks like you want skip -rfu; it gives the example skip -rfu ^std::(allocator|basic_string)<.*>::~?\1 *\( to skip string constructors and destructors.
[Bug middle-end/93644] [10/11/12 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 George R. Goffe changed: What|Removed |Added CC||grgoffe at yahoo dot com --- Comment #20 from George R. Goffe --- Hi, I'm seeing this message from the "current" findutils. What is the solution? Best regards, George...
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Bug 40883 depends on bug 85665, which changed state. Bug 85665 Summary: Multiple typos in diagnostics https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/85665] Multiple typos in diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85665 Chung-Ju Wu changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Chung-Ju Wu --- (In reply to Chung-Ju Wu from comment #13) > > I am thinking of closing this bug issue for now. But it is ALWAYS WELCOME > to contribute patches as "obvious fix" if you notice any other typos in the > nds32 source. Close this issue as it is an omnibus report. It is welcome to propose separated patches on gcc-patches mailing list to fix typos. Feel free to treat it as "obvious fix" if the typo-fix patches are nds32 target related. Thanks.
[Bug testsuite/103196] [12 regression] gcc.target/powerpc/p9-vec-length-full-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103196 --- Comment #5 from Kewen Lin --- (In reply to Richard Biener from comment #4) > Or adjust the testcase. Please? Thanks for the suggestion! I adjusted the test case by making it not unrolled any more, as the patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590959.html. It's still pending on review. :)
[Bug middle-end/104854] -Wstringop-overread should not warn for strnlen, strndup and strncmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
Siddhesh Poyarekar changed:
What|Removed |Added
Summary|-Wstringop-overread should |-Wstringop-overread should
|not warn for strnlen and|not warn for strnlen,
|strndup |strndup and strncmp
Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot
gnu.org
--- Comment #4 from Siddhesh Poyarekar ---
(In reply to Martin Sebor from comment #3)
> The same warning is also issued for some calls to memchr(), strncmp() and
> probably other built-in functions as well. For example:
>
> const char a[] = "123";
>
> char* f (int i)
> {
> return __builtin_memchr (a + i, '3', 7);
> }
>
> warning: ‘__builtin_memchr’ specified bound 7 exceeds source size 4
> [-Wstringop-overread]
> 5 | return __builtin_memchr (a + i, '3', 7);
> | ^~~~
> y.c:1:12: note: source object allocated here
> 1 | const char a[] = "123";
> |^
The warning is arguably legitimate (not this one of course, since it's evident
at compile time that the operation is safe but for non-const `a` it may not be)
for memchr because it operates on an object, not string and will traverse all
of the object for a matching char to the extent of the object size. The
*string* functions are not the same in that context.
> In all these cases the warnings are intentional (i.e., it's a feature, and
> so not a regression). Their purpose is to point out what could be a coding
> mistake. With strndup(), since the use case for it rather than strdup() is
> to copy an initial substring, specifying a bound that's larger than the
> length of the string is pointless.
>
> In general, the GCC manual documents warnings as
>
> diagnostic messages that report constructions that are not inherently
> erroneous but that are risky or suggest there may have been an error.
I don't think these strnlen or strndup warnings point to *risky* or potentially
erroneous code; at best they point to instances where a specific protection is
absent, i.e. the behaviour reduces to strlen and strdup respectively, which is
much more benign than what it currently suggests. That kind of warning seems
more suited to a static analyzer and not a compiler IMO.
Besides, the core cause of a potential overread here is not because the size
argument is larger but because the string may not be NULL terminated. It may
make more sense to invest in that aspect of risky behaviour than the length for
these functions.
> So not all instances of any warning should be expected to indicate errors.
> In fact, many are known to be benign by design (for example, all instances
> of -Wchar-subscripts are benign when -funsigned-char is used; many instance
> of -Waddress are also benign, as are many -Wparentheses, etc.). And
They're not clubbed in with potentially important warnings though, which is a
key distinction. For example, one could mark -Wstirngop-overread as important
warnings but not -Wparentheses, but the high noise could make it difficult to
actually do so.
> although most middle end warnings tend to be designed to trigger only for
> invalid statements (i.e., statements that have undefined behavior if reached
> during execution), some do also trigger for code that's strictly valid but
> suspect. Besides the -Wstringop-overread examples here, other such warnings
> include dynamic allocation calls with sizes in excess of PTRDIFF_MAX
> (-Walloc-size-larger-than), returning the address of a local variable
> (-Wreturn-local-addr), or in GCC 12, storing the address of a local variable
> in an extern pointer (-Wdangling-pointer).
>
> Deciding what code is suspect enough to warn and under what option (-Wall or
> -Wextra) is a judgment call; different people have very different ideas.
I'm testing a patch to resolve this. I noticed strncmp late but it seems to
match this category as well, where a too-long length only reduces the max
protection provided by the n-versions of the string functions.
[Bug libstdc++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859 --- Comment #9 from Patrick Palka --- Should be fixed now, sorry for the build breakage. I suppose we might want to also backport this fix to the 11 branch.
[Bug libstdc++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859 --- Comment #8 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:65857caee8ccfac5007a9fd0e5f18cce5e5fe934 commit r12-7571-g65857caee8ccfac5007a9fd0e5f18cce5e5fe934 Author: Patrick Palka Date: Wed Mar 9 18:48:52 2022 -0500 libstdc++: Avoid implicit narrowing from uint128_t [PR104859] We need to be explicit about narrowing conversions from uint128_t since, on targets that lack __int128, this type is defined as an integer-class type that is only _explicitly_ convertible to the builtin integer types. This issue was latent until r12-7563-ge32869a17b788b made the frontend correctly reject explicit conversion functions during (dependent) copy-initialization. PR libstdc++/104859 libstdc++-v3/ChangeLog: * src/c++17/floating_to_chars.cc (__floating_to_chars_hex): Be explicit when narrowing the shifted effective_mantissa, since it may have an integer-class type.
[Bug middle-end/104854] -Wstringop-overread should not warn for strnlen and strndup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Summary|[11/12 Regression] |-Wstringop-overread should
|-Wstringop-overread should |not warn for strnlen and
|not warn for strnlen and|strndup
|strndup |
--- Comment #3 from Martin Sebor ---
The same warning is also issued for some calls to memchr(), strncmp() and
probably other built-in functions as well. For example:
const char a[] = "123";
char* f (int i)
{
return __builtin_memchr (a + i, '3', 7);
}
warning: ‘__builtin_memchr’ specified bound 7 exceeds source size 4
[-Wstringop-overread]
5 | return __builtin_memchr (a + i, '3', 7);
| ^~~~
y.c:1:12: note: source object allocated here
1 | const char a[] = "123";
|^
In all these cases the warnings are intentional (i.e., it's a feature, and so
not a regression). Their purpose is to point out what could be a coding
mistake. With strndup(), since the use case for it rather than strdup() is to
copy an initial substring, specifying a bound that's larger than the length of
the string is pointless.
In general, the GCC manual documents warnings as
diagnostic messages that report constructions that are not inherently
erroneous but that are risky or suggest there may have been an error.
So not all instances of any warning should be expected to indicate errors. In
fact, many are known to be benign by design (for example, all instances of
-Wchar-subscripts are benign when -funsigned-char is used; many instance of
-Waddress are also benign, as are many -Wparentheses, etc.). And although most
middle end warnings tend to be designed to trigger only for invalid statements
(i.e., statements that have undefined behavior if reached during execution),
some do also trigger for code that's strictly valid but suspect. Besides the
-Wstringop-overread examples here, other such warnings include dynamic
allocation calls with sizes in excess of PTRDIFF_MAX
(-Walloc-size-larger-than), returning the address of a local variable
(-Wreturn-local-addr), or in GCC 12, storing the address of a local variable in
an extern pointer (-Wdangling-pointer).
Deciding what code is suspect enough to warn and under what option (-Wall or
-Wextra) is a judgment call; different people have very different ideas.
[Bug c++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Oops, sorry, there is
template>>
constexpr explicit
operator T() const
{
static_assert(sizeof(T) <= sizeof(uint64_t));
return static_cast(lo);
}
but it is explicit so an explicit cast is needed.
[Bug c++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859
--- Comment #6 from Jakub Jelinek ---
I'm more suprised that this ever worked.
For 32-bit libstdc++, there is no unsigned __int128 support, so it uses
uint128_t.h instead, but that class doesn't have conversion operator to
unsigned.
Wonder if
constexpr explicit
operator unsigned() const
{ return unsigned(lo); }
shouldn't be added to the header and then spots like
const unsigned nibble = effective_mantissa >> rounded_mantissa_bits;
be replaced with
const unsigned nibble = {effective_mantissa >> rounded_mantissa_bits};
[Bug c++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2022-03-09
--- Comment #5 from Patrick Palka ---
I think we just need to add some explicit casts:
diff --git a/libstdc++-v3/src/c++17/floating_to_chars.cc
b/libstdc++-v3/src/c++17/floating_to_chars.cc
index 5825e661bf4..0ccf2623511 100644
--- a/libstdc++-v3/src/c++17/floating_to_chars.cc
+++ b/libstdc++-v3/src/c++17/floating_to_chars.cc
@@ -801,14 +801,14 @@ template
char leading_hexit;
if constexpr (has_implicit_leading_bit)
{
- const unsigned nibble = effective_mantissa >> rounded_mantissa_bits;
+ const unsigned nibble = unsigned(effective_mantissa >>
rounded_mantissa_bits);
__glibcxx_assert(nibble <= 2);
leading_hexit = '0' + nibble;
effective_mantissa &= ~(mantissa_t{0b11} << rounded_mantissa_bits);
}
else
{
- const unsigned nibble = effective_mantissa >>
(rounded_mantissa_bits-4);
+ const unsigned nibble = unsigned(effective_mantissa >>
(rounded_mantissa_bits-4));
__glibcxx_assert(nibble < 16);
leading_hexit = "0123456789abcdef"[nibble];
effective_mantissa &= ~(mantissa_t{0b} <<
(rounded_mantissa_bits-4));
@@ -853,7 +853,7 @@ template
while (effective_mantissa != 0)
{
nibble_offset -= 4;
- const unsigned nibble = effective_mantissa >> nibble_offset;
+ const unsigned nibble = unsigned(effective_mantissa >>
nibble_offset);
__glibcxx_assert(nibble < 16);
*first++ = "0123456789abcdef"[nibble];
++written_hexits;
since on targets which lack __int128, effective_mantissa can be the
integer-class uint128_t, which unlike __int128 is only _explicitly_ convertible
to the builtin integer types. And r12-7563-ge32869a17b788b made us correctly
exclude explicit conversion operators during copy-initialization.
[Bug c++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859 --- Comment #4 from Andrew Pinski --- (In reply to seurer from comment #3) > stage 1. It happens on a non-bootstrap, too. I was worried that it was causing wrong code in the front-end. Can you attach the preprocessed source for floating_to_chars.cc ?
[Bug c++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859 --- Comment #3 from seurer at gcc dot gnu.org --- stage 1. It happens on a non-bootstrap, too.
[Bug c++/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 --- Comment #2 from Andrew Pinski --- What stage is the bootstrap at while the error happens?
[Bug libgcc/104859] [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859 --- Comment #1 from seurer at gcc dot gnu.org --- Looks like this is BE only. And the bisect points here: commit e32869a17b788bee9ca782b174a546b1db17b5ea Author: Patrick Palka Date: Wed Mar 9 08:42:32 2022 -0500 c++: detecting copy-init context during CTAD [PR102137]
[Bug analyzer/104860] RFE: -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument should respect __attribute__((access, ...))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104860 --- Comment #1 from David Malcolm --- Questions posted to GCC list about this: "__attribute__ ((access, ...)) vs __attribute__ ((nonnull))" https://gcc.gnu.org/pipermail/gcc/2022-March/238389.html
[Bug fortran/104849] ICE in find_array_section, at fortran/expr.cc:1616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104849 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed for gcc-12. Closing. Thanks for the report!
[Bug fortran/104849] ICE in find_array_section, at fortran/expr.cc:1616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104849 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:22015e77d3e45306077396b9de8a8a28bb67fb20 commit r12-7569-g22015e77d3e45306077396b9de8a8a28bb67fb20 Author: Harald Anlauf Date: Wed Mar 9 21:58:26 2022 +0100 Fortran: improve error recovery on invalid array section gcc/fortran/ChangeLog: PR fortran/104849 * expr.cc (find_array_section): Avoid NULL pointer dereference on invalid array section. gcc/testsuite/ChangeLog: PR fortran/104849 * gfortran.dg/pr104849.f90: New test.
[Bug fortran/104849] ICE in find_array_section, at fortran/expr.cc:1616
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104849
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-03-09
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Obvious patch for NULL pointer dereference:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index c9c0ba4cc2e..86d61fed302 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1594,7 +1594,9 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
{
if ((begin && begin->expr_type != EXPR_CONSTANT)
|| (finish && finish->expr_type != EXPR_CONSTANT)
- || (step && step->expr_type != EXPR_CONSTANT))
+ || (step && step->expr_type != EXPR_CONSTANT)
+ || (!begin && !lower)
+ || (!finish && !upper))
{
t = false;
goto cleanup;
[Bug analyzer/104793] -Wanalyzer-write-to-const and -Wanalyzer-write-to-string-literal should respect attribute((access, write)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104793 --- Comment #1 from David Malcolm --- See also PR analyzer/104860, which covers this for -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument.
[Bug analyzer/104860] New: RFE: -Wanalyzer-possible-null-argument and -Wanalyzer-null-argument should respect __attribute__((access, ...))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104860
Bug ID: 104860
Summary: RFE: -Wanalyzer-possible-null-argument and
-Wanalyzer-null-argument should respect
__attribute__((access, ...))
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Similar to PR analyzer/104793, but relating to NULL/possibly NULL pointers (and
affects reads as well as writes):
typedef __SIZE_TYPE__ size_t;
int getrandom (void *__buffer, size_t __length,
unsigned int __flags)
__attribute__ ((access (__write_only__, 1, 2)));
#define GRND_RANDOM 0x02
void test (int flag)
{
char *buf = __builtin_malloc (1024);
if (getrandom(buf, 16, GRND_RANDOM))
__builtin_printf("%s\n", buf);
__builtin_free (buf);
}
The call to malloc could fail, but we don't yet complain about the
possibly-NULL param to getrandom, that's marked with __attribute__ ((access,
...))
[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > But that may be just a band-aid. Not even that. The following example shows that bad overflow handling is a regression that was likely introduced in 6.x: program p integer, parameter :: b(0) = 1 + [ huge(1) ] end
[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848
--- Comment #3 from anlauf at gcc dot gnu.org ---
Workaround: using -fno-range-check produces an error where appropriate.
Debugging suggests a potential fix for the ICE (needs testing):
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index c9c0ba4cc2e..cfafe10f727 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1293,7 +1293,7 @@ simplify_intrinsic_op (gfc_expr *p, int type)
gfc_internal_error ("simplify_intrinsic_op(): Bad operator");
}
- if (result == NULL)
+ if (result == NULL || result->expr_type == EXPR_UNKNOWN)
{
gfc_free_expr (op1);
gfc_free_expr (op2);
But that may be just a band-aid.
[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848 --- Comment #2 from anlauf at gcc dot gnu.org --- Forgot to add: print *, y+1_8 ! no ICE
[Bug fortran/104848] ICE in simplify_intrinsic_op, at fortran/expr.cc:1305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104848 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-03-09 --- Comment #1 from anlauf at gcc dot gnu.org --- Interesting. It might be the arithmetic overflow that is not properly handled. program p integer, parameter :: a(2, 0) = 0 integer, parameter :: y(*) = minval(a, dim=2) print *, y ! no ICE print *, y-1 ! no ICE print *, y+1 ! ICE end
[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-03-09 Status|RESOLVED|NEW Ever confirmed|0 |1 Resolution|DUPLICATE |--- --- Comment #7 from Jonathan Wakely --- Ah, but it still won't help for glibc 2.34 because the pthread symbols are not in libpthread.a now. So this is different from PR 52590
[Bug libgcc/104859] New: [12 regression] liibg++ fails during bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104859
Bug ID: 104859
Summary: [12 regression] liibg++ fails during bootstrap
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
Seen with g:bded0d549fdfdc1328b2c0189dc5f8593b4cbe42 r12-7566-gbded0d549fdfdc
but that is probably not the source. I am still bisecting this but as it is
breaking the build I thought I should open it right away.
libtool: compile: /home/seurer/gcc/git/build/gcc-test/./gcc/xgcc
-shared-libgcc -B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-m32 -I/home/seurer/gcc/git/gcc-test/libstdc++-v3/../libgcc
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/32/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++ -std=gnu++17 -nostdinc++
-D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=floating_to_chars.lo -fimplicit-templates -g -O2
-D_GNU_SOURCE -m32 -c
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc
-fPIC -DPIC -D_GLIBCXX_SHARED -o floating_to_chars.o
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc: In
instantiation of 'std::to_chars_result std::__floating_to_chars_hex(char*,
char*, T, optional) [with T = long double]':
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:926:37:
required from 'std::to_chars_result std::__floating_to_chars_shortest(char*,
char*, T, chars_format) [with T = long double]'
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:1612:40:
required from here
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:804:52:
error: cannot convert '{anonymous}::uint128_t' to 'const unsigned int' in
initialization
804 | const unsigned nibble = effective_mantissa >>
rounded_mantissa_bits;
|
~~~^~~~
||
|
{anonymous}::uint128_t
/home/seurer/gcc/git/gcc-test/libstdc++-v3/src/c++17/floating_to_chars.cc:856:56:
error: cannot convert '{anonymous}::uint128_t' to 'const unsigned int' in
initialization
856 | const unsigned nibble = effective_mantissa >>
nibble_offset;
| ~~~^~~~
||
|
{anonymous}::uint128_t
make[9]: *** [floating_to_chars.lo] Error 1
[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852 --- Comment #6 from Jonathan Wakely --- (In reply to Jackson Huff from comment #5) > Just for reference, another person in bug 52590 had tried the same before > but also had no luck. No, they tried a different command, not the one I suggested. I just checked out the code in an Ubuntu container and running make VERBOSE=1 I see that the flags are added to the start of the command: [100%] Linking CXX executable hajime /usr/bin/cmake -E cmake_link_script CMakeFiles/hajime.dir/link.txt --verbose=1 /usr/bin/c++ -static -Wl,--whole-archive -lpthread -Wl,--no-whole-archive -O3 -DNDEBUG -s -flto -fno-fat-lto-objects -flto=auto CMakeFiles/hajime.dir/hajime.cpp.o CMakeFiles/hajime.dir/server.cpp.o CMakeFiles/hajime.dir/server_features.cpp.o CMakeFiles/hajime.dir/server_performance.cpp.o CMakeFiles/hajime.dir/server_performance_counters.cpp.o CMakeFiles/hajime.dir/getvarsfromfile.cpp.o CMakeFiles/hajime.dir/output.cpp.o CMakeFiles/hajime.dir/installer.cpp.o CMakeFiles/hajime.dir/deduce.cpp.o CMakeFiles/hajime.dir/languages.cpp.o CMakeFiles/hajime.dir/wizard.cpp.o CMakeFiles/hajime.dir/constants.cpp.o -o hajime That is wrong: https://web.archive.org/web/20210609020437/c-faq.com/lib/libsearch.html
[Bug ada/104856] Build gcc with a target not containing '-gnu' gets added to gnat target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104856 --- Comment #4 from Bib --- I have a bug raised with Suse: https://bugzilla.suse.com/show_bug.cgi?id=1196861 And they are saying: Hmpf, so the directory name and the -dumpmachine output is using the configured target, while s-oscons.ads contains the canonicalized variant. Gah! Quick grepping on our binary packages indicates that that's the _only_ place where the canonical name is used, so maybe the best course of action would be to hack on it long enough that the generated s-oscons.ads also just contains the provided name without canonicalization.
[Bug ada/104856] Build gcc with a target not containing '-gnu' gets added to gnat target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104856
--- Comment #3 from Bib ---
I tried rebuilding with:
../configure --prefix=/opt/gcc11a --enable-languages=c,c++,ada
--enable-offload-targets=nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror --enable-ssp --disable-libssp
--disable-libvtv --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-11 --without-system-libunwind --with-tune=generic
--build=x86_64-suse-linux --host=x86_64-suse-linux --target=x86_64-suse-linux
--disable-multilib
And it still happens:
big-iron:/home/src/build/gcc-11.2.0/build$ find /opt/gcc11a/ -name s-oscons.ads
-exec grep -Hi Target_Name {} \;
/opt/gcc11a/lib64/gcc/x86_64-suse-linux/11/adainclude/s-oscons.ads:
Target_Name : constant String := "x86_64-suse-linux-gnu";
[Bug target/102215] [GCN offloading] Missing '__atomic_compare_exchange_1' etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102215
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:450526551dcb97b7c0513699d4333efb79b8b490
commit r12-7567-g450526551dcb97b7c0513699d4333efb79b8b490
Author: Tobias Burnus
Date: Wed Mar 9 19:34:48 2022 +0100
GCN: Implement __atomic_compare_exchange_{1,2} in libgcc [PR102215]
libgcc/ChangeLog:
PR target/102215
* config/gcn/atomic.c (__sync_val_compare_and_swap_##SIZE): Move
a line up to non-arg-dependent value first.
(__ATOMIC_COMPARE_EXCHANGE): Define + call to generate
__atomic_compare_exchange_{1,2}.
[Bug middle-end/19779] IBM 128bit long double format is not constant folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779 --- Comment #3 from Jonathan Wakely --- Yeah, I'm not asking for it to be fixed, just noting here that it affects C++ constant expressions.
[Bug middle-end/19779] IBM 128bit long double format is not constant folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- We do fold it with -ffast-math or -funsafe-math-optimizations. PR19405 explains the reasons why we can't fold those results that aren't exactly representable in double double.
[Bug middle-end/19779] IBM 128bit long double format is not constant folded.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19779 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- I think this should be rejects-valid not a missed-optimization enhancement. For C++20 we reject valid code: #include constexpr long double x = 1.0L + std::numeric_limits::epsilon(); :1:32: error: ‘(1.0e+0l + 4.94065645841246544176568792868221e-324l)’ is not a constant expression The code reduces to: constexpr long double x = 1.0L + __LDBL_EPSILON__;
[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852 --- Comment #5 from Jackson Huff --- Just for reference, another person in bug 52590 had tried the same before but also had no luck.
[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852 --- Comment #4 from Jackson Huff --- (In reply to Jonathan Wakely from comment #2) > For distros other than Red Hat (and Fedora, CentOS etc.) you need to use: > > -Wl,--whole-archive -lpthread -Wl,--no-whole-archive > > Otherwise the pthread symbols do not get pulled in by the linker. This would seem like a fix, but applying those flags to both the ADD_FLAGS variable and both manually specifying then in CMakeLists.txt made no difference (I tried variations for hours but no dice).
[Bug libstdc++/52590] std::thread Segmentation fault static linking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590 Jonathan Wakely changed: What|Removed |Added CC||lightningdzeyenr at gmail dot com --- Comment #6 from Jonathan Wakely --- *** Bug 104852 has been marked as a duplicate of this bug. ***
[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- See PR 52590 *** This bug has been marked as a duplicate of bug 52590 ***
[Bug libstdc++/104852] std::[j]thread::detach() still gives segmentation faults with glibc 2.34
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104852 --- Comment #2 from Jonathan Wakely --- This is the usual problem with weak symbols and static linking. For distros other than Red Hat (and Fedora, CentOS etc.) you need to use: -Wl,--whole-archive -lpthread -Wl,--no-whole-archive Otherwise the pthread symbols do not get pulled in by the linker. For GCC 12 and Glibc 2.34 that isn't needed, since r12-5108
[Bug ada/104856] Build gcc with a target not containing '-gnu' gets added to gnat target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104856 --- Comment #2 from Andreas Schwab --- --target defaults to --host when not given (and --host defaults to --build when not given). Looks like something is using the canonical target name instead of the target alias.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780
--- Comment #14 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #10)
> It seems the libstdc++ python hooks could set that up for users with
> gdb.execute ("skip std::move")?
No, that doesn't work. You need to use 'skip "std::move"' otherwise it
doesn't skip it:
$ gdb -q -ex start -ex 'skip std::move' -ex step -ex step -ex cont -ex q a.out
Reading symbols from a.out...
Temporary breakpoint 1 at 0x40110e: file move.C, line 16.
Starting program: /tmp/a.out
Temporary breakpoint 1, main () at move.C:16
16int i = 0;
Function std::move will be skipped when stepping.
17return std::move(i);
std::move (__t=@0x7fffd77c: 0) at move.C:11
11 { return static_cast::type&&>(__t); }
And std::move* doesn't work either:
$ gdb -q -ex start -ex 'skip std::move*' -ex step -ex step -ex cont -ex q a.out
Reading symbols from a.out...
Temporary breakpoint 1 at 0x40110e: file move.C, line 16.
Starting program: /tmp/a.out
Temporary breakpoint 1, main () at move.C:16
16int i = 0;
Function std::move* will be skipped when stepping.
17return std::move(i);
std::move (__t=@0x7fffd77c: 0) at move.C:11
11 { return static_cast::type&&>(__t); }
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 --- Comment #33 from Jonathan Wakely --- Complete patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591468.html
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780
--- Comment #13 from Jonathan Wakely ---
(In reply to Jason Merrill from comment #11)
> I'm surprised that adding the "artificial" attribute didn't work; I thought
> the main point of that attribute was to automatically skip the function in
> the debugger/profiler. I guess that never got implemented in gdb?
It seems to work with optimization, but not at -O0:
$ gdb -q -ex start -ex step -ex step -ex cont -ex q a.out
Reading symbols from a.out...
Temporary breakpoint 1 at 0x40110e: file move.C, line 16.
Starting program: /tmp/a.out
Temporary breakpoint 1, main () at move.C:16
16int i = 0;
17return std::move(i);
std::move (__t=@0x7fffd77c: 0) at move.C:11
11 { return static_cast::type&&>(__t); }
Continuing.
[Inferior 1 (process 1629725) exited normally]
I think I must have only tested -O0 last time.
> But these functions aren't really artificial, just tiny, so using that
> attribute seems wrong.
I think there's a case to be made for things like std::__addressof and
std::__is_constant_evaluated being "artificial" because they are just wrappers
around a built-in, and purely impl details. But I agree that std::move and
std::forward are not "artificial" in the sense of the DW_AT_artificial tag:
https://dwarfstd.org/doc/DWARF5.pdf#page=65
[Bug c++/93083] [C++20] copy deduction rejected when doing CTAD for NTTP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083 Patrick Palka changed: What|Removed |Added CC||nicole.king464 at gmail dot com --- Comment #10 from Patrick Palka --- *** Bug 96331 has been marked as a duplicate of this bug. ***
[Bug c++/96331] Class template argument deduction (CTAD) with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96331 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- This appears to be a dup of PR93083 which is fixed for GCC >= 10.3. *** This bug has been marked as a duplicate of bug 93083 ***
[Bug libstdc++/104858] New: ranges::minmax double dereferences first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104858
Bug ID: 104858
Summary: ranges::minmax double dereferences first
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
In
https://github.com/gcc-mirror/gcc/blob/bded0d549fdfdc1328b2c0189dc5f8593b4cbe42/libstdc%2B%2B-v3/include/bits/ranges_algo.h#L3087:
the initial result is constructed as:
minmax_result> __result = {*__first, *__first};
If *__first performs actually does work (maybe it's a transformed iterator),
then this is wasteful. But more importantly, if *__first gives you an rvalue
reference, then this moves from that iterator twice.
I think the standard requires ranges::minmax(v | views::as_rvalue) to actually
be valid (assuming an as_rvalue adaptor that ensures that the reference type is
an rvalue).
[Bug c++/104802] Non-type template parameter of reference type disallowed under certain conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104802 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98614 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||11.2.0 Last reconfirmed||2022-03-09 Keywords||rejects-valid CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Known to work||12.0 --- Comment #1 from Patrick Palka --- This appears to have been fixed on trunk by r12-1403-gc4e50e500da7692a interestingly enough (as with PR98614).
[Bug target/104857] [nvptx] Add macro specifying ptx isa version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104857 --- Comment #1 from Tom de Vries --- Created attachment 52592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52592=edit Tentative patch
[Bug target/104857] New: [nvptx] Add macro specifying ptx isa version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104857 Bug ID: 104857 Summary: [nvptx] Add macro specifying ptx isa version Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- Add a macro that can be used to test what .version x.y will be emitted in the .s file.
[Bug ada/104856] Build gcc with a target not containing '-gnu' gets added to gnat target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104856 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-03-09 --- Comment #1 from Eric Botcazou --- > Building the gcc suite with Ada with a target such as x86_64-suse-linux > causes Target_Name to be set to x86_64-suse-linux-gnu in s-oscons.ads. That's not what you're doing though since you do not pass --target, so try adding --target=x86_64-suse-linux to the configure line.
[Bug ipa/104813] [12 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: in adjust_references_in_caller, at ipa-cp.cc:4963 since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104813 --- Comment #4 from Martin Jambor --- I have proposed a patch on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591423.html
[Bug c++/104846] [10/11/12 Regression] ICE: tree check: expected function_decl, have field_decl in grokmethod, at cp/decl.cc:17999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104846 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug c++/103460] GCC rejected operator[](auto[]...) after P2128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103460 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 52591 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52591=edit gcc12-pr103460.patch Untested fix.
[Bug testsuite/104732] gcc.target/i386/pr100711-1.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104732 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Roger Sayle --- This should now be fixed on mainline. Rainer please let me know if you notice any remaining issues on solaris/x86.
[Bug middle-end/104854] [11/12 Regression] -Wstringop-overread should not warn for strnlen and strndup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
--- Comment #2 from Siddhesh Poyarekar ---
(In reply to David Malcolm from comment #1)
> Compiler Explorer link for the above (with -fanalyzer -Wall
> -Wstringop-overread -O2; -O2 seems to be needed to trigger it):
Ah yes, sorry, I pasted an older reproducer. This:
char *
foo (void)
{
return __builtin_strndup ("test", 8);
}
doesn't need -O2.
$ gcc -S -Wall ../test.c
../test.c: In function ‘foo’:
../test.c:5:10: warning: ‘__builtin_strndup’ specified bound 8 exceeds source
size 5 [-Wstringop-overread]
5 | return __builtin_strndup ("test", 8);
| ^
[Bug ada/104856] New: Build gcc with a target not containing '-gnu' gets added to gnat target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104856 Bug ID: 104856 Summary: Build gcc with a target not containing '-gnu' gets added to gnat target Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: bib_aab at hotmail dot com Target Milestone: --- Building the gcc suite with Ada with a target such as x86_64-suse-linux causes Target_Name to be set to x86_64-suse-linux-gnu in s-oscons.ads. Build gcc with: ../configure --prefix=/opt/gcc-11 --infodir=/opt/gcc-11/share/info --mandir=/opt/gcc-11/share/man --libdir=/opt/gcc-11/usr/lib64 --libexecdir=/opt/gcc-11/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d --enable-offload-targets=nvptx-none, --without-cuda-driver --enable-checking=release --disable-werror --with-gxx-include-dir=/opt/gcc-11/include/c++/11 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/opt/gcc-11/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-11 --without-system-libunwind --enable-multilib --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Running 'gcc -dumpmachine' returns x86_64-suse-linux. This is as per the configure switches, so all well and good. However: eth5:~$ grep Target_Name /opt/gcc-11/usr/lib64/gcc/x86_64-suse-linux/11/adainclude/s-oscons.ads Target_Name : constant String := "x86_64-suse-linux-gnu"; For some reason -gnu has been added. This means it is near impossible to build the gprbuild tools since it compares them and barfs because they are not the same. And we cannot just edit that file, since it states 'make changes to s-oscons-tmplt.c and rebuild the GNAT runtime library.' Why on earth is it adding -gnu? If it's a good idea, why doesn't -dumpmachine also return it?
[Bug c++/96440] [9/10/11/12 Regression] ICE in tree check: expected tree_list, have error_mark in get_attribute_name, at attribs.c:841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96440 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|9.5 |12.0 --- Comment #6 from Roger Sayle --- This should now be fixed on mainline.
[Bug c++/96437] [10/11/12 Regression] ICE in tree check: expected tree that contains ‘decl common’ structure, have ‘error_mark’ in synthesize_implicit_template_parm, at cp/parser.c:44246
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96437 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|10.4|12.0 --- Comment #5 from Roger Sayle --- This should now be fixed on mainline.
[Bug c++/96329] [11/12 Regression] ICE : tree check: expected string_cst, have error_mark in cp_parser_linkage_specification, at cp/parser.c:14640
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96329 Roger Sayle changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|11.3|12.0 Status|ASSIGNED|RESOLVED --- Comment #6 from Roger Sayle --- This should now be fixed on mainline.
[Bug c++/104846] [10/11/12 Regression] ICE: tree check: expected function_decl, have field_decl in grokmethod, at cp/decl.cc:17999
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104846 --- Comment #2 from Marek Polacek --- (In reply to Marek Polacek from comment #1) > Confirmed. Started with r10-2475-g777e426772f80c. It would be trivial to > bring back the grokmethod hunk to fix this ICE, but we should be more > helpful and say that operator delete[] must return type void, which I think > [basic.stc.dynamic.deallocation]#3 says. The return type is checked in coerce_delete_type but we never got there in this test.
[Bug c++/104855] New: -Wclass-memaccess is too broad with valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104855
Bug ID: 104855
Summary: -Wclass-memaccess is too broad with valid code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: soap at gentoo dot org
Target Milestone: ---
Given the following snippet:
#include
#include
#include
struct A
{
A() = default;
A(unsigned a, unsigned b) : data_(a + b) {}
private:
unsigned data_;
};
static_assert(std::is_trivial_v, "");
static_assert(std::is_trivially_copyable_v, "");
A foo(unsigned x)
{
A result;
std::memcpy(, , sizeof(x));
return result;
}
with GCC 11 and -Wall, I get the following warning
example.cpp: In function ‘A foo(unsigned int)’:
example.cpp:20:16: warning: ‘void* memcpy(void*, const void*, size_t)’ copying
an object of type ‘struct A’ with ‘private’ member ‘A::data_’ from an array of
‘unsigned int’; use assignment or copy-initialization instead
[-Wclass-memaccess]
20 | std::memcpy(, , sizeof(x));
| ~~~^~~~
example.cpp:5:8: note: ‘struct A’ declared here
5 | struct A
|^
which seems overbroad given that the code is 100% valid. I have asked Martin
Sebor, and his reason for this warning is
> about it breaking encapsulation by modifying a private data member.
> In the test case the modification might violate the invariant that
> the class represent the sum of the arguments it's constructed with.
which I understand, but I still consider this warning too broad for valid code,
especially because the suggested workaround is to cast the to a void*,
which involves reinterpret_cast and will raise eyebrows. Clang doesn't do this,
and I think it's right on this one.
[Bug middle-end/104854] [11/12 Regression] -Wstringop-overread should not warn for strnlen and strndup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #1 from David Malcolm ---
Compiler Explorer link for the above (with -fanalyzer -Wall -Wstringop-overread
-O2; -O2 seems to be needed to trigger it):
https://godbolt.org/z/jcEdxfEv9
In function 'foo',
inlined from 'bar' at :12:10:
:6:10: warning: '__builtin_strndup' specified bound 20 exceeds source
size 5 [-Wstringop-overread]
6 | return __builtin_strndup ("test", size);
| ^~~~
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #12 from Patrick Palka --- I should mention I noticed a significant reduction in compile time, memory usage and unstripped object file size in some cases with the proposed patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591091.html. For instance, for the range-v3 test file test/algorithm/set_symmetric_difference4.cpp compiled with -O2 -g and a non-checking compiler, compile time/GC allocations/object file size decreases from 8.29s/551M/3508K to 8.00s/541M/3104K. The object file size decrease (naively measured with du) here is particularly surprising, nearly a 12% decrease. I suppose this means debug info for inlined calls to std::move/forward accounts for >=12% of the debug info size, which we no longer emit with the patch.
[Bug tree-optimization/103724] [9/10/11/12 Regression] invalid warning: iteration 7 invokes undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103724 --- Comment #7 from Frank Heckenbach --- (In reply to Richard Biener from comment #6) > (In reply to Frank Heckenbach from comment #5) > > (In reply to Richard Biener from comment #4) > > > One thing we could do is annotate struct loop * with the (high level) > > > optimizations we've applied so that when we emit this warning we could say > > > > > > note: this loop is the copy generated by loop unswitching where b == 0 > > > > > > or so. Or maybe at least show > > > > > > note: this loop was unswitched > > > > If this is meant to apply to user-visible warnings, I'm not sure I'd like > > it. I usually run with -Werror, and this would still be a warning turned > > error then, wouldn't it? > > Yes. It might provide you with hints how to work around things though, > like do if (c) since b must be != 0. That was just a simplified test case. In my real code, there's nothing to simplify from a user's point of view. > That said, I don't think we can reasonably do something on the GCC side here. How about an option or warning level (if not default) to just omit the warning in the cases you'd say "note: this loop was unswitched"?
[Bug d/103528] [12 regression] d21 doesn't build on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103528 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Richard Biener --- > Fixed? Not completely. I'd argue we should do two things: * Document that older GCC versions need to be built with --enable-libphobos (SPARC or /bin/as). * Enable the Solaris libphobos build on SPARC and with /bin/as. There's no reason left to keep those configurations disabled. I have patches for both.
[Bug c++/104765] Expression statement with a return in a lambda-parameter-default causes segfault when called in a different function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104765 Jun Zhang changed: What|Removed |Added CC||jun at junz dot org --- Comment #5 from Jun Zhang --- Hi, I wonder how's the issue going on? Do we plan to disable expression statements in all default arguments or only in lambda and templates? (I'm working on this in clang so I want to know how GCC deals with it) Thanks!
[Bug middle-end/104854] [11/12 Regression] -Wstringop-overread should not warn for strnlen and strndup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854 Richard Biener changed: What|Removed |Added Summary|[11 Regression] |[11/12 Regression] |-Wstringop-overread should |-Wstringop-overread should |not warn for strnlen and|not warn for strnlen and |strndup |strndup Keywords||diagnostic Target Milestone|--- |11.3
[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781 --- Comment #11 from Jakub Jelinek --- I believe this should now be fixed, Rainer, can you please confirm?
[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- *** Bug 104838 has been marked as a duplicate of this bug. ***
[Bug target/104838] [12 Regression] i686 gnat1 hangs since r12-7472-g609e8c492d62d924
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104838 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed by the PR104781 changes. *** This bug has been marked as a duplicate of bug 104781 ***
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #11 from Jason Merrill --- I'm surprised that adding the "artificial" attribute didn't work; I thought the main point of that attribute was to automatically skip the function in the debugger/profiler. I guess that never got implemented in gdb? Related threads about avoiding debugging of uninteresting functions, which led to the addition of the "artificial" attribute: https://gcc.gnu.org/legacy-ml/gcc-patches/2005-07/threads.html#01969 https://gcc.gnu.org/legacy-ml/gcc-patches/2007-08/threads.html#02300 But these functions aren't really artificial, just tiny, so using that attribute seems wrong.
[Bug c++/96780] debuginfo for std::move and std::forward isn't useful
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #10 from Jason Merrill ---
In gdb nowadays, if you never want to step into a function, you can tell gdb
that with the 'skip' command. There are a bunch of those in the gcc .gdbinit
for tiny functions like std::move, and I have a few in my ~/.gdbinit as well.
It seems the libstdc++ python hooks could set that up for users with
gdb.execute ("skip std::move")?
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2022-03-09
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||wrong-code
Priority|P3 |P1
--- Comment #5 from Richard Biener ---
in .ompexp I see
void MAIN__._omp_fn.0 (struct .omp_data_s.9 & restrict .omp_data_i)
{
...
:
s = 0;
D.4352 = .omp_data_i->__tmp_class_a;
__tmp_class_a.10 = __tmp_class_a;
D.4355 = D.4352->_vptr;
__tmp_class_a.10->_vptr = D.4355;
D.4356 = .omp_data_i->__tmp_class_a;
D.4357 = D.4356->_vptr;
D.4358 = D.4357->_size;
D.4359 = (unsigned long) D.4358;
__tmp_class_a.11 = __tmp_class_a;
D.4361 = __builtin_malloc (D.4359);
__tmp_class_a.11->_data = D.4361;
D.4362 = .omp_data_i->__tmp_class_a;
D.4363 = D.4362->_vptr;
D.4364 = D.4363->_copy;
__tmp_class_a.12 = __tmp_class_a;
D.4366 = .omp_data_i->__tmp_class_a;
D.4367 = D.4366->_data;
D.4364 (D.4367, __tmp_class_a.12);
so .omp_data_i->__tmp_class_a is accessed but then the local __tmp_class_a
is used in the end. So sth is amiss here.
I suspect the unshare_expr is playing havoc with some later lookups.
[Bug target/104781] [12 regression] SEGV in _Unwind_GetGR during i386 Ada bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104781 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:caa6c33c5d5223c50657b08e73177e8d54ceee51 commit r12-7565-gcaa6c33c5d5223c50657b08e73177e8d54ceee51 Author: Jakub Jelinek Date: Wed Mar 9 15:25:30 2022 +0100 x86: Define LIBGCC2_UNWIND_ATTRIBUTE on ia32 [PR104781] On Mon, Mar 07, 2022 at 07:06:28AM -0800, H.J. Lu wrote: > Since eh_return doesn't work with stack realignment, disable SSE on > unwind-c.c and unwind-dw2.c to avoid stack realignment with the 4-byte > incoming stack to avoid SSE usage which is caused by The following change does that using LIBGCC2_UNWIND_ATTRIBUTE macro instead, for ia32 only by forcing -mgeneral-regs-only on routines that call __builtin_eh_return in libgcc. 2022-03-09 Jakub Jelinek PR target/104781 * config/i386/i386.h (LIBGCC2_UNWIND_ATTRIBUTE): Define for ia32.
[Bug middle-end/104854] New: [11 Regression] -Wstringop-overread should not warn for strnlen and strndup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854
Bug ID: 104854
Summary: [11 Regression] -Wstringop-overread should not warn
for strnlen and strndup
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: siddhesh at gcc dot gnu.org
Target Milestone: ---
The only times that strnlen and strndup can result in an actual overread is:
- The source is zero sized
or
- The source is not NULL terminated
In the current state something as trivial as the following:
char *
foo (size_t size)
{
return __builtin_strndup ("test", size);
}
char *
bar (void)
{
return foo (20);
}
issues a warning when the code is harmless. This is probably better suited as
a static analysis heuristic/suggestion than as a compiler warning that tends to
suggest that something is more likely wrong than not.
[Bug testsuite/103196] [12 regression] gcc.target/powerpc/p9-vec-length-full-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103196 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail --- Comment #4 from Richard Biener --- Or adjust the testcase. Please?
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 --- Comment #32 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #30) > I'd have done printf "%s [%s]?" "$question" "$default" instead, but they're > equivalent. Oops, equivalent except for the missing space after the question mark in my version. There are still other issues on Solaris though: $ PATH=/usr/xpg4/bin:$PATH ./contrib/gcc-git-customization.sh Your name [Jonathan Wakely]? Your email address (for git commits) [jwak...@redhat.com]? Local name for upstream repository [origin]? sed: illegal option -- r Usage: sed [-n] script [file...] sed [-n] [-e script]...[-f script_file]...[file...] Account name on gcc.gnu.org (for your personal branches area) [remote_id]? redi ./contrib/gcc-git-customization.sh[16]: eval[1]: =redi: not found [No such file or directory] Local branch prefix for personal branches you want to share (local branches starting / can be pushed directly to your personal area on the gcc server) [me]? Install prepare-commit-msg git hook for 'git commit-mklog' alias [yes]? fatal: ambiguous argument 'hooks': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' cp: illegal option -- git-path cp: Insufficient arguments (1) Usage: cp [-f] [-i] [-p] [-@] [-/] f1 f2 cp [-f] [-i] [-p] [-@] [-/] f1 ... fn d1 cp -r|-R [-H|-L|-P] [-f] [-i] [-p] [-@] [-/] d1 ... dn-1 dn install: cp --git-path /export/home/jwakely/src/gcc/contrib/prepare-commit-msg/--git-path failed sed: illegal option -- r Usage: sed [-n] script [file...] sed [-n] [-e script]...[-f script_file]...[file...] Setting up tracking for personal namespace in remotes/users/me fatal: Invalid refspec '+refs/users//heads/*:refs/remotes/users/me/*' I'll look into those ...
[Bug middle-end/103309] [12 Regression] Random gcc/system.h:784:34: error: section type conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103309 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Assuming fixed.
[Bug middle-end/103483] [12 regression] context-sensitive ranges change triggers stringop-overread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483
--- Comment #22 from Richard Biener ---
There isn't going to be a good solution that makes all folks happy - we'd
either have false negatives or false positives. It is true that we're
accumulating more and more cases where the user gets the impression we want to
warn about
int a[16];
void foo (size_t len)
{
memset (a, 0, len);
}
like
warning: memset called with unbound 'len' argument to buffer of size 16
for example we do not diagnose
int a[2];
void foo (unsigned len)
{
if (len == 1 || len == 20)
__builtin_memset (a, 0, len);
}
even though with len == 20 this is out of bounds. Instead we only
diagnose if both possible accesses are out of bounds but we fail
to see that in the 'else' case we do not call memset at all. What's
the real difference to the len == 1 case that makes us to not
emit the diagnostics here?
What we traditionally consider as "always" and "maybe" is also blurry
with more and more IPA optimization (functions are always only "maybe"
executed).
What static analyzers and fuzzers do is isolate every possible path,
sensible or not, and diagnose those. We're getting closer to that
(but every non-sensical isolated path also consumes object space).
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 --- Comment #31 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #30) > I'd have done printf "%s [%s]?" "$question" "$default" instead, but they're > equivalent. Given that I've tested it and you're a global maintainer, I said > push it! s/said/say/
[Bug other/102664] contrib/gcc-git-customization.sh uses echo -n, which isn't portable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102664 --- Comment #30 from Jonathan Wakely --- Solaris /bin/echo doesn't understand -n jwakely@gcc-solaris11:~/src/gcc$ ./contrib/gcc-git-customization.sh -n Your name [Jonathan Wakely]? -n Your email address (for git commits) [jwak...@redhat.com]? -n Local name for upstream repository [origin]? Richard's patch fixes it for Solaris: Your name [Jonathan Wakely]? Your email address (for git commits) [jwak...@redhat.com]? Local name for upstream repository [origin]? I'd have done printf "%s [%s]?" "$question" "$default" instead, but they're equivalent. Given that I've tested it and you're a global maintainer, I said push it!
[Bug c++/104823] [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104823 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed.
[Bug c++/87820] Explicit user-defined casting inside a template class working in implicit conversion inside function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87820 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 12, thanks for the bug report.
[Bug c++/102137] class template argument deduction with template template parameter allows explicit deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102137 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed for GCC 12.
[Bug d/103528] [12 regression] d21 doesn't build on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103528 --- Comment #10 from Richard Biener --- Fixed?
[Bug bootstrap/103547] [12 Regression] Bootstrap failure with --with-cpu=skylake-avx512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103547 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #4 from Richard Biener --- Assuming fixed. Please re-open if the issue re-appears.
[Bug c++/50370] [C++0x] Multiple declarations with default template arguments accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50370 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #5 from Patrick Palka --- Fixed alongside with PR65396 for GCC 12 by r12-7562-gfe548eb8436f39.
[Bug c++/104702] [12 Regression] False positive -Wunused-value warning with -fno-exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104702
--- Comment #6 from Jakub Jelinek ---
(In reply to Richard Biener from comment #4)
> (In reply to Jakub Jelinek from comment #2)
> > I think the problem in this case are primarily the warning-control.cc
> > changes.
> > In GCC 11, build_vec_init did at the end:
> > /* Now make the result have the correct type. */
> > if (TREE_CODE (atype) == ARRAY_TYPE)
> > {
> > atype = build_pointer_type (atype);
> > stmt_expr = build1 (NOP_EXPR, atype, stmt_expr);
> > stmt_expr = cp_build_fold_indirect_ref (stmt_expr);
> > TREE_NO_WARNING (stmt_expr) = 1;
> > }
> > GCC 12 does instead:
> > if (TREE_CODE (atype) == ARRAY_TYPE)
> > {
> > atype = build_pointer_type (atype);
> > stmt_expr = build1 (NOP_EXPR, atype, stmt_expr);
> > stmt_expr = cp_build_fold_indirect_ref (stmt_expr);
> > suppress_warning (stmt_expr /* What warning? */);
> > }
> > Clearly, at least one of the intended warnings that should be suppressed is
> > OPT_Wunused_value.
> > But as EXPR_LOCATION (stmt_expr) == UNKNOWN_LOCATION here, all
> > suppress_warning
> > does is set TREE_NO_WARNING bit on it (i.e. like GCC 11 used).
> > Later on, add_stmt is called on it and does:
> > if (!EXPR_HAS_LOCATION (t))
> > SET_EXPR_LOCATION (t, input_location);
> > There was also even before build_vec_init a call to
> > suppress_warning with some unrelated expression that had the
> > 284032 {file = 0x3f67310 "pr104702.C", line = 11, column = 31, data = 0x0,
> > sysp = false}
> > location (with OPT_Wparentheses) which is the input_location now newly set
> > by add_stmt on the INDIRECT_REF.
> > Later on, convert_to_void calls
> > && !warning_suppressed_p (expr, OPT_Wunused_value)
> > on the INDIRECT_REF. TREE_NO_WARNING bit is set, but at this point it has a
> > location, so it looks up the location in hash map, finds that
> > OPT_Wparantheses
> > is the warning to be suppressed there and returns that OPT_Wunused_value
> > isn't suppressed there, even when we wanted to suppress all warnings on the
> > tree.
>
> So shouldn't warning_suppressed_p (tree, ...) also honor TREE_NO_WARNING
> even if a location is present? That is,
>
> diff --git a/gcc/warning-control.cc b/gcc/warning-control.cc
> index 0cbb4f079fa..d36f3ff6965 100644
> --- a/gcc/warning-control.cc
> +++ b/gcc/warning-control.cc
> @@ -120,10 +120,12 @@ get_nowarn_spec (const gimple *stmt)
> bool
> warning_suppressed_p (const_tree expr, opt_code opt /* = all_warnings */)
> {
> - const nowarn_spec_t *spec = get_nowarn_spec (expr);
> + if (get_no_warning_bit (expr))
> +return true;
>
> + const nowarn_spec_t *spec = get_nowarn_spec (expr);
>if (!spec)
> -return get_no_warning_bit (expr);
> +return false;
>
>const nowarn_spec_t optspec (opt);
>bool dis = *spec & optspec;
>
> or, if that's not desired, at least
>
> gcc_checking_assert (!get_no_warning_bit (expr));
>
> when there's a spec?
That would basically throw away all the warning-control.cc stuff, get us back
to
the TREE_NO_WARNING/gimple_no_warning behavior. Because the TREE_NO_WARNING
/gimple_no_warning bits are used as a flag whether at least one warning is
disabled.
Anyway, if we keep moreless the current warning-control.cc behavior, it is
unclear what should the FE call when it does:
if (!EXPR_HAS_LOCATION (t))
SET_EXPR_LOCATION (t, input_location);
Shall it do
if (!EXPR_HAS_LOCATION (t) && input_location != UNKNOWN_LOCATION)
{
if (TREE_NO_WARNING (t))
copy_warning (input_location, UNKNOWN_LOCATION);
SET_EXPR_LOCATION (t, input_location);
}
or so or some function that will do roughly that?
The copy_warning in gimple.h looks just wrong to me:
static inline void
gimple_set_location (gimple *g, location_t location)
{
/* Copy the no-warning data to the statement location. */
copy_warning (location, g->location);
g->location = location;
}
If I have some random statement which doesn't have any warning suppression
for it (i.e. !gimple_no_warning_p) and I set the location for it to some real
location, all of sudden that location will have suppressions of "all warnings"
if it is ever used somewhere else where warnings are suppressed.
Shouldn't that do:
if (__builtin_expect (g->no_warning, 0))
copy_warning (location, g->location);
instead?
Shouldn't we have some early return e.g. in the copy_warning (location_t,
location_t) if the locations are the same?
[Bug c++/65396] Function template default template arguments not merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/104823] [12 Regression] narrowing conversion inside non-dependent decltype operand silently accepted ever since r12-6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104823
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:ec0f53a3a542e762f8fc8c22b9d345f922be5867
commit r12-7564-gec0f53a3a542e762f8fc8c22b9d345f922be5867
Author: Patrick Palka
Date: Wed Mar 9 08:42:37 2022 -0500
c++: non-constant non-dependent decltype folding [PR104823]
When processing a non-dependent decltype operand we want to instantiate
it even if it's non-constant, since non-dependent decltype is always
resolved ahead of time. But currently finish_decltype_type uses
instantiate_non_dependent_expr, which instantiates only potentially
constant expressions, and this causes us to miss diagnosing the narrowing
conversion in S{id(v)} in the below testcase because we never instantiate
this non-constant non-dependent decltype operand.
In light of
> On Mon, 7 Mar 2022, Jason Merrill wrote:
>> On 3/7/22 14:41, Patrick Palka wrote:
>>> instantiate_non_dependent_expr instantiates only potentially constant
>>> expressions
>>
>> Hmm, that now strikes me as a problematic interface, as we don't know
whether
>> what we get back is template or non-template trees.
this patch drops the potentially-constant check in i_n_d_e and turns
its dependence check into a checking_assert, since most callers already
check that the argument is non-dependent; thus i_n_d_e now instantiates
even non-constant expressions and always returns non-templated trees.
This patch also relaxes the dependence check in i_n_d_e to use the
_uneval version (since that's what finish_decltype_type uses) and
strengthens the dependence checks used by other callers accordingly.
In cp_parser_parenthesized_expression_list_elt we were calling
instantiate_non_dependent_expr (when parsing an attribute list) without
first checking for non-dependence. We could fix this by guarding the
call appropriately, but I noticed we also fold non-dependent attributes
later from cp_check_const_attribute, so this earlier folding is at best
redundant. And it currently causes us to reject constexpr-attribute4.C
below due to the second folding seeing non-templated trees. Thus the
right solution here seems to be to remove this unguarded call to i_n_d_e
so that we end up instantiating non-dependent attributes only once.
Finally, after calling i_n_d_e in finish_decltype_type we need to keep
processing_template_decl cleared for sake of the later call to
lvalue_kind, which handles templated and non-templated COND_EXPR
differently. Otherwise we'd incorrectly reject the declaration of g in
cpp0x/cond2.C with:
error: 'g' declared as function returning a function
PR c++/104823
gcc/cp/ChangeLog:
* except.cc (build_noexcept_spec): Strengthen dependence check
to instantiation_dependent_expression_p.
* parser.cc (cp_parser_parenthesized_expression_list_elt):
Remove fold_expr_p parameter, and don't call
instantiate_non_dependent_expr.
(cp_parser_parenthesized_expression_list): Adjust accordingly.
* pt.cc (expand_integer_pack): Strengthen dependence check
to instantiation_dependent_expression_p.
(instantiate_non_dependent_expr_internal): Adjust comment.
(instantiate_non_dependent_expr_sfinae): Likewise. Drop
the potentially-constant check, and relax and turn the
dependence check into a checking assert.
(instantiate_non_dependent_or_null): Adjust comment.
* semantics.cc (finish_decltype_type): Keep
processing_template_decl cleared after calling
instantiate_non_dependent_expr_sfinae.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/Wnarrowing19.C: New test.
[Bug c++/102137] class template argument deduction with template template parameter allows explicit deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102137 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e32869a17b788bee9ca782b174a546b1db17b5ea commit r12-7563-ge32869a17b788bee9ca782b174a546b1db17b5ea Author: Patrick Palka Date: Wed Mar 9 08:42:32 2022 -0500 c++: detecting copy-init context during CTAD [PR102137] Here we're failing to communicate to cp_finish_decl from tsubst_expr that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING flag), which causes us to always consider explicit deduction guides when performing CTAD for a templated variable initializer. It turns out this bug also affects consideration of explicit conversion operators for the same reason. But consideration of explicit constructors seems unaffacted thanks to code in build_aggr_init that sets LOOKUP_ONLYCONVERTING when the initializer represents copy-initialization. So this patch fixes this by making cp_finish_decl set LOOKUP_ONLYCONVERTING just like build_aggr_init does, by inspecting the initializer, so that callers don't need to explicitly pass this flag appropriately. PR c++/102137 PR c++/87820 gcc/cp/ChangeLog: * cp-tree.h (is_copy_initialization): Declare. * decl.cc (cp_finish_decl): Set LOOKUP_ONLYCONVERTING when is_copy_initialization is true. * init.cc (build_aggr_init): Split out copy-initialization check into ... (is_copy_initialization): ... here. * pt.cc (instantiate_decl): Pass 0 instead of LOOKUP_ONLYCONVERTING as flags to cp_finish_decl. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/explicit15.C: New test. * g++.dg/cpp1z/class-deduction108.C: New test.
[Bug c++/87820] Explicit user-defined casting inside a template class working in implicit conversion inside function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87820 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e32869a17b788bee9ca782b174a546b1db17b5ea commit r12-7563-ge32869a17b788bee9ca782b174a546b1db17b5ea Author: Patrick Palka Date: Wed Mar 9 08:42:32 2022 -0500 c++: detecting copy-init context during CTAD [PR102137] Here we're failing to communicate to cp_finish_decl from tsubst_expr that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING flag), which causes us to always consider explicit deduction guides when performing CTAD for a templated variable initializer. It turns out this bug also affects consideration of explicit conversion operators for the same reason. But consideration of explicit constructors seems unaffacted thanks to code in build_aggr_init that sets LOOKUP_ONLYCONVERTING when the initializer represents copy-initialization. So this patch fixes this by making cp_finish_decl set LOOKUP_ONLYCONVERTING just like build_aggr_init does, by inspecting the initializer, so that callers don't need to explicitly pass this flag appropriately. PR c++/102137 PR c++/87820 gcc/cp/ChangeLog: * cp-tree.h (is_copy_initialization): Declare. * decl.cc (cp_finish_decl): Set LOOKUP_ONLYCONVERTING when is_copy_initialization is true. * init.cc (build_aggr_init): Split out copy-initialization check into ... (is_copy_initialization): ... here. * pt.cc (instantiate_decl): Pass 0 instead of LOOKUP_ONLYCONVERTING as flags to cp_finish_decl. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/explicit15.C: New test. * g++.dg/cpp1z/class-deduction108.C: New test.
[Bug c++/65396] Function template default template arguments not merged
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65396 --- Comment #10 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:fe548eb8436f3906e6a3c6e3e8707d24e60ec0fa commit r12-7562-gfe548eb8436f3906e6a3c6e3e8707d24e60ec0fa Author: Patrick Palka Date: Wed Mar 9 08:42:19 2022 -0500 c++: merge default targs for function templates [PR65396] We currently merge default template arguments for class templates, but not for function templates. This patch fixes this by factoring out the argument merging logic in redeclare_class_template into a separate function and using it in duplicate_decls as well. PR c++/65396 gcc/cp/ChangeLog: * cp-tree.h (merge_default_template_args): Declare. * decl.cc (merge_default_template_args): Define, factored out from redeclare_class_template. (duplicate_decls): Use it when merging member function template and free function declarations. * pt.cc (redeclare_class_template): Factor out default argument merging logic into merge_default_template_args. Improve location of a note when there's a template parameter kind mismatch. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/vt-34314.C: Adjust expected location of "redeclared here" note. * g++.dg/template/pr92440.C: Likewise. * g++.old-deja/g++.pt/redecl1.C: Adjust expected location of "redefinition of default argument" error. * g++.dg/template/defarg23.C: New test. * g++.dg/template/defarg23a.C: New test.
[Bug tree-optimization/104759] [11/12 Regression] gcc.dg/vect/vect-multitypes-12.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104759 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
