We'll try to canonicalize the arch string for --with-arch,
and the script is written in python, however it will turns out
GCC require python to build for RISC-V port, it's not expect as
the GCC requirement.
So this patch is made this as optional, detect python and only use it
when it available, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98152
Andreas Schwab has created a bug entry for this issue,
using awk or shell should be fine to get the same functionality, but
it might take some time,
so I plan to add some checking to detect python, python2 or python3,
and skip this step if none of
On Sat, Dec 05, 2020 at 06:01:59PM -0300, Alexandre Oliva wrote:
> On Dec 5, 2020, Andreas Schwab wrote:
>
> > ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
> > ../../../../libffi/src/aarch64/ffi.c:67:3: internal compiler error: in
> > emit_library_call_value_1, at c
On Dec 5, 2020, Andreas Schwab wrote:
> ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
> ../../../../libffi/src/aarch64/ffi.c:67:3: internal compiler error: in
> emit_library_call_value_1, at calls.c:5300
>67 | __builtin___clear_cache (start, end);
> | ^
Hi Joseph,
the patch to drop qualifiers during lvalue conversion
was broken, because the code to emit atomic loads did
not trigger anymore. I now added a test that scans for
"atomic_load".
I should have taken the new warning for
_Atomic int y;
y; // warning statement with no effect
as a tel
Hi Jeff!
On 11/30/20 8:22 PM, Jeff Law wrote:
> I also took care of updating cris and mn103 status WRT cc0. Attached is
> what was pushed to the gcc-wwwdocs trunk.
Now that VAX has been converted as well, the entry can be updated here as well.
Now there are only AVR and CR16 that need to be con
On Fri, 20 Nov 2020, Jeff Law wrote:
> Sweet. OK once the prereqs are all ACK'd.
Thank you for your review. I have applied all the changes now, as posted
in their most recent versions, except for 01/31 where I have noticed an
anomaly in the included gcc/testsuite/gcc.c-torture/compile/pr5890
On Sat, Dec 5, 2020 at 6:12 AM Alan Modra wrote:
>
> On Thu, Oct 29, 2020 at 10:10:58PM +1030, Alan Modra wrote:
> > Fixes
> > FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-not stxvd2x
> > FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times mfvsrd 3
> > FAIL: gcc.target/powerpc/signbit
On December 5, 2020 11:59:22 AM GMT+01:00, Jakub Jelinek
wrote:
>On Sat, Dec 05, 2020 at 11:22:24AM +0100, Richard Biener wrote:
>> >two_value_replacement and didn't restrict it to !early_p. Shall we
>> >instead
>> >do two_value_replacement only in late phiopt?
>>
>> Yeah, I guess that would ma
On December 5, 2020 11:57:46 AM GMT+01:00, Jakub Jelinek
wrote:
>On Sat, Dec 05, 2020 at 11:20:11AM +0100, Richard Biener wrote:
>> >As mentioned in the PR, for boolean x we currently optimize
>> >in phiopt x ? 0 : -1 into -(int)!x but it can be optimized as
>> >(int) x - 1 which is one less oper
On 12/2/20 7:57 PM, Jason Merrill wrote:
> On 12/1/20 1:28 PM, Bernd Edlinger wrote:
>> On 11/24/20 11:10 PM, Jason Merrill wrote:
>>> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
Hi,
this avoids the need to use -fno-threadsafe-statics on
arm-none-eabi or working around that probl
On Thu, Oct 29, 2020 at 10:10:58PM +1030, Alan Modra wrote:
> Fixes
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-not stxvd2x
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times mfvsrd 3
> FAIL: gcc.target/powerpc/signbit-1.c scan-assembler-times srdi 3
> FAIL: gcc.target/powerpc/si
On Sat, Dec 05, 2020 at 11:22:24AM +0100, Richard Biener wrote:
> >two_value_replacement and didn't restrict it to !early_p. Shall we
> >instead
> >do two_value_replacement only in late phiopt?
>
> Yeah, I guess that would make sense. I don't remember exactly but I saw
> regressions with early d
On Sat, Dec 05, 2020 at 11:20:11AM +0100, Richard Biener wrote:
> >As mentioned in the PR, for boolean x we currently optimize
> >in phiopt x ? 0 : -1 into -(int)!x but it can be optimized as
> >(int) x - 1 which is one less operation both in GIMPLE and in x86
> >assembly.
> >
> >Bootstrapped/regte
On December 5, 2020 10:14:49 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The following patch improves code generation on the included testcase
>by
>enabling two_value_replacement on booleans. It does that only for
>arg0/arg1
>values that conditional_replacement doesn't handle, and only does it if
On December 5, 2020 10:10:25 AM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR, for boolean x we currently optimize
>in phiopt x ? 0 : -1 into -(int)!x but it can be optimized as
>(int) x - 1 which is one less operation both in GIMPLE and in x86
>assembly.
>
>Bootstrapped/regteste
../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
../../../../libffi/src/aarch64/ffi.c:67:3: internal compiler error: in
emit_library_call_value_1, at calls.c:5300
67 | __builtin___clear_cache (start, end);
| ^~~~
Andreas.
--
> [AMD Public Use]
>
>
> As per https://gcc.gnu.org/codingconventions.html#ChangeLogs
>
> --Snip--
> ChangeLogs
> ChangeLog entries are part of git commit messages and are automatically put
> into a corresponding ChangeLog file.
> --Snip--
>
> This means Changelog files will be updated automat
Hi!
The following patch improves code generation on the included testcase by
enabling two_value_replacement on booleans. It does that only for arg0/arg1
values that conditional_replacement doesn't handle, and only does it if not
in the early phiopt pass, because conditional_replacement isn't done
Hi Segher,
I've been holding off pinging these knowing you had a lot of other
review work, but maybe that's settling down now? You already OK'd
1/8, 2/8 and 6/8.
[PATCH 3/8] [RS6000] rs6000_rtx_costs tidy AND
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555754.html
[PATCH 4/8] [RS6000]
Hi!
As mentioned in the PR, for boolean x we currently optimize
in phiopt x ? 0 : -1 into -(int)!x but it can be optimized as
(int) x - 1 which is one less operation both in GIMPLE and in x86 assembly.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
And/or, shall we have a m
On Sat, Dec 05, 2020 at 08:22:23AM +, Kumar, Venkataramanan via Gcc-patches
wrote:
> [AMD Public Use]
>
>
> As per https://gcc.gnu.org/codingconventions.html#ChangeLogs
>
> --Snip--
> ChangeLogs
> ChangeLog entries are part of git commit messages and are automatically put
> into a correspo
[AMD Public Use]
As per https://gcc.gnu.org/codingconventions.html#ChangeLogs
--Snip--
ChangeLogs
ChangeLog entries are part of git commit messages and are automatically put
into a corresponding ChangeLog file.
--Snip--
This means Changelog files will be updated automatically? I did not do
a
23 matches
Mail list logo
