[Bug middle-end/106831] [13 Regression] mpfr-4.1.0 started failing 2 tests: tget_set_d64 and tget_set_d128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106831 --- Comment #13 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:5dba8b2a91376d0518eb21c69a0700f099aa9cc4 commit r13-2714-g5dba8b2a91376d0518eb21c69a0700f099aa9cc4 Author: Jakub Jelinek Date: Sat Sep 17 08:50:22 2022 +0200 [PR106831] Avoid propagating long doubles that may have multiple representations. Long doubles are tricky when it comes to considering singletons because small numbers and +-INF can have multiple representations for the same number. So we need to be very careful not to treat those as singletons, lest they be incorrectly propagated by VRP. This is similar to the -0.0 and +0.0 duality. In long doubles +INF can be represented with +INF in the MSB and either -0.0 or +0.0 in the LSB. Similarly for numbers that are exactly representable in DF. For example, 1.0 can be represented as either (1.0, +0.0) or (1.0, -0.0). This patch avoids treating these numbers as singletons. Note that NANs in long double format have a LSB of don't care, but this is irrelevant for singleton_p, because NANs are never considered singletons. Also, internally in the frange we store NANs as a pair of boolean flags indicating whether they are +NAN or -NAN, so we don't need any special treatment here for comparing range equality etc. We never see anything but the boolean flags. PR middle-end/106831 gcc/ChangeLog: * value-range.cc (frange::singleton_p): Avoid propagating long doubles that may have multiple representations.
[Bug target/106961] Testsuite failures after Command Line Tools update to v14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106961 --- Comment #2 from simon at pushface dot org --- For the moment, installing Command Line Tools version 13(.4) fixes this problem (people using Xcode need to revert that). I guess the long-term solution will depend on whether the missing libunwind component is deliberate or an oversight on Apple’s part.
[Bug libstdc++/98978] Consider packing _M_Engaged in the tail padding of T in optional<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978
--- Comment #6 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to andysem from comment #3)
> > Is there no way to improve standard components implementation? I'd imagine
> > you could provide the new implementation in the new version inline namespace
> > and still support the old ABI for backward compatibility.
>
> To give a more complete answer: Inline namespaces don't help, that's a myth.
>
> struct X { std::optional b; };
>
> Now one translation unit has X using the old ABI and one has X using the new
> ABI, but they're the same X. The fact that the two versions of optional are
> in different namespaces is no help at all. You still have an ABI break.
>
> We did it for std::string and it was a multi-year effort that caused
> disruption across the industry. It's not worth doing that again to save a
> few bytes in std::optional.
You could include a hash of all members' namespaces in the X's mangled name. Or
maybe add an attribute that would propagate a tag to the outer class' mangled
name. Yes, that's also an ABI change in itself, but a useful one that would
allow inline namespaces to become useful.
I think a way to improve standard library components is essential. If not
inline namespaces then something else. Otherwise there is no evolution path of
the standard library components.
[Bug libstdc++/103626] _GLIBCXX_HOSTED should respect -ffreestanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103626 --- Comment #6 from Arsen Arsenović --- Agreed. Now that I think about it, it'd be just as easy to spot errors if something in freestanding is relying on a hosted feature by just trying to #include those headers on a freestanding install, so more explicitly handling internal headers that aren't installed in freestanding would be redundant. I'll clean that up.
[Bug target/99184] [avr] wrong double to 16-Bit and 32-Bit integers in libgcc/libf7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99184 --- Comment #1 from Georg-Johann Lay --- As a work-around, one can cast to an intermediate 64-bit integer: // For [u]int64_t and uint32_t, do #include double x = 2.9; int x_int = (int) (int64_t) x; uint32_t x_u32 = (uint32_t) (uint64_t) x;
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 92505, which changed state. Bug 92505 Summary: Using mutable in constexpr https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/92505] Using mutable in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92505 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed for GCC 13.
[Bug ipa/105676] [12/13 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105676 paulober changed: What|Removed |Added CC||mibjst9as at mozmail dot com --- Comment #5 from paulober --- I have also problems with the newest version of GCC [12.2.0] suggesting pure when we have const, suggesting const when we have pure (for __atribute__ ((...))). You can find the code i'm reffering to tracted in this PR: https://github.com/pi-hole/FTL/pull/1428
[Bug target/106562] PRU: Inefficient code for zero check of 64-bit (boolean) AND result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106562 --- Comment #1 from Dimitar Dimitrov --- I explored setting REGMODE_NATURAL_SIZE=4 for PRU. This required adjustments in many places in middle end to use REGMODE_NATURAL_SIZE instead of word_mode. That however proved too intrusive. And I don't see how other targets would benefit. I'll instead go with defining an expansion of cbranchdi4 for PRU. That would be contained in the PRU backend only, and thus safer.
[Bug fortran/100132] Optimization breaks pointer association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100132
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to José Rui Faustino de Sousa from comment #1)
> Patch posted
>
> https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
The patch is technically fine and regtests ok, but was unfortunately never
reviewed.
The basic fix can be slightly shortened to:
diff --git a/gcc/fortran/trans-types.cc b/gcc/fortran/trans-types.cc
index 0ea7c74a6f1..c062a5b29d7 100644
--- a/gcc/fortran/trans-types.cc
+++ b/gcc/fortran/trans-types.cc
@@ -3054,12 +3054,23 @@ create_fn_spec (gfc_symbol *sym, tree fntype)
for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
if (spec_len < sizeof (spec))
{
- if (!f->sym || f->sym->attr.pointer || f->sym->attr.target
+ bool is_class = false;
+ bool is_pointer = false;
+
+ if (f->sym)
+ {
+ is_class = f->sym->ts.type == BT_CLASS && CLASS_DATA (f->sym)
+ && f->sym->attr.class_ok;
+ is_pointer = is_class ? CLASS_DATA (f->sym)->attr.class_pointer
+ : f->sym->attr.pointer;
+ }
+
+ if (f->sym == NULL || is_pointer || f->sym->attr.target
|| f->sym->attr.external || f->sym->attr.cray_pointer
|| (f->sym->ts.type == BT_DERIVED
&& (f->sym->ts.u.derived->attr.proc_pointer_comp
|| f->sym->ts.u.derived->attr.pointer_comp))
- || (f->sym->ts.type == BT_CLASS
+ || (is_class
&& (CLASS_DATA (f->sym)->ts.u.derived->attr.proc_pointer_comp
|| CLASS_DATA (f->sym)->ts.u.derived->attr.pointer_comp))
|| (f->sym->ts.type == BT_INTEGER && f->sym->ts.is_c_interop))
I can take care of it for you.
[Bug c++/106964] New: Requires expression produces incorrect result with templated lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106964
Bug ID: 106964
Summary: Requires expression produces incorrect result with
templated lambda
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric41293 at comcast dot net
Target Milestone: ---
Perhaps related bugs: PR99546, PR105222, PR105494.
The following
template concept structural = requires { []{}; };
static_assert(!structural);
fails compilation with
:2:15: error: static assertion failed
2 | static_assert(!structural);
|
using x86-64 gcc 12.2 on Godbolt with -std=c++20.
[Bug target/105932] Small structures returned incorrectly in i386 Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105932 Anthony Green changed: What|Removed |Added CC||green at redhat dot com --- Comment #3 from Anthony Green --- I can confirm this bug. I've been tearing my hair out all day over a series of libffi test case failures on 32-bit x86. Small structures aren't returned properly for the MS ABI.
[Bug target/100799] Stackoverflow in optimized code on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799 --- Comment #15 from Surya Kumari Jangala --- (In reply to Segher Boessenkool from comment #14) > What is the exact command line (and relevant configuration!) required to > reproduce this? The reduced testcase is: SUBROUTINE DGEBAL( JOB, N, ARRAY, LDA, ILO, IHI, SCALE, INFO ) CHARACTER JOB DOUBLE PRECISION ARRAY( LDA, * ), SCALE( * ) LOGICALNOCONV 140 CONTINUE DO 200 I = K, L C = DNRM2( L-K+1, ARRAY( K, I ), 1 ) R = DNRM2( L-K+1, ARRAY( I, K ), LDA ) ICA = IDAMAX( L, ARRAY( 1, I ), 1 ) CA = ABS( ARRAY( ICA, I ) ) IF( C.EQ.ZERO .OR. R.EQ.ZERO ) $ GO TO 200 IF( G.LT.R .OR. MAX( R, RA ).GE.SFMAX2 .OR. $ MIN( F, C, G, CA ).LE.SFMIN2 )GO TO 190 F = F / SCLFAC G = G / SCLFAC 190CONTINUE CALL DSCAL( N-K+1, G, ARRAY( I, K ), LDA ) 200 CONTINUE IF( NOCONV ) $ GO TO 140 END The options to use to reproduce: -mcpu=power8 -O2 -fPIC
[Bug debug/106955] [13 Regression] '-fcompare-debug' failure w/ -std=c++20 -O1 -ftree-parallelize-loops=2 -fno-ipa-sra --param ggc-min-expand=55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106955 --- Comment #1 from Arseny Solokha --- Created attachment 53589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53589&action=edit Reduced preprocessed testcase Unfortunately a 173K file is the best I could come up with after three days of reduction, though it fails the check w/ just -std=c++20 -O1 -fcompare-debug -ftree-parallelize-loops=2.
[Bug target/106959] [13 Regression] ICE in curr_insn_transform, at lra-constraints.cc:4168 (error: unable to generate reloads), or ICE in simplify_subreg, at simplify-rtx.cc:7405
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106959 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |13.0
[Bug tree-optimization/106963] [13 Regression] ICE in vect_gen_perm_mask_checked, at tree-vect-stmts.cc:8606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106963 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||needs-bisection
