So for this bug we have what appears to me to just be a bogus pattern.
Essentially the pattern tries to detect cases where we have an SI mode
value and we can use the Zbs instructions to manipulate a bit.
Conceptually that's great.
The problem is the pattern assumes that SI objects are sign e
v2: With Jonathan Wakely's feedback, centering the simulator range on
days(0). Different changes than v1, but supposedly minimally intrusive.
Committed after testing native x86_64-linux and cross to mmix.
-- >8 --
These two long-running tests happened to fail for me when
run in parallel (nprocs
So this BZ is a case where we incorrectly indicated that the operand
array was suitable for the t-head load/store pair instructions.
In particular there's a test which checks alignment, but that happens
*before* we know if the operands are going to be reversed. So the
routine reported the ope
On Thu, 12 Dec 2024, James K. Lowden wrote:
> ChangeLog
> * Makefile.def: Add libgcobol module and cobol language.
Since this implies the regeneration of top-level Makefile.in please add
a ChangeLog entry to that effect and include the changes to Makefile.in
produced along with the rest
From: "Estevan Castilho (Tevo)"
---
gcc/ada/libgnarl/s-taprop__dummy.adb | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/gcc/ada/libgnarl/s-taprop__dummy.adb
b/gcc/ada/libgnarl/s-taprop__dummy.adb
index 68ec8b448ba..2127fb1f1b1 100644
--- a/gcc/ada/libgnarl/s-tap
Hello,
The dummy s-taprop.adb included in libgnarl has been broken for a few releases,
as the signature for `Unlock' and `Write_Lock' on `RTS_Lock' has changed. That
file doesn't seem to be used by any of the current runtime configurations, but
it can be helpful for bringing up a new target.
T
On 12/21/24 7:11 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
OK.
-- >8 --
I noticed that in a couple of places we sometimes treat any TYPE_DECL of
lambda type as defining a lambda, which isn't always true since C++20:
in `using T = decltype([]{
On 12/22/24 5:38 AM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, and also on
x86_64-unknown-freebsd13.3 by Gerald ([1], see also the discussion on
the PR); OK for trunk?
OK.
[1]: https://gcc.gnu.org/pipermail/gcc-testresults/2024-December/833487.html
-- >8 --
Tested on hppa64-hp-hpux11.11. Okay for trunk?
Dave
---
Add support to provide libiberty mkstemps in gcc
2024-12-28 John David Anglin
gcc/ChangeLog:
PR target/118121
* configure.ac: Check for mkstemps declaration.
* configure: Regenerate.
* config.in: Regene
Hi,
Gentle ping on this patch.
Also, it would be nice if GCC installed libgccjit.pc to include the
directory libgccjit headers and libraries are installed in correctly
always.
Currently, users of libgccjit have to assume GCC includes it in its
include path always, but that might not be true if G
On Sat, 28 Dec 2024, 07:01 Hans-Peter Nilsson, wrote:
> I can't think of a straightforward way to prune these two
> similar tests to a more meaningful subset: there's no easy
> pruning to each Nth iteration instead of every iteration.
> Hopefully exiting the loop after a million runs at the
> beg
> Am 28.12.2024 um 09:13 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcases ICE because fold_array_ctor_reference in the
> RAW_DATA_CST handling just return build_int_cst without actually checking
> that if type is non-NULL, TREE_TYPE (val) is uselessly convertible to it.
>
> By fal
Hi!
The following testcases ICE because fold_array_ctor_reference in the
RAW_DATA_CST handling just return build_int_cst without actually checking
that if type is non-NULL, TREE_TYPE (val) is uselessly convertible to it.
By falling through the code after it without *suboff += we get everything
we
13 matches
Mail list logo
