https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
For boolean types, `a ^ b` is a valid form for `a != b`. This means for
gimple_bitwise_inverted_equal_p, we catch some inverted value forms. This
patch extends inverted_equal_p to allow matching of `^` with the
corresponding `==`. Note in the testcase provided we used to optimize
in GCC 12 to just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86274
Jason Liam changed:
What|Removed |Added
CC||jlame646 at gmail dot com
--- Comment #22
Why is the content of argv, on the stack? why not on data section?
since its on the stack..say, i have
argv[] = "HELLO WORLD";
need to push "HELL"
push "O WO";
push "RLD";
right? or is there any other mechanism to load the string into the stack?
sorry if this
Richard Sandiford 于2023年12月30日周六 23:35写道：
>
> Ping^3
>
I am testing it on MIPS.
> --- a/gcc/common/config/aarch64/aarch64-common.cc
> +++ b/gcc/common/config/aarch64/aarch64-common.cc
> @@ -55,6 +55,7 @@ static const struct default_options
> aarch_option_optimization_table[] =
> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
Eric Gallager changed:
What|Removed |Added
See Also||https://github.com/apple/sw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
--- Comment #3 from Andrew Pinski ---
So for the C testcase, we don't need to create a new pattern, just extend
gimple_bitwise_inverted_equal_p to catch `a == b` and `a ^ b` are inverted
equals like we already do for `a == b` and `a != b`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113072
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Looks like bool sometimes produces != or ^ :)
> ```
> bool foo(bool a, int b)
> {
> bool b1 = b == 1;
> bool b2 = !b1;
> bool c = (a ^
Snapshot gcc-14-20231231 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/14-20231231/
and on various mirrors, see https://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 14 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Excerpts from Jørgen Kvalsvik's message of Dezember 31, 2023 4:51 pm:
> This is a mostly straight port from the gcov-19.c tests from the C test
> suite. The only notable differences from C to D are that D flips the
> true/false outcomes for loop headers, and the D front end ties loop and
> ternary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
--- Comment #7 from Jonathan Wakely ---
(In reply to Xi Ruoyao from comment #4)
> IIRC the "signed_rep_t = __int128;" case has really detected a compiler bug,
> so IMO we shouldn't just disable it.
>
> Maybe my memory is flawed though.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43644
--- Comment #5 from GCC Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:79e1b23b91477b29deccf2cae92a7e8dd816c54a
commit r14-6874-g79e1b23b91477b29deccf2cae92a7e8dd816c54a
Author: Roger Sayle
Date: Sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
--- Comment #2 from Andrew Pinski ---
Note for `~a != b` (for boolean size) we should just convert that into: `a ==
b` .
And then we would have the form for both C++ and C at -O1 in forwprop1 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113186
Bug ID: 113186
Summary: [13/14 Regression] `(a^c) & (a^!c)` is not optimized
to 0 for bool
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords:
We already had smin/smax RTL pattern using vfmin/vfmax instructions.
But for smin/smax, it's unspecified what will happen if either operand
contains any NaN operands. So we would not vectorize the loop with
-fno-finite-math-only (the default for all optimization levels expect
-Ofast).
But,
On 12/28/23 18:21, Juzhe-Zhong wrote:
This patch fixes the following choosing unexpected big LMUL which cause
register spillings.
Before this patch, choosing LMUL = 4:
addisp,sp,-160
addiw t1,a2,-1
li a5,7
bleut1,a5,.L16
vsetivli
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065
--- Comment #7 from Tommy Murphy ---
(In reply to palmer from comment #3)
> The Linux and ELF multilibs are different: for Linux we assumed ISA
> compatibility was up to the distro, so multilib just handles the ABI side of
> things. That said,
On 12/28/23 21:19, Jun Sha (Joshua) wrote:
This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. We only check the
prefix is 'v', so that no extra attribute is needed.
gcc/ChangeLog:
* config/riscv/riscv-protos.h
On 12/30/23 14:21, Tom Tromey wrote:
When I enable cgen rebuilding in the binutils-gdb tree, the default is
to run cgen using 'guile'. However, on my host, guile is guile 2.2,
which doesn't work for me -- I have to use guile3.0.
This patch arranges to pass "GUILE" down to subdirectories, so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
--- Comment #5 from Hans-Peter Nilsson ---
(In reply to Xi Ruoyao from comment #4)
> IIRC the "signed_rep_t = __int128;" case has really detected a compiler bug,
> so IMO we shouldn't just disable it.
Maybe I should have been explicit: that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #4
On Sat, 30 Dec 2023, Hans-Peter Nilsson wrote:
> On Sat, 30 Dec 2023, Jonathan Wakely wrote:
>
> > On Sat, 30 Dec 2023, 01:41 Hans-Peter Nilsson, wrote:
> > > Or perhaps the cause is known?
> >
> > Not to me. It probably is a target codegen bug, since all this test really
> > does is emulate a
On Sun, Dec 31, 2023 at 4:56 PM Roger Sayle wrote:
>
>
> Hi Uros,
>
> > From: Uros Bizjak
> > Sent: 28 December 2023 10:33
> > On Fri, Dec 22, 2023 at 11:14 AM Roger Sayle
> > wrote:
> > >
> > > This patch resolves the failure of pr43644-2.c in the testsuite, a
> > > code quality test I added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175
Hans-Peter Nilsson changed:
What|Removed |Added
Component|libstdc++ |testsuite
--- Comment #3 from
Very many thanks (and a Happy New Year) to the pre-commit
patch testing folks at linaro.org. Their testing has revealed that
although my patch is clean on x86_64, it triggers some problems
on aarch64 and arm. The issue (with the previous version of my
patch) is that these platforms require a
Hi Uros,
> From: Uros Bizjak
> Sent: 28 December 2023 10:33
> On Fri, Dec 22, 2023 at 11:14 AM Roger Sayle
> wrote:
> >
> > This patch resolves the failure of pr43644-2.c in the testsuite, a
> > code quality test I added back in July, that started failing as the
> > code GCC generates for
This is a mostly straight port from the gcov-19.c tests from the C test
suite. The only notable differences from C to D are that D flips the
true/false outcomes for loop headers, and the D front end ties loop and
ternary conditions to slightly different locus.
The test for >64 conditions warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86440
--- Comment #4 from Yohei Kojima ---
Also, -Wignored-qualifiers messages disappeared with g++ compiling b.c.
Probably it is a bug caused by the same reason as this bug.
$ g++ -c -Wall -Wextra -Wignored-qualifiers b.c
b.c: In function 'void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86440
Yohei Kojima changed:
What|Removed |Added
CC||y.koj.eel at gmail dot com
--- Comment
> Am 31.12.2023 um 11:20 schrieb Jørgen Kvalsvik :
>
> On 31/12/2023 10:40, Jan Hubicka wrote:
This seems good. Profile-arcs is rarely used by itself - most of time it
is implied by -fprofile-generate and -ftest-coverage and since
condition coverage is more associated to the
On 31/12/2023 10:40, Jan Hubicka wrote:
This seems good. Profile-arcs is rarely used by itself - most of time it
is implied by -fprofile-generate and -ftest-coverage and since
condition coverage is more associated to the second, I guess
-fcondition-coverage is better name.
Since
> > This seems good. Profile-arcs is rarely used by itself - most of time it
> > is implied by -fprofile-generate and -ftest-coverage and since
> > condition coverage is more associated to the second, I guess
> > -fcondition-coverage is better name.
> >
> > Since -fcondition-coverage now affects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113170
Andrew Pinski changed:
What|Removed |Added
Keywords|ice-on-invalid-code |
--- Comment #3 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113170
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
36 matches
Mail list logo
