can see?
Ok, I'll wait a week and then do the backport and testing.
Peter
u-cpu=power8 -maltivec -mcmodel=large" } */
>
> This is okay.
>
> There's no pretty solution.
>
> Or we enable -mcmodel= for all powerpc targets and make it a nop for
> Darwin and PPC32 Linux.
...or we could create a mcmodel_ok effective target test that could be used.
Ie, keep the ugly wart in target-supports.exp.
Peter
ow, just use power10. */
> + if (rs6000_cpu == PROCESSOR_FUTURE)
> +return "future";
...but this doesn't.
Peter
/doc/invoke.texi mentioning Power to the list of architectures that
are enabling -free with the -O* options, which currently only mentions
Alpha, AArch64 and x86. Being good community participants, it'd be
good to add the missing riscv, sparc and h8300 when adding Power.
Peter
On 4/24/23 10:28 AM, Jakub Jelinek wrote:
> On Mon, Apr 24, 2023 at 10:23:06AM -0500, Peter Bergner wrote:
>> On 4/19/23 3:00 PM, Segher Boessenkool wrote:
>>> On Wed, Apr 19, 2023 at 11:23:07PM +0530, Ajit Agarwal wrote:
>>>>* common/config/rs6000/rs600
On 4/28/23 6:49 PM, Hans-Peter Nilsson wrote:
> On Fri, 28 Apr 2023, Jeff Law wrote:
>> So while what Ajit has done is a step forward, at some point the actual
>> details of the ABI need to be described in a way that can be checked and
>> consumed by REE.
>
> IIRC I als
e branches. Ok there too
assuming testing is clean? I can wait to push the gcc12 backport until
after the release.
Peter
If there is a homogeneous struct with float128 members, they should be
copied to vector register save area. The current code incorrectly copies
only the value of the first m
On 5/4/23 2:29 PM, Peter Bergner wrote:
> I'd like to pull in Dan's upstream libffi commit into trunk to fix a
> wrong code bug/testsuite failure on powerpc64le-linux with long double
> defaulting to ieee128. This passed bootstrap and regtesting with no
> regressions. Ok fo
On 2/6/23 1:25 AM, Richard Biener wrote:
> May I ask to consider delaying this to stage1 exactly because of this
> last reason?
That is our plan. We're just still working through the review so it's
ready when stage1 opens up.
Peter
power8 defaults for both of those. It's hard for me to believe that
--with-tune=power9 could hide the issue, but we'll try that configuration
too. Do you have any other configure options that might affect things?
Peter
er-mode CFI in the
> future (at least for developers who can recompile the runtime),
> so I use -fsanitize=cfi as a compilation option here.
Please don't. The various CFI-related build flags are confusing enough
without also having this inconsistency between Clang and GCC.
Peter
R_PAIR
added to power10's rs6000-cpu.def definition. That way, stxvp isn't generated
on Power10, but would be by default on any possible future cpus without
having to add a flag to those cpus rs6000-cpu.def entries.
Peter
On 6/7/22 4:24 PM, Segher Boessenkool wrote:
> On Tue, Jun 07, 2022 at 04:17:04PM -0500, Peter Bergner wrote:
>> I think I mentioned this offline, but I'd prefer a negative target flag,
>> something like TARGET_NO_STORE_VECTOR_PAIR that defaults to off, meaning we'd
>
flags. But if it is a negative flag, we have to explicitly clear it.
Ok, I completely forgot about this specific issue and its negative affect on
inlining, so I agree it's a bad idea. Request withdrawn. :-)
Peter
his passed bootstrap and regtesting with no regressions on powerpc64le-linux.
Ok for trunk? This is an issue in GCC 12 and 11 too. Ok for the release
branches after some burn-in on trunk?
Peter
gcc/
PR c/106016
* expr.cc (count_type_elements): Handle OPAQUE_TYPE.
gcc/testsuite/
On 2/25/21 9:40 PM, Peter Bergner wrote:
> On 2/25/21 7:09 PM, Segher Boessenkool wrote:
>> On Thu, Feb 25, 2021 at 07:05:26PM -0600, Peter Bergner wrote:
>>> The compat builtin patch was approved for backporting to GCC10, so we'll
>>> need this fix to go along with
On 2/11/21 2:22 PM, Peter Bergner wrote:
> The mma_assemble_input_operand predicate is too lenient on the memory
> operands it will accept, leading to an ICE when illegitimate addresses
> are passed in. The solution is to only accept memory operands with
> addresses that are valid f
On 2/23/21 5:18 PM, Peter Bergner wrote:
> On 2/23/21 4:53 PM, Segher Boessenkool wrote:
>> The patch is okay for trunk and for 10. Thank you!
>
> Fixed and pushed to trunk. I'll push the backport after a day or two
> of burn in on trunk. Thanks!
Pushed to gcc10, so fixed everywhere.
Peter
e.
This passed bootstrap and regtesting on powerpc64le-linux with no regressions.
Ok for the GCC 10 release branch?
Peter
gcc/
2021-03-16 Peter Bergner
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Handle
disassembling a vector pair vector by vector in little-end
On 3/17/21 10:45 AM, Segher Boessenkool wrote:
> On Tue, Mar 16, 2021 at 05:48:27PM -0500, Peter Bergner wrote:
>> This passed bootstrap and regtesting on powerpc64le-linux with no
>> regressions.
>> Ok for the GCC 10 release branch?
>
> Yes, this is okay. Thanks!
Ok, pushed. Thanks!
Peter
st in mma_assemble_input_operand exists in GCC 10, but I
have been unable to get it to ICE there with this test case. I assume
we still want to fix it there too? If so, ok for GCC 10 after some trunk
burn in?
Peter
gcc/
PR target/99842
* config/rs6000/predicates.md:
gcc/testsuite/
PR target/
I'd like to ping the following patch:
https://patchwork.ozlabs.org/project/gcc/patch/f96c751e-b534-e49c-d3ec-2b3567798...@linux.ibm.com/
Peter
On 6/14/21 12:08 PM, Jakub Jelinek wrote:
> On Wed, May 26, 2021 at 04:16:31PM -0500, Peter Bergner via Gcc-patches wrote:
>> Using an MMA builtin within an openmp parallel code block leads to an SSA
>> verification ICE on the temporaries we create while expanding the MMA
>>
and
GCC 10 after baking on trunk for a while?
Peter
gcc/
* config/rs6000/rs6000-builtin.def (BU_MMA_LD, BU_MMA_ST): New macros.
(__builtin_vsx_lxvp, __builtin_vsx_stxvp): New built-ins.
* config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Expand
lxvp and
On 6/30/21 3:56 PM, Peter Bergner wrote:
> The following patch is bootstrapping and regtesting on powerpc64le-linux.
> Ok for trunk if there are no regressions? Ok to backport to GCC 11 and
> GCC 10 after baking on trunk for a while?
Bootstrap and regression testing came back clean.
Peter
On 7/1/21 1:01 PM, Segher Boessenkool wrote:
> On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
>> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
>> The following patch adds support for them to GCC so that we stay in sync
>> with LLVM
On 7/1/21 1:01 PM, Segher Boessenkool wrote:
> On Wed, Jun 30, 2021 at 04:56:04PM -0500, Peter Bergner wrote:
>> LLVM added the __builtin_vsx_lxvp and __builtin_vsx_stxvp built-ins.
>> The following patch adds support for them to GCC so that we stay in sync
>> with LLVM
oo.
Correct. Basically any time we return an integral type (signed or unsigned)
type is smaller than the hard register we are returning it in, we can get these
unwanted sign/zero extensions.
I'm sure we have quite a few bugzillas mentioning the unneeded sign/zero
extends.
Peter
When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
for the MEM operand which causes an unrecognizable insn ICE. The solution
is to use the correct TMODE mode.
Is this ok for trunk and gcc12 assuming my bootstraps and regtests show
no regressions?
Peter
gcc/
PR
owerpc64le-linux. The fix was approved
by Vlad. Committed and pushed after bootstrap testing and checking there
were no testsuite regressions when compared to the commit before the
commit that caused the ICE.
Peter
gcc/
PR rtl-optimization/109179
* lra-constraints.cc (combine_r
On 3/17/23 5:35 PM, Peter Bergner wrote:
> When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
> for the MEM operand which causes an unrecognizable insn ICE. The solution
> is to use the correct TMODE mode.
>
> Is this ok for trunk and gcc12 assuming my
On 3/17/23 7:17 PM, Peter Bergner wrote:
> On 3/17/23 5:35 PM, Peter Bergner wrote:
>> When we expand the __builtin_vec_xst_trunc built-in, we use the wrong mode
>> for the MEM operand which causes an unrecognizable insn ICE. The solution
>> is to use the correct TMODE mode.
On 3/17/23 4:20 PM, Peter Bergner via Gcc-patches wrote:
> On 3/16/23 10:37 PM, Surya Kumari Jangala wrote:
>> The issue of suboptimal code exists even for integer return value and not
>> just bool return value. See
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784#c9
On 3/19/23 10:20 PM, Kewen.Lin via Gcc-patches wrote:
> Nice, OK for trunk and gcc12 branch, thanks!
Pushed to trunk and the GCC 12 release branch. Thanks.
Peter
ey are, 2) whether your
patch fixes them or could fix them. Thanks.
https://gcc.gnu.org/PR41742
https://gcc.gnu.org/PR65010
https://gcc.gnu.org/PR82940
https://gcc.gnu.org/PR107949
Peter
L, 1 },
./gcc/common/config/alpha/alpha-common.cc:{ OPT_LEVELS_2_PLUS, OPT_free,
NULL, 1 },
...maybe we should enable it too (in a separate patch) once yours goes in now
that it will actually do something for us? Thoughts?
I'll note the docs/man page only mention x86, Aarch64 and Alpha enabling REE at
-O2 and above, but clearly others have been added since, so if we enable REE at
-O2 and above, we should fix that too.
Peter
On 3/23/23 11:32 AM, Jeff Law via Gcc-patches wrote:
> On 3/23/23 10:29, Peter Bergner wrote:
>> I'm sorry that I don't know how REE works. Why can't it optimize this?
>> I see in the REE dump:
>>
>> (insn 20 18 22 3 (set (reg:DI 4 4)
>>
best to come up with some generic interface
using target hooks like "param regs are sign/zero extended" or "call return
values are sign/zero extended", etc. that targets can conditionally opt into
depending on their ABI that is in effect.
Peter
Tested cris-elf, bootstrapped & checked native
x86_64-pc-linux-gnu for good measure. Ok to commit?
If it wasn't for there already being an auto_inc_dec pass,
this looks like a good place to put it, considering the
framework data. (BTW, current auto-inc-dec generation is so
poor that you can repl
Since I don't see a quick fix at r14-1444-g3f4853a5f00fab, I
thought I'd better notify the author (I have written authors
if there was more than one ;-) of suspect commits in the
range r14-1425-g80ee7d02e8db48..e1240bda3e0b for the
build-break at r14-1442-ge1240bda3e0bb1 for cris-elf, where
I get:
> From: Jonathan Wakely
> Date: Wed, 31 May 2023 21:06:16 +0100
> On Wed, 31 May 2023 at 16:32, Jonathan Wakely wrote:
> > On Wed, 31 May 2023 at 16:29, Hans-Peter Nilsson via Libstdc++ <
> > libstd...@gcc.gnu.org> wrote:
> >
> >> Since I don't
Oops. Sorry. Committed as obvious. A bootstrap
--enable-checking=yes,extra,rtl (same as the reporter, but
not the default) with the patch completed, where a bootstrap
without it failed.
-- >8 --
PR bootstrap/110120
* postreload.cc (reload_cse_move2add, move2add_use_add2_insn): U
> Date: Tue, 6 Jun 2023 16:30:12 +0100
> From: Jonathan Wakely via Gcc-patches
> On Thu, 1 Jun 2023 at 16:59, Jonathan Wakely via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
> > Tested x86_64-linux. I'd appreciate a second set of eyeballs on this
> > before I push it.
> >
>
> Pushed to trunk
> Date: Wed, 7 Jun 2023 18:06:15 -0400
> From: Jason Merrill via Gcc-patches
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Now that we support NRV from an inner block, we can also support non-NRV
> returns from other blocks, since once the NRV is out of scope a later return
Hi!
The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
about 10 minutes to run for cris-elf in the "gdb simulator"
here on my arguably way-past-retirement machine (and it
looks like it gained a minute with LRA). I've seen it
timing out every now and then on busy days with load >
`nproc`.
> From: Mike Stump
> Date: Fri, 9 Jun 2023 10:18:45 -0700
> On Jun 9, 2023, at 9:20 AM, Hans-Peter Nilsson via Gcc-patches
> wrote:
> >
> > The test 27_io/basic_istream/ignore/wchar_t/94749.cc takes
> > about 10 minutes to run for cris-elf in the "gdb
Thank you for your consideration. (Or is that phrase only used negatively?)
> From: Jonathan Wakely
> Date: Fri, 9 Jun 2023 21:40:15 +0100
> test01, test02, test03 and test04 should run almost instantly. On my system
> they take about 5 microseconds each. So I don't think splitting those up
> w
See gcc/config/newlib-stdint.h, where targets that have
LONG_TYPE_SIZE == 32, get INT32_TYPE defined to "long int".
INT32_TYPE ends up in the target int32_t.
Thus the tests failed for 32-bit newlib targets due to related
warning messages being matched to "aka int" where the emitted
message for the
> Date: Mon, 14 Aug 2023 16:47:40 +0800
> From: "Kewen.Lin via Gcc-patches"
> on 2023/8/14 15:53, Jan-Benedict Glaw wrote:
> > echo timestamp > s-constrs-h
> > /var/lib/laminar/run/gcc-local/82/local-toolchain-install/bin/g++
> > -std=c++11 -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti
>
I'll commit this in a few hours pending testing. It seems
trivial enough to be posted before testing is finished
though, now that it has passed the previous
point-of-breakage. JFTR, I'm testing against the version
with the "first" breaking commit: r14-3092, not r14-3093 the
one with recog.h.
--
> From: Hans-Peter Nilsson
> Date: Tue, 15 Aug 2023 06:57:04 +0200
Whoops, of course there was a typo due to
insufficient-last-minute-renaming syndrome. :)
> -#define TARGET_LEGITIMATE_ADDRESS_P cris_legitimate_address_p
> +#define TARGET_LEGITIMATE_ADDRESS_P cris_target_legitima
Re-testing as previously mentioned, reposted freshly for reference.
-- >8 --
While there's another patch that fixes the immediate error
in the PR by other means, the include of tree.h here is
something I prefer to avoid.
PR bootstrap/111021
* config/cris/cris-protos.h: Revert recen
> Date: Thu, 17 Aug 2023 21:32:29 +0100
> From: Jonathan Wakely via Gcc-patches
> Tested x86_64-linux. Pushed to trunk.
Does the below typo imply that for x86_64-linux,
"__DBL_MANT_DIG__ == __LDBL_MANT_DIG__" is false and the
code is actually untested?
> libstdc++-v3/ChangeLog:
>
> * con
Oops. The validation was there, but PATTERN was applied
before that. Noticeable only with rtl-checking (for example
as in the report: "--enable-checking=yes,rtl") as this
statement was only a (one of many) straggling olde-C
declare-and-initialize-at-beginning-of-block thing.
PR target/11
Left-over from r14-383-gfaf8bea79b6256.
* lib/target-supports.exp (check_effective_target_lra): Remove
cris-*-* from expression for exceptions to LRA.
---
gcc/testsuite/lib/target-supports.exp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/
> Date: Mon, 26 Jun 2023 11:57:49 -0700
> From: Thomas Rodgers via Gcc-patches
> On Wed, May 17, 2023 at 12:32 PM Jonathan Wakely wrote:
> > All the actual code changes look good.
Unfortunately, this overwrote the fix for PR108672. I take
it there's a step missing from the synchronization proc
Committed as obvious after regtest for cris-elf together
with the "next" patch, that replaces unspec
CRIS_UNSPEC_SWAP_BITS with bitreverse (which hit the ICE).
-- >8 --
This seems to have just been overlooked when introducing
BITREVERSE. Note that the function name mem_loc_descriptor
is a misnome
This is just expected to be a change in representation.
No code is expected to change; no new tests are added.
* config/cris/cris.md (CRIS_UNSPEC_SWAP_BITS): Remove.
("cris_swap_bits", "ctzsi2"): Use bitreverse instead.
---
gcc/config/cris/cris.md | 9 ++---
1 file changed, 2
Ok to commit? It survived both a cris-elf regtest and a
x86_64-linux-gnu native regtest. :)
8<
The debug-function in sel-sched-dump.cc that would be
suitable for a hookup to a command in gdb is guarded by
#ifdef INSN_SCHEDULING, thus can't be used for all targets.
Better move the functi
Committed as obvious. Also, I wrote the neighboring code
- apparently including that line...
-- >8 --
Observed when disabling LEGITIMIZE_RELOAD_ADDRESS for
cris-elf: the current code doesn't handle the post-cc0
parallel-with-clobber-of-cc0 sets, dropping down into the
fatal_insn call. Following
Regtested cris-elf with its LEGITIMIZE_RELOAD_ADDRESS
disabled, where it regresses gcc.target/cris/rld-legit1.c;
as expected, because that test guards proper function of its
LEGITIMIZE_RELOAD_ADDRESS i.e., that there's no sign of
decomposed address elements.
LRA also causes a similar decomposition
Tested for cris-elf. Ok to commit?
-- >8 --
Looks like there's a failed assumption that
sizeof (union U { char u1[5]; int u2; float u3; }) == 8.
However, for "packed" targets like cris-elf, it's 5.
These two tests have always failed for cris-elf. I see from
https://gcc.gnu.org/pipermail/gcc-tes
I'd much rather install
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611531.html
than this one, because obviously a general solution is
better than a target list. But, that would require
approval, and I got NAK. This change however, piling on to
the target list, is within target mainta
TL;DR: committed as obvious.
-- >8 --
I use objs-gcc.sh as a preparatory step before calling
btest-gcc.sh in my scripts, for example my cris-elf
autotester. I thought, why not use it for native builds
too. Except that use, with binutils release-style tarballs
and a x86_64-pc-linux-gnu host, was b
Asking for the lines outside the "#if __CRIS__" part.
Ok to commit?
-- >8 --
tm.texi says for BIGGEST_ALIGNMENT (from which
__BIGGEST_ALIGNMENT__ is derived): "Biggest alignment that
any data type can require on this machine, in bits."
That is, using that value might be too strict for alignment
o
cance and having seen no other comments, I'll do
that, but delay another week.
brgds, H-P
>
> Qing
>
> > On Feb 15, 2023, at 2:19 PM, Hans-Peter Nilsson wrote:
> >
> > Tested for cris-elf. Ok to commit?
> >
> > -- >8 --
> > Looks like there&
Ok to commit?
I suggest that when committed I'll also set the bugzilla
entry in SUSPENDED mode, as opposed to RESOLVED. I mean,
the issue isn't really solved; that'd be a patch improving
pointer tracking across ivopts.
-- >8 --
For cris-elf before this patch, ever since it was added,
this test g
Ok to commit?
-- >8 --
I see overlong lines in the output when a test fails, for
example for a bug exposed for cris-elf and pru-elf in
gcc.dg/analyzer/allocation-size-multiline-3.c:
Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expec
Ok to commit?
-- >8 --
Those multi-line-patterns are literal. Sometimes a regexp
needs to be matched. This is a start: just three elements
are supported: "(" ")" and the compound ")?" (and on second
thought, it can be argued that "(...)" alone is not useful).
Note that Tcl "string map" is documen
I'll install this as obvious provided that the prerequisite
multiline.exp patch is approved.
-- >8 --
For 32-bit newlib targets (such as cris-elf and pru-elf),
that int32_t is "long int". See other regexps in the
testsuite matching "aka (long )?int" (with single-quotes
where needed) where the patt
> From: David Malcolm
> Date: Fri, 24 Feb 2023 14:07:02 -0500
> Old-Content-Type: text/plain; charset="UTF-8"
> Old-Content-Transfer-Encoding: base64
> Content-Type: TEXT/plain; charset=iso-8859-1
>
> On Fri, 2023-02-24 at 18:54 +0100, Hans-Peter Nilsson wrote:
&g
> From: Mike Stump
> Date: Mon, 27 Feb 2023 09:41:18 -0800
> > diff --git a/gcc/testsuite/lib/multiline.exp
> > b/gcc/testsuite/lib/multiline.exp
> > index 84ba9216642e..5eccf2bbebc1 100644
> > --- a/gcc/testsuite/lib/multiline.exp
> > +++ b/gcc/testsuite/lib/multiline.exp
>
> > - ${maybe
Reacting to a long-standing XPASS for CRIS. Maybe better do
as https://gcc.gnu.org/PR79356#c11 suggests: xfail it for
x86 only ...except I see m68k also does not xpass.
testsuite:
PR testsuite/79356
* gcc.dg/attr-alloc_size-11.c: Add CRIS to the list
of targets excluding x
Committed as obvious.
-- >8 --
Reacting to a long-standing XPASS for CRIS. This one is
slightly brown paper-bag level; it was never the here-removed
xfailed scan that failed and I didn't notice that XPASS when
reporting success on the commit as a whole. It's not logical to
re-read what was just-w
As recommended by testsuite maintainer: Regression analysis
works only if the string is the same.
testsuite:
* lib/multiline.exp (handle-multiline-outputs): Shorten
message to the same for fail and pass.
---
gcc/testsuite/lib/multiline.exp | 4 ++--
1 file changed, 2 insertions(+)
Committed as obvious after sanity-checking cris-elf and
native x86_64-linux.
-- >8 --
There are no messages about padding for targets that don't
pad, i.e. default_packed. Noticed for cris-elf, verified
for pru-elf at gcc-testresults@.
testsuite:
* gcc.dg/plugin/infoleak-vfio_iommu_type1.c
Ping...
> From: Hans-Peter Nilsson
> Date: Thu, 16 Feb 2023 21:05:29 +0100
> Asking for the lines outside the "#if __CRIS__" part.
> Ok to commit?
>
> -- >8 --
> tm.texi says for BIGGEST_ALIGNMENT (from which
> __BIGGEST_ALIGNMENT__ is derived): "
Ok to commit?
-- >8 --
Investigating analyzer tesstsuite errors for cris-elf. The same are
seen for pru-elf according to posts to gcc-testresults@.
For glibc, errno is #defined as:
extern int *__errno_location (void) __THROW __attribute_const__;
# define errno (*__errno_location ())
while for n
Ok to commit? (After this, there's
gcc.dg/analyzer/flex-without-call-summaries.c left to do.)
-- >8 --
Investigating analyzer testsuite errors for cris-elf. The same are
seen for pru-elf according to posts to gcc-testresults@.
The test fd-access-mode-target-headers.c uses the analyzer
"sm-fd" w
> From: David Malcolm
> Date: Tue, 28 Feb 2023 14:12:47 -0500
> On Tue, 2023-02-28 at 19:47 +0100, Hans-Peter Nilsson wrote:
> > Ok to commit?
> > -- >8 --
> > Investigating analyzer tesstsuite errors for cris-elf. The same are
> > seen for pru-elf a
> From: David Malcolm
> Date: Tue, 28 Feb 2023 21:25:34 -0500
> On Wed, 2023-03-01 at 01:59 +0100, Hans-Peter Nilsson wrote:
> > > From: David Malcolm
> > > Date: Tue, 28 Feb 2023 14:12:47 -0500
> >
> > > On Tue, 2023-02-28 at 19:47 +0100, Hans
> From: David Malcolm
> Cc: gcc-patches@gcc.gnu.org
> Date: Wed, 01 Mar 2023 08:32:13 -0500
> Also, the analyzer uses region_model::set_errno in various
> known_function implementations, e.g. for functions that can succeed or
> fail, to set errno on the "failure" execution path to a new symbolic
> From: Hans-Peter Nilsson
> Date: Wed, 1 Mar 2023 16:36:46 +0100
> ... this is what I intend to commit later
> today, just keeping the added comment as brief as
> reasonable:
Except I see the hook for errno magic took care of
gcc.dg/analyzer/flex-without-call-summaries.c so I
> Date: Thu, 2 Mar 2023 00:23:36 +0100
> From: Bernhard Reutner-Fischer
> On Wed, 1 Mar 2023 17:02:31 +0100
> Hans-Peter Nilsson via Gcc-patches wrote:
>
> > > From: Hans-Peter Nilsson
> > > Date: Wed, 1 Mar 2023 16:36:46 +0100
> >
> >
> Date: Thu, 2 Mar 2023 01:37:12 +0100
> From: Bernhard Reutner-Fischer
> On Thu, 2 Mar 2023 00:54:33 +0100
> Hans-Peter Nilsson wrote:
>
> > > Date: Thu, 2 Mar 2023 00:23:36 +0100
> > > From: Bernhard Reutner-Fischer
> >
> > > On Wed, 1 Mar
Trivia: I copied that ASMNAME construct from the
18-year-minus-a-month old commit of r0-66993-gc5221531453e02,
where it fixed a similar testsuite error. Committed as obvious.
-- >8 --
This fixes:
Running /x/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/attr-copy-6.c (test for excess errors)
Committed as obvious. FWIW, I'm on the side that emitting
the warning when the reason is just that it's the default
layout, is bad. A discussion took place years ago when the
warning was added.
-- >8 --
For targets where the byte-wise structure element layout is
the same as for attribute-packed,
Committed as obvious.
-- >8 --
* g++.dg/cpp0x/pr84497.C: Handle USER_LABEL_PREFIX == "_" on
scan-assembler identifiers.
* gcc.dg/debug/btf/btf-enum64-1.c, gcc.dg/ipa/symver1.c: Ditto.
---
gcc/testsuite/g++.dg/cpp0x/pr84497.C | 6 +++---
gcc/testsuite/gcc.dg/debug/b
CRIS has no conditional execution and no conditional moves.
* gcc.dg/ifcvt-4.c: Add cris-*-* to skip list.
---
gcc/testsuite/gcc.dg/ifcvt-4.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/ifcvt-4.c b/gcc/testsuite/gcc.dg/ifcvt-4.c
index 46245f0d0
CRIS defines DATA_ALIGNMENT such that alignment can be
applied differently to different data of the same type, when
"references to it must bind to the current definition"
(varasm.cc:align_variable). Here, it means that more
alignment is then applied to g, but not f, so the test-case
fails because
Ping...
> From: Hans-Peter Nilsson
> Date: Fri, 24 Feb 2023 20:16:03 +0100
>
> Ok to commit?
> -- >8 --
> Those multi-line-patterns are literal. Sometimes a regexp
> needs to be matched. This is a start: just three elements
> are supported: "(" &qu
Ok to commit?
-- >8 --
The RTL "expand" dump is the first RTL dump, and it also appears to be
the earliest trace of the target having implemented sibcalls.
Including the "," in the pattern searched for, to try and avoid
possible false matches, but there doesn't appear to be any identifiers
or targe
Will commit as obvious, when the 1/3 tail_call is applied.
-- >8 --
Spot-checked the PDF output for sanity.
* doc/sourcebuild.texi: Document check_effective_target_tail_call.
---
gcc/doc/sourcebuild.texi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/gcc/doc/sourcebuild.texi b/gcc
Borderline obvious when tail_call is available, so I'll then apply.
-- >8 --
While gcc.dg/plugin/must-tail-call-2.c passes for all targets even
without this, the error message is, for a target like cris-elf that
doesn't implement sibling calls: "error: cannot tail-call: machine
description does not
This is sort-of a spin-off from effective_target_tail_call: I thought
that'd best be implemented by scanning a tree-dump, specifically
-fdump-tree-optimized, but the "tail call" found there is emitted for
*all* targets. Debugged and ready to apply, putting it out for
consideration as someone will
> From: Mike Stump
> Date: Mon, 6 Mar 2023 02:05:35 -0800
> Ok
Thanks! The server-side hook didn't like my ChangeLog
entry:
* lib/multiline.exp (_build_multiline_regex): Map
"{re:" to "(", ":re}" to ")" and ":re?}" to ")?".
It seems I forgot to validate that patch by
c
Committed as obvious.
-- >8 --
The recently added tests missed checking for "fopenmp" (see
other tests where "-fopenmp" is passed), which makes them
fail on non-openmp systems.
* gcc.dg/analyzer/omp-parallel-for-get-min.c,
gcc.dg/analyzer/omp-parallel-for-1.c: Require effective tar
It's not obvious to me whether considered best to include or
exclude these tests that depend on structure layout details.
If excluding, the obvious alternative to this patch is then
to add a top one-liner (to dg-skip-if the test for
default_packed targets or a similar excluding expression).
I'm fin
Committed as obvious.
-- >8 --
Targets that don't support prefetching get a warning:
cc1: warning: '-fprefetch-loop-arrays' not supported for this target
Align with other tests passing -fprefetch-loop-arrays for
all targets: add "-w" to options.
* gcc.dg/pr106397.c: Add -w to options.
---
Committed as obvious.
-- >8 --
Targets that don't support scheduling get a warning:
cc1: warning: instruction scheduling not supported on this target machine
Do like other target-generic tests unconditionally passing
-fschedule-insns: require effective target scheduling.
* gcc.dg/pr108117
2101 - 2200 of 2386 matches
Mail list logo
