Bitmasks for constants are currently created only for trailing zeros.
There is no reason not to also include leading 1's in the value that are
also known.
Given a range such as [5,7], possible values in binary are 0101,
0110, 0111. we can conclude that not only are the leading
bitmask_intersection should not return immediately if the current mask
is unknown.
Unknown often means it is the default for a range, and this may interact
in interesting ways with the other bitmask, producing more precise results.
Bootstraps on x86_64-pc-linux-gnu with no regressions. Pus
On 5/9/25 13:27, Vineet Gupta wrote:
> FRM mode switching state machine has DYN as default state which it also
> fallsback to after transitioning to other states such as DYN_CALL.
> Currently TARGET_MODE_EMIT generates a FRM restore on any transition to
> DYN leading to spurious/extraneous FRM rest
The start_sequence/end_sequence interface was a big improvement over
the previous state, but one slightly awkward thing about it is that
you have to call get_insns before end_sequence in order to get the
insn sequence itself:
To get the contents of the sequence just made, you must call
`get_
This series makes end_sequence return the insn sequence that
it ends, so that callers don't need to call get_insns separately.
It also updates many callers to take advantage of the new return value.
Although this kind of refactoring/API change can in general make
backports harder, I think in this
This is the result of using a regexp to replace:
rtx( |_insn *) = end_sequence ();
return ;
with:
return end_sequence ();
gcc/
* asan.cc (asan_emit_allocas_unpoison): Directly return the
result of end_sequence.
(hwasan_emit_untag_frame): Likewise.
* config/
This patch mops up obvious redundancies that weren't caught by the
automatic regexp replacements in earlier patches. It doesn't do
anything with genemit.cc, since that will be part of a later series.
gcc/
* config/arm/arm.cc (arm_gen_load_multiple_1): Simplify use of
end_sequence.
This is the result of using a regexp to replace instances of:
= get_insns ();
end_sequence ();
with:
= end_sequence ();
where the indentation is the same for both lines, and where there
might be blank lines inbetween.
gcc/
* asan.cc (asan_clear_shadow): Use the return value of
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/cpplib/zh_CN.po
(This file, 'cpp
This patch is split into 4 parts in case one of them causes any issues,
it'll be easier to track.
In an attempt to make bitmasks on ranges a bit more consistent,
get_bitmask_from_range has uses outside value-range.cc. This patch
simply moves the static function into a constructor for irange_b
This patch improves op1_range for bitwise and operations. Previously we
did some basic attempts to determine a range but they often we not very
precise.
This leverages the previous changes and recognizes that any known bit on
the LHS of an AND that falls within the MASK must also be known in o
Recent changes to get_range_from_bitmask can sometimes turn a small
range into an undefined one if the bitmask indicates the bits make all
values impossible.
range_cast () was not expecting this and checks for UNDEFINED before
peforming the cast. It also needs to check for it after the cast
cpplib-15.1-b20250316.zh_CN.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
When the last format argument to a Tcl proc is named 'args' it has
special meaning and is a list that accepts any number of arguments[1].
This means when "" is passed to the proc and then we expand "$args" we
get an empty list formatted as "{}". My r16-537-g3e2b83faeb6b14 change
broke all uses of d
Subject: [PATCH] cobol: One additional edit to
testsuite/cobol.dg/group1/check_88.cob [PR120251]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Missed one edit. This fixes that.
gcc/testsuite/ChangeLog:
PR cobol/120251
* cobol.dg/group
Hi Jonathan,
> On Thu, 15 May 2025 at 15:02, Rainer Orth
> wrote:
>>
>> Hi Jonathan,
>>
>> >> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
>> >> > sparc-sun-solaris2.11:
>> >> >
>> >> > In file included from
>> >> > /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++20/format
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Chinese (simplified) team of translators. The file is available at:
https://translationproject.org/latest/gcc/zh_CN.po
(This file, 'gcc-15.1.
I noticed that I am missing deduction guides for function_ref.
Interestingly only function_ref has them, and not move_only_function,
copyable_function.
On Thu, May 15, 2025 at 5:00 AM Patrick Palka wrote:
>
>
> On Wed, 14 May 2025, Tomasz Kamiński wrote:
>
> > This patch implements C++26 functio
I noticed that fowprop does not dump when forward_propagate_into_comparison
did a change to the assign statement.
I am actually using it to help guide changing/improving/add match patterns
instead of depending on doing a tree "combiner" here.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/Chang
+CC @pinskia
On 5/10/25 06:55, Jeff Law wrote:
>
> On 5/9/25 2:27 PM, Vineet Gupta wrote:
>> gcc/ChangeLog:
>>
>> * emit-rtl.cc (next_nonnote_nondebug_insn): Update comments.
>>
>> Signed-off-by: Vineet Gupta
>> ---
>> gcc/emit-rtl.cc | 6 +-
>> 1 file changed, 5 insertions(+), 1 dele
1) Optimize (a >> 1) + (b >> 1) + ((a | b) & 1) to .AVG_CEIL (a, b)
2) Optimize (a | b) - ((a ^ b) >> 1) to .AVG_CEIL (a, b)
Prof is at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118994#c6
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR middle
On Wed, 14 May 2025, Tamar Christina wrote:
> > > > >
> > > > > - /* Loops vectorized with a variable factor won't benefit from
> > > > > + /* Loops vectorized would have already taken into account unrolling
> > specified
> > > > > + by the user as the suggested unroll factor, as such we nee
Dear all,
Here's my patch for PR120265. Bootstrapped and tested on aarch64 that it
causes no regressions. I also added a testcase. I'd be grateful
if you could commit it.
Otherwise, feedback to improve it is welcome.
Many thanks
MCCCS
From 1e901c3fa5c8cc3e55d4f1715b4aae4ae3d66714 Mon Sep 17 00
On Wed, May 14, 2025 at 9:18 PM Luc Grosheintz
wrote:
> The standard states that the IndexType must be a signed or unsigned
> integer. This mandate was implemented using `std::is_integral_v`. Which
> also includes (among others) char and bool, which neither signed nor
> unsigned integers.
>
> lib
On Wed, May 14 2025, David Malcolm wrote:
> On Thu, 2025-04-03 at 13:58 +0200, Rasmus Villemoes wrote:
>> In many setups, especially when CI and/or some meta-build system like
>> Yocto or buildroot, is involved, gcc ends up being invoked using
>> absolute path names, which are often long and unin
On Wed, May 14, 2025 at 10:46 PM Jonathan Wakely wrote:
> Use __builtin_signbit directly instead of std::signbit.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/complex (arg(T)): Use __builtin_signbit instead of
> std::signbit.
> ---
>
> This would avoid overload resolution for std
This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.
As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to const void*, so again we do not cast away const from
On Wed, 14 May 2025 at 20:18, Luc Grosheintz wrote:
>
> The standard states that the IndexType must be a signed or unsigned
> integer. This mandate was implemented using `std::is_integral_v`. Which
> also includes (among others) char and bool, which neither signed nor
> unsigned integers.
>
> libs
On Thu, 15 May 2025 at 11:14, Jonathan Wakely wrote:
>
> On Wed, 14 May 2025 at 20:18, Luc Grosheintz wrote:
> >
> > The standard states that the IndexType must be a signed or unsigned
> > integer. This mandate was implemented using `std::is_integral_v`. Which
> > also includes (among others) cha
Mild preference against; use the names from the standard, not the
implementation, in such diagnostics.
to 15. toukok. 2025 klo 13.20 Jonathan Wakely
kirjoitti:
> On Thu, 15 May 2025 at 11:14, Jonathan Wakely wrote:
> >
> > On Wed, 14 May 2025 at 20:18, Luc Grosheintz
> wrote:
> > >
> > > The s
Although Clang trunk has been adjusted to handle our std::format_kind
definition (because they need to be able to compile the GCC 15.1.0
release), it's probably better to not rely on something that they might
start diagnosing again in future.
Define the primary template in terms of an immediately
Am Do., 15. Mai 2025 um 13:00 Uhr schrieb Jonathan Wakely <
jwak...@redhat.com>:
> Although Clang trunk has been adjusted to handle our std::format_kind
> definition (because they need to be able to compile the GCC 15.1.0
> release), it's probably better to not rely on something that they might
>
During the GCC compilation, some warnings about temporary object dangling
references emerged. They appeared in these code lines in riscv-common.cc:
const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext_info =
get_riscv_ext_info (ext) and auto &ext_info = get_riscv_ext_info (search
On Thu, May 08, 2025 at 09:41:08PM +0800, Yangyu Chen wrote:
>
>
> > On 8 May 2025, at 18:36, Richard Sandiford
> > wrote:
> >
> > Yangyu Chen writes:
> >>> On 6 May 2025, at 17:49, Alfie Richards wrote:
> >>>
> >>> On 06/05/2025 09:36, Yangyu Chen wrote:
> > On 6 May 2025, at 16:01, Al
On Thu, 15 May 2025 at 12:15, Daniel Krügler wrote:
>
> Am Do., 15. Mai 2025 um 13:00 Uhr schrieb Jonathan Wakely
> :
>>
>> Although Clang trunk has been adjusted to handle our std::format_kind
>> definition (because they need to be able to compile the GCC 15.1.0
>> release), it's probably better
Please also add the message to dg-error check in format_kind_neg.cc.
With that LGTM.
On Thu, May 15, 2025 at 2:19 PM Jonathan Wakely wrote:
> On Thu, 15 May 2025 at 12:15, Daniel Krügler
> wrote:
> >
> > Am Do., 15. Mai 2025 um 13:00 Uhr schrieb Jonathan Wakely <
> jwak...@redhat.com>:
> >>
> >
No strong preference, but Ville's argument sounds reasonable.
On Thu, May 15, 2025 at 12:25 PM Ville Voutilainen <
ville.voutilai...@gmail.com> wrote:
> Mild preference against; use the names from the standard, not the
> implementation, in such diagnostics.
>
> to 15. toukok. 2025 klo 13.20 Jonat
This patch implements C++26 function_ref as specified in P0792R14,
with correction for constraints for constructor accepting nontype_t
parameter from LWG 4256.
As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
changed to const void*, so again we do not cast away const from
On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
Please also add the message to dg-error check in format_kind_neg.cc.
With that LGTM.
Yes, already done locally. Here's what I'm testing now.
commit 3c154b2d95d30580c18aa0fedd9e67200867653f
Author: Jonathan Wakely
AuthorDate: Thu May 15 11:0
On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely wrote:
> On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
> >Please also add the message to dg-error check in format_kind_neg.cc.
> >With that LGTM.
>
> Yes, already done locally. Here's what I'm testing now.
>
Any reason to not put the whole message
We should also back-port this commit to GCC-14.
Thanks,
Yangyu Chen
On 6/9/2024 07:07, Zhao Dingyi wrote:
This patch aims to add the missing instruction types to the XiangShan-Nanhu
scheduler model.
The current XiangShan -Nanhu model lacks the trap, atomic trap, fcvt_i2f, and
fcvt_f2i instruc
On Thu, 15 May 2025 at 13:43, Tomasz Kaminski wrote:
>
>
>
> On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely wrote:
>>
>> On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
>> >Please also add the message to dg-error check in format_kind_neg.cc.
>> >With that LGTM.
>>
>> Yes, already done locally. H
On Thu, May 15, 2025 at 2:53 PM Jonathan Wakely wrote:
> On Thu, 15 May 2025 at 13:43, Tomasz Kaminski wrote:
> >
> >
> >
> > On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely
> wrote:
> >>
> >> On 15/05/25 14:35 +0200, Tomasz Kaminski wrote:
> >> >Please also add the message to dg-error check in
> On 15 May 2025, at 14:01, Alice Carlotti wrote:
>
> On Thu, May 08, 2025 at 09:41:08PM +0800, Yangyu Chen wrote:
>>
>>
>>> On 8 May 2025, at 18:36, Richard Sandiford
>>> wrote:
>>>
>>> Yangyu Chen writes:
> On 6 May 2025, at 17:49, Alfie Richards wrote:
>
> On 06/05/2025
Hi Jonathan,
>> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
>> > sparc-sun-solaris2.11:
>> >
>> > In file included from
>> > /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++20/format.cc:29:
>> > /var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/incl
On Thu, 15 May 2025 at 13:56, Tomasz Kaminski wrote:
>
>
>
> On Thu, May 15, 2025 at 2:53 PM Jonathan Wakely wrote:
>>
>> On Thu, 15 May 2025 at 13:43, Tomasz Kaminski wrote:
>> >
>> >
>> >
>> > On Thu, May 15, 2025 at 2:41 PM Jonathan Wakely wrote:
>> >>
>> >> On 15/05/25 14:35 +0200, Tomasz K
On Thu, 15 May 2025 at 15:02, Rainer Orth wrote:
>
> Hi Jonathan,
>
> >> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
> >> > sparc-sun-solaris2.11:
> >> >
> >> > In file included from
> >> > /vol/gcc/src/hg/master/local/libstdc++-v3/src/c++20/format.cc:29:
> >> > /var/gcc/reg
> Hi,
>
> starting with GCC 15 the order is not unique for any symtab_nodes but
> m_uid is, I believe we ought to dump the latter in the ipa-clones dump,
> if only so that people can reliably match entries about new clones to
> those about removed nodes (if any).
>
> Bootstrapped and tested on x8
On Wed, May 14, 2025 at 02:46:15AM +, Kugan Vivekanandarajah wrote:
> Adding Eugene and Andi to CC as Sam suggested.
>
> > On 13 May 2025, at 12:57 am, Richard Sandiford
> wrote:
> >
> > External email: Use caution opening links or attachments
> >
> >
> > Kugan Vivekanandarajah writes:
> >>
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
The modules tests have used their own version of the code to run tests under
multiple standard versions; they should use the same one as other tests.
I'm not sure about continuing to run modules tests in C++17 mode, but I
guess we might as
This is a follow-up to the earlier patch that adds std::to_underlying to the
set of stdlib functions that are folded. We don't seem to need to handle
the same-type case specially, the folding will just do the right thing.
Also fix up the mistake of not tweaking the cmdline switch doc in the earlie
Status
==
The GCC 14 branch is now frozen for the GCC 14.3 release, a release
candidate is being prepared.
All changes to the branch require release manager approval.
Previous Report
===
https://gcc.gnu.org/pipermail/gcc/2025-April/245990.html
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Import didn't like differences in DECL_DECLARED_CONSTEXPR_P due to implicit
constexpr, breaking several g++.dg/modules tests; we should handle that
along with DECL_MAYBE_DELETED. For which we need to stream the bit.
gcc/cp/ChangeLog:
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Patrick pointed out that if the parm/arg types aren't complete yet at this
point, it would affect the type_has_converting_constructor and
TYPE_HAS_CONVERSION tests. I don't have a testcase, but it makes sense for
safety.
PR c++/995
On 5/14/25 4:48 PM, Patrick Palka wrote:
On Wed, 14 May 2025, Patrick Palka wrote:
On Wed, 14 May 2025, Jason Merrill wrote:
On 5/14/25 2:44 PM, Patrick Palka wrote:
On Wed, 14 May 2025, Patrick Palka wrote:
On Wed, 14 May 2025, Jason Merrill wrote:
On 5/12/25 7:53 PM, Patrick Palka wrot
On Thu, May 15, 2025 at 4:07 PM Jonathan Wakely wrote:
> On Thu, 15 May 2025 at 13:56, Tomasz Kaminski wrote:
> >
> >
> >
> > On Thu, May 15, 2025 at 2:53 PM Jonathan Wakely
> wrote:
> >>
> >> On Thu, 15 May 2025 at 13:43, Tomasz Kaminski
> wrote:
> >> >
> >> >
> >> >
> >> > On Thu, May 15, 20
Without would make sense to me, because whenever I wrote an
identifier with _ I felt like I was presenting the user with
a name that they shouldn't know about.
A pedantic question: Can I also fix the line below, or do
you prefer to be strict about one semantic change per commit?
On 5/15/25 2:40
On Thu, 15 May 2025 at 16:11, Luc Grosheintz wrote:
>
> Without would make sense to me, because whenever I wrote an
> identifier with _ I felt like I was presenting the user with
> a name that they shouldn't know about.
>
> A pedantic question: Can I also fix the line below, or do
> you prefer to
On Thu, 15 May 2025 at 16:12, Jonathan Wakely wrote:
>
> On Thu, 15 May 2025 at 16:11, Luc Grosheintz wrote:
> >
> > Without would make sense to me, because whenever I wrote an
> > identifier with _ I felt like I was presenting the user with
> > a name that they shouldn't know about.
> >
> > A pe
On Thu, 15 May 2025 at 18:19, Jason Merrill wrote:
> > @@ -3347,8 +3347,6 @@ cp_fold (tree x, fold_flags_t flags)
> > || id_equal (DECL_NAME (callee), "as_const")))
> > {
> > r = CALL_EXPR_ARG (x, 0);
> > - if (!same_type_p (TREE_TYPE (x), TREE_TYPE (r)))
>
This patch series adds support for the CMPBR extension. It includes the
new `+cmpbr` option and rules to generate the new instructions when
lowering conditional branches.
Testing done:
`make bootstrap; make check`
Karl Meakin (9):
AArch64: place branch instruction rules together
AArch64: refo
The `far_branch` attribute only ever takes the values 0 or 1, so make it
a `no/yes` valued string attribute instead.
gcc/ChangeLog:
* config/aarch64/aarch64.md (far_branch): Replace 0/1 with
no/yes.
(aarch64_bcond): Handle rename.
(aarch64_cbz1): Likewise.
The rules for conditional branches were spread throughout `aarch64.md`.
Group them together so it is easier to understand how `cbranch4`
is lowered to RTL.
gcc/ChangeLog:
* config/aarch64/aarch64.md (condjump): Move.
(*compare_condjump): Likewise.
(aarch64_cb1): Likewise.
On 5/15/25 10:36 AM, Ville Voutilainen wrote:
This is a follow-up to the earlier patch that adds std::to_underlying to the
set of stdlib functions that are folded. We don't seem to need to handle
the same-type case specially, the folding will just do the right thing.
Also fix up the mistake of n
Add rules for lowering `cbranch4` to CBB/CBH/CB when
CMPBR extension is enabled.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_1Kib): New constant.
(BRANCH_LEN_N_1Kib): Likewise.
(cbranch4): Emit CMPBR instructions if possible.
(cbranch4): New expand rul
Add the `+cmpbr` option to enable the FEAT_CMPBR architectural
extension.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (cmpbr): New
option.
* config/aarch64/aarch64.h (TARGET_CMPBR): New macro.
* doc/invoke.texi (cmpbr): New option.
---
gcc/config
Make the formatting of the RTL templates in the rules for branch
instructions more consistent with each other.
gcc/ChangeLog:
* config/aarch64/aarch64.md (cbranch4): Reformat.
(cbranchcc4): Likewise.
(condjump): Likewise.
(*compare_condjump): Likewise.
(aar
Move the rules for CBZ/TBZ to be above the rules for
CBB/CBH/CB. We want them to have higher priority
because they can express larger displacements.
gcc/ChangeLog:
* config/aarch64/aarch64.md (aarch64_cbz1): Move
above rules for CBB/CBH/CB.
(*aarch64_tbz1): Likewise.
gcc/
Commit the test file `cmpbr.c` before rules for generating the new
instructions are added, so that the changes in codegen are more obvious
in the next commit.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: Add `cmpbr` to the list of extensions.
* gcc.target/aarch64/cmpbr.c: N
Extract the hardcoded values for the minimum PC-relative displacements
into named constants and document them.
gcc/ChangeLog:
* config/aarch64/aarch64.md (BRANCH_LEN_P_128MiB): New constant.
(BRANCH_LEN_N_128MiB): Likewise.
(BRANCH_LEN_P_1MiB): Likewise.
(BRANCH_LE
Hi,
Here's the patch set. This time, feature complete, and fully tested
with no regressions. I'll send a reply with the test results in a
moment.
v22 changes:
- Move Link: tags to above the changelog, as Jason requested.
- Update the tests for -pedantic-errors. Some tests are now errors
gcc/ChangeLog:
* Makefile.in (USER_H): Add .
* ginclude/stdcountof.h: Add countof macro.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-stdcountof.c: Add tests for .
Signed-off-by: Alejandro Colomar
---
gcc/Makefile.in | 1 +
gcc/ginclude/stdcount
It has been standardized in C2y.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_sizeof_or_countof_expression):
Add -Wpedantic diagnostic for _Countof in <= C23 mode.
gcc/testsuite/ChangeLog:
* gcc.dg/countof-compat.c
* gcc.dg/countof-no-compat.c
* gcc.dg/counto
This operator is similar to sizeof but can only be applied to an array,
and returns its number of elements.
FUTURE DIRECTIONS:
- We should make it work with array parameters to functions,
and somehow magically return the number of elements of the array,
regardless of it being really a poin
Here's the test run. No regressions.
BTW, there are some differences between runs. I _think_ this is due to
running them in separate days, and having run 'make install' in between,
which seems to have made some tests that would normally fail now succeed
but that's unrelated to the feature, and i
On Thu, May 15, 2025 at 7:30 PM Jonathan Wakely wrote:
> When the last format argument to a Tcl proc is named 'args' it has
> special meaning and is a list that accepts any number of arguments[1].
> This means when "" is passed to the proc and then we expand "$args" we
> get an empty list formatt
On Thu, May 15, 2025 at 7:02 PM Andrew MacLeod wrote:
>
> Recent changes to get_range_from_bitmask can sometimes turn a small
> range into an undefined one if the bitmask indicates the bits make all
> values impossible.
>
> range_cast () was not expecting this and checks for UNDEFINED before
> pef
On Thu, May 15, 2025 at 8:22 PM Andrew Pinski wrote:
>
> I noticed that fowprop does not dump when forward_propagate_into_comparison
> did a change to the assign statement.
> I am actually using it to help guide changing/improving/add match patterns
> instead of depending on doing a tree "combiner
On Fri, May 16, 2025 at 1:05 AM Jeff Law wrote:
>
>
>
> On 5/15/25 11:18 AM, Richard Sandiford wrote:
> > The start_sequence/end_sequence interface was a big improvement over
> > the previous state, but one slightly awkward thing about it is that
> > you have to call get_insns before end_sequence
On Thu, May 15, 2025 at 7:46 PM Rainer Orth
wrote:
> Hi Jonathan,
>
> > On Thu, 15 May 2025 at 15:02, Rainer Orth
> wrote:
> >>
> >> Hi Jonathan,
> >>
> >> >> > this patch broke Solaris bootstrap, both i386-pc-solaris2.11 and
> >> >> > sparc-sun-solaris2.11:
> >> >> >
> >> >> > In file included
Hi Tomasz,
>> I've a local patch in tree to support __float128 on SPARC, so I'll try
>> with an unmodified tree first. However, 2 days ago I could bootstrap
>> with that included just fine.
>>
> Is __float128 a distinct type from long double, in case when both are
> 128bit?
> I have assumed that
LGTM!
Thanks for the Patch.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 15. Mai 2025 22:36:19 schrieb Harald Anlauf :
Dear all,
the attached patch fixes missing default-initialization of function
results of derived type that happens under some conditions, see PR.
The logic when default initia
An updated version of patch, that takes a safer approach on not declaring a
special formatter for __float128 if its long double is possibly IEEE 128.
Please let me know if that version addressed the problem on sparc. I
thinking there are more sparc machines in compiler farm, so I am going to
check
When a paradoxical subreg is detected, validate_subreg exits early, thus
skipping the important checks later in the function.
Fix by continuing with the checks instead of declaring early that the
paradoxical subreg is valid.
One of the newly allowed subsequent checks needed to be disabled for
par
Commit r16-160-ge6f89d78c1a752 exposed that validate_subreg is
skipping important checks for paradoxical subregs, which manifested as a
regression for pru-unknown-elf. This patch series is enabling some of
the skipped checks, and adds one more for hardware subreg mode validity.
Changes since v1:
After r16-160-ge6f89d78c1a752, late_combine2 started transforming the
following RTL for pru-unknown-elf:
(insn 3949 3948 3951 255 (set (reg:QI 56 r14.b0 [orig:1856 _619 ] [1856])
(and:QI (reg:QI 1 r0.b1 [orig:1855 _201 ] [1855])
(const_int 3 [0x3])))
(nil))
...
Dear all,
the attached patch fixes missing default-initialization of function
results of derived type that happens under some conditions, see PR.
The logic when default initialization is to be applied is rather
contorted, and reversing the order of two cases fixed the issue.
Regtesting revealed
On Thu, May 15, 2025 at 12:34 PM Dimitar Dimitrov wrote:
>
> After r16-160-ge6f89d78c1a752, late_combine2 started transforming the
> following RTL for pru-unknown-elf:
>
> (insn 3949 3948 3951 255 (set (reg:QI 56 r14.b0 [orig:1856 _619 ] [1856])
> (and:QI (reg:QI 1 r0.b1 [orig:1855 _20
On Thu, 15 May 2025 at 18:32, Ville Voutilainen
wrote:
>
> On Thu, 15 May 2025 at 18:19, Jason Merrill wrote:
>
> > > @@ -3347,8 +3347,6 @@ cp_fold (tree x, fold_flags_t flags)
> > > || id_equal (DECL_NAME (callee), "as_const")))
> > > {
> > > r = CALL_EXPR_ARG (x,
* git.html: Note that devel/omp/gcc-15 exists, and that the
corresponding gcc-14 branch is now stale.
---
htdocs/git.html | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 8edaa254..0b55a970 100644
--- a/htdocs
On 5/15/25 8:35 PM, Kito Cheng wrote:
Hm, it really doesn't make too much sense to get that warning, but
I can reproduce that when I compile with gcc 13 (and newer)...and
seems like a known issue [1][2]...
I still hadn't managed to convince myself the code was wrong. It looked
more like
While evaluating Shreya's logical AND synthesis work on spec2017 I ran
into a code quality regression where combine was failing to eliminate a
redundant sign extension.
I had a hunch the problem would be with the multiple sets of the same
pseudo register in the AND synthesis path. I was right
The previous check `_GLIBCXX_FORMAT_F128 != 1` was passing if
_GLIBCXX_FORMAT_F128 was not defined, i.e. evaluted to zero.
This broke sparc-sun-solaris2.11 and x86_64-darwin.
PR libstdc++/119246
libstdc++-v3/ChangeLog:
* include/std/format: Updated check for _GLIBCXX_FORMAT_F128
On Thu, May 15, 2025 at 9:17 AM Tomasz Kamiński wrote:
> The previous check `_GLIBCXX_FORMAT_F128 != 1` was passing if
> _GLIBCXX_FORMAT_F128 was not defined, i.e. evaluted to zero.
>
> This broke sparc-sun-solaris2.11 and x86_64-darwin.
>
> PR libstdc++/119246
>
> libstdc++-v3/ChangeLog:
On 5/14/25 6:26 AM, Nathaniel Shead wrote:
On Tue, May 13, 2025 at 12:40:30PM -0400, Jason Merrill wrote:
On 5/9/25 11:48 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
One slight concern I have is why we end up in 'maybe_thunk_body' to
start wit
0001-cobol-Don-t-display-0xFF-HIGH-VALUE-characters-in-te.patch
Description: Binary data
On 5/12/25 11:21 AM, Maciej W. Rozycki wrote:
On Tue, 25 Feb 2025, Maciej W. Rozycki wrote:
Address this issue by recursing into COMPONENT_REF tree nodes until the
outermost one has been reached, which is supposed to be a MEM_REF one,
accumulating the offset as we go, fixing a commit e0dae4d
On Sat, 10 May 2025 09:42:16 PDT (-0700), jeffreya...@gmail.com wrote:
On 5/10/25 6:30 AM, Jiawei wrote:
This patch introduces support for RISC-V Profiles RV20 and RV22 [1],
enabling developers to utilize these profiles through the -march option.
[1] https://github.com/riscv/riscv-profiles/re
On Thu, May 15, 2025 at 9:45 PM Rainer Orth
wrote:
> Hi Tomasz,
>
> >> I've a local patch in tree to support __float128 on SPARC, so I'll try
> >> with an unmodified tree first. However, 2 days ago I could bootstrap
> >> with that included just fine.
> >>
> > Is __float128 a distinct type from l
On 5/15/25 5:12 PM, Jonathan Wakely wrote:
On Thu, 15 May 2025 at 16:12, Jonathan Wakely wrote:
On Thu, 15 May 2025 at 16:11, Luc Grosheintz wrote:
Without would make sense to me, because whenever I wrote an
identifier with _ I felt like I was presenting the user with
a name that they sh
1 - 100 of 109 matches
Mail list logo
