[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 --- Comment #3 from Richard Biener --- So I'm looking again at this. For the simple cases I have at hand we can fix the C++ FE issue with diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c index d035e611be4..81097942449 100644 --- a/gcc/cp/cvt.c +++ b/gcc/cp/cvt.c @@ -1645,7 +1645,12 @@ convert_to_void (tree expr, impl_conv_void implicit, tsub st_flags_t complain) } expr = build1 (CONVERT_EXPR, void_type_node, expr); } - if (! TREE_SIDE_EFFECTS (expr)) + if (! TREE_SIDE_EFFECTS (expr) + && ! (CONVERT_EXPR_P (expr) + && TREE_CODE (TREE_OPERAND (expr, 0)) == CALL_EXPR + && ! TREE_NOTHROW (TREE_OPERAND (expr, 0))) + && ! (TREE_CODE (expr) == CALL_EXPR + && ! TREE_NOTHROW (expr))) expr = void_node; return expr; } of course that relies on seeing f() or (void)f(), it already fails with (void)(1 + f()). We also diagnose such stmts as having no effect: t.ii: In function 'int bar(int*, int)': t.ii:13:10: warning: statement has no effect [-Wunused-value] 13 |1 + foo (n); |~~^ there's expr_noexcept_p that seems to work here even for 1 + foo () but I'm not sure it's the correct tool. But it would simplify a fix to diff --git a/gcc/cp/cvt.c b/gcc/cp/cvt.c index d035e611be4..4885a7c6584 100644 --- a/gcc/cp/cvt.c +++ b/gcc/cp/cvt.c @@ -1645,7 +1645,7 @@ convert_to_void (tree expr, impl_conv_void implicit, tsubst_flags_t complain) } expr = build1 (CONVERT_EXPR, void_type_node, expr); } - if (! TREE_SIDE_EFFECTS (expr)) + if (! TREE_SIDE_EFFECTS (expr) && expr_noexcept_p (expr, 0)) expr = void_node; return expr; } I'm giving that full testing.
[Bug tree-optimization/101373] New: PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373
Bug ID: 101373
Summary: PRE hoists trapping instructions over possibly
throwing calls
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int __attribute__((const,noipa)) foo (int j)
{
if (j != 0)
throw 1;
return 0;
}
int __attribute__((noipa)) bar (int *p, int n)
{
int ret = 0;
if (n)
{
foo (n);
ret = *p;
}
ret += *p;
return ret;
}
int main()
{
try
{
return bar (nullptr, 1);
}
catch (...)
{
return 0;
}
}
Here PRE hoists *p before the if (n) which it may not do.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 Richard Biener changed: What|Removed |Added Depends on||100409 Last reconfirmed||2021-07-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Keywords||wrong-code Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Testing a patch. Depends on a fix for PR100409 which else breaks the testcase in the C++ frontend already. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 [Bug 100409] C++ FE elides pure throwing call
[Bug bootstrap/101369] Bootstrap failure of gcc-12-20210704 on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101369 --- Comment #3 from Richard Biener --- IIRC there was a recently filed duplicate.
[Bug c++/101371] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371 Richard Biener changed: What|Removed |Added Last reconfirmed||2021-07-08 Status|UNCONFIRMED |NEW Known to fail||12.0 Ever confirmed|0 |1 Version|unknown |10.3.1 Keywords||ice-on-valid-code --- Comment #1 from Richard Biener --- Confirmed. Also fails on trunk. clang accepts it.
[Bug bootstrap/101372] [12 Regression] Bootstrap failure compiling gcc/cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug bootstrap/101374] New: [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374
Bug ID: 101374
Summary: [12 Regression] bootstrap failure varpool.c:490:19:
error: array subscript 'varpool_node[0]' is partly
outside array bounds of 'varpool_node [0]'
[-Werror=array-bounds]
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
Bootstrap fails for me with
/home/rguenther/src/trunk/gcc/varpool.c:490:19: error: array subscript
'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]'
[-Werror=array-bounds]
490 | if (!definition && !in_other_partition)
| ^~
In file included from /home/rguenther/src/trunk/gcc/varpool.c:29:
/home/rguenther/src/trunk/gcc/cgraph.h: In member function 'availability
varpool_node::_ZN12varpool_node16get_availabilityEP11symtab_node.part.0(symtab_node*)':
/home/rguenther/src/trunk/gcc/cgraph.h:1969:39: note: object
'varpool_node::' of size 120
1969 | struct GTY((tag ("SYMTAB_VARIABLE"))) varpool_node : public symtab_node
| ^~~~
when in stage2.
configure --enable-languages=c++,obj-c++
make -j24 STAGE1_CFLAGS="-O2"
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Richard Biener changed: What|Removed |Added CC||msebor at gcc dot gnu.org Keywords||diagnostic Target||x86_64-*-* Target Milestone|--- |12.0
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374
--- Comment #1 from Richard Biener ---
Reverting g:a110855667782dac7b674d3e328b253b3b3c919b gets me past this failure
point.
I'll note the printed location is bogus as well, it points to
/* Return variable availability. See cgraph.h for description of individual
return values. */
enum availability
varpool_node::get_availability (symtab_node *ref)
{
if (!definition && !in_other_partition) <
return AVAIL_NOT_AVAILABLE;
if (!TREE_PUBLIC (decl))
it might eventually warn on this->definition though?
[Bug bootstrap/101372] [12 Regression] Bootstrap failure compiling gcc/cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 Richard Biener changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Richard Biener --- Probably similar to PR101374 - try reverting r12-2132
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #4 from Harald van Dijk --- The documentation for the pure attribute refers to "functions that have no observable effects on the state of the program other than to return a value" which implies not throwing exceptions, the Wsuggest-attribute=pure text says that pure functions have to return normally, and the presence of throw statements suppresses the compiler's suggestion to mark functions as pure. This function throws, so should the fact that it is marked pure not simply make the whole thing undefined?
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409
--- Comment #5 from Richard Biener ---
Hmm, doesn't quite work.
FAIL: g++.dg/cpp0x/sfinae19.C -std=c++14 (internal compiler error)
FAIL: g++.dg/cpp0x/sfinae22.C -std=c++14 (internal compiler error)
FAIL: g++.dg/cpp1y/pr61636-2.C -std=c++14 (internal compiler error)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for errors, line 79)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 80)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 82)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 83)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 84)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 85)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 88)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (internal compiler error)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for excess errors)
the ICE is
/home/rguenther/src/trunk/gcc/testsuite/g++.dg/cpp0x/sfinae19.C:8:30: internal
compiler error: in check_noexcept_r, at cp/except.c:1053^M
if ((code == CALL_EXPR && CALL_EXPR_FN (t))
|| code == AGGR_INIT_EXPR)
{
/* We can only use the exception specification of the called function
for determining the value of a noexcept expression; we can't use
TREE_NOTHROW, as it might have a different value in another
translation unit, creating ODR problems.
We could use TREE_NOTHROW (t) for !TREE_PUBLIC fns, though... */
tree fn = cp_get_callee (t);
if (concept_check_p (fn))
return NULL_TREE;
tree type = TREE_TYPE (fn);
gcc_assert (INDIRECT_TYPE_P (type));
where the type is likely the lang_type in:
VOID
align:1 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x766851f8
pointer_to_this
reference_to_this >
whatever that exactly is, it isn't a reference or pointer type.
processing_template_decl is true in this context, but if we assume
that in this context expr_noexcept_p is true we probably miss diagnostics.
Jason, any idea?
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 --- Comment #6 from Richard Biener --- Created attachment 51116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51116&action=edit patch I was testing I was testing this patch.
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 Richard Biener changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #7 from Richard Biener --- Jason, any idea?
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 --- Comment #8 from Richard Biener --- (In reply to Harald van Dijk from comment #4) > The documentation for the pure attribute refers to "functions that have no > observable effects on the state of the program other than to return a value" > which implies not throwing exceptions, the Wsuggest-attribute=pure text says > that pure functions have to return normally, and the presence of throw > statements suppresses the compiler's suggestion to mark functions as pure. > This function throws, so should the fact that it is marked pure not simply > make the whole thing undefined? It has been consensus that throwing exceptions and const/pure are different concepts that co-exist. See for example the recent discussion at https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569435.html
[Bug testsuite/101375] New: arm: Adding -mfpu=auto makes many tests unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101375 Bug ID: 101375 Summary: arm: Adding -mfpu=auto makes many tests unsupported Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- While looking at updating my validation configs to use -mfpu=auto, I noticed that adding this options makes many tests unsupported. Given that most of them actually check if -mfpu is overridden, maybe I shouldn't add -mfpu=auto? Specifically, for arm-none-eabi, configured with default cpu/fpu/mode, and running the tests with -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd/-mfpu=auto instead of -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd results in: < FAIL: gcc.dg/ipa/ipa-icf-38.c scan-ltrans-tree-dump-not optimized "Function bar" < FAIL: gcc.dg/ipa/ipa-icf-38.c scan-wpa-ipa-dump icf "Equal symbols: 1" < FAIL: gcc.dg/ipa/ipa-icf-38.c scan-wpa-ipa-dump icf "Semantic equality hit:foo/[0-9+]+->bar/[0-9+]+" < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-5.c -O0 < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-5.c -O1 < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-5.c -O2 < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-5.c -O2 -flto -fno-use-linker-plugin -flto-partition=none < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-5.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-5.c -O3 -g < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-5.c -Os < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-6.c -O0 < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-6.c -O1 < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-6.c -O2 < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-6.c -O2 -flto -fno-use-linker-plugin -flto-partition=none < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-6.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-6.c -O3 -g < UNSUPPORTED: gcc.dg/torture/arm-fp16-ops-6.c -Os < UNSUPPORTED: gcc.target/arm/aapcs/vfp18.c < UNSUPPORTED: gcc.target/arm/aapcs/vfp19.c < UNSUPPORTED: gcc.target/arm/aapcs/vfp20.c < UNSUPPORTED: gcc.target/arm/aapcs/vfp21.c < UNSUPPORTED: gcc.target/arm/aapcs/vfp22.c < UNSUPPORTED: gcc.target/arm/aapcs/vfp23.c < UNSUPPORTED: gcc.target/arm/aapcs/vfp24.c < UNSUPPORTED: gcc.target/arm/aapcs/vfp25.c < UNSUPPORTED: gcc.target/arm/f16_f64_conv_no_dp.c < UNSUPPORTED: gcc.target/arm/fp16-aapcs-1.c < UNSUPPORTED: gcc.target/arm/fp16-compile-vcvt.c < UNSUPPORTED: gcc.target/arm/pr51835.c < UNSUPPORTED: gcc.target/arm/vect-half-floats.c instead of all passes. This essentially means these tests become unsupported in all the configs I'm testing, thus I'm worried about test coverage.
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 --- Comment #2 from Richard Biener --- I'm reducing a testcase for the varpool.c warning.
[Bug c++/101376] New: Missing Wsuggest-attribute=const/Wsuggest-attribute=pure for throwing functions, wrong Wattributes for pure/const throwing functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101376
Bug ID: 101376
Summary: Missing
Wsuggest-attribute=const/Wsuggest-attribute=pure for
throwing functions, wrong Wattributes for pure/const
throwing functions
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
According to PR100409, const/pure functions are allowed to throw. As such, I
would expect that
void f() {
throw "!";
}
produces a diagnostic with -Wsuggest-attribute=const but no diagnostic is
produced.
In fact, if I modify this to add the attribute myself, like so:
__attribute__((const)) void f() {
throw "!";
}
I get "warning: 'const' attribute on function returning 'void'". This warning
is documented but now wrong. The documentation reads
"Because a const function cannot have any observable side effects it does not
make sense for it to return void. Declaring such a function is diagnosed."
A helper function to throw an exception makes sense to declare as returning
void, and meets the criteria of a const function.
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 --- Comment #9 from Harald van Dijk --- (In reply to Richard Biener from comment #8) > It has been consensus that throwing exceptions and const/pure are different > concepts that co-exist. See for example the recent discussion at > https://gcc.gnu.org/pipermail/gcc-patches/2021-May/569435.html Thanks, based on that I have created PR101376.
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409
--- Comment #10 from Richard Biener ---
(In reply to Richard Biener from comment #7)
> Jason, any idea?
diff --git a/gcc/cp/except.c b/gcc/cp/except.c
index a8cea53cf91..cbc94dff790 100644
--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -1050,7 +1050,7 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, void
* /*data*/)
if (concept_check_p (fn))
return NULL_TREE;
tree type = TREE_TYPE (fn);
- gcc_assert (INDIRECT_TYPE_P (type));
+ gcc_assert (INDIRECT_TYPE_P (type) || type == unknown_type_node);
type = TREE_TYPE (type);
STRIP_NOPS (fn);
@@ -1073,7 +1073,7 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, void
* /*data*/)
to evaluate the noexcept-specifier's operand here, but that could
cause instantiations that would fail. */
}
- if (!TYPE_NOTHROW_P (type))
+ if (type == unknown_type_node || !TYPE_NOTHROW_P (type))
return fn;
}
fixes all but the ICE for g++.dg/warn/noeffect4.C where we end up with
an invalid CALL_EXPR:
arg:0
readonly
arg:0
side-effects tree_6
fn
also notice how sizeof() doesn't have side-effects but the call has. I
suppose that's somehow an "unevaluated" sizeof() expression we don't
expect to hit expr_noexcept_p? OTOH noexcept(sizeof(foo())) might be
"valid"?
Changing the assert to if (INDIRECT_TYPE_P (type)) conditionalizing the
use of 'type' beyond of course works. Aka
diff --git a/gcc/cp/except.c b/gcc/cp/except.c
index a8cea53cf91..623b83b8dc2 100644
--- a/gcc/cp/except.c
+++ b/gcc/cp/except.c
@@ -1050,8 +1050,6 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, void
* /*data*/)
if (concept_check_p (fn))
return NULL_TREE;
tree type = TREE_TYPE (fn);
- gcc_assert (INDIRECT_TYPE_P (type));
- type = TREE_TYPE (type);
STRIP_NOPS (fn);
if (TREE_CODE (fn) == ADDR_EXPR)
@@ -1073,7 +1071,8 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, void
* /*data*/)
to evaluate the noexcept-specifier's operand here, but that could
cause instantiations that would fail. */
}
- if (!TYPE_NOTHROW_P (type))
+ if (!INDIRECT_TYPE_P (type)
+ || !TYPE_NOTHROW_P (TREE_TYPE (type)))
return fn;
}
which leaves us with
FAIL: g++.dg/warn/noeffect4.C -std=gnu++98 (test for warnings, line 84)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 84)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++17 (test for warnings, line 84)
FAIL: g++.dg/warn/noeffect4.C -std=gnu++2a (test for warnings, line 84)
not diagnosing
sizeof (x++);// { dg-warning "no effect" }
not sure what should happen to the x++ side-effect (throwing).
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374
--- Comment #3 from Richard Biener ---
The following fails with -O2 -Wall -Werror after but not before the rev. - not
sure if the reduction is otherwise sensible.
template struct reinterpret_is_a_helper {
template static T cast(U p) { return T(p); }
};
template bool is_a(U);
template T dyn_cast(U p) {
if (is_a(p))
return reinterpret_is_a_helper::cast(p);
return 0;
}
enum tree_node_structure_enum { TS_DECL_COMMON };
void contains_struct_check(int, tree_node_structure_enum, const char *, int,
const char *);
enum availability { AVAIL_NOT_AVAILABLE, AVAIL_AVAILABLE };
struct symtab_node {
symtab_node *ultimate_alias_target();
unsigned definition : 1;
unsigned in_other_partition : 1;
};
struct varpool_node : symtab_node {
availability get_availability();
varpool_node *ultimate_alias_target(symtab_node *);
unsigned : 1;
};
inline symtab_node *symtab_node::ultimate_alias_target() {
dyn_cast(this)->get_availability();
dyn_cast(this)->get_availability();
return 0;
}
inline varpool_node *varpool_node::ultimate_alias_target(symtab_node *) {
symtab_node __trans_tmp_1 = *symtab_node::ultimate_alias_target();
varpool_node *n = dyn_cast(&__trans_tmp_1);
return n;
}
availability varpool_node::get_availability() {
symtab_node ref;
if (definition && in_other_partition)
return AVAIL_NOT_AVAILABLE;
ultimate_alias_target(&ref);
contains_struct_check(0, TS_DECL_COMMON, "", 5, __FUNCTION__);
return AVAIL_AVAILABLE;
}
> /tmp/obj2/prev-gcc/cc1plus -quiet varpool.ii -O2 -Wall -Werror
In member function 'availability varpool_node::get_availability()',
inlined from 'symtab_node* symtab_node::ultimate_alias_target()' at
varpool.ii:25:51,
inlined from 'varpool_node*
varpool_node::ultimate_alias_target(symtab_node*)' at varpool.ii:30:66,
inlined from 'availability
varpool_node::_ZN12varpool_node16get_availabilityEv.part.0()' at
varpool.ii:38:24:
varpool.ii:36:18: error: array subscript 'varpool_node[0]' is partly outside
array bounds of 'varpool_node [0]' [-Werror=array-bounds]
36 | if (definition && in_other_partition)
| ~~~^
varpool.ii: In member function 'availability
varpool_node::_ZN12varpool_node16get_availabilityEv.part.0()':
varpool.ii:19:8: note: object 'varpool_node::' of size 4
19 | struct varpool_node : symtab_node {
|^~~~
In member function 'availability varpool_node::get_availability()',
inlined from 'symtab_node* symtab_node::ultimate_alias_target()' at
varpool.ii:26:51,
inlined from 'varpool_node*
varpool_node::ultimate_alias_target(symtab_node*)' at varpool.ii:30:66,
inlined from 'availability
varpool_node::_ZN12varpool_node16get_availabilityEv.part.0()' at
varpool.ii:38:24:
varpool.ii:36:18: error: array subscript 'varpool_node[0]' is partly outside
array bounds of 'varpool_node [0]' [-Werror=array-bounds]
36 | if (definition && in_other_partition)
| ~~~^
varpool.ii: In member function 'availability
varpool_node::_ZN12varpool_node16get_availabilityEv.part.0()':
varpool.ii:19:8: note: object 'varpool_node::' of size 4
19 | struct varpool_node : symtab_node {
|^~~~
cc1plus: all warnings being treated as errors
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374
--- Comment #4 from Richard Biener ---
Little bit less undefined - reconstructed the original symtab_node *ref
argument of get_availability. Maybe we're confused about the upcast to
varpool_node?
template struct reinterpret_is_a_helper {
template static T cast(U p) { return T(p); }
};
template bool is_a(U);
template T dyn_cast(U p) {
if (is_a(p))
return reinterpret_is_a_helper::cast(p);
return 0;
}
enum tree_node_structure_enum { TS_DECL_COMMON };
void contains_struct_check(int, tree_node_structure_enum, const char *, int,
const char *);
enum availability { AVAIL_NOT_AVAILABLE, AVAIL_AVAILABLE };
struct symtab_node {
symtab_node *ultimate_alias_target();
unsigned definition : 1;
unsigned in_other_partition : 1;
};
struct varpool_node : symtab_node {
availability get_availability(symtab_node *);
varpool_node *ultimate_alias_target(symtab_node *);
unsigned : 1;
};
inline symtab_node *symtab_node::ultimate_alias_target() {
dyn_cast(this)->get_availability(this);
dyn_cast(this)->get_availability(this);
return 0;
}
inline varpool_node *varpool_node::ultimate_alias_target(symtab_node *) {
symtab_node __trans_tmp_1 = *symtab_node::ultimate_alias_target();
varpool_node *n = dyn_cast(&__trans_tmp_1);
return n;
}
availability varpool_node::get_availability(symtab_node *ref) {
if (definition && in_other_partition)
return AVAIL_NOT_AVAILABLE;
ultimate_alias_target(ref);
contains_struct_check(0, TS_DECL_COMMON, "", 5, __FUNCTION__);
return AVAIL_AVAILABLE;
}
[Bug bootstrap/101372] [12 Regression] Bootstrap failure compiling gcc/cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 --- Comment #2 from Tamar Christina --- yes revering r12-2132 does indeed fix it.
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409
Richard Biener changed:
What|Removed |Added
Depends on||101087
--- Comment #11 from Richard Biener ---
(In reply to Richard Biener from comment #10)
> (In reply to Richard Biener from comment #7)
> > Jason, any idea?
...
> which leaves us with
>
> FAIL: g++.dg/warn/noeffect4.C -std=gnu++98 (test for warnings, line 84)
> FAIL: g++.dg/warn/noeffect4.C -std=gnu++14 (test for warnings, line 84)
> FAIL: g++.dg/warn/noeffect4.C -std=gnu++17 (test for warnings, line 84)
> FAIL: g++.dg/warn/noeffect4.C -std=gnu++2a (test for warnings, line 84)
>
> not diagnosing
>
> sizeof (x++);// { dg-warning "no effect" }
>
> not sure what should happen to the x++ side-effect (throwing).
Ah, that's likely PR101087
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101087
[Bug 101087] [9/10/11/12 Regression] Unevaluated operand of sizeof affects
noexcept operator
[Bug target/100637] [i386] Vectorize 4-byte vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100637 --- Comment #12 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:663a014e77709bfbd4145c605b178169eaf334fc commit r12-2136-g663a014e77709bfbd4145c605b178169eaf334fc Author: Uros Bizjak Date: Thu Jul 8 12:19:54 2021 +0200 i386: Add pack/unpack patterns for 32bit vectors [PR100637] V1SI mode shift is needed to shift 32bit operands and consequently we need to implement V1SI moves and pushes. 2021-07-08 Uroš Bizjak gcc/ PR target/100637 * config/i386/i386-expand.c (ix86_expand_sse_unpack): Handle V4QI mode. * config/i386/mmx.md (V_32): New mode iterator. (mov): Use V_32 mode iterator. (*mov_internal): Ditto. (*push2_rex64): Ditto. (*push2): Ditto. (movmisalign): Ditto. (mmx_v1si3): New insn pattern. (sse4_1_v2qiv2hi2): Ditto. (vec_unpacks_lo_v4qi): New expander. (vec_unpacks_hi_v4qi): Ditto. (vec_unpacku_lo_v4qi): Ditto. (vec_unpacku_hi_v4qi): Ditto. * config/i386/i386.h (VALID_SSE2_REG_MODE): Add V1SImode. (VALID_INT_MODE_P): Ditto.
[Bug bootstrap/101372] [12 Regression] Bootstrap failure compiling gcc/cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 Andreas Schwab changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andreas Schwab --- It's all the same. *** This bug has been marked as a duplicate of bug 101374 ***
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Andreas Schwab changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #5 from Andreas Schwab --- *** Bug 101372 has been marked as a duplicate of this bug. ***
[Bug c++/101376] Missing Wsuggest-attribute=const/Wsuggest-attribute=pure for throwing functions, wrong Wattributes for pure/const throwing functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101376 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2021-07-08 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed. Now, having EH as the only effect of a const function is of course quite some obfuscation ;) The first part is likely difficult since 'throw' appears as call to __cxa_throw () to the IPA pure/const pass plus there's a __cxa_allocate_exception call. So our present implementation of EH makes the function not actually 'const' - still a user can declare it 'const'.
[Bug tree-optimization/40210] gcc byte swap builtins inadequately optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40210
--- Comment #12 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:4c619132b3f14dc5e672a7f2f0e09cb784193559
commit r12-2137-g4c619132b3f14dc5e672a7f2f0e09cb784193559
Author: Roger Sayle
Date: Thu Jul 8 11:46:14 2021 +0100
PR tree-optimization/40210: Fold (bswap(X)>>C1)&C2 to (X>>C3)&C2 in
match.pd
All of the optimizations/transformations mentioned in bugzilla for
PR tree-optimization/40210 are already implemented in mainline GCC,
with one exception. In comment #5, there's a suggestion that
(bswap64(x)>>56)&0xff can be implemented without the bswap as
(unsigned char)x, or equivalently x&0xff.
This patch implements the above optimization, and closely related
variants. For any single bit, (bswap(X)>>C1)&1 can be simplified
to (X>>C2)&1, where bit position C2 is the appropriate permutation
of C1. Similarly, the bswap can eliminated if the desired set of
bits all lie within the same byte, hence (bswap(x)>>8)&255 can
always be optimized, as can (bswap(x)>>8)&123.
Previously,
int foo(long long x) {
return (__builtin_bswap64(x) >> 56) & 0xff;
}
compiled with -O2 to
foo:movq%rdi, %rax
bswap %rax
shrq$56, %rax
ret
with this patch, it now compiles to
foo:movzbl %dil, %eax
ret
2021-07-08 Roger Sayle
Richard Biener
gcc/ChangeLog
PR tree-optimization/40210
* match.pd (bswap optimizations): Simplify (bswap(x)>>C1)&C2 as
(x>>C3)&C2 when possible. Simplify bswap(x)>>C1 as ((T)x)>>C2
when possible. Simplify bswap(x)&C1 as (x>>C2)&C1 when 0<=C1<=255.
gcc/testsuite/ChangeLog
PR tree-optimization/40210
* gcc.dg/builtin-bswap-13.c: New test.
* gcc.dg/builtin-bswap-14.c: New test.
[Bug bootstrap/101377] New: 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Bug ID: 101377 Summary: 'exec format error' on x86_64-w64-mingw32 Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: lh_mouse at 126 dot com Target Milestone: --- Created attachment 51117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51117&action=edit bootstrap log With binutils 2.36 I get /d/lh_mouse/GitHub/MINGW-packages-dev/mingw-w64-gcc-git/src/gcc/libgomp/configure: line 4071: ./conftest.exe: cannot execute binary file: Exec format error Reverting cfc9fdcec8861be0d11ec4493cca518bf5b4c32d makes the build proceed again.
[Bug testsuite/101375] arm: Adding -mfpu=auto makes many tests unsupported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101375 --- Comment #1 from Christophe Lyon --- The same is true when targeting more "natural" options for arm-eabi: -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp/-mfpu=auto
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Keywords||build Summary|'exec format error' on |[11/12 Regression] 'exec |x86_64-w64-mingw32 |format error' on ||x86_64-w64-mingw32 Target Milestone|--- |11.2 Known to fail||11.1.1 --- Comment #1 from Richard Biener --- So it's likely the issue that mingw/cygwin do not like executables with DWARF5 debug and g:cfc9fdcec8861be0d11ec4493cca518bf5b4c32d somehow autodetects support for it in gas which then, despite GCC defaulting to DWARF4 ends up emitting DWARF5 by means of --gdwarf-5 passed to it?
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Richard Biener --- Note this should block 11.2 with a RC due in about two weeks.
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2021-07-08 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #3 from Eric Botcazou --- > So it's likely the issue that mingw/cygwin do not like executables with > DWARF5 debug and g:cfc9fdcec8861be0d11ec4493cca518bf5b4c32d somehow > autodetects support for it in gas which then, despite GCC defaulting to DWARF4 > ends up emitting DWARF5 by means of --gdwarf-5 passed to it? Binutils 2.36 should be detected as HAVE_LD_BROKEN_PE_DWARF5 by the configure script and DWARF 4 forced by: #ifdef HAVE_LD_BROKEN_PE_DWARF5 /* If the PE linker has broken DWARF 5 support, make DWARF 4 the default. */ if (TARGET_PECOFF) SET_OPTION_IF_UNSET (opts, opts_set, dwarf_version, 4); #endif so --gdwarf-5 should not be passed, but something obviously does not work. Could you post the *couple* of lines from config.log starting with: configure:30285: checking broken PE linker dwarf5 support
[Bug target/101366] memset codegen for constant sized does not use SSE instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101366 H.J. Lu changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from H.J. Lu --- Should be fixed by https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574249.html which generates: movsbl -1(%rdi), %eax pxor%xmm0, %xmm0 movd%eax, %xmm15 pshufb %xmm0, %xmm15 movups %xmm15, (%rdi) movups %xmm15, 16(%rdi) movups %xmm15, 32(%rdi) movups %xmm15, 48(%rdi) ret
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #12 from Marek Polacek --- (In reply to Richard Biener from comment #10) > (In reply to Richard Biener from comment #7) > > Jason, any idea? > > diff --git a/gcc/cp/except.c b/gcc/cp/except.c > index a8cea53cf91..cbc94dff790 100644 > --- a/gcc/cp/except.c > +++ b/gcc/cp/except.c > @@ -1050,7 +1050,7 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, > void * /*data*/) >if (concept_check_p (fn)) > return NULL_TREE; >tree type = TREE_TYPE (fn); > - gcc_assert (INDIRECT_TYPE_P (type)); > + gcc_assert (INDIRECT_TYPE_P (type) || type == unknown_type_node); >type = TREE_TYPE (type); > >STRIP_NOPS (fn); > @@ -1073,7 +1073,7 @@ check_noexcept_r (tree *tp, int * /*walk_subtrees*/, > void * /*data*/) > to evaluate the noexcept-specifier's operand here, but that > could > cause instantiations that would fail. */ > } > - if (!TYPE_NOTHROW_P (type)) > + if (type == unknown_type_node || !TYPE_NOTHROW_P (type)) > return fn; > } > > > fixes all but the ICE for g++.dg/warn/noeffect4.C where we end up with > an invalid CALL_EXPR: > > arg:0 long unsigned int> > readonly > arg:0 0x765615e8 int> > side-effects tree_6 > fn 0x766a5f18> > > > also notice how sizeof() doesn't have side-effects but the call has. I > suppose that's somehow an "unevaluated" sizeof() expression we don't > expect to hit expr_noexcept_p? OTOH noexcept(sizeof(foo())) might be > "valid"? Incidentally I just posted a patch for noexcept(sizeof(foo())) because we got the result wrong (I hadn't been aware of this PR): bug 101087. Not sure if that is going to help here, but it could.
[Bug c++/101371] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
Reduced, even g++ 7 ICEs. We only ICE with -std=c++14.
struct berry_set_CX;
template struct __array_traits { typedef berry_set_CX _Type[_Nm]; };
template struct array {
typename __array_traits<_Nm>::_Type _M_elems;
};
struct _Base_bitset {
long _M_w;
};
struct berry_set_CX {
_Base_bitset bset;
constexpr berry_set_CX() : bset() {}
constexpr berry_set_CX(berry_set_CX &rhs) : bset(rhs.bset) {}
};
struct bersets_by_citrus_CX {
array<8> berrysets;
};
struct entree0_CX {
constexpr entree0_CX(bersets_by_citrus_CX) {}
};
struct berrybox_CX {
constexpr entree0_CX make_entree() const {
bersets_by_citrus_CX bsbc{};
return bsbc;
}
berrybox_CX(berry_set_CX);
};
void init() {
berry_set_CX fixed;
berrybox_CX nu_cs0(fixed);
entree0_CX pas = nu_cs0.make_entree();
}
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 --- Comment #13 from Jason Merrill --- (In reply to Richard Biener from comment #3) > - if (! TREE_SIDE_EFFECTS (expr)) > + if (! TREE_SIDE_EFFECTS (expr) && expr_noexcept_p (expr, 0)) > expr = void_node; The assumption that an expression with TREE_SIDE_EFFECTS unset can be discarded if its value is not used is made throughout the compiler. Abandoning that invariant seems like a bad idea. And changing from checking a flag to walking through the whole expression in all of those places sounds like an algorithmic complexity problem. If a pure/const function can throw, fine. But that shouldn't affect how optimization treats the function call, or we'll end up pessimizing the vast majority of calls to pure/const functions that don't throw (but are not explicitly declared noexcept). In this testcase, if the user doesn't want the compiler to optimize away a call to foo(), they shouldn't mark it pure.
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #4 from Liu Hao --- configure said 'yes' for 'broken dwarf5 support'. I am not quite clear whether this means whether it is broken or not (but I suspect yes): ``` configure:29798: checking linker PT_GNU_EH_FRAME support configure:29829: result: no configure:29832: checking linker CIEv3 in .eh_frame support configure:29869: result: yes configure:29872: checking linker position independent executable support configure:29913: result: yes configure:29916: checking linker PIE support with copy reloc configure:29965: result: no configure:29968: checking linker EH-compatible garbage collection of sections configure:30048: result: no configure:30051: checking linker EH garbage collection of sections bug configure:30095: result: no configure:30098: checking linker for compressed debug sections configure:30158: result: 3 configure:30228: checking broken PE linker dwarf5 support configure:30249: result: yes configure:30258: checking linker --as-needed support configure:30319: result: yes ``` This macro was also defined: ``` | #define HAVE_LD_BROKEN_PE_DWARF5 1 ```
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 --- Comment #14 from Richard Biener --- (In reply to Jason Merrill from comment #13) > (In reply to Richard Biener from comment #3) > > - if (! TREE_SIDE_EFFECTS (expr)) > > + if (! TREE_SIDE_EFFECTS (expr) && expr_noexcept_p (expr, 0)) > > expr = void_node; > > The assumption that an expression with TREE_SIDE_EFFECTS unset can be > discarded if its value is not used is made throughout the compiler. > Abandoning that invariant seems like a bad idea. And changing from checking > a flag to walking through the whole expression in all of those places sounds > like an algorithmic complexity problem. > > If a pure/const function can throw, fine. But that shouldn't affect how > optimization treats the function call, or we'll end up pessimizing the vast > majority of calls to pure/const functions that don't throw (but are not > explicitly declared noexcept). In this testcase, if the user doesn't want > the compiler to optimize away a call to foo(), they shouldn't mark it pure. Hmm, fair enough. Does that mean C++ should default to -fdelete-dead-exceptions? Elsewhere it's said that TREE_SIDE_EFFECTS, const/pure and EH are orthogonal concepts but yes, that we have to walk expressions recursively to figure nothrow sucks. Though the convert_to_void "optimization" could be seen as premature, on GIMPLE there's no recursive walking needed and nothrow discovery should discover nothrow-ness of most small functions that have the body available - so the other option I considered was to remove that optimization. Now, this C++ decision makes my life a bit harder (writing testcases for the middle-end issues around throwing pure/const functions).
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 Richard Biener changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #2 from Richard Biener --- Eric, is it possible to write an equivalent testcase in Ada? I don't seem to get any progress with the C++ FE miscompiling this from the start (PR100409) but I do have a patch for this issue (but I don't want to fix it without adding a testcase).
[Bug debug/101378] New: Negative DW_AT_data_member_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378
Bug ID: 101378
Summary: Negative DW_AT_data_member_location
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: simon.marchi at polymtl dot ca
Target Milestone: ---
I'm at 1ca642d785c49e9e0b28651b190720267703f023 (current master).
$ cat test.cpp
#include
int main() {
std::unique_ptr p(new int);
return 0;
}
$ /opt/gcc/git/bin/g++ test.cpp -g3 -O0
$ readelf --debug-dump a.out
...
<3><968>: Abbrev Number: 79 (DW_TAG_member)
<969> DW_AT_name: (indirect string, offset: 0xc214): _M_head_impl
<96d> DW_AT_decl_file : 4
<96e> DW_AT_decl_line : 125
<96f> DW_AT_decl_column : 39
<970> DW_AT_type: <0x67e>
<974> DW_AT_data_member_location: -1
...
The -1 DW_AT_data_member_location value looks wrong. Previous gcc versions
would say 0, which makes more sense. It doesn't seem to change anything
whether I use DWARF 4 or 5.
Related GDB bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28063
[Bug c++/101371] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371 --- Comment #3 from Marek Polacek --- The ICE started with r247813.
[Bug tree-optimization/101379] New: libatomic build failure on arm after r12-2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Bug ID: 101379 Summary: libatomic build failure on arm after r12-2132 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- After r12-2132, I've noticed a build failure in libatomic for arm. It can be reproduced with --target arm-linux-gnueabi (not with arm-eabi): In file included from /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/arm/host-config.h:4, from /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/libatomic_i.h:232, from /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c:25: /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c: In function 'libat_store': /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/linux/arm/host-config.h:42:34: error: array subscript 0 is outside array bounds of 'unsigned int[0]' [-Werror=array-bounds] 42 | #define __kernel_helper_version (*(unsigned int *)0x0ffc) | ~^~~~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/linux/arm/host-config.h:104:26: note: in expansion of macro '__kernel_helper_version' 104 | # define IFUNC_COND_2 (__kernel_helper_version >= 5) | ^~~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/linux/arm/host-config.h:169:57: note: in expansion of macro 'IFUNC_COND_2' 169 | # define MAYBE_HAVE_ATOMIC_CAS_8(IFUNC_COND_1 | IFUNC_COND_2) | ^~~~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/libatomic_i.h:40:25: note: in expansion of macro 'MAYBE_HAVE_ATOMIC_CAS_8' 40 | #define C2_(X,Y)X ## Y | ^ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/libatomic_i.h:41:25: note: in expansion of macro 'C2_' 41 | #define C2(X,Y) C2_(X,Y) | ^~~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c:58:10: note: in expansion of macro 'C2' 58 | if (!C2(MAYBE_HAVE_ATOMIC_CAS_,N)) break; \ | ^~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c:95:25: note: in expansion of macro 'LARGER' 95 | case 5 ... 7: L8: LARGER(8); /* FALLTHRU */ | ^~ cc1: all warnings being treated as errors make[4]: *** [Makefile:586: gstore.lo] Error 1
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Andreas Schwab changed: What|Removed |Added Target|x86_64-*-* | --- Comment #6 from Andreas Schwab --- Broken everywhere.
[Bug tree-optimization/101379] libatomic build failure on arm after r12-2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Andreas Schwab changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andreas Schwab --- dup *** This bug has been marked as a duplicate of bug 101374 ***
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Andreas Schwab changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #7 from Andreas Schwab --- *** Bug 101379 has been marked as a duplicate of this bug. ***
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Last reconfirmed||2021-07-08 --- Comment #8 from Martin Sebor --- Thanks for the reduced test case!
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #5 from Eric Botcazou --- > configure said 'yes' for 'broken dwarf5 support'. I am not quite clear > whether this means whether it is broken or not (but I suspect yes): Yes, it's indeed broken as expected. Out of curiosity, can you attach this config.log file as well?
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #6 from Liu Hao --- Created attachment 51118 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51118&action=edit gzip'd gcc/config.log Of course.
[Bug sanitizer/101380] New: Segmentation fault in __asan_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101380
Bug ID: 101380
Summary: Segmentation fault in __asan_init
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: puspmvqyfzxrbytwsu at niwghx dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
/* testcase.c */
int main()
{
}
/* end of source */
When compiling with the command line
gcc -no-pie -fsanitize=address testcase.c
the output file a.out contains a bug causing it to sometimes crash on startup
(pre-main) with a segmentation fault. This segmentation fault is not handled by
the address sanitizer, but gives the default segmentation fault
message.
According to my testing with ltrace, the segmentation fault seems to be caused
in __asan_init:
/* ltrace ./a.out */
__asan_init(1, 0x72a9c5ef89c8, 0x72a9c5ef89d8, 0x61d7e2856060
--- SIGSEGV (Segmentation fault) ---
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++
/* end of ltrace */
/* gcc -v -no-pie -fsanitize=address testcase.c */
Es werden eingebaute Spezifikationen verwendet.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread-Modell: posix
Unterstützte LTO-Kompressionsalgorithmen: zlib zstd
gcc-Version 11.1.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-no-pie' '-fsanitize=address' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/cc1 -quiet -v testcase.c -quiet
-dumpdir a- -dumpbase testcase.c -dumpbase-ext .c -mtune=generic -march=x86-64
-version -fsanitize=address -o /tmp/ccUMl4NV.s
GNU C17 (GCC) Version 11.1.0 (x86_64-pc-linux-gnu)
kompiliert von GNU-C-Version 11.1.0, GMP Version 6.2.1, MPFR Version 4.1.0,
MPC Version 1.2.1. isl Versiom isl-0.24-GMP
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
nicht vorhandenes Verzeichnis
»/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/include«
wird ignoriert
Suche für »#include "..."« beginnt hier:
Suche für »#include <...>« beginnt hier:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include
/usr/local/include
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include-fixed
/usr/include
Ende der Suchliste.
GNU C17 (GCC) Version 11.1.0 (x86_64-pc-linux-gnu)
kompiliert von GNU-C-Version 11.1.0, GMP Version 6.2.1, MPFR Version 4.1.0,
MPC Version 1.2.1. isl Versiom isl-0.24-GMP
GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3d0ac5c030c008e73f10e8b66957dbfa
COLLECT_GCC_OPTIONS='-v' '-no-pie' '-fsanitize=address' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a-'
as -v --64 -o /tmp/ccPP003Z.o /tmp/ccUMl4NV.s
GNU assembler version 2.36.1 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.36.1
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-no-pie' '-fsanitize=address' '-mtune=generic'
'-march=x86-64' '-dumpdir' 'a.'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccy5uDZk.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/crt1.o
/usr/lib/gcc/x86_64-pc-
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 --- Comment #15 from Jason Merrill --- (In reply to Richard Biener from comment #14) > Does that mean C++ should default to -fdelete-dead-exceptions? That makes sense. The C++ standard has nothing to say about this, since pure/const are extensions. And throwing an exception from a signal handler is undefined behavior.
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #7 from Eric Botcazou --- > Of course. Thanks. There are weird things in the log, for example: configure:29292: checking assembler for assembly of compiler generated 64-bit .debug_line configure:29306: /mingw64/x86_64-w64-mingw32/bin/as-o conftest.o conftest.s >&5 conftest.s: Assembler messages: conftest.s:17: Error: unknown pseudo-op: `.4byte' conftest.s:18: Error: unknown pseudo-op: `.2byte' conftest.s:19: Error: unknown pseudo-op: `.4byte' conftest.s:26: Error: unknown pseudo-op: `.8byte' .2byte/.4byte/.8byte are supposed to be supported by binutils 2.36. Can you post the output of /mingw64/x86_64-w64-mingw32/bin/as --version?
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #8 from LIU Hao --- lh_mouse@lhmouse-pc ~ $ /mingw64/x86_64-w64-mingw32/bin/as --version GNU assembler (GNU Binutils) 2.36.1 Copyright (C) 2021 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-w64-mingw32'.
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374
--- Comment #9 from Martin Sebor ---
For the test case the warning sees this:
int varpool_node::_ZN12varpool_node16get_availabilityEv.part.0 (struct
varpool_node * const this)
{
...
struct symtab_node * _7;
struct varpool_node * _12;
...
[local count: 1073741824]:
_7 = &this_1(D)->D.2395;<<< varpool_node::symtab_node subobject
_11 = is_a (_7);
if (_11 != 0)
goto ; [71.00%]
else
goto ; [29.00%]
[local count: 311385128]:
[local count: 1073741824]:
# _12 = PHI <_7(2), 0B(3)> <<< _12 size is (at most) 4
_15 = BIT_FIELD_REF <*_12, 8, 0>; <<< -Warray-bounds
The MEM_REF *_12 accesses a varpool_node object with size 8 but _12 points to a
symtab_node subobject with size of just 4. So the warning code works
correctly. It triggers because the call to compute_objsize(..., 1, ...) (with
Object Size Type 1) respects subobject boundaries and so doesn't consider that
_12, or more precisely _7, points to a subobject of a larger object. Before
r12-2132 -Warray-bounds did its own slightly more conservative computation
which was roughly equivalent to Object Size Type 0.
Calling compute_objsize(..., 0, ...) instead avoids the warning for the reduced
test case. Let me see if it also fixes the rest of the problems.
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #9 from Eric Botcazou --- > lh_mouse@lhmouse-pc ~ $ /mingw64/x86_64-w64-mingw32/bin/as --version > GNU assembler (GNU Binutils) 2.36.1 > Copyright (C) 2021 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or later. > This program has absolutely no warranty. > This assembler was configured for a target of `x86_64-w64-mingw32'. Thanks. So I was confused and 2.36 indeed rejects the directive on Windows, you need the upcoming 2.37 to accept them. In any case, I can reproduce the problem with a cross-compiler.
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #10 from Eric Botcazou --- Fixing.
[Bug bootstrap/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #11 from Eric Botcazou --- Created attachment 51119 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51119&action=edit Tentative fix This is a minimal fix to restore the previous state on Windows (I don't think that a more complete fix is worth the hassle since binutils 2.37 supports DWARF 5).
[Bug bootstrap/101369] Bootstrap failure of gcc-12-20210704 on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101369 --- Comment #4 from James McKelvey --- Probably duplicate of 101377 for 11.1.1. I see error for 11 and 12.
[Bug target/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #12 from LIU Hao --- I will try rebuilding tomorrow (~11hrs later).
[Bug c++/57314] [Core/1635] default template arguments for member template functions of class templates are instantiated before allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57314 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org CC||mpolacek at gcc dot gnu.org Status|SUSPENDED |ASSIGNED --- Comment #3 from Marek Polacek --- I think this is resolved by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1787r6.html -- in C++23, template default arguments are a complete-class context. Will try to implement this in GCC 12.
[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #1 from Marek Polacek ---
(In reply to Jason Merrill from comment #0)
> The changes from this paper should not affect a significant amount of code;
> many are clarifications that bring the wording in line with existing
> practice, some are clarifications of corner cases that most code doesn't
> depend on, like ambiguous lookup within a conversion-type-id.
>
> A few changes that allow code that has been ill-formed:
>
> conversion-type-id is added to the list of type-only contexts from P0634:
>
> template struct A { operator T::type(); }; // OK
This already works; I fixed it via DR 2413 in GCC 10.
> ::template is also not required in type-only contexts:
>
> template auto f(T t) { return static_cast>(t); } // OK
This needs to be implemented, but it's in the spirit of P0634 which I
implemented. Strongly related to DR 1478.
It's also reminiscent of CWG 96 which is assigned to me.
> Default template arguments are now complete-class contexts, like default
> function arguments:
>
> template struct A {
> template void g() { } // OK
> T t;
> };
This is DR 1635 / bug 57314.
Since I've dealt with deferred parsing quite often recently (in the context of
deferred noexcept parsing), I might as well tackle this one too. My hope is
that the very same trick of stashing the tokens and then reparsing them at the
end of the class will work here too. This will probably need some kind of
tparm -> defarg mapping.
So it looks like I'm in a position to fix at least parts of this proposal, thus
mine for now.
A question worth considering is whether we only want to allow the code in
C++23, or whether we really want to treat those issues as DRs, and so allow the
code in previous modes. P0634 is only enabled in C++20, so it makes the best
sense to me to only allow the above in C++23.
[Bug debug/101378] Negative DW_AT_data_member_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378 --- Comment #1 from Simon Marchi --- I bisected, it started with: libstdc++: Remove inheritance from elements in std::tuple 91e6226f880b048275a7ceedef716e159c7cefd9 So it's likely related to the use of [[no_unique_address]]. Relevant thread on dwarf-discuss: http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2021-June/004825.html
[Bug middle-end/33699] [9/10/11/12 regression] missing optimization on const addr area store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699 Michael Meissner changed: What|Removed |Added CC||meissner at gcc dot gnu.org --- Comment #32 from Michael Meissner --- I looked at adding the following powerpc patch that was proposed in March, 2021: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566744.html There are two parts to the patch, that are sort of unrelated. The first part is to add minimum and maximum section anchor offset values and use -fsection anchors. I ran a spec 2017 benchmark on a pre-production power10 system, comparing my normal run times to run times with -fsection-anchors and setting the minimum/maximum section anchor offsets. Two benchmarks improved and two benchmarks regressed: xalancbmk_r: 1.75% regression cactuBSSN_r: 4.24% improvement blender_r: 1.92% regression roms_r: 1.05% improvement I then built spec 2017 with just the part of setting const_anchor, but not the section anchor minimum/maximum offsets. Eight benchmarks did not build due to assertion failures in cse.c: gcc_r exchange2_r cactuBSSN_r wrf_r blender_r cam4_r fotonik3d_r roms_r If I specify the section anchor minimum/maximum offsets, add -fsection-anchors, and set the const_anchor, all 23 INT+FP benchmarks build, but WRF_R does not run correctly. So without more debugging, I don't recommend setting const_anchor. It is probably useful to set the minimum/maximum section anchor offsets in case people use -fsection-anchors. As an aside, if we wanted to accept using constant addresses in the PowerPC, we would need to recognize a constant address as being legitimate. This may be useful in some embedded environments where you have devices at certain memory locations. But somebody would need to add the support.
[Bug target/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #13 from Eric Botcazou --- > I will try rebuilding tomorrow (~11hrs later). OK, thanks in advance.
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:9bf9f27ac6db4823628c435da9b242fd82bf8d68 commit r12-2171-g9bf9f27ac6db4823628c435da9b242fd82bf8d68 Author: Martin Sebor Date: Thu Jul 8 11:34:27 2021 -0600 Use Object Size Type zero for -Warray-bounds [PR101374]. Resolves: PR bootstrap/101374 - -Warray-bounds accessing a member subobject as derived gcc/cp/ChangeLog: PR bootstrap/101374 * module.cc (module_state::read_macro_maps): Temporarily disable -Warray-bounds. (module_state::install_macros): Same. gcc/ChangeLog: PR bootstrap/101374 * gimple-array-bounds.cc (array_bounds_checker::check_mem_ref): Use Object Size Type 0 instead of 1. gcc/testsuite/ChangeLog: PR bootstrap/101374 * c-c++-common/Warray-bounds-3.c: Xfail assertion. * c-c++-common/Warray-bounds-4.c: Same.
[Bug ipa/101066] [10/11/12 Regression] Wrong code after fixup_cfg3 since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:763121ccd908f52bc666f277ea2cf42110b3aad9 commit r12-2172-g763121ccd908f52bc666f277ea2cf42110b3aad9 Author: Martin Jambor Date: Thu Jul 8 19:44:41 2021 +0200 ipa-sra: Fix thinko when overriding safe_to_import_accesses (PR 101066) The "new" IPA-SRA has a more difficult job than the previous not-truly-IPA version when identifying situations in which a parameter passed by reference can be passed into a third function and only thee converted to one passed by value (and possibly "split" at the same time). In order to allow this, two conditions must be fulfilled. First the call to the third function must happen before any modifications of memory, because it could change the value passed by reference. Second, in order to make sure we do not introduce new (invalid) dereferences, the call must postdominate the entry BB. The second condition is actually not necessary if the caller function is also certain to dereference the pointer but the first one must still hold. Unfortunately, the code making this overriding decision also happen to trigger when the first condition is not fulfilled. This is fixed in the following patch. gcc/ChangeLog: 2021-06-16 Martin Jambor PR ipa/101066 * ipa-sra.c (class isra_call_summary): New member m_before_any_store, initialize it in the constructor. (isra_call_summary::dump): Dump the new field. (ipa_sra_call_summaries::duplicate): Copy it. (process_scan_results): Set it. (isra_write_edge_summary): Stream it. (isra_read_edge_summary): Likewise. (param_splitting_across_edge): Only override safe_to_import_accesses if m_before_any_store is set. gcc/testsuite/ChangeLog: 2021-06-16 Martin Jambor PR ipa/101066 * gcc.dg/ipa/pr101066.c: New test.
[Bug bootstrap/101369] Bootstrap failure of gcc-12-20210704 on Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101369 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- (In reply to James McKelvey from comment #4) > Probably duplicate of 101377 for 11.1.1. I see error for 11 and 12. It is the same for both. *** This bug has been marked as a duplicate of bug 101377 ***
[Bug target/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Andrew Pinski changed: What|Removed |Added CC||mckelvey at maskull dot com --- Comment #14 from Andrew Pinski --- *** Bug 101369 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/55278] [9/10/11/12 Regression] Botan performance regressions, other compilers generate better code than gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55278 --- Comment #28 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #12) > (force gcc to avoid xorw memory, %hireg and instead use movzwl memory, > %sireg; ... xorl %sireg, %sireg2) and p2 was something similar for *xorqi_1. > > Looking at icc generated assembly, it is interesting to see that the only > HImode instructions it ever uses are rolw and movw stores, for everything > else it uses > movzwl loads and SImode arithmetics (well, I guess shift right > shrw/sarw/rorw can't be avoided either). Similarly, icc on the testcase > doesn't emit any QImode instructions at all, while gcc emits tons of them > and llvm something in between. -mtune-ctrl=^himode_math,^qimode_math will eliminate all HImode and QImode arithmetics.
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #11 from Martin Sebor --- r12-2171 unblocks bootstrap on x86_64. I'll leave this open in case there's still more fallout. Go currently doesn't bootstrap due to a valid -Warray-bounds triggered also by r12-2132. I sent the patch below to Ian: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574752.html
[Bug libfortran/101305] Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h and CFI_establish
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101305 sandra at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |sandra at gcc dot gnu.org --- Comment #2 from sandra at gcc dot gnu.org --- I'm working on patches for this.
[Bug tree-optimization/101379] libatomic build failure on arm after r12-2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Martin Sebor changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #2 from Martin Sebor --- This is not a duplicate of pr101374. Constant addresses are often the result of null pointer arithmetic and not considered valid (point to an object of zero size). When they're deliberate the code needs to suppress the warning somehow. It can be done via #pragma GCC diagnostic or by making the pointer variable volatile (or otherwise obscuring its constness).
[Bug bootstrap/101372] [12 Regression] Bootstrap failure compiling gcc/cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Resolution|DUPLICATE |--- Ever confirmed|0 |1 Keywords||diagnostic Last reconfirmed||2021-07-08 Status|RESOLVED|ASSIGNED --- Comment #4 from Martin Sebor --- I have fixed these instances in r12-2171 but I don't think the root cause is the same as the warnings noted in pr101374. Let me use this bug to track the analysis and the right fix in case the suppression is not appropriate.
[Bug go/101246] gccgo cross-compiler targeting arm fails to build with gcc 11. Missing structs in runtime.inc. Using uclibc-ng
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101246 --- Comment #5 from Lance Fredrickson --- Just to check another architecture, I tried building gccgo-11 for x86_64 and uclibc-ng. With gcc-11 I get the same build-time error with x86_64 as I did with arm. gccgo-10 for x86_64 & uclibc-ng did build, but when compiling a simple program I get a few undefined errors I don't have with arm. undefined reference to `__wrap_pthread_create' undefined reference to `__morestack_block_signals' undefined reference to `__generic_morestack' undefined reference to `__morestack_unblock_signals' Probably needs to be its own bug report. Not sure if gcc-10 will see more releases, but I would guess it would still be present in gcc-11 if it built. I hope uclibc-ng still gets some love from gcc and is supported. It plays nice with old kernels, has more supported targets, and is still actively developed.
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 --- Comment #12 from Peter Bergner --- (In reply to Martin Sebor from comment #11) > r12-2171 unblocks bootstrap on x86_64. My bootstrap on powerpc64le-linux completes now too.
[Bug testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 Patrick McGehearty changed: What|Removed |Added CC||patrick.mcgehearty at oracle dot c ||om --- Comment #1 from Patrick McGehearty --- I identified the root cause as not fully understanding the IBM native format. The gcc internal representation uses KF mode for IBM 128-bit floating point. It uses DF mode for all 64-bit floating point. When KF mode is used, the value for LDBL_EPSILON is 0x1.0p-1074 and RMINSCAL= 1/LDBL_EPSILON is infinity. Then all input values which trigger scaling will overflow to infinity which of course fails the test. Switching the constants to use DF instead of KF resolves the overflow issue without significantly changing the usefulness of the new method. That's because DF and KF mode use the same number of bits for the exponent, allowing MAX and MIN to be nearly identical. The patch is being submitted to gcc-patc...@gcc.gnu.org now. The fix only requires changes to one file: libgcc/config/rs6000/_divkc3.c diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c index a1d29d2..2b229c8 100644 --- a/libgcc/config/rs6000/_divkc3.c +++ b/libgcc/config/rs6000/_divkc3.c @@ -38,10 +38,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If not, see #endif #ifndef __LONG_DOUBLE_IEEE128__ -#define RBIG (__LIBGCC_KF_MAX__ / 2) -#define RMIN (__LIBGCC_KF_MIN__) -#define RMIN2 (__LIBGCC_KF_EPSILON__) -#define RMINSCAL (1 / __LIBGCC_KF_EPSILON__) +#define RBIG (__LIBGCC_DF_MAX__ / 2) +#define RMIN (__LIBGCC_DF_MIN__) +#define RMIN2 (__LIBGCC_DF_EPSILON__) +#define RMINSCAL (1 / __LIBGCC_DF_EPSILON__) #define RMAX2 (RBIG * RMIN2) #else #define RBIG (__LIBGCC_TF_MAX__ / 2)
[Bug c++/101087] [9/10/11/12 Regression] Unevaluated operand of sizeof affects noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101087 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:dee00bf6894be0cabb8f263c993357a6f8444f8b commit r12-2174-gdee00bf6894be0cabb8f263c993357a6f8444f8b Author: Marek Polacek Date: Wed Jul 7 20:02:18 2021 -0400 c++: Fix noexcept with unevaluated operand [PR101087] It sounds plausible that this assert int f(); static_assert(noexcept(sizeof(f(; should pass: sizeof produces a std::size_t and its operand is not evaluated, so it can't throw. noexcept should only evaluate to false for potentially evaluated operands. Therefore I think that check_noexcept_r shouldn't walk into operands of sizeof/decltype/ alignof/typeof. PR c++/101087 gcc/cp/ChangeLog: * cp-tree.h (unevaluated_p): New. * except.c (check_noexcept_r): Use it. Don't walk into unevaluated operands. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept70.C: New test.
[Bug c++/101087] [9/10/11/12 Regression] Unevaluated operand of sizeof affects noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101087 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:cbef732522568f8adce46c472b16391c864d0fd0 commit r11-8709-gcbef732522568f8adce46c472b16391c864d0fd0 Author: Marek Polacek Date: Wed Jul 7 20:02:18 2021 -0400 c++: Fix noexcept with unevaluated operand [PR101087] It sounds plausible that this assert int f(); static_assert(noexcept(sizeof(f(; should pass: sizeof produces a std::size_t and its operand is not evaluated, so it can't throw. noexcept should only evaluate to false for potentially evaluated operands. Therefore I think that check_noexcept_r shouldn't walk into operands of sizeof/decltype/ alignof/typeof. PR c++/101087 gcc/cp/ChangeLog: * cp-tree.h (unevaluated_p): New. * except.c (check_noexcept_r): Use it. Don't walk into unevaluated operands. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept70.C: New test. (cherry picked from commit dee00bf6894be0cabb8f263c993357a6f8444f8b)
[Bug c++/101315] C++20 lambdas in unevaluated context: erroneously fails with "incomplete type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101315 --- Comment #1 from janpmoeller at gmx dot de --- Just for reference, the clang bug report is https://bugs.llvm.org/show_bug.cgi?id=51032.
[Bug c++/101087] [9/10/11/12 Regression] Unevaluated operand of sizeof affects noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101087 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:879e7df182910886789aaac493efb0bc31ab0982 commit r10-9972-g879e7df182910886789aaac493efb0bc31ab0982 Author: Marek Polacek Date: Wed Jul 7 20:02:18 2021 -0400 c++: Fix noexcept with unevaluated operand [PR101087] It sounds plausible that this assert int f(); static_assert(noexcept(sizeof(f(; should pass: sizeof produces a std::size_t and its operand is not evaluated, so it can't throw. noexcept should only evaluate to false for potentially evaluated operands. Therefore I think that check_noexcept_r shouldn't walk into operands of sizeof/decltype/ alignof/typeof. PR c++/101087 gcc/cp/ChangeLog: * cp-tree.h (unevaluated_p): New. * except.c (check_noexcept_r): Use it. Don't walk into unevaluated operands. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept70.C: New test. (cherry picked from commit cbef732522568f8adce46c472b16391c864d0fd0)
[Bug c++/101087] [9 Regression] Unevaluated operand of sizeof affects noexcept operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101087 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Summary|[9/10/11/12 Regression] |[9 Regression] Unevaluated |Unevaluated operand of |operand of sizeof affects |sizeof affects noexcept |noexcept operator |operator| Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed in GCC 10+.
[Bug c++/100409] C++ FE elides pure throwing call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409 Bug 100409 depends on bug 101087, which changed state. Bug 101087 Summary: [9 Regression] Unevaluated operand of sizeof affects noexcept operator https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101087 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug testsuite/100451] g++.dg/warn/Warray-bounds-20.C XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:c232f07b931e3e4cb7cbd96e47b161f1c390f21d commit r12-2176-gc232f07b931e3e4cb7cbd96e47b161f1c390f21d Author: Martin Sebor Date: Thu Jul 8 16:08:20 2021 -0600 Adjust expected output for LP32 [PR100451]. gcc/testsuite/ChangeLog: PR testsuite/100451 * g++.dg/warn/Warray-bounds-20.C: Adjust expected output for LP32.
[Bug testsuite/100451] g++.dg/warn/Warray-bounds-20.C XPASSes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-7-8 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Fixed.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 100451, which changed state. Bug 100451 Summary: g++.dg/warn/Warray-bounds-20.C XPASSes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100451 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 --- Comment #13 from Martin Sebor --- Thanks for the confirmation!
[Bug bootstrap/101372] [12 Regression] Bootstrap failure compiling gcc/cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 --- Comment #5 from Segher Boessenkool --- On powerpc64-linux the failure is In file included from /home/segher/src/gcc/gcc/c-family/c-common.h:26, from /home/segher/src/gcc/gcc/cp/cp-tree.h:40, from /home/segher/src/gcc/gcc/cp/module.cc:209: In function 'tree_node* identifier(const cpp_hashnode*)', inlined from 'bool module_state::read_macro_maps()' at /home/segher/src/gcc/gcc/cp/module.cc:16305:10: /home/segher/src/gcc/gcc/tree.h:1089:58: error: array subscript -1 is outside array bounds of 'cpp_hashnode [288230376151711743]' [-Werror=array-bounds] 1089 | ((tree) ((char *) (NODE) - sizeof (struct tree_common))) | ^ /home/segher/src/gcc/gcc/cp/module.cc:277:10: note: in expansion of macro 'HT_IDENT_TO_GCC_IDENT' 277 | return HT_IDENT_TO_GCC_IDENT (HT_NODE (const_cast (node))); | ^ In file included from /home/segher/src/gcc/gcc/tree.h:23, from /home/segher/src/gcc/gcc/c-family/c-common.h:26, from /home/segher/src/gcc/gcc/cp/cp-tree.h:40, from /home/segher/src/gcc/gcc/cp/module.cc:209: /home/segher/src/gcc/gcc/tree-core.h: In member function 'bool module_state::read_macro_maps()': /home/segher/src/gcc/gcc/tree-core.h:1445:24: note: at offset -24 into object 'tree_identifier::id' of size 16 1445 | struct ht_identifier id; |^~ In file included from /home/segher/src/gcc/gcc/c-family/c-common.h:26, from /home/segher/src/gcc/gcc/cp/cp-tree.h:40, from /home/segher/src/gcc/gcc/cp/module.cc:209: In function 'tree_node* identifier(const cpp_hashnode*)', inlined from 'void module_state::install_macros()' at /home/segher/src/gcc/gcc/cp/module.cc:16915:10: /home/segher/src/gcc/gcc/tree.h:1089:58: error: array subscript -1 is outside array bounds of 'cpp_hashnode [288230376151711743]' [-Werror=array-bounds] 1089 | ((tree) ((char *) (NODE) - sizeof (struct tree_common))) | ^ /home/segher/src/gcc/gcc/cp/module.cc:277:10: note: in expansion of macro 'HT_IDENT_TO_GCC_IDENT' 277 | return HT_IDENT_TO_GCC_IDENT (HT_NODE (const_cast (node))); | ^ In file included from /home/segher/src/gcc/gcc/tree.h:23, from /home/segher/src/gcc/gcc/c-family/c-common.h:26, from /home/segher/src/gcc/gcc/cp/cp-tree.h:40, from /home/segher/src/gcc/gcc/cp/module.cc:209: /home/segher/src/gcc/gcc/tree-core.h: In member function 'void module_state::install_macros()': /home/segher/src/gcc/gcc/tree-core.h:1445:24: note: at offset -24 into object 'tree_identifier::id' of size 16 1445 | struct ht_identifier id; |^~ In file included from /home/segher/src/gcc/gcc/c-family/c-common.h:26, from /home/segher/src/gcc/gcc/cp/cp-tree.h:40, from /home/segher/src/gcc/gcc/cp/module.cc:209: In function 'tree_node* identifier(const cpp_hashnode*)', inlined from 'void module_state::install_macros()' at /home/segher/src/gcc/gcc/cp/module.cc:16933:16: /home/segher/src/gcc/gcc/tree.h:1089:58: error: array subscript -1 is outside array bounds of 'cpp_hashnode [288230376151711743]' [-Werror=array-bounds] 1089 | ((tree) ((char *) (NODE) - sizeof (struct tree_common))) | ^ /home/segher/src/gcc/gcc/cp/module.cc:277:10: note: in expansion of macro 'HT_IDENT_TO_GCC_IDENT' 277 | return HT_IDENT_TO_GCC_IDENT (HT_NODE (const_cast (node))); | ^ In file included from /home/segher/src/gcc/gcc/tree.h:23, from /home/segher/src/gcc/gcc/c-family/c-common.h:26, from /home/segher/src/gcc/gcc/cp/cp-tree.h:40, from /home/segher/src/gcc/gcc/cp/module.cc:209: /home/segher/src/gcc/gcc/tree-core.h: In member function 'void module_state::install_macros()': /home/segher/src/gcc/gcc/tree-core.h:1445:24: note: at offset -24 into object 'tree_identifier::id' of size 16 1445 | struct ht_identifier id; |^~ cc1plus: all warnings being treated as errors
[Bug tree-optimization/101379] libatomic build failure on arm after r12-2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
--- Comment #3 from Martin Sebor ---
Christophe, does this patch work for you? Another alternative is to add
#pragma GCC diagnostic ignored around the dereference.
diff --git a/libatomic/config/linux/arm/host-config.h
b/libatomic/config/linux/arm/host-config.h
index 1520f237d73..f866b8a1160 100644
--- a/libatomic/config/linux/arm/host-config.h
+++ b/libatomic/config/linux/arm/host-config.h
@@ -39,8 +39,12 @@ typedef void (__kernel_dmb_t) (void);
#define __kernel_dmb (*(__kernel_dmb_t *) 0x0fa0)
/* Kernel helper page version number. */
-#define __kernel_helper_version (*(unsigned int *)0x0ffc)
-
+static inline unsigned
+__kernel_helper_version ()
+{
+ const unsigned *volatile addr = (unsigned int *)0x0ffc;
+ return *addr;
+}
#ifndef HAVE_STREX
static inline bool
[Bug bootstrap/101372] [12 Regression] Bootstrap failure compiling gcc/cp/module.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:79d3378c7d73814442eb468c562ab8aa572f9c43 commit r12-2178-g79d3378c7d73814442eb468c562ab8aa572f9c43 Author: Martin Sebor Date: Thu Jul 8 16:36:15 2021 -0600 Move warning suppression to the ultimate callee. Resolves: PR bootstrap/101372 - -Warray-bounds in gcc/cp/module.cc causing bootstrap failure gcc/cp/ChangeLog: PR bootstrap/101372 * module.cc (identifier): Suppress warning. (module_state::read_macro_maps): Remove warning suppression. (module_state::install_macros): Ditto.
[Bug bootstrap/101372] [12 Regression] -Warray-bounds in gcc/cp/module.cc causing bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Summary|[12 Regression] Bootstrap |[12 Regression]
|failure compiling |-Warray-bounds in
|gcc/cp/module.cc|gcc/cp/module.cc causing
||bootstrap failure
Blocks||56456
Resolution|--- |FIXED
--- Comment #7 from Martin Sebor ---
The warning triggers here because the code accesses an object using an address
computed by adding a negative constant to the address of a member subobject.
The arithmetic result is a pointer to another object but logically (in C) the
computation is invalid.
The preprocessed code for the identifier() function does this:
static inline tree identifier (const cpp_hashnode *node)
{
return ((tree) ((char *) ((&(const_cast (node))->ident)) -
sizeof (struct tree_common)));
}
That's strictly incorrect (undefined) and the warning points it out. The IL
below shows where the problem is detected:
void module_state::install_macros (struct module_state * const this)
{
...
union tree_node * _95;
...
[local count: 710990510]:
_95 = get_identifier_with_length (_93, len.30_94);
_96 = &MEM[(struct tree_identifier *)_95].id; <<< subobject
[local count: 1014686043]:
# _97 = PHI <0B(10), _96(11)>
len ={v} {CLOBBER};
_43 = get_macro_imports (_97);
_45 = bytes_in::u (sec_32);
flags_46 = _45 & 3;
if (flags_46 == 0)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 479439156]:
_47 = &MEM [(void *)_97 + -24B]; <<< -Warray-bounds
Pointer arithmetic needs to be bounded to the innermost object (or subobject)
the pointer was derived from. The warning enforces it to prevent accessing the
wrong member by accident. The following alternate way code the same function
avoids the warning:
static inline tree identifier (const cpp_hashnode *node)
{
char *p = (char *)const_cast (node);
p += __builtin_offsetof (cpp_hashnode, ident);
p -= sizeof (struct tree_common);
return (tree)p;
}
But rewriting it this way using the HT_XXX macros would be cumbersome so it
might be better to suppress the warning. I have committed r12-2178 moving the
suppression from the callers to the identifier() function.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 101372, which changed state. Bug 101372 Summary: [12 Regression] -Warray-bounds in gcc/cp/module.cc causing bootstrap failure https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101372 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug other/101381] New: [12 regression] missing warning in g++.dg/warn/Warray-bounds-20.C after r12-2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101381
Bug ID: 101381
Summary: [12 regression] missing warning in
g++.dg/warn/Warray-bounds-20.C after r12-2132
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:a110855667782dac7b674d3e328b253b3b3c919b, r12-2132
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=g++.dg/warn/Warray-bounds-20.C"
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++98 note (test for warnings,
line 38)
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++98 note (test for warnings,
line 55)
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++14 note (test for warnings,
line 38)
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++14 note (test for warnings,
line 55)
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++17 note (test for warnings,
line 38)
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++17 note (test for warnings,
line 55)
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++2a note (test for warnings,
line 38)
FAIL: g++.dg/warn/Warray-bounds-20.C -std=gnu++2a note (test for warnings,
line 55)
I saw this only for 32 bit BE on powerpc64.
commit a110855667782dac7b674d3e328b253b3b3c919b
Author: Martin Sebor
Date: Wed Jul 7 14:05:25 2021 -0600
Correct handling of variable offset minus constant in -Warray-bounds
[PR100137]
[Bug testsuite/101381] [12 regression] missing warning in g++.dg/warn/Warray-bounds-20.C after r12-2132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101381 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Last reconfirmed||2021-7-8 Resolution|--- |FIXED Component|other |testsuite Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- I literally just fixed this: r12-2176. Please reopen if they persist.
[Bug lto/101382] New: function declarations with identical asm label aliasing a target function does not compile with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101382
Bug ID: 101382
Summary: function declarations with identical asm label
aliasing a target function does not compile with -flto
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: fabian.parzefall at mailbox dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 51120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51120&action=edit
Input reproducing the bug
GCC cannot compile a module containing two function declarations with the same
asm label and the same alias attribute when -flto is enabled. Here is an
excerpt from the attachment:
void a(void) { ... }
extern typeof(a) b asm("x") __attribute__((alias("a")));
extern typeof(a) c asm("x") __attribute__((alias("a")));
When compiling with:
gcc -flto -c -o gcc-lto-asm-label-bug.o gcc-lto-asm-label-bug.c
gcc -flto -o gcc-lto-asm-label-bug gcc-lto-asm-label-bug.o
The second command invoked produces this error message:
lto1: fatal error: missing resolution data for *x
compilation terminated.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Compiling without -flto works as expected. GCC versions tested are 9.3.0 and
11.1.0 on Ubuntu 20.04.
[Bug c++/101371] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371
--- Comment #4 from Marek Polacek ---
Reduced more:
struct A {
int i;
};
struct B {
A a{};
constexpr B() : a() {}
constexpr B(const B &rhs) : a(rhs.a) {}
};
struct C {
B arr[1];
};
constexpr C
fn ()
{
C c{};
return c;
}
C c = fn();
[Bug c++/101371] [9/10/11/12 Regression] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371 Marek Polacek changed: What|Removed |Added Target Milestone|--- |9.5 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Summary|constexpr expansions|[9/10/11/12 Regression] |trigger internal Compiler |constexpr expansions |Error |trigger internal Compiler ||Error --- Comment #5 from Marek Polacek --- ...which started with my r272217.
[Bug c++/101371] [9/10/11/12 Regression] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371 Marek Polacek changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/95681] False positive uninitialized variable usage in decNumberCompareTotalMag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95681 --- Comment #1 from Jeffrey H. Johnson --- Confirm this behavior and reached same analysis with gcc version 11.1.1 20210531 (Red Hat 11.1.1-3) on x86_64.
[Bug debug/101283] Several tests fail on Darwin with -gctf/gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101283 David Edelsohn changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #19 from David Edelsohn --- I disabled on AIX because CTF and BTF were not enumerated as explicit debug formats that emitted the normal GCC warning checked by DejaGNU.
