[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720 --- Comment #18 from CVS Commits --- The master branch has been updated by Yvan Roux : https://gcc.gnu.org/g:9d503515ceebc778a5c2958f7459367c34f1fed0 commit r13-2655-g9d503515ceebc778a5c2958f7459367c34f1fed0 Author: Torbjörn SVENSSON Date: Wed Sep 14 07:22:27 2022 +0200 testsuite: gluefile file need to be prefixed When the status wrapper is used, the gluefile need to be prefixed with -Wl, in order for the test cases to have the dump files with the expected names. 2022-09-14 Torbjörn SVENSSON gcc/testsuite/ PR target/95720 * lib/g++.exp: Moved gluefile block to after flags have been prefixed for the target_compile call. * lib/gcc.exp: Likewise. * lib/wrapper.exp: Reset adjusted state flag. Co-Authored-By: Yvan ROUX Signed-off-by: Torbjörn SVENSSON
[Bug ipa/106935] [10/11/12/13 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.cc:1505 since r10-5098-g9b14fc3326e08797
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106935 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/106937] [10/11/12/13 Regression] ICE tree check: expected identifier_node, have tree_list in pp_tree_identifier, at tree-pretty-print.cc:4606 since r10-1214-g1bf32c1141e23074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106937 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5
[Bug tree-optimization/106938] [13 Regression] ICE in predicate::init_from_control_deps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106938 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2022-09-14 --- Comment #1 from Richard Biener --- Oh, another case. t.c:22:1: error: basic block 3 has no control altering stmt but 2 outgoing edges 22 | foo (void) | ^~~ [local count: 440058051]: # uninitialized_3(ab) = PHI goto ; [99.96%] I suppose I should try to push the part of the verifier that "works". I'm going to keep the assert in uninit analysis since it's nice to catch all these bugs.
[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920
--- Comment #4 from Richard Biener ---
might be nice to have a way to declare a variable at a fixed address so the
code can become
extern hab_rvt_entry_p **entryptr __attribute__((at(0x908)));
int main() {
hab_rvt_entry_t *a = *entryptr;
a();
return 0;
}
(I googled that some embedded compiler suppports 'at')
Note if you have a definition there's a workaround to declare the
variable in a custom section and use a linker script to place that
at a fixed address. Still that doesn't allow the compiler to
optimize the access instructions.
We could honor the 'at' attribute when expanding the variable to RTL.
Such variables are going to be interesting for alias analysis btw,
so we should document it being undefined when a variables declared
with 'at' overlaps with another variable (or allocated object).
[Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106920 --- Comment #5 from Dominique Martinet --- hmm this is a pretty complex topic. My problem like pointed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 is more with all the legacy code that I have to deal with, that isn't maintained by anyone, and well the sorry state of embedded systems upstreams in general... So I'm really just sitting there trying to get old code to keep working with my newer gcc version. (I actually wonder why that didn't fail with gcc11, I've been using that for a while...) The solution in that other bug ^ to just not issue warnings for constant addresses is good in general and I was just unlucky that such an address happened below 4k for this code. I don't understand why the ast tree cannot make the difference between a constant address and a constant null pointer macroed to hell, but since that only happens with optimizations enabled I guess some info is lost at that point and there was nothing to do or it would have been done. Anyway, I consider that closed, there's been enough ink spilled in the other thread and thank you all for the quick replies!
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905 --- Comment #5 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:93b09bf3246f413b8e469ebfd8ce43947c0073a6 commit r13-2656-g93b09bf3246f413b8e469ebfd8ce43947c0073a6 Author: liuhongt Date: Tue Sep 13 13:25:24 2022 +0800 Check another epilog variable peeling case in vectorizable_nonlinear_induction. in vectorizable_nonlinear_induction, r13-2503-gc13223b790bbc5 prevent variable peeling by only checking LOOP_VINFO_MASK_SKIP_NITERS (loop_vinfo). But when "!vect_use_loop_mask_for_alignment_p (loop_vinfo) && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0", vectorizer will still do variable peeling for epilog, and it hits gcc_assert in vect_peel_nonlinear_iv_init. gcc/ChangeLog: PR tree-optimization/106905 * tree-vect-loop.cc (vectorizable_nonlinear_induction): Return false when !vect_use_loop_mask_for_alignment_p (loop_vinfo) && LOOP_VINFO_PEELING_FOR_ALIGNMENT (loop_vinfo) < 0. gcc/testsuite/ChangeLog: * gcc.target/i386/pr106905.c: New test. * gcc.target/ia64/pr106905.c: New test.
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905 --- Comment #6 from Hongtao.liu --- Fixed in GCC13.
[Bug tree-optimization/106938] [13 Regression] ICE in predicate::init_from_control_deps since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106938 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[13 Regression] ICE in |[13 Regression] ICE in |predicate::init_from_contro |predicate::init_from_contro |l_deps |l_deps since ||r13-2500-g0a4a2667dc115ca7 --- Comment #2 from Martin Liška --- Btw. started with r13-2500-g0a4a2667dc115ca7.
[Bug target/100645] ICE in related_vector_mode, at stor-layout.c:537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100645
Kewen Lin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
--- Comment #2 from Kewen Lin ---
Confirmed.
type v2di (vector(2) long long int) goes with TImode with altivec support,
which isn't a vector mode, so it fails with:
gcc_assert (VECTOR_MODE_P (vector_mode));
The reason why veclower doesn't lower it is that: it can go with vec_shr_optab
against TImode.
/* Also detect vec_shr pattern - VEC_PERM_EXPR with zero
vector as VEC1 and a right element shift MASK. */
if (optab_handler (vec_shr_optab, TYPE_MODE (vect_type))
!= CODE_FOR_nothing
...
One alternative is to guard this check with VECTOR_MODE_P(TYPE_MODE
(vect_type)), but someone can argue that target shouldn't support this kind of
optab for one non vector mode. So it's more reasonable to fix it in target
code:
diff --git a/gcc/config/rs6000/vector.md b/gcc/config/rs6000/vector.md
index b87a742cca8..ed3feee2041 100644
--- a/gcc/config/rs6000/vector.md
+++ b/gcc/config/rs6000/vector.md
@@ -1532,7 +1532,7 @@ (define_expand "vec_shr_"
[(match_operand:VEC_L 0 "vlogical_operand")
(match_operand:VEC_L 1 "vlogical_operand")
(match_operand:QI 2 "reg_or_short_operand")]
- "TARGET_ALTIVEC"
+ "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)"
{
rtx bitshift = operands[2];
rtx shift;
TImode is excluded by VECTOR_UNIT_ALTIVEC_OR_VSX_P check.
[Bug c++/106940] New: Feature request: -Wsuggest-noexcept and -Wsuggest-explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106940 Bug ID: 106940 Summary: Feature request: -Wsuggest-noexcept and -Wsuggest-explicit Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: felix.von.s at posteo dot de Target Milestone: --- When writing classes, I routinely tend to forget that constructors can be used for implicit conversions, unless marked explicit. I also tend to forget about noexcept specifiers, which can lead to performance pitfalls, especially with move constructors and move assignment operators. So I would like a compiler warning that could remind me to consider such concerns. In case of noexcept, I don’t particularly need full semantic analysis of the body; a pure syntax check whether the specifier is present should suffice. And in case of explicit, no other kind of check is possible, obviously. I imagine -Wsuggest-explicit could be suppressed for copy and move constructors from the same type. I am undecided whether it should apply to conversion operators, but leaning towards yes. The warnings would be silenced by adding explicit specifiers: explicit(false) and noexcept(false). Each warning should probably require the earliest language version where the respective silencing is possible (C++20 and C++11, respectively).
[Bug libstdc++/106932] Incorrect behavior of std::filesystem::copy() with overwrite_existing or update_existing options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106932 --- Comment #7 from Jonathan Wakely --- How would that work? The compile has no idea whether "source" is a regular file or directory. Should it just suggest adding 'recursive' to the options whenever a non-empty set of options is used?
[Bug c++/106940] Feature request: -Wsuggest-noexcept and -Wsuggest-explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106940 Jonathan Wakely changed: What|Removed |Added Blocks||87403 Severity|normal |enhancement Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||amacleod at redhat dot com,
||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Note, we'll need something similar for OpenMP #pragma omp assume
(C/C++/Fortran).
I thought we could represent it in the IL as:
if (.IFN_ASSUME ())
{
if (!cond)
__builtin_unreachable ();
}
where .IFN_ASSUME would eventually be folded into false. We'd need to teach
the ranger etc. to take advantage of the bbs guarded by .IFN_ASSUME () as if
the condition would be true, the inliner to try to discover SESE regions
guarded by that condition and ignore them for size estimation purposes and
perhaps have somewhat higher code growth limits into those regions.
Richi doesn't like that.
Another possibility is to represent these as:
.IFN_ASSUME (outlined_fun, args...);
where the cond expression would be outlined into an artificial function.
Ranger and other optimization passes then could try to evaluate the body of
outlined_fun with the assumption that the function returns true (if it returns
false, then it is UB). We'd never emit the artificial outlined functions into
assembly nor debug info, but would inline into them and try to optimize them
after IPA. Would be nice to have callgraph order their post IPA opts before
functions that .IFN_ASSUME reference them.
Either the outlined functions could be created in the FEs (e.g. for C++ we
could perhaps partly use code that we use for lambda capture discoveries), but
the disadvantage would be that we'd need to do it 3 times.
So another option would be some new GENERIC/GIMPLE statement kind used for
these and lower it only at say gimple lowering time (we have a precedent of
creating
outlined functions at ompexp time for OpenMP expansion).
Thoughts on this? Aldy/Andrew, do you think it is something the ranger could
handle?
[Bug tree-optimization/106934] [10/11/12/13 Regression] ICE: verify_gimple failed since r9-5682-gef310a95a934d0f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106934 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:05f5c42cb42c5088187d44cc45a5f671d19ad8c5 commit r13-2657-g05f5c42cb42c5088187d44cc45a5f671d19ad8c5 Author: Richard Biener Date: Wed Sep 14 09:00:35 2022 +0200 tree-optimization/106934 - avoid BIT_FIELD_REF of bitfields The following avoids creating BIT_FIELD_REF of bitfields in update-address-taken. The patch doesn't implement punning to a full precision integer type but leaves a comment according to that. PR tree-optimization/106934 * tree-ssa.cc (non_rewritable_mem_ref_base): Avoid BIT_FIELD_REFs of bitfields. (maybe_rewrite_mem_ref_base): Likewise. * gfortran.dg/pr106934.f90: New testcase.
[Bug tree-optimization/106934] [10/11/12 Regression] ICE: verify_gimple failed since r9-5682-gef310a95a934d0f3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106934 Richard Biener changed: What|Removed |Added Known to work||13.0 Priority|P3 |P2 Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE: |ICE: verify_gimple failed |verify_gimple failed since |since |r9-5682-gef310a95a934d0f3 |r9-5682-gef310a95a934d0f3 | Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
[Bug c++/106924] Nested class: virtual function returns wrong pointer of covariant type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106924
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2022-09-14
--- Comment #1 from Jonathan Wakely ---
Reduced to remove unnecessary virtual functions that are never used, and fix
the printf formats, and make it fail at runtime:
extern "C" int printf(const char*, ...);
extern "C" void abort();
struct BaseA
{
virtual ~BaseA(){}
};
struct BaseB
{
virtual ~BaseB(){}
};
struct DerivedAB;
struct FabForB
{
virtual BaseA* getPtr()=0;
virtual ~FabForB(){}
};
struct DerivedAB : BaseB, BaseA
{
struct ABFabNested : FabForB
{
virtual DerivedAB* getPtr();
};
};
void print(const DerivedAB* dp, const BaseA* ap, bool nested = false)
{
}
DerivedAB d;
DerivedAB* DerivedAB::ABFabNested::getPtr()
{
DerivedAB* p = &d;
printf("TEST fab nested: addr %p base %p\n", p, (BaseA*)p);
return p;
}
struct ABFab : FabForB
{
virtual DerivedAB* getPtr()
{
DerivedAB* p = &d;
printf("TEST fab:addr %p base %p\n", p, (BaseA*)p);
return p;
}
};
int main()
{
ABFab fab;
DerivedAB::ABFabNested fabNested;
BaseA* a1 = fab.getPtr();
BaseA* a2 = static_cast(fab).getPtr();
printf("TEST addr %p %p\n", a1, a2);
a1 = fabNested.getPtr();
a2 = static_cast(fabNested).getPtr();
printf("TEST nested addr %p %p\n", a1, a2);
if (a1 != a2)
abort();
}
G++ prints:
TEST fab:addr 0x404060 base 0x404068
TEST fab:addr 0x404060 base 0x404068
TEST addr 0x404068 0x404068
TEST fab nested: addr 0x404060 base 0x404068
TEST fab nested: addr 0x404060 base 0x404068
TEST nested addr 0x404068 0x404060
Aborted (core dumped)
When we call fabNested.getPtr() to get a DerivedAB* and then convert to BaseA*
at the call site, the pointer is correctly adjusted to the BaseA base
subobject.
When we call static_cast(fabNested).getPtr() to get a BaseA* the
covariant return is not adjusted, and the address of the DerivedAB complete
object is returned, not its BaseA base subobejct..
[Bug c++/106924] Nested class: virtual function returns wrong pointer of covariant type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106924
--- Comment #2 from Jonathan Wakely ---
Oops, slightly further reduce to remove the ununsed print function:
extern "C" int printf(const char*, ...);
extern "C" void abort();
struct BaseA
{
virtual ~BaseA(){}
};
struct BaseB
{
virtual ~BaseB(){}
};
struct DerivedAB;
struct FabForB
{
virtual BaseA* getPtr()=0;
virtual ~FabForB(){}
};
struct DerivedAB : BaseB, BaseA
{
struct ABFabNested : FabForB
{
virtual DerivedAB* getPtr();
};
};
DerivedAB d;
DerivedAB* DerivedAB::ABFabNested::getPtr()
{
DerivedAB* p = &d;
printf("TEST fab nested: addr %p base %p\n", p, (BaseA*)p);
return p;
}
struct ABFab : FabForB
{
virtual DerivedAB* getPtr()
{
DerivedAB* p = &d;
printf("TEST fab:addr %p base %p\n", p, (BaseA*)p);
return p;
}
};
int main()
{
ABFab fab;
DerivedAB::ABFabNested fabNested;
BaseA* a1 = fab.getPtr();
BaseA* a2 = static_cast(fab).getPtr();
printf("TEST addr %p %p\n", a1, a2);
a1 = fabNested.getPtr();
a2 = static_cast(fabNested).getPtr();
printf("TEST nested addr %p %p\n", a1, a2);
if (a1 != a2)
abort();
}
This fails at least as far back as 4.1.0, I didn't test further.
[Bug tree-optimization/106878] [11/12/13 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise caluclation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:645ef01a463f15fc230e2155719c7a12cec89acf
commit r13-2658-g645ef01a463f15fc230e2155719c7a12cec89acf
Author: Jakub Jelinek
Date: Wed Sep 14 12:36:36 2022 +0200
Disallow pointer operands for |, ^ and partly & [PR106878]
My change to match.pd (that added the two simplifications this patch
touches) results in more |/^/& assignments with pointer arguments,
but since r12-1608 we reject pointer operands for BIT_NOT_EXPR.
Disallowing them for BIT_NOT_EXPR and allowing for BIT_{IOR,XOR,AND}_EXPR
leads to a match.pd maintainance nightmare (see one of the patches in the
PR), so either we want to allow pointer operand on BIT_NOT_EXPR (but then
we run into issues e.g. with the ranger which expects it can emulate
BIT_NOT_EXPR ~X as - 1 - X which doesn't work for pointers which don't
support MINUS_EXPR), or the following patch disallows pointer arguments
for all of BIT_{IOR,XOR,AND}_EXPR with the exception of BIT_AND_EXPR
with INTEGER_CST last operand (for simpler pointer realignment).
I had to tweak one reassoc optimization and the two match.pd
simplifications.
2022-09-14 Jakub Jelinek
PR tree-optimization/106878
* tree-cfg.cc (verify_gimple_assign_binary): Disallow pointer,
reference or OFFSET_TYPE BIT_IOR_EXPR, BIT_XOR_EXPR or, unless
the second argument is INTEGER_CST, BIT_AND_EXPR.
* match.pd ((type) X op CST -> (type) (X op ((type-x) CST)),
(type) (((type2) X) op Y) -> (X op (type) Y)): Punt for
POINTER_TYPE_P or OFFSET_TYPE.
* tree-ssa-reassoc.cc (optimize_range_tests_cmp_bitwise): For
pointers cast them to pointer sized integers first.
* gcc.c-torture/compile/pr106878.c: New test.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
Note my main dislike is because the former is essentially
if (0)
{
if (!cond)
__builtin_unreachable ();
}
that is, the assumption itself, not only its condition computation (and
side-effects) are thrown away.
With
cond = .IFN_ASSUME (outlined_cond_computer, args...);
if (!cond)
__builtin_unreachable ();
or as Jakub prefers with implicit unreachable, the side-effects we want to
elide are in 'outlined_cond_computer' and we can later "optimize" the
.IFN_ASSUME call to compute true.
For ranger the difficulty in the latter form is that there will be
assertions on 'args...', variables at the call site, but what they
are is specified by outlined_cond_computer returning true. Consider
_bool outlined_cond_computer (int i, int j)
{
return i_1(D) == j_2(D);
}
from
[[assume(i == j)]];
we'd then have
.IFN_ASSUME (cond_fn, i_2, j_5);
and just like IPA does, we'd have to "connect" relations/ranges
produced by outlined_cond_computer via argument positions. I think
we can easily funnel in argument ranges from the caller and thus
possibly compute outlined_cond_computer outgoing ranges for the
arguments (only those are interesting!) on the "true" return edge.
Complication is the IL is in another function, set_cfun is a bit
expensive but in theory most things could be formulated in a way
to not require 'cfun' be set "correctly".
On the C++ frontend side I'd simply handle
[[assume(expr)]]
as if 'expr' were in a lambda -> bool with everything captured by value.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
--- Comment #3 from Richard Biener ---
(In reply to Richard Biener from comment #2)
> On the C++ frontend side I'd simply handle
>
> [[assume(expr)]]
>
> as if 'expr' were in a lambda -> bool with everything captured by value.
... because it seems (ick!)
void foo()
{
int i = 0;
[[assume(++i == 1)]];
if (i != 0)
std::abort ();
}
needs to work. We couldn't let that ++i "escape" to GENERIC/GIMPLE, even
when protected with if (.IFN_ASSUME ()) it would create ugly PHIs.
[Bug modula2/106443] Many 32-bit tests FAIL to link on Solaris/sparcv9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106443 Rainer Orth changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from Rainer Orth --- It can. I've verified both sparcv9-sun-solaris2.11 (and, while I'm at it) i386-pc-solaris2.11 bootstraps off the unpatched devel/modula-2 branch and results lookgood: ca. 20 FAILs per multilib only in both cases.
[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- Something very odd is going on. foo.simdclone.2 contains a *cmpti_doubleword instruction, that is defined using define_insn_and_split to be split pre-reload. For some reason, this isn't getting split during the split1 pass, but continues through reload until things finally fail in cprop_hardreg. Interestingly the corresponding instruction is correctly split in simdclone.0 and simdclone.1. The .293e.split1 file contains (much redacted)... ;; Function foo.simdclone.0 Splitting with gen_split_2 (i386.md:1511) deleting insn with uid = 16. ;; Function foo.simdclone.1 Splitting with gen_split_2 (i386.md:1511) deleting insn with uid = 22. ;; Function foo.simdclone.2 i.e. no splits are performed on foo.simdclone.2, but they are on simdclone.0 and simdclone.1. Perhaps an off-by-one error? I'll investigate further, but I doubt this is an issue in the i386.md machine description; the ((simd)) attribute is interacting strangely with the split pass.
[Bug c++/106654] [C++23] P1774 - Portable assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654 --- Comment #4 from Jakub Jelinek --- Note, I think for [[assume(i == j)]]; we can just emit if (i == j) ; else __builtin_unreachable (); - it is just the TREE_SIDE_EFFECTS case that would need the extra treatment (I think the no side-effect cases will be occur often enough that it is worth avoiding the outlining etc. costs). Well, possibly also anything that could trap or fault or with some expression size limit. If it doesn't have side-effects and can't trap/fault, we either DCE it, or it doesn't result in visible side-effects. But possible floating point side-effects, or integer division by zero, or memory dereferences etc. should go the new way.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 Thomas Schwinge changed: What|Removed |Added Status|ASSIGNED|WAITING CC||tschwinge at gcc dot gnu.org --- Comment #17 from Thomas Schwinge --- Please re-try after recent commit r13-2108-g5dbc94bf13c5ef2f2b777d76d7880fe2153aa37b "Add libgo dependency on libbacktrace".
[Bug target/96072] ICE: Segmentation fault (in add_reg_note)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
CC||linkw at gcc dot gnu.org
Status|WAITING |NEW
--- Comment #5 from Kewen Lin ---
Confirmed.
if (DEFAULT_ABI == ABI_V4 || flag_shrink_wrap)
{
/* If the frame pointer was used then we can't delay emitting
a REG_CFA_DEF_CFA note. This must happen on the insn that
restores the frame pointer, r31. We may have already emitted
a REG_CFA_DEF_CFA note, but that's OK; A duplicate is
discarded by dwarf2cfi.cc/dwarf2out.cc, and in any case would
be harmless if emitted. */
if (frame_pointer_needed)
{
insn = get_last_insn ();
add_reg_note (insn, REG_CFA_DEF_CFA,
plus_constant (Pmode, frame_reg_rtx, frame_off));
RTX_FRAME_RELATED_P (insn) = 1;
}
ICE since the insn here is (rtx) 0x0.
I think the code here has the assumption that the frame pointer restoring
happened ahead, it's:
/* If we have a frame pointer, we can restore the old stack pointer
from it. */
else if (frame_pointer_needed_indeed)
{
frame_reg_rtx = sp_reg_rtx;
[Bug target/96072] ICE: Segmentation fault (in add_reg_note)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072
Kewen Lin changed:
What|Removed |Added
CC||bergner at gcc dot gnu.org
--- Comment #6 from Kewen Lin ---
diff --git a/gcc/config/rs6000/rs6000-logue.cc
b/gcc/config/rs6000/rs6000-logue.cc
index 59fe1c8cb8b..a868ede24fb 100644
--- a/gcc/config/rs6000/rs6000-logue.cc
+++ b/gcc/config/rs6000/rs6000-logue.cc
@@ -4924,7 +4924,7 @@ rs6000_emit_epilogue (enum epilogue_type epilogue_type)
a REG_CFA_DEF_CFA note, but that's OK; A duplicate is
discarded by dwarf2cfi.cc/dwarf2out.cc, and in any case would
be harmless if emitted. */
- if (frame_pointer_needed)
+ if (frame_pointer_needed_indeed)
{
insn = get_last_insn ();
add_reg_note (insn, REG_CFA_DEF_CFA,
The above diff can fix the issue, I think it's related to commit r10-7981,
which introduced frame_pointer_needed_indeed but missed to update the condition
for adding reg note under new flag.
[Bug tree-optimization/106914] [13 Regression] ICE in operator[], at vec.h:889 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106914 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||rsandifo at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #2 from rsandifo at gcc dot gnu.org --- Dup of PR106794. I'll add this testcase to the patch. *** This bug has been marked as a duplicate of bug 106794 ***
[Bug tree-optimization/106794] [13 Regression] ICE in vect_transform_slp_perm_load_1 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106794 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||gs...@t-online.de --- Comment #5 from rsandifo at gcc dot gnu.org --- *** Bug 106914 has been marked as a duplicate of this bug. ***
[Bug target/106933] [13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r13-2049-g6f94923dea21bd92
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106933 --- Comment #3 from Roger Sayle --- Ignore all of Comment 2. The reason the instruction isn't getting split, is that (unlike the other clones), the pseudo's mode is V1TI (not TI), hence doesn't match the constraint. The problem is STV (again), where uses of a pseudo are split into different chains, and some chains are considered profitable, and other chains aren't supported in V1TImode. Searching for mode conversion candidates... insn 13 is marked as a TImode candidate insn 16 is marked as a TImode candidate Created a new instruction chain #7 Building chain #7... Adding insn 13 to chain #7 Collected chain #7... insns: 13 Computing gain for chain #7... Instruction gain 4 for13: [r91:DI]=r82:TI REG_DEAD r91:DI Total gain: 5 Converting chain #7... deferring rescan insn with uid = 13. Created a new instruction chain #8 Building chain #8... Adding insn 16 to chain #8 Collected chain #8... insns: 16 Computing gain for chain #8... Instruction gain -4 for16: flags:CCZ=cmp(r82:V1TI,0x1) REG_DEAD r82:V1TI Total gain: -3 Chain #8 conversion is not profitable Total insns converted: 1 The issue is that you can't convert insn 13 to V1TImode if you don't convert insn 16, i.e. all uses of a pseudo should have the same mode. [Calling PUT_MODE on the first use, implicitly updates the second]. I believe (this time) that the uninitialized value from "empty()" confuses that DF analysis, and insns 13 and 16 end up on different (dependency) chains, because the lack on initialization makes them look independent.
[Bug middle-end/106941] New: Warn/Error conversion between opaque types in generic handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106941 Bug ID: 106941 Summary: Warn/Error conversion between opaque types in generic handling Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-checking Severity: minor Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: linkw at gcc dot gnu.org CC: bergner at gcc dot gnu.org, hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org, segher at gcc dot gnu.org, unassigned at gcc dot gnu.org Depends on: 106833 Target Milestone: --- Target: powerpc*-linux-gnu In PR106833, Segher pointed out that we should emit warning or error messages for conversion between two opaque types even if they have the same mode, as documentation said conversion should not expected for opaque type. For now, rs6000_invalid_conversion has some checks which are mainly based on mode but they are target specific. As #c12 of PR106833, Segher expected this can be handled generically, no target code is needed for it. Since "we currently have only one type for each of our two opaque modes", give it a minor severity for now. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 [Bug 106833] Miss to handle OPAQUE_TYPE specially in verify_type
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896 --- Comment #4 from rsandifo at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) > I think you may want to use something like: > bb->count.probability_in (ENTRY_BLOCK_PTR_FOR_FN (cfun)->count).to_sreal() I'm not sure modelling it as a probability would work. In general, a bb can be executed more often than the entry block (e.g. for loops) or less often (e.g. if the whole function is a diamond). Modelling it as a probability would cap one of the two cases to 1 (i.e. same as equal counts).
[Bug middle-end/106941] Warn/Error conversion between opaque types in generic handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106941 Bug 106941 depends on bug 106833, which changed state. Bug 106833 Summary: Miss to handle OPAQUE_TYPE specially in verify_type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/106833] Miss to handle OPAQUE_TYPE specially in verify_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 Kewen Lin changed: What|Removed |Added Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #14 from Kewen Lin --- Should be fixed on trunk, opened PR106941 for conversion as Segher's comments.
[Bug tree-optimization/106936] [13 Regression] ICE in get_value_range, at value-query.cc:170 since r13-1815-g8b8103dcd2624936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936 --- Comment #3 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:12a8d5e2f2e7d7535115e4e105c0f9eb4d50fdad commit r13-2663-g12a8d5e2f2e7d7535115e4e105c0f9eb4d50fdad Author: Aldy Hernandez Date: Wed Sep 14 14:48:36 2022 +0200 [PR106936] Remove assert from get_value_range. This assert was put here to make sure that the legacy get_value_range() wasn't being called on stuff that legacy couldn't handle (floats, etc), because the result would ultimately be copied into a value_range_equiv. In this case, simplify_casted_cond() is calling it on an offset_type which is neither an integer nor a pointer. However, range_of_expr happily punted on it, and then the fallthru code set the range to VARYING. As value_range_equiv can store VARYING types of anything (including types it can't handle), this is fine. The easiest thing to do is remove the assert. If someone from the non legacy world tries to get a non integer/pointer range here, it's going to blow up anyhow because the temporary in get_value_range is int_range_max. PR tree-optimization/106936 gcc/ChangeLog: * value-query.cc (range_query::get_value_range): Remove assert. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/pr106936.C: New test.
[Bug tree-optimization/106936] [13 Regression] ICE in get_value_range, at value-query.cc:170 since r13-1815-g8b8103dcd2624936
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106936 Aldy Hernandez changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Aldy Hernandez --- fixed
[Bug tree-optimization/106938] [13 Regression] ICE in predicate::init_from_control_deps since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106938 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:cd14c97cd92ca11c66ee3d8dc4dd543c5aa8e024 commit r13-2664-gcd14c97cd92ca11c66ee3d8dc4dd543c5aa8e024 Author: Richard Biener Date: Wed Sep 14 13:53:56 2022 +0200 tree-optimization/106938 - cleanup abnormal edges after inlining After inlining and IPA transforms we run fixup_cfg to fixup CFG effects in other functions. But that fails to clean abnormal edges from non-pure/const calls which might no longer be necessary when ->calls_setjmp is false. The following ensures this happens and refactors things so we call EH/abnormal cleanup only on the last stmt in a block. PR tree-optimization/106938 * tree-cfg.cc (execute_fixup_cfg): Purge dead abnormal edges for all last stmts in a block. Do EH cleanup only on the last stmt in a block. * gcc.dg/pr106938.c: New testcase.
[Bug tree-optimization/106938] [13 Regression] ICE in predicate::init_from_control_deps since r13-2500-g0a4a2667dc115ca7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106938 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug middle-end/106833] Miss to handle OPAQUE_TYPE specially in verify_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 --- Comment #15 from Peter Bergner --- (In reply to Kewen Lin from comment #14) > Should be fixed on trunk I assume this is broken on the release branches too and we'll need backports?
[Bug modula2/102322] libgm2 Makefiles should be self-contained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102322 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Gaius Mulley --- Now fixed in the latest development branch (from GCC-13).
[Bug modula2/106917] modula-2 fails to bootstrap with the modula-2 branch ,20220912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106917 --- Comment #2 from Gaius Mulley --- I've git pushed fixes to libgm2 relating to GM2_FOR_TARGET. Does this also fix this build?
[Bug middle-end/105469] [10/11/12/13 Regression] "execution reached an unreachable program point" with -flto since r5-7027-g0b986c6ac777aa4e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105469 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5 Last reconfirmed|2022-05-04 00:00:00 |2022-9-14 Priority|P3 |P2 Summary|"execution reached an |[10/11/12/13 Regression] |unreachable program point" |"execution reached an |with -flto since|unreachable program point" |r5-7027-g0b986c6ac777aa4e |with -flto since ||r5-7027-g0b986c6ac777aa4e --- Comment #15 from Richard Biener --- Re-confirmed on todays trunk. IPA folks - can you please have a look here?
[Bug tree-optimization/55288] Improve handling/suppression of maybe-uninitialized warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to work||4.8.2 --- Comment #6 from Richard Biener --- Fixed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 55288, which changed state. Bug 55288 Summary: Improve handling/suppression of maybe-uninitialized warnings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/106896] [13 Regression] ICE in to_sreal_scale, at profile-count.cc:339 since r13-2288-g61c4c989034548f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106896 --- Comment #5 from Martin Liška --- > Modelling it > as a probability would cap one of the two cases to 1 (i.e. same as > equal counts). You are correct, Honza should answer here!
[Bug middle-end/106833] Miss to handle OPAQUE_TYPE specially in verify_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106833 --- Comment #16 from Kewen Lin --- (In reply to Peter Bergner from comment #15) > (In reply to Kewen Lin from comment #14) > > Should be fixed on trunk > > I assume this is broken on the release branches too and we'll need backports? Good question, currently function verify_type uses are all guarded by flag_checking, I just had a testing, the ICE didn't get exposed with release branches, I think it is because that they are configured with --enable-checking=release by default, but it's still reproducible with one extra explicit option -fchecking=1 for release branches. Hi Richi, what do you think of the backporting for this case?
[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816
--- Comment #6 from Martin Liška ---
(In reply to Richard Biener from comment #5)
> The function should probably inherit all of the IPA pure/const/modref
> analysis result, that is all "IPA" state should be copied. I think we want
> some helper
> here - IPA clone creation must have something, no?
Well, in IPA clones utilize so-called function_summary that is a typical place
where we store analysis results. And we don't typically create a new tree
declarations when we clone cgraph_nodes (clones share the same FE declaration).
However, I noticed we want to do likely something similar to what cp/decl.c
does:
static void
merge_attribute_bits (tree newdecl, tree olddecl)
{
TREE_THIS_VOLATILE (newdecl) |= TREE_THIS_VOLATILE (olddecl);
TREE_THIS_VOLATILE (olddecl) |= TREE_THIS_VOLATILE (newdecl);
TREE_NOTHROW (newdecl) |= TREE_NOTHROW (olddecl);
TREE_NOTHROW (olddecl) |= TREE_NOTHROW (newdecl);
TREE_READONLY (newdecl) |= TREE_READONLY (olddecl);
TREE_READONLY (olddecl) |= TREE_READONLY (newdecl);
DECL_IS_MALLOC (newdecl) |= DECL_IS_MALLOC (olddecl);
DECL_IS_MALLOC (olddecl) |= DECL_IS_MALLOC (newdecl);
DECL_PURE_P (newdecl) |= DECL_PURE_P (olddecl);
DECL_PURE_P (olddecl) |= DECL_PURE_P (newdecl);
DECL_UNINLINABLE (newdecl) |= DECL_UNINLINABLE (olddecl);
DECL_UNINLINABLE (olddecl) |= DECL_UNINLINABLE (newdecl);
}
...
/* Merge the noreturn bit. */
TREE_THIS_VOLATILE (olddecl) = TREE_THIS_VOLATILE (newdecl);
TREE_READONLY (olddecl) = TREE_READONLY (newdecl);
TREE_NOTHROW (olddecl) = TREE_NOTHROW (newdecl);
DECL_IS_MALLOC (olddecl) = DECL_IS_MALLOC (newdecl);
DECL_PURE_P (olddecl) = DECL_PURE_P (newdecl);
I can see IPA passes doing similar declaration clonning for VAR_DECLs
(gcc/ipa-param-manipulation.cc, gcc/tree-inline.c).
@Martin: Do we have a declaration cloning code for functions somewhere?
[Bug ipa/106816] noreturn/pure attributes are not set correctly on multiversioned functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106816 Martin Liška changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #7 from Martin Liška --- Let me assign it to myself.
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472 --- Comment #18 from Jeff Rahr --- Thomas - After applying this patch, I reran 'autogen Makefile.def' so that line was already in Makefile.in. I am able to get gcc to build if I remove the bootstrap=true from libbacktrace and libatomic on lines 172 and 194 in Makefile.def. This was added to Makefile.def as part of a patch to D language by: https://github.com/gcc-mirror/gcc/commit/5fee5ec362f7a243f459e6378fd49dfc89dc9fb5 I am not building D language, so not sure if I was building D it would make any difference.
[Bug target/106942] New: ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106942
Bug ID: 106942
Summary: ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE
in extract_insn, at recog.cc:2791 (error:
unrecognizable insn)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: crazylht at gmail dot com, dcb314 at hotmail dot com,
lingling.kong7 at gmail dot com, marxin at gcc dot gnu.org,
unassigned at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
+++ This bug was initially created as a clone of Bug #106742 +++
1. gcc 13.0.0 20220911 snapshot (g:0ea5e3f4542832b8da016b152695e64a2a386309)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.target/i386/vect-bfloat16-2a.c, w/ -mavx -O1:
typedef __bf16 v16bf __attribute__ ((__vector_size__ (32)));
v16bf
vec_init_dup_v16bf (__bf16 a1)
{
return __extension__ (v16bf) {
a1, a1, a1, a1, a1, a1, a1, a1,
a1, a1, a1, a1, a1, a1, a1, a1
};
}
% x86_64-unknown-linux-gnu-gcc-13.0.0 -mavx -O1 -c ohm7ipdh.c
during RTL pass: expand
ohm7ipdh.c: In function 'vec_init_dup_v16bf':
ohm7ipdh.c:6:10: internal compiler error: in gen_lowpart_general, at
rtlhooks.cc:57
6 | return __extension__ (v16bf) {
| ^
0x73101e gen_lowpart_general(machine_mode, rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/rtlhooks.cc:57
0x137fbb3 ix86_expand_vector_init_duplicate(bool, machine_mode, rtx_def*,
rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/config/i386/i386-expand.cc:15049
0x137f7ff ix86_expand_vector_init_duplicate(bool, machine_mode, rtx_def*,
rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/config/i386/i386-expand.cc:15117
0x138377b ix86_expand_vector_init(bool, rtx_def*, rtx_def*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/config/i386/i386-expand.cc:16095
0x1a4f36d ???
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/config/i386/sse.md:26602
0xb30678 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/recog.h:407
0xb30678 store_constructor(tree_node*, rtx_def*, int, poly_int<1u, long>, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/expr.cc:7407
0xb334dd expand_constructor
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/expr.cc:8745
0xb1fc7a expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/expr.cc:10990
0xb20c36 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/expr.cc:10629
0x9f598c expand_expr
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/expr.h:310
0x9f598c expand_return
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/cfgexpand.cc:3809
0x9f598c expand_gimple_stmt_1
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/cfgexpand.cc:3918
0x9f598c expand_gimple_stmt
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/cfgexpand.cc:4044
0x9fb597 expand_gimple_basic_block
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/cfgexpand.cc:6096
0x9fd137 execute
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/cfgexpand.cc:6822
2. W/ -mavx -O0, it yields the following instead:
% gcc-13.0.0 -mavx -O0 -c ohm7ipdh.c
ohm7ipdh.c: In function 'vec_init_dup_v16bf':
ohm7ipdh.c:10:1: error: unrecognizable insn:
10 | }
| ^
(insn 12 11 13 2 (set (reg:V16BF 84)
(vec_concat:V16BF (reg:V16QI 85)
(reg:V16QI 85))) "ohm7ipdh.c":6:10 -1
(nil))
during RTL pass: vregs
ohm7ipdh.c:10:1: internal compiler error: in extract_insn, at recog.cc:2791
0x730822 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/rtl-error.cc:108
0x73083e _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/rtl-error.cc:116
0x72edc3 extract_insn(rtx_insn*)
/var/tmp/portage/sys-devel/gcc-13.0.0_p20220911/work/gcc-13-20220911/gcc/recog.cc:2791
0xb83be3 instantiate_virtual_regs_in_insn
/var/tmp/porta
[Bug target/106902] [11/12/13 Regression] Program compiled with -O3 -mfma produces different result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106902
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #6 from Alexander Monakov ---
This is a lovely showcase how optimizations cooperatively produce something
unexpected.
TL;DR: SLP introduces redundant computations and then fma formation contracts
some (but not all) of those, dramatically reducing numerical stability. In
principle that's similar to incorrectly "optimizing"
double f(double x)
{
double y = x * x;
return y - y;
}
(which is guaranteed to return either NaN or 0) to
double f(double x)
{
return fma(x, x, -(x * x));
}
which returns the round-off tail of x * x (or NaN). I think there's already
another bug with a similar root cause.
In this bug, we begin with (note, all following examples are supposed to be
compiled without fma contraction, i.e. -O0, plain -O2, or -O2 -ffp-contract=off
if your target has fma):
#include
#include
double one = 1;
double b1 = 0x1.70e906b54fe4fp+1;
double b2 = -0x1.62adb4752c14ep+1;
double b3 = 0x1.c7001a6f3bd8p-1;
double B = 0x1.29c9034e7cp-13;
void f1(void)
{
double x1 = 0, x2 = 0, x3 = 0;
for (int i = 0; i < 99; ) {
double t = B * one + x1 * b1 + x2 * b2 + x3 * b3;
printf("%d %g\t%a\n", i++, t, t);
x3 = x2, x2 = x1, x1 = t;
}
}
predcom unrolls by 3 to get rid of moves:
void f2(void)
{
double x1 = 0, x2 = 0, x3 = 0;
for (int i = 0; i < 99; ) {
x3 = B * one + x1 * b1 + x2 * b2 + x3 * b3;
printf("%d %g\t%a\n", i++, x3, x3);
x2 = B * one + x3 * b1 + x1 * b2 + x2 * b3;
printf("%d %g\t%a\n", i++, x2, x2);
x1 = B * one + x2 * b1 + x3 * b2 + x1 * b3;
printf("%d %g\t%a\n", i++, x1, x1);
}
}
SLP introduces some redundant vector computations:
typedef double f64v2 __attribute__((vector_size(16)));
void f3(void)
{
double x1 = 0, x2 = 0, x3 = 0;
f64v2 x32 = { 0 }, x21 = { 0 };
for (int i = 0; i < 99; ) {
x3 = B * one + x21[1] * b1 + x2 * b2 + x3 * b3;
f64v2 x13b1 = { x21[1] * b1, x3 * b1 };
x32 = B * one + x13b1 + x21 * b2 + x32 * b3;
x2 = B * one + x3 * b1 + x1 * b2 + x2 * b3;
f64v2 x13b2 = { b2 * x1, b2 * x32[0] };
x21 = B * one + x32 * b1 + x13b2 + x21 * b3;
x1 = B * one + x2 * b1 + x32[0] * b2 + x1 * b3;
printf("%d %g\t%a\n", i++, x32[0], x32[0]);
printf("%d %g\t%a\n", i++, x32[1], x32[1]);
printf("%d %g\t%a\n", i++, x21[1], x21[1]);
}
}
Note that this is still bit-identical to the initial function. But then
tree-ssa-math-opts "randomly" forms some FMAs:
f64v2 vfma(f64v2 x, f64v2 y, f64v2 z)
{
return (f64v2){ fma(x[0], y[0], z[0]), fma(x[1], y[1], z[1]) };
}
void f4(void)
{
f64v2 vone = { one, one }, vB = { B, B };
f64v2 vb1 = { b1, b1 }, vb2 = { b2, b2 }, vb3 = { b3, b3 };
double x1 = 0, x2 = 0, x3 = 0;
f64v2 x32 = { 0 }, x21 = { 0 };
for (int i = 0; i < 99; ) {
x3 = fma(b3, x3, fma(b2, x2, fma(B, one, x21[1] * b1)));
f64v2 x13b1 = { x21[1] * b1, x3 * b1 };
x32 = vfma(vb3, x32, vfma(vb2, x21, vfma(vB, vone, x13b1)));
x2 = fma(b3, x2, b2 * x1 + fma(B, one, x3 * b1));
f64v2 x13b2 = { b2 * x1, b2 * x32[0] };
x21 = vfma(vb3, x21, x13b2 + vfma(vB, vone, x32 * vb1));
x1 = fma(b3, x1, b2 * x32[0] + fma(B, one, b1 * x2));
printf("%d %g\t%a\n", i++, x32[0], x32[0]);
printf("%d %g\t%a\n", i++, x32[1], x32[1]);
printf("%d %g\t%a\n", i++, x21[1], x21[1]);
}
}
and here some of the redundantly computed values are computed differently
depending on where rounding after multiplication was omitted. Somehow this is
enough to make the computation explode numerically.
[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939
--- Comment #5 from Andrew Pinski ---
(In reply to Arseny Vakhrushev from comment #4)
> Thanks a lot, Andrew! Totally my bad. Well, comparison seems to work too:
>
> extern char _src[], _dst[], _end[]; // Defined by the linker
> int main(void) {
> char *src = &_src[0];
> char *dst = &_dst[0];
> char *end = &_end[0];
> while (src < end) *dst++ = *src++;
> return 0;
> }
>
> Are the asm("" : "+r" (p)) statements strictly needed?
The inline-asm is needed because in C it is undefined to compare pointers that
are from different arrays. Basically it is a way to hide it from the compiler.
[Bug target/55522] -funsafe-math-optimizations is unexpectedly harmful, especially w/ -shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522 --- Comment #22 from Brendan Dolan-Gavitt --- I think loading shared libraries from within threads is actually pretty common when shared libs are used as plugins for some GUI app. I made a graph of the reverse dependencies of Debian packages that contain shared libraries linking to crtfastmath.o, and you can see that most of them are related to A/V plugins (e.g. the largest cluster is from gstreamer-plugins-bad): https://moyix.net/~moyix/ffast_debian.pdf Granted, I think you could argue in this case that only affecting the thread that loaded the plugin is the *intended* behavior.
[Bug c++/106943] New: GCC building clang/llvm with LTO flags causes ICE in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 Bug ID: 106943 Summary: GCC building clang/llvm with LTO flags causes ICE in clang Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: immoloism at googlemail dot com Target Milestone: --- Created attachment 53574 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53574&action=edit ICE error I've found an interesting ICE which only occurs when LTO flags are turned on in GCC while building clang and llvm while compiling compiler-rt-sanitizers. If I rebuild clang/llvm without the flto cflags then the bug does not appear. CFLAGS used to build clang/llvm "-march=native -O2 -pipe -fgraphite-identity -floop-nest-optimize -flto=8 -fuse-linker-plugin -falign-functions=32" This is the first time I've run into anything like this so please ask if any other files or tests will help you identify the cause and I'd be happy to oblige. I have reported this to the LLVM team and they believe this could be an issue your end so hopefully you have some ideas to add.
[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 --- Comment #1 from Immolo --- https://github.com/llvm/llvm-project/issues/57740
[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 --- Comment #2 from Andrew Pinski --- Does it happen it you don't build with -fgraphite-identity -floop-nest-optimize ?
[Bug c/106939] Linker-defined symbols are stained due to 'array subscript is partly outside array bounds' warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106939
--- Comment #6 from Arseny Vakhrushev ---
Lots of thanks again, Andrew!
--
#include
#include
extern char _dst[], _src[], _end[];
int main(void) {
memcpy(_dst, _src, _end - _src);
uint32_t *dst = (uint32_t *)_dst;
uint32_t *src = (uint32_t *)_src;
uint32_t *end = (uint32_t *)_end;
while (src < end) *dst++ = *src++;
return 0;
}
---
Well, I hope I'm not doing anything terribly wrong, but the above works very
nice for me, looks clean, involves pointer arithmetics and doesn't produce any
warnings. I also can't really understand how it is possible for pointer
comparison to be undefined. If you could point me to the corresponding C
standard section, I would really appreciate that! Thanks a lot again!
[Bug target/106942] ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106942 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-09-14 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Started with r13-2111-g6910cad55ffc330d
[Bug fortran/106944] New: ICE in gfc_build_array_ref, at fortran/trans.cc:482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106944 Bug ID: 106944 Summary: ICE in gfc_build_array_ref, at fortran/trans.cc:482 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r10 between 20190825 and 20190901 : $ cat z1.f90 module m type t(n) integer, len :: n = 4 end type contains subroutine s(x) type(t(8)) :: x(..) select rank (x) end select end end $ cat z2.f90 module m type t(n) integer, kind :: n = 4 end type contains subroutine s(x) type(t(8)) :: x(..) select rank (x) end select end end $ gfortran-13-20220911 -c z1.f90 -fcheck=all z1.f90:10:6: 10 |end | 1 internal compiler error: Segmentation fault 0xd8cf5f crash_signal ../../gcc/toplev.cc:314 0x8671dd gfc_build_array_ref(tree_node*, tree_node*, tree_node*, bool, tree_node*) ../../gcc/fortran/trans.cc:482 0x86cc2c gfc_conv_descriptor_subfield ../../gcc/fortran/trans-array.cc:445 0x86cccd gfc_conv_descriptor_ubound ../../gcc/fortran/trans-array.cc:509 0x875828 gfc_conv_descriptor_ubound_get(tree_node*, tree_node*) ../../gcc/fortran/trans-array.cc:517 0x875828 gfc_full_array_size(stmtblock_t*, tree_node*, int) ../../gcc/fortran/trans-array.cc:8683 0x87b77e structure_alloc_comps ../../gcc/fortran/trans-array.cc:9035 0x87fb26 gfc_check_pdt_dummy(gfc_symbol*, tree_node*, int, gfc_actual_arglist*) ../../gcc/fortran/trans-array.cc:10285 0x8917d1 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*) ../../gcc/fortran/trans-decl.cc:4669 0x893b85 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.cc:7756 0x86ada9 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.cc:2369 0x815a4f translate_all_program_units ../../gcc/fortran/parse.cc:6658 0x815a4f gfc_parse_file() ../../gcc/fortran/parse.cc:6977 0x86350f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug fortran/106944] ICE in gfc_build_array_ref, at fortran/trans.cc:482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106944 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- Similar for these variants : $ cat z3.f90 module m type t(n) integer, len :: n = 4 end type contains subroutine s(x) type(t) :: x(..) select rank (x) end select end end $ cat z4.f90 module m type t(n) integer, kind :: n = 4 end type contains subroutine s(x) type(t) :: x(..) select rank (x) end select end end
[Bug fortran/106945] New: [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 Bug ID: 106945 Summary: [10/11/12/13 Regression] ICE: 'verify_gimple' failed Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r7, using option -fcoarray=single or -fcoarray=lib : (gcc configured with --enable-checking=yes) $ cat z1.f90 module m type t class(*), allocatable :: a[:] end type end $ gfortran-13-20220911 -c z1.f90 -ftrapv -fcheck=all -fcoarray=lib z1.f90:5:3: 5 | end | ^ Error: mismatching comparison operand types integer(kind=8) unsigned long if (_10 != 1) goto ; else goto ; z1.f90:5:3: internal compiler error: 'verify_gimple' failed 0xf8e34d verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.cc:5221 0xc07671 gimplify_body(tree_node*, bool) ../../gcc/gimplify.cc:16605 0xc07915 gimplify_function_tree(tree_node*) ../../gcc/gimplify.cc:16721 0xa20787 cgraph_node::analyze() ../../gcc/cgraphunit.cc:676 0xa23a66 analyze_functions ../../gcc/cgraphunit.cc:1240 0xa24c0d symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.cc:2500
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- No ICE with "program" instead of "module" : $ cat z2.f90 program p type t class(*), allocatable :: a[:] end type end
[Bug fortran/106946] New: [10/11/12/13 Regression] ICE in resolve_component, at fortran/resolve.cc:14726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106946 Bug ID: 106946 Summary: [10/11/12/13 Regression] ICE in resolve_component, at fortran/resolve.cc:14726 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with r9 between 20180819 and 20180826 : $ cat z1.f90 program p type t class(u), allocatable :: a b end type end $ cat z2.f90 module m type t class(u), allocatable :: a b end type end $ gfortran-9-20180819 -c z1.f90 z1.f90:3:30: 3 | class(u), allocatable :: a b | 1 Error: Derived type at (1) has not been previously defined and so cannot appear in a derived type definition $ gfortran-13-20220911 -c z1.f90 z1.f90:3:33: 3 | class(u), allocatable :: a b | 1 Error: Syntax error in data declaration at (1) z1.f90:1:9: 1 | program p | 1 Error: Argument 'src' of '_copy' with PASS(src) at (1) must be of the derived type '__class_p_U_a' f951: internal compiler error: Segmentation fault 0xf386bf crash_signal ../../gcc/toplev.cc:314 0x8781c2 resolve_component ../../gcc/fortran/resolve.cc:14726 0x878ca2 resolve_fl_derived0 ../../gcc/fortran/resolve.cc:15075 0x878fed resolve_fl_derived ../../gcc/fortran/resolve.cc:15207 0x872a67 resolve_symbol ../../gcc/fortran/resolve.cc:15584 0x891d72 do_traverse_symtree ../../gcc/fortran/symbol.cc:4174 0x876034 resolve_types ../../gcc/fortran/resolve.cc:17534 0x8714ac gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.cc:17649 0x8592a4 resolve_all_program_units ../../gcc/fortran/parse.cc:6606 0x8592a4 gfc_parse_file() ../../gcc/fortran/parse.cc:6862 0x8a7c6f gfc_be_parse_file ../../gcc/fortran/f95-lang.cc:229
[Bug c++/106943] GCC building clang/llvm with LTO flags causes ICE in clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943 --- Comment #3 from Immolo --- I just rebuilt to test and yes it does still fail with the graphite flags disabled with the same warnings.
[Bug fortran/106944] ICE in gfc_build_array_ref, at fortran/trans.cc:482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106944 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-14 --- Comment #2 from Martin Liška --- Started with r10-2912-g70570ec192745095.
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-14 CC||marxin at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r8-4344-gaea5e9327a49bc73.
[Bug fortran/106946] [10/11/12/13 Regression] ICE in resolve_component, at fortran/resolve.cc:14726
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106946 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-09-14 CC||janus at gcc dot gnu.org, ||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Started with r9-2568-g00cad178a359da70.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #1 from Peter Bergner --- (In reply to Jakub Jelinek from comment #0) > When GCC is configured on powerpc64le-linux against glibc 2.26 or later (but > in theory also on older glibcs through libquadmath), there is full support > for IEEE 754 quad (on power8 in software, on power9 through hw support), so > I don't see why D shouldn't be supported in that case. I haven't tried building D on powerpc64le-linux before, so I don't know what the failure mode is. Are you saying we since we have the IEEE128 support in the compiler, we just need to enable it for D somehow (config file change?) or that there is some build error when we do build D on powerpc64le-linux? I'll kick off a build with D enabled to educate myself.
[Bug middle-end/106947] New: -Waddress + bool + pragma generates meaningless diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106947
Bug ID: 106947
Summary: -Waddress + bool + pragma generates meaningless
diagnostic
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at cs dot ucla.edu
Target Milestone: ---
I found this while testing Gnulib with gcc (GCC) 12.1.1 20220507 (Red Hat
12.1.1-1) on x86-64.
Compile the following with "gcc -Waddress -S t.c":
#pragma GCC diagnostic ignored "-Waddress"
int s;
_Bool e = &s;
int
main ()
{
int error = 0;
{
_Bool e1 = &s;
if (!e1)
error = 1;
}
return error;
}
The output is the meaningless diagnostic:
t.c: In function ‘main’:
t.c:2:5: note: ‘s’ declared here
2 | int s;
| ^
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #2 from Jakub Jelinek --- Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the only target that does: power*-*-linux*) LIBPHOBOS_SUPPORTED=yes LIBDRUNTIME_ONLY=yes ;; I believe the latter means it builds only a small part of libphobos and I think the reason is the long double stuff (I think D has float/double/real types and the last one is the largest floating point available). Now, because IBM extended and IEEE quad are effectively unordered (neither is subset nor superset of the other), it is hard to determine which one is actually larger, but IEEE quad has both higher exponent range and larger mantissa precision for most of number, it is just those cases closely around values representable in double that can have higher precision in IBM extended.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #3 from Dan Horák --- a couple notes - you need to start with GCC 11 as GCC 12 needs an existing gdc compiler - the phobos/dmd standard library seems to support ieeequad type, learned from ldc, I believe they all share the same standard library - https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libphobos/configure.tgt;h=0063dd23249101b3506106ebbe32f454bcb829fb;hb=HEAD#l47 can go away, seems to build OK in GCC 11 without the line
[Bug tree-optimization/106905] [13 Regression] ia64: ICE in in vect_peel_nonlinear_iv_init, at tree-vect-loop.cc:8412 on zstd-1.5.2 since r13-2503-gc13223b790bbc5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106905 --- Comment #7 from Sergei Trofimovich --- The change fixed real zstd-1.5.2 build on ia64 as well. Thank you!
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
--- Comment #4 from Jakub Jelinek ---
I think the IEEE quad support isn't 100%, I see a couple of spots with:
static if (real.mant_dig > 64)
{
pragma(msg, "printFloat tests disabled because of unsupported `real`
format");
}
where real.mant_dig == 64 is the Intel extended format (and 53 is double
precision). IEEE quad is 113 though.
[Bug c/106947] -Waddress + bool + pragma generates meaningless diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106947
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |c
--- Comment #1 from Andrew Pinski ---
The bug is in the C front-end.
Specifically the bug is in maybe_warn_for_null_address which does not check the
return value of warning if it should do the inform.
Something like this will fix the issue:
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index d37de2a313b..59e384ac997 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -11619,6 +11619,7 @@ build_vec_cmp (tree_code code, tree type,
static void
maybe_warn_for_null_address (location_t loc, tree op, tree_code code)
{
+ bool do_note = false;
/* Prevent warnings issued for macro expansion. */
if (!warn_address
|| warning_suppressed_p (op, OPT_Waddress)
@@ -11706,17 +11707,17 @@ maybe_warn_for_null_address (location_t loc, tree op,
tree_code code)
return;
if (code == EQ_EXPR)
-warning_at (loc, OPT_Waddress,
+do_note = warning_at (loc, OPT_Waddress,
"the comparison will always evaluate as % "
"for the address of %qE will never be NULL",
op);
else
-warning_at (loc, OPT_Waddress,
+do_note = warning_at (loc, OPT_Waddress,
"the comparison will always evaluate as % "
"for the address of %qE will never be NULL",
op);
- if (DECL_P (op))
+ if (do_note && DECL_P (op))
inform (DECL_SOURCE_LOCATION (op), "%qD declared here", op);
}
[Bug c/106947] -Waddress + bool + pragma generates meaningless diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106947 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-09-14
[Bug c/106947] [12/13 Regression] -Waddress + bool + pragma generates meaningless diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106947 Andrew Pinski changed: What|Removed |Added Summary|-Waddress + bool + pragma |[12/13 Regression] |generates meaningless |-Waddress + bool + pragma |diagnostic |generates meaningless ||diagnostic Target Milestone|--- |12.3 --- Comment #2 from Andrew Pinski --- This is a regression from GCC 11.x which did not have this inform. The inform was added in r12-4059-g4dc7ce6fb39179 . What is interesting is the C++ front-end was done correctly but not the C front-end ...
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #5 from Jakub Jelinek --- BTW, for the case where -mabi=ieeelongdouble is the default unless there is some power* specific configuration in the library that needs to be done perhaps changing configure.tgt is all we need, but for the case where long double is IBM extended and only _Float128/__float128 is IEEE quad perhaps some compiler changes are needed too. I see stuff like: ireal_type_node = build_distinct_type_copy (long_double_type_node); TYPE_IMAGINARY_FLOAT (ireal_type_node) = 1; else if (TYPE_MAIN_VARIANT (basetype) == long_double_type_node || TYPE_MAIN_VARIANT (basetype) == ireal_type_node) fmodfn = builtin_decl_explicit (BUILT_IN_FMODL); etc. (e.g. grep for long_double_type_node or BUILT_IN_[A-Z0-9_]*L etc.) in the backend.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #6 from Dan Horák --- I don't disagree :-) Also the D stdlib code is difficult to readable for me with all the "version()" sections ...
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
--- Comment #7 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #5)
> BTW, for the case where -mabi=ieeelongdouble is the default unless there is
> some power* specific configuration in the library that needs to be done
> perhaps changing configure.tgt is all we need
Though, not sure even about that.
Because the -mabi={ibm,ieee}longdouble switch on the glibc/libm side is done
mostly through __asm redirection in preprocessor, while presumably code emitted
directly by the D compiler just hardcodes library API names (in that case it
should be using __*ieee128 or *f128 instead of *l), similarly for library calls
made from D source using some C compatibility if it has some; library sources
written in C would be fine.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #8 from Peter Bergner --- (In reply to Jakub Jelinek from comment #5) > BTW, for the case where -mabi=ieeelongdouble is the default unless there is > some power* specific configuration in the library that needs to be done > perhaps changing configure.tgt is all we need Maybe a dumb question, but do we really need to support IBM 128 extended format at all, regardless of whether long double is IBM128 or IEEE128? Meaning, since D is "new" and we have no backwards compatibility issues, can we just say D only supports IEEE128? ...assuming doing that can make things easier for us. (In reply to Dan Horák from comment #3) > - you need to start with GCC 11 as GCC 12 needs an existing gdc compiler Yeah, I found that out pretty quickly :-) > - > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libphobos/configure.tgt; > h=0063dd23249101b3506106ebbe32f454bcb829fb;hb=HEAD#l47 can go away, seems to > build OK in GCC 11 without the line Ah, but this is news to me. I'll kill my trunk build and remove that line and re-kick things off. Thanks!
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #9 from Peter Bergner --- (In reply to Jakub Jelinek from comment #2) > Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the > only target that does: > power*-*-linux*) > LIBPHOBOS_SUPPORTED=yes > LIBDRUNTIME_ONLY=yes > ;; It's interesting that the power*-*-freebsd*) target stanza doesn't have "LIBDRUNTIME_ONLY=yes".
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #10 from Iain Buclaw --- (In reply to Peter Bergner from comment #9) > (In reply to Jakub Jelinek from comment #2) > > Well, I certainly see libphobos/configure.tgt having powerpc*-linux* as the > > only target that does: > > power*-*-linux*) > > LIBPHOBOS_SUPPORTED=yes > > LIBDRUNTIME_ONLY=yes > > ;; > > It's interesting that the power*-*-freebsd*) target stanza doesn't have > "LIBDRUNTIME_ONLY=yes". Someone else tested that port. From what I recall, I did a spot check and saw that IBM128 is only supported on AIX, Darwin, and Linux-with-long-double-format=ibm. For all other Power ports, it's IEEE128 by default.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #11 from Jakub Jelinek --- Doesn't powerpc*-*-freebsd* use IEEE double long double? grep LONG_DOUBLE_SIZE * darwin.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 linux64.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 linux.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 rs6000.cc:#ifndef RS6000_DEFAULT_LONG_DOUBLE_SIZE rs6000.cc:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 64 And, sure, it would be ok to support only IEEE quad as D real for powerpc*-linux*, but then D can be only supported with -mvsx. Furthermore, dunno if D has its own math library or uses libm or both, if it doesn't have everything on its own, then it would need at least glibc 2.27 or later (the one with *f128 support) or perhaps 2.32 or which has __*ieee128 support.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #12 from Iain Buclaw --- (In reply to Jakub Jelinek from comment #11) > Doesn't powerpc*-*-freebsd* use IEEE double long double? > grep LONG_DOUBLE_SIZE * > darwin.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 > linux64.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 > linux.h:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 128 > rs6000.cc:#ifndef RS6000_DEFAULT_LONG_DOUBLE_SIZE > rs6000.cc:#define RS6000_DEFAULT_LONG_DOUBLE_SIZE 64 Could be that instead, yeah. > And, sure, it would be ok to support only IEEE quad as D real for > powerpc*-linux*, but then D can be only supported with -mvsx. Furthermore, > dunno if D has its own math library or uses libm or both, if it doesn't have > everything on its own, then it would need at least glibc 2.27 or later (the > one with *f128 support) or perhaps 2.32 or which has __*ieee128 support. Its sort of both. The core D runtime has libm C bindings (core/stdc/math.d), whereas the standard runtime implements its own (pure) math library (std/math/*.d).
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #13 from Peter Bergner --- (In reply to Peter Bergner from comment #1) > I'll kick off a build with D enabled to educate myself. Ok, I see the following on a powerpc64le-linux build on a system that defaults to long double == IBM128. I have access to a Fedora36 box that defaults to IEEE128 so I'll try a build there too. /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math/package.d:320:5: error: static assert: "Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs" 320 | static assert(real.mant_dig == 53 || real.mant_dig == 64 | ^ make[5]: *** [Makefile:1289: std/complex.lo] Error 1 make[5]: Leaving directory '/home/bergner/gcc/build/gcc-fsf-mainline-lang-D/powerpc64le-linux/libphobos/src' make[4]: *** [Makefile:484: all-recursive] Error 1 make[4]: Leaving directory '/home/bergner/gcc/build/gcc-fsf-mainline-lang-D/powerpc64le-linux/libphobos' make[3]: *** [Makefile:411: all] Error 2 make[3]: Leaving directory '/home/bergner/gcc/build/gcc-fsf-mainline-lang-D/powerpc64le-linux/libphobos' make[2]: *** [Makefile:23281: all-stage3-target-libphobos] Error 2 make[2]: Leaving directory '/home/bergner/gcc/build/gcc-fsf-mainline-lang-D' make[1]: *** [Makefile:28917: stage3-bubble] Error 2 make[1]: Leaving directory '/home/bergner/gcc/build/gcc-fsf-mainline-lang-D' make: *** [Makefile:1065: all] Error 2
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 --- Comment #14 from Peter Bergner --- Similar error on a long double == IEEE128 system: /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math.d:281:5: error: static assert "Only 64-bit, 80-bit, and 128-bit reals are supported for LittleEndian CPUs" 281 | static assert(real.mant_dig == 53 || real.mant_dig == 64 | ^
[Bug target/106942] ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106942 --- Comment #2 from Hongtao.liu --- It looks like similar as PR106887
[Bug fortran/106948] New: pure subroutine with pure procedure as dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106948 Bug ID: 106948 Summary: pure subroutine with pure procedure as dummy Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jfeng33 at hotmail dot com Target Milestone: --- Compiling the below code failed and gave the following error in which f was declared to be pure: 22 | x = int(f(real(x)) * 0.1) | 1 Error: Reference to impure function ‘f’ at (1) within a PURE procedure module a implicit none interface new pure module subroutine b(x, f) integer, intent(inout) :: x interface pure function f(x) result(r) real, intent(in) :: x real :: r end function f end interface end subroutine b end interface new end module a submodule(a) a_b implicit none contains module procedure b x = int(f(real(x)) * 0.1) end procedure b end submodule a_b program test use a implicit none integer :: x x = 10 call new(x, g) print *, x contains pure function g(y) result(r) real, intent(in) :: y real :: r r = sqrt(y) end function g end program test
[Bug target/106942] ICE in gen_lowpart_general, at rtlhooks.cc:57, or ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106942 Arseny Solokha changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Arseny Solokha --- Indeed, it does. *** This bug has been marked as a duplicate of bug 106887 ***
[Bug target/106887] ICE in extract_insn, at recog.cc:2791 since r13-2111-g6910cad55ffc330d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106887 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #1 from Arseny Solokha --- *** Bug 106942 has been marked as a duplicate of this bug. ***
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832 ibuclaw at gcc dot gnu.org changed: What|Removed |Added CC||ibuclaw at gcc dot gnu.org --- Comment #15 from ibuclaw at gcc dot gnu.org --- (In reply to Peter Bergner from comment #14) > Similar error on a long double == IEEE128 system: > > /home/bergner/gcc/gcc-fsf-mainline-lang-D/libphobos/src/std/math.d:281:5: > error: static assert "Only 64-bit, 80-bit, and 128-bit reals are supported > for LittleEndian CPUs" > 281 | static assert(real.mant_dig == 53 || real.mant_dig == 64 > | ^ Looks like you configured for IBM128 to me.
[Bug target/96072] [10/11/12 Regression] ICE: Segmentation fault (in add_reg_note)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96072 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Status|NEW |ASSIGNED Summary|ICE: Segmentation fault (in |[10/11/12 Regression] ICE: |add_reg_note) |Segmentation fault (in ||add_reg_note) --- Comment #7 from Kewen Lin --- I confirmed this is one regression, it passed with r10-7980 but started to fail with r10-7981. And it's reproducible on ppc64 be machine with options "-m32 -O1".
[Bug target/106550] [rs6000] sub-optimal 64bit constant generation for P10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106550 --- Comment #3 from CVS Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:7a3dfc23a910a47b6c1113b3a28a22858d0b9e7a commit r13-2679-g7a3dfc23a910a47b6c1113b3a28a22858d0b9e7a Author: Jiufu Guo Date: Mon Sep 5 13:36:10 2022 +0800 rs6000: Using pli(paddi) and rotate to build 64bit constants Hi, Test cases are updated/added, and code is refined as the comments in the review for previous version: https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600768.html As mentioned in PR106550, since pli could support 34bits immediate, we could use less instructions(3insn would be ok) to build 64bits constant with pli. For example, for constant 0x020805006106003, we could generate it with: asm code1: pli 9,101736451 (0x6106003) sldi 9,9,32 paddi 9,9, 213 (0x0208050) or asm code2: pli 10, 213 pli 9, 101736451 rldimi 9, 10, 32, 0 The asm code2 would be better. This patch generates the asm code2 in split1 pass, this patch also supports to generate asm code1 when splitter is only after RA. This patch pass boostrap and regtest on ppc64. P10 testing is running. Thanks for any comments! BR, Jeff(Jiufu) PR target/106550 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Use pli. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106550.c: New test. * gcc.target/powerpc/pr106550_1.c: New test.
[Bug d/106832] Missing powerpc64le-linux support for D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106832
--- Comment #16 from Dan Horák ---
Peter, what stage is it? A build on Fedora rawhide/ppc64le in the
releases/gcc-11 branch using
"./configure --enable-languages=d --enable-bootstrap
--with-long-double-format=ieee"
together with
@@ -44,7 +44,7 @@ case "${target}" in
;;
power*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
- LIBDRUNTIME_ONLY=yes
+# LIBDRUNTIME_ONLY=yes
;;
riscv*-*-linux*)
LIBPHOBOS_SUPPORTED=yes
finished successfully.
