вт, 25 февр. 2025 г. в 20:23, Jakub Jelinek :
>
> Hi!
>
> As can be seen in gcc/po/gcc.pot:
> #: config/avr/avr.cc:2754
> #, c-format
> msgid "bad I/O address 0x"
> msgstr ""
>
> exgettext couldn't retrieve the whole format string in this case,
> because it uses a macro in the middle. output_opera
Add check for constrained auto type specifier in function declaration or
function type declaration with trailing return type. Issue error if such
usage is detected.
Test file renamed, and added a new test for type declaration.
Successfully bootstrapped and regretested on x86_64-pc-linux-gnu:
Adde
* Patrick Palka [2025-02-28 10:37:37]:
> Hi,
>
> On Fri, 28 Feb 2025, Da Xie wrote:
>
> > This bug comes from a missing check when a function declaration has a
> > late-specified return type and a constrained auto type specifier. By
> > adding such a check, we can catch such uses and diagnose t
For LL-SC loops, if the atomic operation has succeeded, the SC
instruction always imply a full barrier, so the barrier we manually
inserted only needs to take the account for the failure memorder, not
the success memorder (the barrier is skipped with "b 3f" on success
anyway).
Note that if we use
On 2/28/25 12:16 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/branches?
Yes.
-- >8 --
We crash because we generate
{[0 ... 1]={.low=0, .high=1}, [1]={.low=0, .high=1}}
which output_constructor_regular_field doesn't want to see. This
happens since
gcc:
PR target/69374
* doc/install.texi (Specific, *-*-freebsd*): Simplify description.
---
gcc/doc/install.texi | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index bc5263e5348..189b5f93a99 100644
--- a/gcc/doc/i
I found this little change locally, probably from when I reviewed the
original wording.
Pushed.
Gerald
---
htdocs/gcc-13/changes.html | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 49261e1b..4860c500 100644
On Sat, 1 Mar 2025 at 15:52, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> The attached patch implements the tuple protocol for std::complex (added
> by P2819R2 for C++26).
>
> Tested on x86-64 Linux. Beware that you need the latest GCC trunk,
> otherwise you'll get an ICE (PR 119045).
>
> It's also on
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> The ranges::move and ranges::move_backward algorithms are supposed to
> use ranges::iter_move(iter) instead of std::move(*iter), which matters
> for an iterator type with an iter_move overload findable by ADL.
>
> Currently those algorithms use std::_
On Fri, 14 Feb 2025, Gerald Pfeifer wrote:
> On Fri, 24 Jan 2025, David Malcolm wrote:
>> The attached patch adds a postprocessing step to "bin" that
>> turns e.g.
>> TEXT
>> to:
>> TEXT
> It looks like this is causing an issue for (at least) one of our pages.
>
> http://gcc.gnu.org/projects/c
Hi!
On Sat, Mar 01, 2025 at 02:25:01PM -0500, Lewis Hyatt wrote:
> FYI I think there is a typo in this fallback implementation for the
> not-HAVE_ATTRIBUTE_ALIAS case, first argument intended to be "size"
> rather than "s".
You're right.
It compiled with a warning:
../../gcc/ggc-common.cc: In fu
On Sat, Mar 1, 2025 at 3:41 AM Jakub Jelinek wrote:
> --- gcc/ggc-common.cc.jj2025-01-02 11:23:32.505293652 +0100
> +++ gcc/ggc-common.cc 2025-02-28 12:12:20.207598711 +0100
> @@ -119,6 +119,25 @@ ggc_mark_roots (void)
> }
>
> /* Allocate a block of memory, then clear it. */
> +#ifdef
Am 01.03.25 um 19:20 schrieb Steve Kargl:
On Sat, Mar 01, 2025 at 03:56:21PM +0100, Harald Anlauf wrote:
the attached patch fixes a front-end memleak that is seen when
running f951 under valgrind and while parsing invalid uses of
NULLIFY.
I had this in my tree for some time without any problem
On Sat, Mar 01, 2025 at 03:56:21PM +0100, Harald Anlauf wrote:
>
> the attached patch fixes a front-end memleak that is seen when
> running f951 under valgrind and while parsing invalid uses of
> NULLIFY.
>
> I had this in my tree for some time without any problems, in an
> attempt to further red
On 2/19/25 7:52 PM, Jin Ma wrote:
Are you suggesting that we should emit the rounding mode insn earlier or
incorporate the rounding mode into the pattern (in fact, there are already
operands[9]/reg FRM_REGNUM)? However, this doesn't seem to be effective
because the side effects of the roundi
On 2/19/25 11:20 PM, Xi Ruoyao wrote:
On Thu, 2025-02-20 at 10:31 +0800, Jin Ma wrote:
On Wed, 19 Feb 2025 21:53:32 +0800, Jeff Law wrote:
On 2/19/25 1:00 AM, Robin Dapp wrote:
As I mentioned before, this may not be a good solution, as it risks missing
other
optimization opportunities. A
Hello,
The attached patch implements the tuple protocol for std::complex (added
by P2819R2 for C++26).
Tested on x86-64 Linux. Beware that you need the latest GCC trunk,
otherwise you'll get an ICE (PR 119045).
It's also on Forge here
https://forge.sourceware.org/gcc/gcc-TEST/pulls/34
tog
On 2/24/25 3:22 AM, Yuriy Kolerov wrote:
zce must imply zcf but this rule was corrupted after
refactoring in 9e12010b5e724277ea. This may be observed
ater generating an .s file from any source code file with
-mriscv-attribute -march=rv32if_zce -mabi=ilp32 -S
options. A full march will be prese
On 2/25/25 12:05 PM, Yuriy Kolerov wrote:
Hi Jeff,
That check is performed in a lambda function:
{"zce", "zcf",
[] (const riscv_subset_list *subset_list) -> bool
{
return subset_list->xlen () == 32 && subset_list->lookup ("f");
}},
The typo was in a rule itself:
{"zcf"
On 2/27/25 1:17 PM, Jan Dubiec wrote:
When INT_TYPE_SIZE < BITS_PER_WORD gcc emits a call to an external ffs()
implementation instead of a call to "__builtin_ffs()" – see function
init_optabs() in /gcc/optabs-libfuncs.cc. External ffs()
(which is usually the one from newlib) in turn calls __bu
> Am 01.03.2025 um 09:59 schrieb Jakub Jelinek :
>
> Hi!
>
> As the comment in check_line says:
> /* get_buffer is not null terminated, but the sscanf stops after a number.
> */
> the buffer is not null terminated, there is line.length () to determine
> the size of the line. But unlike wh
Dear all,
the attached patch fixes a front-end memleak that is seen when
running f951 under valgrind and while parsing invalid uses of
NULLIFY.
I had this in my tree for some time without any problems, in an
attempt to further reduce leaks that obscure more significant
front-end issues, but am o
Hi!
As the comment in check_line says:
/* get_buffer is not null terminated, but the sscanf stops after a number. */
the buffer is not null terminated, there is line.length () to determine
the size of the line. But unlike what the comment says, sscanf actually
still requires null terminated st
cpplib-15-b20250216.fr.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
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 French team of translators. The file is available at:
https://translationproject.org/latest/cpplib/fr.po
(This file, 'cpplib-15-b20250216.
gcc/ChangeLog:
* config/loongarch/sync.md (UNSPEC_TI_FETCH_ADD): New unspec.
(UNSPEC_TI_FETCH_SUB): Likewise.
(UNSPEC_TI_FETCH_AND): Likewise.
(UNSPEC_TI_FETCH_XOR): Likewise.
(UNSPEC_TI_FETCH_OR): Likewise.
(UNSPEC_TI_FETCH_NAND_MASK_INVERTED): Like
> Am 01.03.2025 um 09:41 schrieb Jakub Jelinek :
>
> Hi!
>
> As analyzed by Andrew/David/Richi/Sam in the PR, the reason for the
> libgccjit ICE is that there are GC allocations with finalizers and we
> still mark ggc_internal_{,cleared_}alloc with ATTRIBUTE_MALLOC, which
> to the optimizers
If the vector is naturally aligned, it cannot cross cache lines so the
LSX load is guaranteed to be atomic. Thus we can use LSX to do the
lock-free atomic load, instead of using a lock.
gcc/ChangeLog:
* config/loongarch/sync.md (atomic_loadti_lsx): New define_insn.
(atomic_loadti
Hi!
As analyzed by Andrew/David/Richi/Sam in the PR, the reason for the
libgccjit ICE is that there are GC allocations with finalizers and we
still mark ggc_internal_{,cleared_}alloc with ATTRIBUTE_MALLOC, which
to the optimizers hints that nothing will actually read the state
of the objects when
Hi Andre,
This looks fine to me. You say that this is a regression. How far back does
it go?
OK for mainline and, if required, for backporting.
Thanks for the patch.
Paul
On Fri, 28 Feb 2025 at 15:54, Andre Vehreschild wrote:
> Hi all,
>
> on this regression I had to chew a longer time. Ass
30 matches
Mail list logo
