m68k fails to bootstrap since -ffold-mem-offsets was introduced,
in what looks like wrong-code during stage2.
To restore bootstrap this disables -ffold-mem-offsets on m68k.
It's not ideal, but better than keeping bootstraps broken until
the root cause is debugged and fixed.
Tested with a bootstra
Applied this patch.
Johann
--
AVR: Improve documentation for -mmcu=.
gcc/
* doc/invoke.texi (AVR Options) <-mmcu>: Remove "Atmel".
Note on complete device support.
AVR: Add examples for ISR macro to interrupt attribute doc.
gcc/
* doc/extend.texi (AVR Function Attri
On 2/18/24 02:18, Mikael Pettersson wrote:
m68k fails to bootstrap since -ffold-mem-offsets was introduced,
in what looks like wrong-code during stage2.
To restore bootstrap this disables -ffold-mem-offsets on m68k.
It's not ideal, but better than keeping bootstraps broken until
the root caus
If assembler and linker supports
add %reg1, name@gottpoff(%rip), %reg2
with R_X86_64_CODE_6_GOTTPOFF, we can generate it instead of
mov name@gottpoff(%rip), %reg2
add %reg1, %reg2
gcc/
* configure.ac (HAVE_AS_R_X86_64_CODE_6_GOTTPOFF): Defined as 1
if R_X86_64_CODE_6_GOTTPOFF i
Tested on i686-darwin9, x86_64-darwin14,17,19,21,23, x86_64-linux,
aarch64-linux-gnu,
OK for trunk?
eventual back-ports?
thanks
Iain
--- 8< ---
Darwin's linker warns when we make a direct branch to code that is
in a weak definition (citing that if a different implementation of
the weak function
On Linux/x86_64,
1e3f78dbb328a2f2db8def241372cb947d9cb7eb is the first bad commit
commit 1e3f78dbb328a2f2db8def241372cb947d9cb7eb
Author: Richard Biener
Date: Mon Feb 12 10:40:42 2024 +0100
tree-optimization/113863 - elide degenerate virtual PHIs when moving ee
stores
caused
FAIL: gcc.c
On Linux/x86_64,
c9ce332b557bb95987d038d98ea929cdfd1eae1d is the first bad commit
commit c9ce332b557bb95987d038d98ea929cdfd1eae1d
Author: Jonathan Wakely
Date: Wed Feb 7 11:31:10 2024 +
libstdc++: Use 128-bit arithmetic for std::linear_congruential_engine
[PR87744]
caused
FAIL: 26_n
On Linux/x86_64,
7f3d900684ad989164114f25eb46a33871c6533d is the first bad commit
commit 7f3d900684ad989164114f25eb46a33871c6533d
Author: Jonathan Wakely
Date: Wed Feb 7 11:31:10 2024 +
libstdc++: Fix FAIL: 26_numerics/random/pr60037-neg.cc [PR113931]
caused
FAIL: 26_numerics/random/
Hi David,
On Thu, Jan 04, 2024 at 09:57:09AM -0500, David Malcolm wrote:
> I've pushed the .opt.urls patch kit to gcc trunk [1], so hopefully the
> CI check you wrote can go live now.
And then I was on vacation myself and forgot. I am sorry.
So, I did try the regenerate-opt-urls locally, and it
On Sun, 2024-02-18 at 08:42 -0700, Jeff Law wrote:
>
> On 2/18/24 02:18, Mikael Pettersson wrote:
> > m68k fails to bootstrap since -ffold-mem-offsets was introduced,
> > in what looks like wrong-code during stage2.
> >
> > To restore bootstrap this disables -ffold-mem-offsets on m68k.
> > It's n
For calling-convention-*.c, LGTM but one nit about change log. Take **Update**
here may make others not easy to learn what you did about the file.
You can say similar to "Rearrange and adjust the asm-checker times" or
likewise. Of course, you can refine the changelog when commit.
> * gcc.target/
target maybe_x32 doesn't check if platform has gnu/stubs-x32.h, but
it's included by stdint.h in the testcase.
Adjust testcase: remove stdint.h, use 'typedef long long int64_t'
instead.
Commit as an obvious patch.
gcc/testsuite/ChangeLog:
PR target/113711
* gcc.target/i386/apx-nd
On 2/17/24 15:14, François Dumont wrote:
Thanks for the link, tested and committed.
I assume this is the cause for the below failure now,
$ cat test.cc
#include
#include
void f(std::vector &v, void const * p) {
std::erase(v, p);
}
$ ~/gcc/inst/bin/g++ -std=c++20 -D_GLIBCXX_DEBUG -fsy
On Sat, Feb 17, 2024 at 11:30 AM wrote:
>
> From: Pan Li
>
> This patch would like to add the middle-end presentation for the
> unsigned saturation add. Aka set the result of add to the max
> when overflow. It will take the pattern similar as below.
>
> SAT_ADDU (x, y) => (x + y) | (-(TYPE)((TY
Ping this patch which is simple fix on VSETVL PASS.
Ok for trunk ?
juzhe.zh...@rivai.ai
From: Juzhe-Zhong
Date: 2024-02-01 17:02
To: gcc-patches
CC: kito.cheng; kito.cheng; jeffreyalaw; rdapp.gcc; Juzhe-Zhong
Subject: [PATCH v2] RISC-V: Suppress the vsetvl fusion for conflict successors
Update
On Fri, Feb 16, 2024 at 01:51:54PM +, Jonathan Wakely wrote:
> Ah, although __atomic_compare_exchange only takes pointers, the
> compiler replaces that with a call to __atomic_compare_exchange_n
> which takes the newval by value, which presumably uses an 80-bit FP
> register and so the padding
Hi!
The following testcase ICEs, because BIT_FIELD_REF's position is not
multiple of the vector element's bit size and the code uses exact_div
to divide those 2 values.
For BIT_INSERT_EXPR, the tree-cfg.cc verification verifies the position
is a multiple of the inserted bit size when inserting in
17 matches
Mail list logo
