On 2/13/25 7:09 PM, Jerry D wrote:
On 2/13/25 1:42 PM, Harald Anlauf wrote:
Am 12.02.25 um 21:49 schrieb Jerry D:
The attached patch is fairly obvious. The use of notify_std is changed
to a gfc_error. Several test cases had to be adjusted.
Regression tested on x86_64.
OK for trunk?
This is
From: Jeff Law
Date: Sat, 15 Feb 2025 09:19:42 -0700
> It's as reasonable as other methods such as turning it into a
> define_expand and emitting a conditional branch around the sequence when
> the count is zero.
Yeah, it would be "better" to avoid those extra instructions when the
count is kn
On 2/15/25 10:08 AM, Keith Packard wrote:
From: Jeff Law
Date: Sat, 15 Feb 2025 09:19:42 -0700
It's as reasonable as other methods such as turning it into a
define_expand and emitting a conditional branch around the sequence when
the count is zero.
Yeah, it would be "better" to avoid thos
On 2/12/25 2:22 PM, Jakub Jelinek wrote:
Or just go with that even for GCC 15 (completely untested and dunno if
something needs to be done about s = NULL passed to query or not) for
now, with the advantage that it can do something even for the cases where
type is not compatible with types of
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:54 PM EST
Subject: [PATCH] 5 new 'cobol' FE files
gcc/cobol/ChangeLog
* gcobc: New file.
* gcobol.1: New file.
* gcobol.3: New file.
* help.
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:55 PM EST
Subject: [PATCH] 10 new 'cobol' FE files
libgcobol/ChangeLog
* charmaps.h: New file.
* common-defs.h: New file.
* ec.h: New file.
"James K. Lowden" writes:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:52 PM EST
> Subject: [PATCH] 3 new 'cobol' FE files
>
> gcc/cobol/ChangeLog
> * cdf-copy.cc: New file.
> * lexio.cc: New file.
>
The following 15 patches constitute 134,033 lines of code in 97 files
to build and document the COBOL front end. The messages are
grouped by files in a more or less logical order. We have:
4K dir create gcc/cobol and libgcobol directories
8K pre introduce ChangeLog files
92K bl
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:52 PM EST
Subject: [PATCH] Add 'cobol' to 17 files
ChangeLog
* Makefile.def: Add libgcobol module and cobol language.
* Makefile.in: Add libgcobol module an
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:54 PM EST
Subject: [PATCH] 12 new 'cobol' FE files
gcc/cobol/ChangeLog
* posix/.gitignore: New file.
* posix/Makefile: New file.
* posix/README.md:
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:51 PM EST
Subject: [PATCH] 2 new 'cobol' FE files
gcc/cobol/ChangeLog
* ChangeLog: New file.
libgcobol/ChangeLog
* ChangeLog: New file.
---
gcc/cobol/Chan
>From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
From: "James K. Lowden"
Date: Sat 15 Feb 2025 12:50:51 PM EST
Subject: [PATCH] Add 'cobol' to 1 file
contrib/gcc-changelog/ChangeLog
* git_commit.py: Add libgcobol module and cobol language.
---
contrib/gcc-changelo
> It's as reasonable as other methods such as turning it into a
> define_expand and emitting a conditional branch around the sequence when
> the count is zero.
Thanks much. I suspect the cost of the PSW setting instructions is far
less than a branch, so how about this version which emits them o
"James K. Lowden" writes:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:52 PM EST
> Subject: [PATCH] Add 'cobol' to 17 files
The commit message summary (first line) should say something like the
email title, so
"James K. Lowden" writes:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:54 PM EST
> Subject: [PATCH] 12 new 'cobol' FE files
Please make sure the commit summaries reflect the contents.
>
> gcc/cobol/ChangeLog
>
On Sat, 2025-02-15 at 16:01 -0500, James K. Lowden wrote:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -
> 0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:53 PM EST
> Subject: [PATCH] 9 new 'cobol' FE files
>
> gcc/cobol/ChangeLog
> * cdf.y: New file.
>
On Sat, 2025-02-15 at 16:02 -0500, James K. Lowden wrote:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -
> 0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:53 PM EST
> Subject: [PATCH] 3 new 'cobol' FE files
>
> gcc/cobol/ChangeLog
> * gengen.cc: New file.
On Sat, 2025-02-15 at 16:02 -0500, James K. Lowden wrote:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -
> 0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:53 PM EST
> Subject: [PATCH] 2 new 'cobol' FE files
>
> gcc/cobol/ChangeLog
> * genapi.cc: New file.
On Sat, 2025-02-15 at 16:00 -0500, James K. Lowden wrote:
> The following 15 patches constitute 134,033 lines of code in 97 files
> to build and document the COBOL front end. The messages are
> grouped by files in a more or less logical order. We have:
I've replied to some of the patches with com
Committed - thanks!
Palmer Dabbelt 于2025年2月15日周六 01:16写道：
>
> On Thu, 13 Feb 2025 23:12:54 PST (-0800), ji...@linux.alibaba.com wrote:
> > When using riscv_v_abi, the return and arguments of the function should
> > be adequately checked to avoid ICE.
> >
> > PR target/118872
> >
> > gcc/Cha
When REG_UNUSED notes indicate that some result bytes are not
used by the following code, then there's no need to asm out them.
The patch uses such notes for the asm out of AND, IOR, XOR, PLUS, MINUS.
Passes without regressions. Ok for trunk?
Johann
--
AVR: Don't asm output operations for un
This patch executes avr_builtin_supported_p at a later time and in
avr_resolve_overloaded_builtin. This allows for better diagnostics
and avoids lto1 hiccups when a built-in decl is NULL_TREE.
Ok for trunk?
Johann
--
AVR: Diagnose unsupported built-ins in avr_resolve_overloaded_builtin.
This
Excerpts from liushuyu's message of Februar 13, 2025 10:00 pm:
> From: Zixing Liu
>
> gcc/ChangeLog:
> * config/rs6000/rs6000-d.cc: define ELFv1 and ELFv2
> version identifiers according to the target options.
>
> gcc/testsuite/ChangeLog:
> * gdc.dg/ppcabi.d: Add a test to te
On 2/14/25 9:38 AM, Alexey Merzlyakov wrote:
It fixes one of the PR108016 mis-optimization.
The patch adjusts expanding for __builtin_add/sub_overflow() on RV64 targets
to avoid unnecessary sext.w instructions.
It replaces expanded for ADD/SUB_OVERFLOW code:
r141:SI=r139:DI#0+r140:DI#0 ..
On 2/14/25 4:20 AM, Robin Dapp wrote:
Hi,
the test scanned for vmin and vmax instead of vminu and vmaxu.
This patch fixes that.
Will commit as obvious once the CI is OK with it.
Regards
Robin
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr117722.c: Scan for vminu and
On 2/14/25 4:21 AM, Robin Dapp wrote:
Hi,
my last fix wasn't sufficient. This patch just scans for the scalar
insns now.
Going to commit as obvious if the CI is happy.
Regards
Robin
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/reduc/reduc-8.c: Scan for add.
On 2/13/25 3:54 PM, Edwin Lu wrote:
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the following occurs
vsetvli a5,a1,e32,m1,tu,ma
vle32.v v2,
On Sat, 15 Feb 2025 08:47:16 PST (-0800), jeffreya...@gmail.com wrote:
On 2/13/25 3:54 PM, Edwin Lu wrote:
The instruction scheduler appears to be speculatively hoisting vsetvl
insns outside of their basic block without checking for data
dependencies. This resulted in a situation where the fol
Instead of a test with { target c++11_only } and another with
c++14_only and another with c++17 we can have a single test that uses
{ target c++11 }. This avoids needing to make edits to three very
similar tests.
Also fix the signatures for std::cbegin and std::cend which had the
wrong expression
Use a requires-clause on the partial specialization of the
__pmf_expects_stop_token variable template, which is used for the
extension that allows constructing std::jthread with a
pointer-to-member-function that accepts a std::stop_token argument.
Also add a comment referring to the related Bugzil
Add conditional noexcept to the remaining range access functions that
were not changed in r15-5669-g8692cb10e82e72. This is now being proposed
for C++26 by P3623R0 (not published yet).
libstdc++-v3/ChangeLog:
* include/bits/range_access.h (rbegin, rend, crbegin, crend):
Add condit
These should have been unsigned, but the static assertions are only in
the public std::bit_ceil and std::bit_width functions, not the internal
__bit_ceil and __bit_width ones.
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h (__find_next_valid_abi): Cast
__bit_ceil argum
This makes several functions in faster to compile, with fewer
expressions to parse and fewer instantiations of __numeric_traits
required.
libstdc++-v3/ChangeLog:
PR libstdc++/118855
* include/std/bit (__count_lzero, __count_rzero, __popcount):
Use type-generic built-ins w
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_base.h: Do not include .
---
Tested x86_64-linux. Pushed to trunk.
libstdc++-v3/include/bits/shared_ptr_base.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/shared_ptr_base.h
b/libstdc++-v3/include/bits/sh
From: Thomas Schwinge
As of Subversion r231013 (Git commit 00e5241831c1227615a45b7bcba29c393671cb3f)
"[PTX] Another libcall patch", only used 'nvptx_record_needed_fndecl' is
locally.
gcc/
* config/nvptx/nvptx.cc (nvptx_record_needed_fndecl): Tag as
'static'.
---
gcc/conf
The SCMPU instruction doesn't change the C and Z flags when the
incoming length is zero, which means the insn will produce a
value based upon the existing flag values.
As a quick kludge, adjust these flags to ensure a zero result in this
case.
Signed-off-by: Keith Packard
---
gcc/config/rx/rx.m
Hello world,
I just committed the fix for PR 11845 as obvious and simple, as
r15-7552-gfd00010ba21c04bddb20aef52f62de5636075067 .
Fix PR 118884, Lapack build failure.
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated s
Hello Harald,
the attached patch fixes inconsistent handling of passing derived type
actual arguments to scalar dummies with VALUE,OPTIONAL attribute.
As suggested by Tobias, we should consistently pass a hidden boolean
flag that indicates the presence or absence of the actual, similar to
the ca
On 2/14/25 4:27 AM, Robin Dapp wrote:
Hi,
this patch adds two bridge patterns for combine in order to fix the
widen-complicate tests that regressed since GCC 14.
They key is to allow combination with a ephemeral binary-operation insn
that widens its first operand. This can subsequently be c
On 2/15/25 3:31 AM, Keith Packard wrote:
The SCMPU instruction doesn't change the C and Z flags when the
incoming length is zero, which means the insn will produce a
value based upon the existing flag values.
As a quick kludge, adjust these flags to ensure a zero result in this
case.
It's as
In our .sarif output from e.g.:
bad-binary-op.c: In function ‘test_4’:
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka
‘struct s’} and ‘T’ {aka ‘struct t’})
19 | return callee_4a () + callee_4b ();
| ^
|
Given the .sarif output from e.g.:
too-many-arguments.c: In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a';
expected 0, have 1
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void
Our SARIF output supplies "error" for the rule ID for DK_ERROR,
since a value is required, but it's not useful to print in sarif-replay.
Filter it out.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7563-gd022a068e0c858.
gcc/ChangeLog:
* libsarifrep
This adds support to sarif-replay to display fix-it hints
stored in GCC's SARIF output.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r15-7564-gd0d5204afff226.
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Call
handle_f
The PR indicates a very specific issue with regard to SSA coalescing
failures because there's a pre IV increment loop exit test. While
IVOPTs created the desired IL we later simplify the exit test into
the undesirable form again. The following fixes this up during RTL
expansion where we try to im
Am 14.02.25 um 19:19 schrieb Jerry D:
I think this is good to commit. (all 7 parts)
I think so too, with one caveat...
Does anyone else have any comments?
This patch series (of necessity) introduces ABI changes. What will
happen with user code compiled against the old interface?
I guess
(The *new* patch is attached.)
Hi, Jakub and Thomas~ I found some problems when compiling GCC, and it turns
out it was related to libgomp.
$ git clone ...
$ mkdir gcc-build
$ cd gcc-build
If I configure GCC with
$ CC=gcc-14 CXX=g++-14 CFLAGS=-DNDEBUG ../gcc/conf
On Sun, 16 Feb 2025 11:59:37 +0800, Jeff Law wrote:
>
>
> On 2/14/25 12:12 AM, Jin Ma wrote:
> > When using riscv_v_abi, the return and arguments of the function should
> > be adequately checked to avoid ICE.
> >
> > PR target/118872
> >
> > gcc/ChangeLog:
> >
> > * config/riscv/riscv.
On 2/14/25 12:12 AM, Jin Ma wrote:
When using riscv_v_abi, the return and arguments of the function should
be adequately checked to avoid ICE.
PR target/118872
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_fntype_abi): Strengthen the logic
of the check to avoid missi
On Sat, 2025-02-15 at 16:01 -0500, James K. Lowden wrote:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -
> 0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:52 PM EST
> Subject: [PATCH] 3 new 'cobol' FE files
>
[...]
> +/*
> + * Replace any separators in the co
On Sat, 2025-02-15 at 16:01 -0500, James K. Lowden wrote:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -
> 0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:53 PM EST
> Subject: [PATCH] 1 new 'cobol' FE file
>
+ if( ($$ & $2) == $2 ) {
+
On Sat, 15 Feb 2025 10:30:18 PST (-0800), jeffreya...@gmail.com wrote:
On 2/15/25 10:07 AM, Palmer Dabbelt wrote:
Since this is purely a performance related patch, gate the target hook
with an opt flag to see the fallout.
PR 117974
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sche
On 2/15/25 10:07 AM, Palmer Dabbelt wrote:
Since this is purely a performance related patch, gate the target hook
with an opt flag to see the fallout.
PR 117974
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_sched_can_speculate_insn):
(TARGET_SCHED_CAN_SPECULATE_INSN): Implement
"James K. Lowden" writes:
> From 5d53920602e234e4d99ae2d502e662ee3699978e 4 Oct 2024 12:01:22 -0400
> From: "James K. Lowden"
> Date: Sat 15 Feb 2025 12:50:53 PM EST
> Subject: [PATCH] 3 new 'cobol' FE files
>
> gcc/cobol/ChangeLog
> * gengen.cc: New file.
> * genmath.cc: New file.
>
Hello world,
I just committed Andrew's patch from the PR as obvious as
r15-7557-gbf84e5e64662f8f0fdebfc0212e32bfca678f9eb .
Best regards
Thomas
Remove defunct web site for site of Fortran preprocessor.
gcc/fortran/ChangeLog:
PR fortran/118159
* invoke.
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
Here during constant evaluation we encounter a VAR_DECL with DECL_VALUE_EXPR
of the RESULT_DECL, where the latter has been adjusted for
pass-by-invisible-reference. We already had the code to deal with this, we
just need to use it in the no
56 matches
Mail list logo
