On Thu, 13 Mar 2025 at 03:54, Patrick Palka wrote:
>
> On Wed, 12 Mar 2025, Patrick Palka wrote:
>
> > On Wed, 12 Mar 2025, Patrick Palka wrote:
> >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> > > perhaps 13?
OK for trunk and 14 and 13.
> > >
> > > N.B. the use of
We have long had the fold:
/* Pattern match
tem = (sizetype) ptr;
tem = tem & algn;
tem = -tem;
... = ptr p+ tem;
and produce the simpler and easier to analyze with respect to alignment
... = ptr & ~algn; */
But the gimple in gcc.target/aarch64/sve/pr98119.c has a var
On Thu, Mar 13, 2025 at 11:09 AM Matthias Klose wrote:
>
> the gcobol and gcobc binaries are currently installed without honoring
> the program prefix and program suffix. Honor these while installing.
>
> Ok for the trunk?
OK.
Thanks,
Richard.
> Matthias
>
On Thu, Mar 13, 2025 at 04:11:51PM +0100, Andreas Schwab wrote:
> On Mär 13 2025, Richard Biener wrote:
>
> > The following makes sure to record -D_FORTIFY_SOURCE=n and
> > -U_FORTIFY_SOURCE in the DW_AT_producer debuginfo attribute when
> > present on the compiler command line.
>
> Should this a
I discovered from some further testing that I broke 'import std' in some
cases with my last patch; this fixes that.
This still isn't sufficient I've found to fix PR119154 completely, as
there's still more cases where this assert fires due to performing
import_export_decl on non-DECL_REALLY_EXTERN
On Thu, Mar 13, 2025 at 03:51:15PM +0100, Richard Biener wrote:
> On Thu, 13 Mar 2025, Jakub Jelinek wrote:
>
> > On Thu, Mar 13, 2025 at 03:44:21PM +0100, Richard Biener wrote:
> > > + case OPT_D:
> > > + case OPT_U:
> > > + if (strncmp (options[i].arg, "_FORTIFY_SOURCE",
> > > +
On Thu, 13 Mar 2025, Jason Merrill wrote:
> On 3/13/25 3:54 AM, Richard Biener wrote:
> > On Thu, 13 Mar 2025, Jakub Jelinek wrote:
> >
> >> Hi!
> >>
> >> On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
> >>> On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> >>>
> On Tue, Mar 11, 2
Hi!
Apparently some programs in the wild use
#if __has_attribute(musttail)
__attribute__((musttail)) return foo ();
#else
return foo ();
#endif
clang supports musttail both as a standard attribute ([[clang::musttail]]
which we also support for compatibility) and the above worked just
fine with
Am 13.03.2025 um 12:49 schrieb Richard Biener:
On Thu, 13 Mar 2025, Sam James wrote:
Simon Sobisch writes:
Thanks for your work on adding a testsuite. Can you please explain why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work i
gcc.target/aarch64/sve/pr96357.c started failing after
r15-518-g99b1daae18c095d6, which tweaked the heuristics
about when to sink code. The testcase has:
double i = d, j = 1.0 - f, k = j ? d : j;
if (k == 1.0)
i = 0.0;
*l = *n = *g = *h = i * 0.5;
where k == 1.0 is false if j is zero (
On Thu, 13 Mar 2025, Tejas Belagod wrote:
> On 3/12/25 4:45 PM, Richard Biener wrote:
> > On Wed, 12 Mar 2025, Tejas Belagod wrote:
> >
> >> On 3/10/25 7:21 PM, Richard Biener wrote:
> >>> On Sat, 8 Mar 2025, Tejas Belagod wrote:
> >>>
> On 3/8/25 12:55 AM, Tejas Belagod wrote:
> > On 3/
Hi, thanks for the feedback!
I have sent a new version, keeping the match.pd patterns, fixing the
formatting issues and changing std::set to hash_set
(https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677526.html).
Konstantinos
On Mon, Mar 10, 2025 at 6:49 PM Andrew Pinski wrote:
>
> On Mon,
Hi Richard,
> Could you give details? I thought it was always known that trapped
> system register accesses were slow. In the previous versions, the
> checks seemed to be presented as an up-front price worth paying for
> faster atomic operations, on the systems that would use those paths.
> Now
> On Mar 12, 2025, at 12:40, Martin Uecker wrote:
>
> Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
>>
>>> On Mar 10, 2025, at 15:34, Martin Uecker wrote:
>>>
>>> Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
>>>
>>> ...
>>>
That said, my preferen
On Thu, Mar 13, 2025 at 10:00:48AM -0400, Jason Merrill wrote:
> On 3/13/25 3:54 AM, Richard Biener wrote:
> > On Thu, 13 Mar 2025, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
> > > > On Wed, 12 Mar 2025, Jakub Jelinek wrote:
> >
From: Tomasz Kamiński
This is another piece of P1206R7, adding new members to std::stack,
std::queue, and std::priority_queue.
PR libstdc++/111055
libstdc++-v3/ChangeLog:
* include/bits/stl_queue.h (queue(from_range_t, _Rg&&))
(queue(from_range_t, _Rg&&, const _Alloc&),
Wilco Dijkstra writes:
> Hi Richard,
>
>> Could you give details? I thought it was always known that trapped
>> system register accesses were slow. In the previous versions, the
>> checks seemed to be presented as an up-front price worth paying for
>> faster atomic operations, on the systems tha
On 3/13/25 3:54 AM, Richard Biener wrote:
On Thu, 13 Mar 2025, Jakub Jelinek wrote:
Hi!
On Wed, Mar 12, 2025 at 02:01:14PM +0100, Richard Biener wrote:
On Wed, 12 Mar 2025, Jakub Jelinek wrote:
On Tue, Mar 11, 2025 at 12:13:13PM +0100, Richard Biener wrote:
On Tue, 11 Mar 2025, Jakub Jelin
When I changed DECL_GIMPLE_REG_P over to DECL_NOT_GIMPLE_REG_P I
failed to update its description.
Pushed to trunk.
* tree.h (DECL_NOT_GIMPLE_REG_P): Update description.
---
gcc/tree.h | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/gcc/tree.h b/gcc/tree.h
The following makes sure to record -D_FORTIFY_SOURCE=n and
-U_FORTIFY_SOURCE in the DW_AT_producer debuginfo attribute when
present on the compiler command line.
We seem to want this internally now, not sure whether others also
need this (I'm happily carrying this downstream).
Bootstrapped on x86
Hello people!
This patch adds a link to the Algol 68 front-end development list to
lists.html. OK?
Thanks!
---
htdocs/lists.html | 5 +
1 file changed, 5 insertions(+)
diff --git a/htdocs/lists.html b/htdocs/lists.html
index 03e4a2a2..d5f1d3c8 100644
--- a/htdocs/lists.html
+++ b/htdocs/l
On Thu, Mar 13, 2025 at 03:44:21PM +0100, Richard Biener wrote:
> + case OPT_D:
> + case OPT_U:
> + if (strncmp (options[i].arg, "_FORTIFY_SOURCE",
> + strlen ("_FORTIFY_SOURCE")) == 0)
I'd say you want to verify that after that substring there is either
'\0' or "=".
* Jonathan Wakely:
> On Thu, 13 Mar 2025 at 09:24, Florian Weimer wrote:
>>
>> * Jonathan Wakely:
>>
>> > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
>> >>
>> >> * François Dumont:
>> >>
>> >> > + // Get hash code for a node that comes from another _Hashtable.
>> >> > + // Reus
On Thu, 13 Mar 2025, Richard Sandiford wrote:
> Updates in v2:
>
> - Make one of the pointer-arith-11.c scans require LP64, since
> the constant is printed differently for ILP32, and would be
> printed differently still for 16-bit targets.
>
> - Avoid use of element_precision in scalar-only
On Wed, 12 Mar 2025, Richard Sandiford wrote:
> Thanks for the review!
>
> Andrew Pinski writes:
> > On Wed, Mar 12, 2025 at 12:00 PM Richard Sandiford
> > wrote:
> >>
> >> Using a combination of rules, we were able to fold
> >>
> >> ((X >> C1) & C2) * (1 << C1) --> X & (C2 << C1)
> >>
> >>
On Thu, 13 Mar 2025 at 11:51, Florian Weimer wrote:
>
> * Jonathan Wakely:
>
> > On Thu, 13 Mar 2025 at 09:24, Florian Weimer wrote:
> >>
> >> * Jonathan Wakely:
> >>
> >> > On Thu, 13 Mar 2025 at 06:50, Florian Weimer wrote:
> >> >>
> >> >> * François Dumont:
> >> >>
> >> >> > + // Get has
Using a combination of rules, we were able to fold
((X >> C1) & C2) * (1 << C1) --> X & (C2 << C1)
if everything was done at the same precision, but we couldn't fold
it if the AND was done at a different precision. The optimisation is
often (but not always) valid for that case too.
This pat
Updates in v2:
- Make one of the pointer-arith-11.c scans require LP64, since
the constant is printed differently for ILP32, and would be
printed differently still for 16-bit targets.
- Avoid use of element_precision in scalar-only folds
- Use tree_int_cst_sgn instead of wi::to_widest.
Orig
> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
>
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".
> When executed in the initial "top-level" program-id, it results in
> the value 1 being passed back to
On Mon, Mar 10, 2025 at 11:59 PM Martin Jambor wrote:
>
> Hi,
>
> when reading the function ao_compare::compare_ao_refs I came accross
> what I believe to ba a copy-and-paste error which this patch fixes.
>
> Bootstrapped, LTO-bootstrapped and tested on x86_64-linux. OK for
> master?
OK. I'll n
Testcases for match.pd patterns
`((a ^ b) & c) cmp d | a != b -> (0 cmp d | a != b)` and
`(a ^ b) cmp c | a != b -> (0 cmp c | a != b)` were failing on some targets,
like PowerPC.
This patch adds an implemenetation for the optimization in reassoc. Doing so,
we can now handle cases where the relate
This is the second part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N2683.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implement
This is the first part of the P3370R1 proposal just approved by the
committee in Wrocław. This adds C++ equivalents of the functions added
to C23 by WG14 N3022.
These functions are in the global namespace, but to avoid collisions
with the same functions defined by other standard library
implementa
On Mär 13 2025, Richard Biener wrote:
> The following makes sure to record -D_FORTIFY_SOURCE=n and
> -U_FORTIFY_SOURCE in the DW_AT_producer debuginfo attribute when
> present on the compiler command line.
Should this also handle defines passed via -Wp?
--
Andreas Schwab, SUSE Labs, sch...@suse
Among other things, this testcase tests an addition of the four
values (n*4+[0:3])*9//2 for each n in [0:99]. The addition is
done in multiple integer and floating-point types and the test
is compiled with -ffast-math.
One of the floating-point types is _Float16, and as Andrew says
in the PR, _Fl
Since we have vcmp and vcmpe instructions (vcmpe raises an "Invalid
Operation" exception in presence of a NaN operand), we need to tell
the compiler it is not safe to reverse comparisons of floating-point
arguments.
On armv8-m.main+dsp+fp (cortex-m33):
PASS: gcc.dg/torture/builtin-iseqsig-1.c
at -
From: Sam James
Sent: Friday, March 7, 2025 11:39 PM
To: Prathamesh Kulkarni
Cc: Thomas Schwinge; Tobias Burnus; Joseph Myers; Xi Ruoyao; Matthew Malcomson;
gcc-patches@gcc.gnu.org; Tom de Vries
Subject: Re: [RFC] PR81358: Enable automatic linking of l
On Thu, Mar 13, 2025 at 01:45:43PM -0400, Jason Merrill wrote:
> On 3/13/25 11:27 AM, Jakub Jelinek wrote:
> Parsing a jump-statement under cp_parser_expression_statement just because
> it happens to start with __attribute is pretty strange.
It is true that it is pretty strange, but that is where
Hi James,
> Our intention, tell me if you disagree, is that cobol is enabled if
>
> 1. --enable-languages=all, and
> 2. the host and target are "known good", x86_64 or aarch64
you tend to forget there's a world outside of Linux, actually: as you
can see at least in PRs cobol/119217 and cobol/11
On Thu, 13 Mar 2025, JeanHeyd Meneide wrote:
> On Thu, Mar 13, 2025 Qing Zhao wrote:
>
> > ...
> >
> > Is N3188 the following:
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3188.htm
> >
> > What’s the status of this proposal?
>
>
> N3188 was discussed during the January 2024 Meeti
On Tue, 11 Mar 2025 11:18:22 +0100
Andreas Schwab wrote:
> > +
> > +# It's early days for COBOL, and it is known to compile on only
> > some host and +# target systems. We remove COBOL from other builds
> > with a warning. +
> > +cobol_is_okay_host="no"
> > +cobol_is_okay_target="no"
> > +
> >
On 3/13/25 3:16 PM, Jakub Jelinek wrote:
On Thu, Mar 13, 2025 at 01:45:43PM -0400, Jason Merrill wrote:
On 3/13/25 11:27 AM, Jakub Jelinek wrote:
Parsing a jump-statement under cp_parser_expression_statement just because
it happens to start with __attribute is pretty strange.
It is true that i
Introduce support for a new set of NEON square-root intrinsics for half,
single, and double precision.
modified: gcc/config/arm/arm-builtins.cc
1. Define the df_UP macro to map to E_DFmode.
2. Add CODE_FOR_neon_vsqrtsf and CODE_FOR_neon_vsqrtdf constants that
reference the underlying VFP sqrt
On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
> Thanks for your work on adding a testsuite. Can you please explain
> why
> you do this when a complete testsuite exists in autoconf (autotest)
> format (which roots back to decade of work in GnuCOBOL, with all
> copyrights for that alread
This patch introduces inline definitions for the __fma and __fmaf
functions in arm_acle.h for Aarch64 targets. These definitions rely on
__builtin_fma and __builtin_fmaf to ensure proper inlining and to meet
the ACLE requirements [1].
The patch has been tested locally using a crosstool-NG sysroot
This patch introduces inline definitions for the __fma and __fmaf
functions in arm_acle.h for arm targets. These definitions rely on
__builtin_fma and __builtin_fmaf to ensure proper inlining and to meet
the ACLE requirements [1].
The patch has been tested locally using a crosstool-NG sysroot for
On Thu, Mar 13, 2025 at 03:52:25PM -0400, Jason Merrill wrote:
> > > How about changing cp_parser_std_attribute_spec_seq in cp_parser_statement
> > > to cp_parser_attributes_opt?
> >
> > I'd be afraid that would be quite significant change of behavior everywhere,
> > something that C doesn't allow
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 14 after
a while?
-- >8 --
The type tuple> is clearly copy/move constructible, but for
reasons that are not yet completely understood checking this triggers
constraint recursion with our C++20 tuple implementation (and not the
C++17
On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > > + // Defined as a template to work around PR libstdc++/116440.
> > > + template
> > > + constexpr explicit(!__
On Thu, Mar 13, 2025 at 05:23:00PM -0400, Ayan Shafqat wrote:
> This patch introduces two new inline functions, __sqrt and __sqrtf, in
> arm_acle.h for Aarch64 targets. These functions wrap the new builtins
> __builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively,
> providing direct ac
On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
>
> On Thu, 13 Mar 2025, Ville Voutilainen wrote:
>
> > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > wrote:
> > >
> > > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > > > + // Defined as a template to work around PR libstdc++
On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > Do we also want to constraint the tuple(const _Elements&...)
> > constructor with requires sizeof...(_Elements) >= 1, which is present
> > on the C++17 version?
>
> Oh we don't need that constraint, because we have an explicit
> specializati
On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > Do we also want to constraint the tuple(const _Elements&...)
> > > constructor with requires sizeof...(_Elements) >= 1, which is present
> > > on the C++17 version?
> >
> > Oh we
On Thu, 13 Mar 2025, Simon Sobisch wrote:
>
> Am 13.03.2025 um 12:49 schrieb Richard Biener:
> > On Thu, 13 Mar 2025, Sam James wrote:
> >
> >> Simon Sobisch writes:
> >>
> >>> Thanks for your work on adding a testsuite. Can you please explain why
> >>> you do this when a complete testsuite exi
On Thu, 13 Mar 2025, Sam James wrote:
> Simon Sobisch writes:
>
> > Thanks for your work on adding a testsuite. Can you please explain why
> > you do this when a complete testsuite exists in autoconf (autotest)
> > format (which roots back to decade of work in GnuCOBOL, with all
> > copyrights f
Hi,
this patch fixes false incosistent profile error message seen when building
SPEC with
-fprofile-use -fdump-ipa-profile.
The problem is that with dumping tree_esitmate_probability is run in dry run
mode to report success rates of heuristics. It however runs
determine_unlikely_bbs
which ovewri
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/version.def (ranges_to_input): Define.
* include/bits/version.h: Regenerate.
* include/std/ranges (ranges::to_input_view): Define for C++26.
(views::__detai
On Thu, 13 Mar 2025, Jakub Jelinek wrote:
> On Thu, Mar 13, 2025 at 03:44:21PM +0100, Richard Biener wrote:
> > + case OPT_D:
> > + case OPT_U:
> > + if (strncmp (options[i].arg, "_FORTIFY_SOURCE",
> > +strlen ("_FORTIFY_SOURCE")) == 0)
>
> I'd say you want to verify t
> On Mar 12, 2025, at 18:46, Yeoul Na wrote:
>
>
>
>> On Mar 12, 2025, at 3:40 PM, Bill Wendling wrote:
>>
>> On Wed, Mar 12, 2025 at 3:28 PM Yeoul Na wrote:
On Mar 12, 2025, at 2:51 PM, John McCall wrote:
On 12 Mar 2025, at 16:02, Bill Wendling wrote:
> Qing pointed o
On Thu, Mar 13, 2025 Qing Zhao wrote:
> ...
>
> Is N3188 the following:
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3188.htm
>
> What’s the status of this proposal?
N3188 was discussed during the January 2024 Meeting in Strasbourg,
France. There was "along the lines" (opinion poll)
This adds missing documentation for LTO flags.
Ok?
gcc/ChangeLog:
* doc/invoke.texi: (Optimize Options):
Add incremental LTO flags.
---
gcc/doc/invoke.texi | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/d
Am Donnerstag, dem 13.03.2025 um 15:41 + schrieb Qing Zhao:
>
> > On Mar 12, 2025, at 12:40, Martin Uecker wrote:
> >
> > Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
> > >
> > > > On Mar 10, 2025, at 15:34, Martin Uecker wrote:
> > > >
> > > > Am Montag, dem 10.03.2025 u
Am Donnerstag, dem 13.03.2025 um 19:48 +0100 schrieb JeanHeyd Meneide:
> On Thu, Mar 13, 2025 Martin Uecker wrote:
>
>
...
> Part of this problem is self-inflicted: VLAs in structures are
> a GNU extension and not an ISO C feature (for reasons like this one).
Note that this has nothing to do
vect_slp_prefer_store_lanes_p allows an SLP tree to be split even
if the tree could use store-lanes, provided that one of the new
groups would operate on full vectors for each scalar iteration.
That heuristic is no longer firing for gcc.target/aarch64/pr99873_2.c.
The test contains:
void __attrib
Support for dynamic selectors in "declare variant" was developed in
parallel with support for the adjust_args/append_args clauses and the
dispatch construct; they collided in a bad way. This patch fixes the
"sorry" for calls that need both by removing the adjust_args/append_args
code from gimplify
On Thu, 13 Mar 2025, Jason Merrill wrote:
> > I'd be afraid that would be quite significant change of behavior everywhere,
> > something that C doesn't allow (like mixing std and GNU attributes in any
> > orders or [[]] __attribute__(()) [[]][[]] __attribute__(())
> > expression-statement). Or it
On Thu, 13 Mar 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 14 after
> a while?
>
> -- >8 --
>
> The type tuple> is clearly copy/move constructible, but for
> reasons that are not yet completely understood checking this triggers
> constraint recurs
Am 13.03.2025 um 21:35 schrieb David Malcolm:
On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
Thanks for your work on adding a testsuite. Can you please explain
why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work in GnuCOBO
This patch changes the `sqrt` builtin definition from `BUILTIN_VHSDF_DF`
to `BUILTIN_VHSDF_HSDF` in `aarch64-simd-builtins.def`, ensuring the
builtin covers half, single, and double precision variants. The redundant
`VAR1 (UNOP, sqrt, 2, FP, hf)` lines are removed, as they are no longer
needed now
This patch introduces two new inline functions, __sqrt and __sqrtf, in
arm_acle.h for Aarch64 targets. These functions wrap the new builtins
__builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively,
providing direct access to hardware instructions without relying on the
standard math lib
This patch introduces acle_sqrt.c in the AArch64 testsuite, verifying
that the new __sqrt and __sqrtf intrinsics emit the expected fsqrt
instructions for double and float arguments.
Coverage for new intrinsics ensures that __sqrt and __sqrtf are
correctly expanded to hardware instructions and do n
On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
wrote:
>
> On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > + // Defined as a template to work around PR libstdc++/116440.
> > + template
> > + constexpr explicit(!__convertible())
> > + tuple(const _Elements&... __elemen
On Thu, 13 Mar 2025 at 23:14, Patrick Palka wrote:
> Ah, I just realized the C++17 tuple impl already defines the
> tuple(const _Elements&...) constructor as a template in order to
> constrain it! So this patch arguably makes the C++20 constructor
> set more consistent with the C++17 impl, and so
On Thu, Mar 13, 2025 at 05:25:26PM -0400, Ayan Shafqat wrote:
> This patch introduces acle_sqrt.c in the AArch64 testsuite, verifying
> that the new __sqrt and __sqrtf intrinsics emit the expected fsqrt
> instructions for double and float arguments.
>
> Coverage for new intrinsics ensures that __s
On Thu, 13 Mar 2025, 22:28 Patrick Palka, wrote:
> On Thu, 13 Mar 2025, Jonathan Wakely wrote:
>
> > On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
> > >
> > > On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> > >
> > > > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > > > wrote:
> > > >
On Thu, Mar 13, 2025 at 06:33:08PM -0400, James K. Lowden wrote:
> I guess the most controversial engineering choice was to rely on
> __int128 and _Float128. Those gave us native processing and binary <->
> string conversion. Having been advised of real.cc, we're taking a
> look. If we can get 1
On 13/03/2025 08:22, Christophe Lyon wrote:
> Since we have vcmp and vcmpe instructions (vcmpe raises an "Invalid
> Operation" exception in presence of a NaN operand), we need to tell
> the compiler it is not safe to reverse comparisons of floating-point
> arguments.
>
> On armv8-m.main+dsp+fp (co
Apologies for the delay, had been waiting on some other relevant patches
to go in to make sure we didn't break any valid existing behaviours. It
should all be working properly now. I think I've also addressed all your
comments. Most notable change is that it now uses the 'sorry' mechanism.
Bo
> On Mar 13, 2025, at 12:29, Martin Uecker wrote:
>
> Am Donnerstag, dem 13.03.2025 um 15:41 + schrieb Qing Zhao:
>>
>>> On Mar 12, 2025, at 12:40, Martin Uecker wrote:
>>>
>>> Am Mittwoch, dem 12.03.2025 um 16:20 + schrieb Qing Zhao:
> On Mar 10, 2025, at 15:34, Martin Uec
On Thu, 13 Mar 2025 13:37:32 -0400
Paul Koning wrote:
> > 4. cast pointers formatted with %p as (void*)
>
> Could that be (const void *) instead?
Yes. Nothing is committed yet; I'll make that change first.
Could you explain why it matters, please, for my edification?
--jkl
On Tue, 11 Mar 2025 14:40:19 +0100 (CET)
Richard Biener wrote:
> > Looking at pretty much all of the above, it seems very Fortran
> > specific with its weird diagnostic output (capital Warning:/Error:,
> > the (1) and (2) in the diagnostics with later printing of those
> > lines and the like. Unl
> On Mar 12, 2025, at 12:58, Joseph Myers wrote:
>
> On Wed, 12 Mar 2025, Martin Uecker wrote:
>
>> For a designator
>>
>> struct foo { int n; } a = { .n = 1 };
>>
>> we also refer to a member 'n' of an instance 'a' of a structure type.
>> The instance is simply implied by the context.
>>
>
Dear all,
while testing different stuff using code from the initial commit,
I figured that I copy-pasted erroneous code that could lead to
an infinite loop which did not update its control variable,
and an unhandled REF_INQUIRY in a switch statement.
Fixed and committed as simple and obvious, al
On Thu, 6 Mar 2025 at 16:29, Jonathan Wakely wrote:
>
> On Wed, 29 Jan 2025 at 18:55, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, I suppose this is stage 1 material?
>
> Yes, I think so, since it could impact C++17 programs.
>
> OK for trunk as soon as stage 1 opens though, thanks.
"Andre Vieira (lists)" writes:
> Apologies for the delay, had been waiting on some other relevant patches
> to go in to make sure we didn't break any valid existing behaviours. It
> should all be working properly now. I think I've also addressed all your
> comments. Most notable change is that
On 3/13/25 11:16 AM, Nathaniel Shead wrote:
I discovered from some further testing that I broke 'import std' in some
cases with my last patch; this fixes that.
This still isn't sufficient I've found to fix PR119154 completely, as
there's still more cases where this assert fires due to performing
> On Mar 13, 2025, at 11:27 AM, James K. Lowden
> wrote:
>
> On Mon, 10 Mar 2025 19:10:26 +0100
> Richard Biener wrote:
>
>>> What is the right answer? Designated initializers are part of C99,
>>> but weren't added to C++ until C++20
>>> (https://en.cppreference.com/w/cpp/language/initiali
On 3/13/25 11:27 AM, Jakub Jelinek wrote:
Hi!
Apparently some programs in the wild use
#if __has_attribute(musttail)
__attribute__((musttail)) return foo ();
#else
return foo ();
#endif
clang supports musttail both as a standard attribute ([[clang::musttail]]
which we also support for comp
> On Mar 13, 2025, at 2:33 PM, James K. Lowden wrote:
>
> ...
> 3. --enable-languages=cobol, and
> 4. the host and target are "plausible", 64-bit LE.
Why does it need LE? I understand 64 bits. I might try it on my PowerPC based
Mac. :-)
paul
On Thu, Mar 13, 2025 Martin Uecker wrote:
> ...
>
> So it seems to be a possible way forward while avoiding
> language divergence and without introducing anything too novel
> in either language.
>
> (But others still have concerns about .n and prefer __self__.)
I would like to gently push
On Tue, 11 Mar 2025 at 17:21, Christophe Lyon
wrote:
>
> r14-7202-gc8ec3e1327cb1e added vld1xN and vst1xN intrinsics and some
> tests on arm, but didn't enable some existing tests.
>
> Since these tests are shared with aarch64, this patch replaces the
> 'dg-skip-if "unimplemented" { arm*-*-* }' di
On Thu, 13 Mar 2025 at 23:28, Patrick Palka wrote:
> > Oh, never mind. The pack is just deduced as an empty pack.
>
> Yep that's my understanding, though I don't know where in the standard
> this is specified, a quick Ctrl+F is failing me.
I'll go with https://eel.is/c++draft/temp.variadic#9, and
This plugs a small loophole in the pattern matching done by -fdump-ada-spec.
Tested on x86-64/Linux, applied on mainline, 14 and 13 branches.
2025-03-13 Eric Botcazou
PR ada/119265
* c-ada-spec.cc (dump_ada_node) : Deal with typedefs
of unsigned __int128.
--
Eric Bo
Based on the PR119214 discussion about "-O -ftracer" causing the assembler
to fail, I offer the following patch.
Okay for trunk? (Gives me shivers to say that the first time!)
Author: Robert Dubner
Date: Thu Mar 13 21:03:46 2025 -0400
COBOL: Prevent use of ASM_EXPR for optimized COBOL co
On Fri, 14 Mar 2025 at 00:04, Ville Voutilainen
wrote:
>
> On Fri, 14 Mar 2025 at 00:03, Ville Voutilainen
> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:57, Jonathan Wakely wrote:
> > > > Do we also want to constraint the tuple(const _Elements&...)
> > > > constructor with requires sizeof...(_Eleme
On Thu, 13 Mar 2025 14:45:23 -0400
Paul Koning wrote:
> > 3. --enable-languages=cobol, and
> > 4. the host and target are "plausible", 64-bit LE.
>
> Why does it need LE? I understand 64 bits. I might try it on my
> PowerPC based Mac. :-)
That's a good point. "Need" I don't know. I'm not
On Thu, 13 Mar 2025 at 21:54, Jonathan Wakely wrote:
>
> On Thu, 13 Mar 2025 at 21:29, Patrick Palka wrote:
> >
> > On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> >
> > > On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> > > wrote:
> > > >
> > > > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wr
On 3/12/25 10:57 AM, Nathaniel Shead wrote:
On Mon, Mar 10, 2025 at 02:52:07PM -0400, Jason Merrill wrote:
On 3/10/25 9:52 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
Or should this wait for GCC16?
-- >8 --
While looking at PR c++/119154 I notic
On Thu, Mar 13, 2025 at 01:37:37PM -0400, Jason Merrill wrote:
> On 3/13/25 11:16 AM, Nathaniel Shead wrote:
> > I discovered from some further testing that I broke 'import std' in some
> > cases with my last patch; this fixes that.
> >
> > This still isn't sufficient I've found to fix PR119154 co
This patch introduces two new inline functions, __sqrt and __sqrtf, in
arm_acle.h for Aarch64 targets. These functions wrap the new builtins
__builtin_aarch64_sqrtdf and __builtin_aarch64_sqrtsf, respectively,
providing direct access to hardware instructions without relying on the
standard math lib
1 - 100 of 132 matches
Mail list logo
