On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> 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/ra
The following fixes a missing guard on slp_node in get_load_store_type.
Pushed as obvious.
PR tree-optimization/119166
* tree-vect-stmts.cc (get_load_store_type): Guard SLP tree
access.
---
gcc/tree-vect-stmts.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Hi Jerry,
thanks for the review. Committed as 87c7db8b1b2c1484d6de3331098669735d33f95e.
I also had it checked using the W3C validator w/o any errors. Therefore
committed.
Thanks again,
Andre
On Mon, 10 Mar 2025 10:01:46 -0700
Jerry D wrote:
> On 3/10/25 9:57 AM, Jerry D wrote:
> > On
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The PR119190 patch I've posted regresses the PR119120 testcase (not adding
> to testsuite, as it is fairly hard to scan for that problem).
> The issue is that for the partial setting of _Complex floating vars
> through __real__ on it first and _
Hi!
The PR119190 patch I've posted regresses the PR119120 testcase (not adding
to testsuite, as it is fairly hard to scan for that problem).
The issue is that for the partial setting of _Complex floating vars
through __real__ on it first and __imag__ later (or vice versa) and since
we forced all c
Another problem in pr110625_[24].c was that the latency calculations
were ignoring VEC_PERM_EXPRs that had no associated stmt_vec_info.
Such VEC_PERM_EXPRs are common and expected for SLP these days.
After this change, the number of general ops in the testcases seems
to be accurate apart from one
This patch changes the output on the simple test I tried from:
$ ./gcobol -B. hello.cob -S
hello.cob:2:8: error: syntax error, unexpected NAME, expecting FUNCTION or
PROGRAM-ID
2 |porgram-id. hello.
|^
cobol1: error: failed compiling hello.cob
to:
$ ./gcobol -B. hello.
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (ranges_to_input): Def
After r15-6660-g45d306a835cb3f865, in some cases
DFP constants would cause an ICE. This is due to
do a mismatch of a few things. The predicate of the move
uses aarch64_valid_fp_move to say if the constant is valid or not.
But after reload/LRA when can_create_pseudo_p returns false;
aarch64_valid_f
For many functions in tbz_2.c, it doesn't matter whether the code
tests a 32-bit or a 64-bit register. g6-g8 have started testing
32-bit registers, but the others could in future too.
Tested on aarch64-linux-gnu & pushed.
Richard
gcc/testsuite/
* gcc.target/aarch64/tbz_2.c: Accept both
Before r14-2877-gbf67bf4880ce5be0, the aarch64 code assumed that
every multi-vector reduction would use single def-use cycles.
The patch fixed it to test what the vectoriser actually planned
to do, using newly provided information.
At the time, we didn't try to use single def-use cycles for any co
On Fri, Feb 28, 2025 at 10:06:49AM +0100, Richard Biener wrote:
> > I've done 3 x86_64-linux and i686-linux bootstraps/regtests, each time
> > with the 3rd patch to gather statistics on number of successful ICF function
> > merges, and once with no further patches, once with the first patch and
> >
pr110625_[24].c started failing after r15-1329-gd66b820f392aa9a7,
which switched to single def-use cycles for single-lane SLP.
The problem is that we only costed one vector accumulator
operation for an N-vector cycle.
The problem seems to have been latent, and meant that we also
only costed one FA
On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> OK, I've done that and amended the set of testcases with one
> exercising dg-error. I had to prune the sprious
>
> cobol1: error: failed compiling t.cob
>
> message we emit. I don't see any warnings emitted from the frontend
> an
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> > OK, I've done that and amended the set of testcases with one
> > exercising dg-error. I had to prune the sprious
> >
> > cobol1: error: failed compiling t.cob
> >
> > message we emit.
> On 11 Mar 2025, at 14:30, Richard Biener wrote:
>
> On Tue, 11 Mar 2025, Richard Biener wrote:
>
>> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>>
>>> On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
OK, I've done that and amended the set of testcases with one
exerci
On Tue, Mar 11, 2025 at 02:45:33PM +, Iain Sandoe wrote:
> > The following incremental patch does this. The result has everything
> > needed but also some weird entries:
> >
> > Setting LD_LIBRARY_PATH to
> > .:/tmp/obj/x86_64-pc-linux-gnu/./libgcobol/.libs:/tmp/obj/x86_64-pc-linux-gnu/./lib
Hi!
My/Kees' earlier patches adjusted -Wunterminated-string-initialization
warning so that it doesn't warn about initializers of nonstring decls
and that nonstring attribute is allowed on multi-dimensional arrays.
Unfortunately as this testcase shows, we still warn about initializers
of multi-dime
Hi!
--enable-link-serialization relies on each FE participating properly,
setting .serial, depending on $(.prev) and printing progress.
The configure option is mainly for LTO bootstraps when we don't want to link
all the FEs at once because that can consume too much memory.
The comment changes ar
On 10/03/2025 21:48, Tobias Burnus wrote:
This patch requires the to be submitted GOMP_interop patch, which
handles the generic libgomp parts. But once it is available, this
patch adds support for the foreign runtimes cuda/cuda_driver/hip
for nvptx and hip/hsa for gcn.
The patch is based on my o
Hi,
The PR shows us spinning in dce.cc:fast_dce at the start of combine.
This spinning appears to be because of a disagreement between the fast_dce code
and the code in df-problems.cc:df_lr_bb_local_compute. Specifically, they
disagree on the treatment of partial defs. For the testcase in the PR
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> Seems the LANG_HOOKS_NAME change for COBOL broke debug info,
> in particular instead of DW_LANG_Cobol85 it is now DW_LANG_C.
>
> Fixed thusly, ok for trunk?
OK.
> 2025-03-11 Jakub Jelinek
>
> * dwarf2out.cc (gen_compile_unit_die): U
Hi!
Without this we can't commit anything refering to cobol/NN PRs.
Committed as obvious (and subsequently tested it with r15-7960 commit.
2025-03-11 Jakub Jelinek
* gcc-changelog/git_commit.py (bug_components): Add cobol.
--- contrib/gcc-changelog/git_commit.py.jj
+++ contrib/g
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> Looking at libgcobol.la, I see a lot of cruft, stuff that just shouldn't
> be there because automake generates it otherwise right, but also stuff
> using undefined variables etc.
> libgcobol.{a,so*} seems to build and install the same as before.
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 01:24:12PM +0100, Richard Biener wrote:
> > The following adds a simple cobol.dg test harness, based on gfortran.dg.
> > It's invoked by make check-cobol, has a single test that should pass.
> >
> > Running /home/rguenther/src/gc
Hello Kyrylo,
On Tue, Mar 11, 2025 at 08:55:46AM +, Kyrylo Tkachov wrote:
> This looks ok to me.
> GCC is currently in a regression fixing stage so normally such a change would
> wait until stage 1 reopens.
> But this looks like a pretty safe change so I’m not against taking it now.
> Do you
Hi!
On Tue, Mar 04, 2025 at 10:02:58AM +0100, Jakub Jelinek wrote:
> The following testcases (one with #embed, one with large initializer
> turned into RAW_DATA_CST) show that I forgot to handle RAW_DATA_CST in
> module streaming.
>
> Similar to the PCH case we need to stream out RAW_DATA_CST wit
Hi,
in the somewhat convoluted vector code of PR119114 we extracting
a mask value from a vector mask. After some
middle-end simplifications we end up with a value of -2. Its
lowest bit is correctly unset representing "false".
When initializing a bitmak vector from values we compare the full
va
On 11/03/2025 13:46, Torbjorn SVENSSON wrote:
Is it okay to backport below patch and r15-7890-gb7f5d911480 to
releases/gcc-14?
Yes, sure.
R.
Kind regards,
Torbjörn
On 2025-03-11 12:06, Richard Earnshaw wrote:
GCC will complain if the -mcpu flag specifies a different architecture
to that s
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 02:45:33PM +, Iain Sandoe wrote:
> > > The following incremental patch does this. The result has everything
> > > needed but also some weird entries:
> > >
> > > Setting LD_LIBRARY_PATH to
> > > .:/tmp/obj/x86_64-pc-linux-g
Am 11.03.25 um 10:22 schrieb Andre Vehreschild:
Hi Thomas,
looks good to me as well. Thanks for the patch.
Committed as r15-7964.
Thanks Harald and Andre!
Best regards
Thomas
gcc.target/aarch64/sve/pred-not-gen-[14].c started failing after
r15-268-g9dbff9c05520a74e, but we didn't look at it in time for
GCC 15. This patch marks the failures as expected for now.
We should revisit for GCC 16.
See the PR for some discussion about what a GCC 16 fix might
look like.
Tested
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/version.def (ranges_to_input): Def
Implement visit_format_arg and basic_format_arg::visit function,
in terms of _M_visit_user member functions, that wraps any type
stored inside basic_format_arg, that is not specified as standard
into the handle. This affects __in128, unsigned __in128,
PowerPC specific __iee128 and __ibm128, and _
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Mar 11, 2025 at 5:04 PM Patrick Palka wrote:
> On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka
> wrote:
> > Tested on x86_64-pc-linux-gnu, do
Andrew Pinski writes:
> After r15-6660-g45d306a835cb3f865, in some cases
> DFP constants would cause an ICE. This is due to
> do a mismatch of a few things. The predicate of the move
> uses aarch64_valid_fp_move to say if the constant is valid or not.
> But after reload/LRA when can_create_pseudo_
Am 10.03.25 um 22:34 schrieb Harald Anlauf:
the patch looks basically fine but I cannot find the testcase.
You're right, here it is.
Best regards
Thomas
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 20bf6e127ff..ef9c80147cc 100644
--- a/gcc/fortra
Hi!
The PR116463 r15-3128 change regressed the following testcase at -O0.
While for -O1+ we can do -fvar-tracking-assignments, for -O0 we don't
(partly because it is compile time expensive and partly because at -O0
most of the vars live most of their lifetime in memory slots), so if we
DCE some st
Hi,
This is v3 of the series comprising the final 4 outstanding changes. I
note that the corresponding v2 patches have been approved, but concerns
were discussed, which this update has addressed.
This series has come out of a discussion[1] around the removal of non-BWX
Alpha support from th
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:50:41AM +0100, Richard Biener wrote:
> > --- a/gcc/cobol/Make-lang.in
> > +++ b/gcc/cobol/Make-lang.in
> > @@ -364,3 +364,5 @@ cobol.stagefeedback: stagefeedback-start
> > -mv cobol/*$(objext) stagefeedback/cobol
> >
> >
Hi!
Seems the LANG_HOOKS_NAME change for COBOL broke debug info,
in particular instead of DW_LANG_Cobol85 it is now DW_LANG_C.
Fixed thusly, ok for trunk?
2025-03-11 Jakub Jelinek
* dwarf2out.cc (gen_compile_unit_die): Use DW_LANG_Cobol85 if
language_string is "GCC COBOL" rat
Hi!
When we know libgcobol is unsupported on 32-bit arches, we should just say
so in configure.tgt, the same way as on other targets.
Tested on x86_64-linux with --enable-languages=c,c++,cobol, ok for trunk?
2025-03-11 Jakub Jelinek
* configure.tgt: Only set LIBGCOBOL_SUPPORTED for l
On Mon, Mar 10, 2025 at 10:15:00AM +0100, Juergen Christ wrote:
> In legitimize_pic_address we create a
> (const (unspec ... UNSPEC_GOTENT))
> in the GOT offset might be >= 4k. However, the
> s390_delegitimize_address does not contain a case for this scenario.
>
> gcc/ChangeLog:
>
> * conf
Hi Iain,
> Tested on x86_64-darwin21 for
> --enable-languages=all
> => configure: WARNING: cobol not supported for this target
> --enable-languages=all,cobol
> => cobol is added to the languages to build.
>
> OK for trunk?
for the time being, I think it would be better to do this the
TL;DR without this change we get circa 2500 new fails in the gm2 testsuite
when PR119172 is fixed.
Recent increases in security constraints on macOS14+ (resulting in PR119172)
mean that the system will not fall back to using alternate shared libs than
the ones actually linked (when we fix 119172).
On Tue, Mar 11, 2025 at 10:45:09AM +0100, Andreas Schwab wrote:
> On Mär 11 2025, Jakub Jelinek wrote:
>
> > --- libgcobol/configure.tgt.jj 2025-03-11 09:18:22.133128278 +0100
> > +++ libgcobol/configure.tgt 2025-03-11 09:53:32.208959209 +0100
> > @@ -30,12 +30,16 @@ case "${target}" in
> >
The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has a single test that should pass.
There's sth not exactly working with respect to setting the
LD_LIBRARY_PATH, but fixing that externally results in
Running /home/rguenther/src/gcc/gcc/test
Hi Ayan,
> On 9 Mar 2025, at 21:46, Ayan Shafqat wrote:
>
> 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
Currently insn_cost() only considers the source part of a SET.
Implement TARGET_INSN_COST in order to also take the destination into
account. This may make a difference in case of a MEM where the address
is a SYMBOL_REF.
Fixes testsuite/gcc.target/s390/section-anchors.c.
gcc/ChangeLog:
The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has a single test that should pass.
There's sth not exactly working with respect to setting the
LD_LIBRARY_PATH, but fixing that externally results in
Running /home/rguenther/src/gcc/gcc/test
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> In GCC 12 we've switched to using *.cc suffixes for C++ sources in GCC
> sources, including generated files, instead of using *.c suffixes and
> compiling them as C++ anyway (that was the case since we've switched
> GCC to C++ in GCC 4.8).
> I'v
On Tue, Mar 11, 2025 at 01:24:12PM +0100, Richard Biener wrote:
> The following adds a simple cobol.dg test harness, based on gfortran.dg.
> It's invoked by make check-cobol, has a single test that should pass.
>
> Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
> FAIL: cobol.dg/
The following implements -fdump-tree-original dumping for cobol,
mimicing what the D frontend does.
OK?
Thanks,
Richard.
gcc/cobol/
* gengen.cc (gg_finalize_function): Dump to TDI_original.
---
gcc/cobol/gengen.cc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/cobol/gengen.c
Hi!
Sorry, seems I've screwed up the earlier libgcobol/configure.tgt change.
Looking in more detail, the way e.g. libsanitizer/configure.tgt works is
that it is sourced twice, once at toplevel and there it just sets
UNSUPPORTED=1 for fully unsupported triplets, and then inside of
libsanitizer/conf
On Tue, Mar 11, 2025 at 10:57:39AM +0100, Richard Biener wrote:
> The following makes sure to convert the folded expression to the
> original expression type.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> Thanks,
> Richard.
>
> PR middle-end/119204
> * builtins.cc
Floating points types _Float16, _Float32, _Float64, and bfloat16,
can be formatted only if std::to_chars overloads for such types
where provided. Currently this is only the case for architectures
where float and double are 32-bits and 64-bits IEEE floating points types.
This patch updates the prep
From: Yash Shinde
This patch addresses an issue in the C preprocessor where incorrect
line number information is generated when processing files with a
large number of lines. The problem arises from improper handling
of location intervals in the line map, particularly when locations
exceed LINE_M
On Mär 11 2025, Jakub Jelinek wrote:
> --- libgcobol/configure.tgt.jj2025-03-11 09:18:22.133128278 +0100
> +++ libgcobol/configure.tgt 2025-03-11 09:53:32.208959209 +0100
> @@ -30,12 +30,16 @@ case "${target}" in
> LIBGCOBOL_SUPPORTED=yes
> ;;
> powerpc64le-*-linux*)
> -
With non-BWX Alpha implementations we have a problem of data races where
a 8-bit byte or 16-bit word quantity is to be written to memory in that
in those cases we use an unprotected RMW access of a 32-bit longword or
64-bit quadword width. If contents of the longword or quadword accessed
outsi
Hi!
Looking at libgcobol.la, I see a lot of cruft, stuff that just shouldn't
be there because automake generates it otherwise right, but also stuff
using undefined variables etc.
libgcobol.{a,so*} seems to build and install the same as before.
Ok for trunk?
Note, I stull see DT_RUNPATH in the in
The following adds a simple cobol.dg test harness, based on gfortran.dg.
It's invoked by make check-cobol, has a single test that should pass.
Running /home/rguenther/src/gcc/gcc/testsuite/cobol.dg/dg.exp ...
FAIL: cobol.dg/pass.cob -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops
-ftracer
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The PR116463 r15-3128 change regressed the following testcase at -O0.
> While for -O1+ we can do -fvar-tracking-assignments, for -O0 we don't
> (partly because it is compile time expensive and partly because at -O0
> most of the vars live most o
On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> 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/ra
Tested on x86_64-darwin21 for
--enable-languages=all
=> configure: WARNING: cobol not supported for this target
--enable-languages=all,cobol
=> cobol is added to the languages to build.
OK for trunk?
thanks, Iain
--- 8< ---
By defult, Darwin does not have sufficient tools to build CO
On Tue, 11 Mar 2025, Rainer Orth wrote:
> Hi Iain,
>
> > Tested on x86_64-darwin21 for
> > --enable-languages=all
> > => configure: WARNING: cobol not supported for this target
> > --enable-languages=all,cobol
> > => cobol is added to the languages to build.
> >
> > OK for trunk?
>
>
Hi all,
After commit r15-4510, the following testcases also do not need XFAIL.
Ok for trunk?
Thx,
Haochen
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx512f-pr103750-1.c: Remove XFAIL.
* gcc.target/i386/avx512f-pr103750-2.c: Ditto.
* gcc.target/i386/avx512fp16-pr103750-
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 10:18:18AM +0100, Richard Biener wrote:
> > I think the patch as-is is more robust, but still - ugh ... I wonder
> > whether we can instead avoid introducing the COMPLEX_EXPR at all
> > at -O0?
>
> Can we set DECL_NOT_GIMPLE_REG_
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> The following testcase takes very long time to compile, because
> skip_simple_arithmetic decides to first call tree_invariant_p on
> the second argument (and indirectly recurse there). I think before
> canonicalization of operands for commutati
Hi Thomas,
looks good to me as well. Thanks for the patch.
Regards,
Andre
On Tue, 11 Mar 2025 07:11:53 +0100
Thomas Koenig wrote:
> Am 10.03.25 um 22:34 schrieb Harald Anlauf:
>
> > the patch looks basically fine but I cannot find the testcase.
>
> You're right, here it is.
>
> Best re
Hi!
In GCC 12 we've switched to using *.cc suffixes for C++ sources in GCC
sources, including generated files, instead of using *.c suffixes and
compiling them as C++ anyway (that was the case since we've switched
GCC to C++ in GCC 4.8).
I've noticed gcc/cobol has 3 generated files still with c ex
On Feb 18 2025, James K. Lowden wrote:
> @@ -2525,6 +2543,36 @@ directories, to avoid imposing the performance cost of
>missing_languages=`echo "$missing_languages" | sed -e "s/^,//" -e "s/,$//"`
>stage1_languages=`echo "$stage1_languages" | sed -e "s/^,//" -e "s/,$//"`
>new_enable_lan
On Tue, Mar 11, 2025 at 10:50:41AM +0100, Richard Biener wrote:
> --- a/gcc/cobol/Make-lang.in
> +++ b/gcc/cobol/Make-lang.in
> @@ -364,3 +364,5 @@ cobol.stagefeedback: stagefeedback-start
> -mv cobol/*$(objext) stagefeedback/cobol
>
> selftest-cobol:
> +
> +lang_checks += check-cobol
> di
On 11-03-2025 15:30, Jonathan Wakely wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender
and know the content is safe.
On 03/03/25 03:05 -0800, yash.shi...@windriver.com wrote:
From: Yash Shinde
This
On 03/03/25 03:05 -0800, yash.shi...@windriver.com wrote:
From: Yash Shinde
This patch addresses an issue in the C preprocessor where incorrect line number
information is generated when processing
files with a large number of lines. The problem arises from improper handling
of location interv
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> Hi!
>
> --enable-link-serialization relies on each FE participating properly,
> setting .serial, depending on $(.prev) and printing progress.
> The configure option is mainly for LTO bootstraps when we don't want to link
> all the FEs at once because th
The following makes sure to convert the folded expression to the
original expression type.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
Thanks,
Richard.
PR middle-end/119204
* builtins.cc (fold_builtin_strcspn): Preserve the original
expression type.
Rename `emit_unlikely_jump' function to `alpha_emit_unlikely_jump', so
as to avoid namespace pollution, updating callers accordingly and export
it for use in the machine description. Make it return the insn emitted.
gcc/
* config/alpha/alpha-protos.h (alpha_emit_unlikely_jump):
On Tue, 11 Mar 2025, Richard Biener wrote:
> The following adds a simple cobol.dg test harness, based on gfortran.dg.
> It's invoked by make check-cobol, has a single test that should pass.
> There's sth not exactly working with respect to setting the
> LD_LIBRARY_PATH, but fixing that externally
The next change for Alpha will produce extra labels and branches in
reload, which in turn requires basic blocks to be split at completion.
We do this already for functions that can trap, so just extend the
arrangement with a check for the changed number of labels necessarily
implied by the extr
Similarly to data races with 8-bit byte or 16-bit word quantity memory
writes on non-BWX Alpha implementations we have the same problem even on
BWX implementations with partial memory writes produced for unaligned
stores as well as block memory move and clear operations. This happens
at the bo
On Tue, 11 Mar 2025, Iain Sandoe wrote:
> Tested on x86_64-darwin21 for
> --enable-languages=all
> => configure: WARNING: cobol not supported for this target
> --enable-languages=all,cobol
> => cobol is added to the languages to build.
>
> OK for trunk?
OK.
Thanks,
Richard.
> thank
GCC will complain if the -mcpu flag specifies a different architecture
to that specified in -march, but if the floating-point ABI is "soft",
then differences in the floating-point architecture features are
ignored.
However, the arm_libc_fp_abi checks whether we change the FP ABI by
adding -mfloat-
On Tue, 11 Mar 2025, Jakub Jelinek wrote:
> On Tue, Mar 11, 2025 at 01:24:53PM +0100, Jakub Jelinek wrote:
> > Sorry, seems I've screwed up the earlier libgcobol/configure.tgt change.
> > Looking in more detail, the way e.g. libsanitizer/configure.tgt works is
> > that it is sourced twice, once at
On Mon, Mar 10, 2025 at 7:07 PM James K. Lowden
wrote:
>
> On Mon, 10 Mar 2025 17:34:40 +0100
> Richard Biener wrote:
>
> > index 10a42cb1dd7..8e18ef1 100644
> > --- a/gcc/Makefile.in
> > +++ b/gcc/Makefile.in
> > ...
> > +# user-defined functions for GCOBOL
> > +udfdir = $(datadir)/gcobol/ud
On Mon, Mar 10, 2025 at 5:34 PM Richard Biener
wrote:
>
> On Sat, Mar 8, 2025 at 12:12 AM Robert Dubner wrote:
> >
> > Richard and Jakub, and everybody else who has offered advice and help
> >
> > I trust you realize that your message means Jim and I are reaching the top
> > of a mountain we've b
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
-- >8 --
build_over_call has:
t = build2 (MODIFY_EXPR, void_type_node,
build2 (MEM_REF, array_type, arg0, alias_set),
build2 (MEM_REF, array_type, arg, alias_set));
val
Hello world,
the attached patch makes sure that procedures from abstract
interfaces and dummy arguments are not put into the global
symbol table, and are not checked against global symbols.
Regression-tested. OK for trunk?
Best regards
Thomas
Abstract interfaces and dummy arguments ar
When we call loongarch_reassoc_shift_bitwise for
_alsl_reversesi_extend, the mask is in DImode but we are trying
to operate it in SImode, causing an ICE.
To fix the issue sign-extend the mask into the mode we want. And also
specially handle the case the mask is extended into -1 to avoid a
miss-op
Am Montag, dem 10.03.2025 um 16:45 -0400 schrieb John McCall:
> > On 10 Mar 2025, at 15:34, Martin Uecker wrote:
> > > > Am Montag, dem 10.03.2025 um 15:00 -0400 schrieb John McCall:
> > > > > > That said, my preference is still to just give preference to the
> > > > > > field name,
> > > > > > wh
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 e0dae4da4c45 ("Alpha:
> Also use tree information
> Am 10.03.2025 um 08:16 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase shows a bug in unwind-dw2-btree.h.
> In short, the header provides lock-free btree data structure (so no parent
> link on nodes, both insertion and deletion are done in top-down walks
> with some locking of ju
On Mon, Mar 10, 2025 at 03:51:29PM +0100, Konstantinos Eleftheriou wrote:
> Testcases for 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 moves the optimization to reasso
We are not supposed to diagnose missing input files.
Pushed.
gcc/cobol/
* gcobolspec.cc (lang_specific_driver): For OPT_print_* do
not error on no input files.
---
gcc/cobol/gcobolspec.cc | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/cobol/gcobolspec.cc b/
In https://gcc.gnu.org/contribute.html#patches we ask to use [PR]
without the Bugzilla component identifier and with no space between
'PR' and the number, but git_check_commit.py accepts all forms. The
patch enforces what we document.
Note that this would reject a few of the recent commits.
This patch is the C equivalent of commit r15-6512-gcf94ba812ca496 for C++,
to improve the location information for individual items in an OpenMP
variable list.
gcc/c/ChangeLog
PR c/118579
* c-parser.cc (c_parser_omp_variable_list): Capture location
information when KIND is
Hi!
I've rushed up the PR117178 multi-dimensional nonstring support. Before
a week off I've just bootstrapped/regtested the actual change, so
handle_nonstring_attribute/get_attr_nonstring_decl adjustments after playing
with simple short tests and left the testcases for the next day, where I've
ba
Dear all,
here's a patch that fixes a 15-regression (NULL pointer dereference)
and implements a missed check of SAVE of a COMMON in a BLOCK construct.
Two separate testcases, as the respective error messages occur at
different stages in the frontend.
Regtested on x86_64-pc-linux-gnu. OK for ma
Add missing move_constructible && regular_invocable constrains on functor type,
for invocations of `views::zip_transform` without range arguments.
libstdc++-v3/ChangeLog:
* include/std/ranges (_ZipTransform::operator()):
Add `move_constructible` and `regular_invocable` constraints
On 3/7/25 4:05 AM, Robin Dapp wrote:
Hi,
in PR119115 we end up with an orphaned
vsetvli zero,t1,e16,m1,ta,ma.
t1 originally came from another vsetvl that was fused from
vsetvli a4,a3,e8,mf2,ta,ma
vsetvli t1,a3,e8,mf2,ta,ma (1)
to
vsetvli zero,a3,e16,m1,ta,ma.
On Tue, 11 Mar 2025, Richard Biener wrote:
> On Tue, 11 Mar 2025, Jakub Jelinek wrote:
>
> > On Tue, Mar 11, 2025 at 02:40:19PM +0100, Richard Biener wrote:
> > > OK, I've done that and amended the set of testcases with one
> > > exercising dg-error. I had to prune the sprious
> > >
> > > cobol
1 - 100 of 175 matches
Mail list logo
