On Thu, 29 Jun 2023, Richard Biener wrote:
IIRC we have some simplification rules that turn bit operations into
arithmetics. Arithmetic is allowed if it keeps the values inside
[-1,0] for signed bools or [0, 1] for unsigned bools.
I have now verified that all cases seems to be just one
Certain downstream compilers (for example, in Fedora) default to
-freport-bug. The extra output breaks the following tests. We can use
-fno-report-bug to fix that. Patch verified with:
$ make check RUNTESTFLAGS='--target_board=unix\{,-freport-bug\} plugin.exp'
Tested x86_64-pc-linux-gnu, ok
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110487
Bug ID: 110487
Summary: invalid wide Boolean value
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
From: benjamin priour
See below formatting updates on my patch.
In mail https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623140.html,
David Malcolm says regtesting failed for him.
So I did it once more this morning rebased on fresh trunk dc93a0f633b
and target x86_64-linux-gnu, the output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #27 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #26)
> It is included here:
> https://www.desy.de/~reuter/downloads/repro002.tar.xz
> I am working on a smaller example right now.
Good. I can reproduce
On Tue, Jun 27, 2023 at 07:23:32AM +0100, Richard Sandiford wrote:
> Andrew Carlotti via Gcc-patches writes:
> > Many intrinsics currently depend on both an architecture version and a
> > feature, despite the corresponding instructions being available within
> > GCC at lower architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
--- Comment #17 from Rogério de Souza Moraes
---
Created attachment 55428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55428=edit
Preprocessed file for GCC 13.1.0 bug
This is the preprocessed file (*.i*) that triggers the bug reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852
Rogério de Souza Moraes changed:
What|Removed |Added
CC||rogerio.souza at gmail dot
On Thu, 29 Jun 2023 at 17:59, Tom Tromey wrote:
> > Jonathan Wakely writes:
>
> > Looks good. OK for trunk, and OK to backport after some soak time on
> trunk. Thanks.
>
> AdaCore doesn't need a backport of this, and I don't think it's
> extremely important; so unless you want me to do it,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #26 from Jürgen Reuter ---
(In reply to anlauf from comment #25)
> Unfortunately, there is no main.f90, which is needed to build whizard.
>
Indeed, sorry, cf. below
> The Makefile needs to be modified to take into account that
On 6/29/23 11:36, Marek Polacek wrote:
On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13?
-- >8 --
cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding
a
On 6/29/23 11:22, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13/12?
OK.
-- >8 --
Here we find ourselves instantiating the NSDMI for A<1>::m when
computing argument conversions during overload resolution, and
thus tf_conv is set. This
On 6/24/23 09:24, Nathaniel Shead wrote:
On Fri, Jun 23, 2023 at 11:59:51AM -0400, Patrick Palka wrote:
Hi,
On Sat, 22 Apr 2023, Nathaniel Shead via Gcc-patches wrote:
Bootstrapped and tested on x86_64-pc-linux-gnu.
-- 8< --
This patch raises an error early when the decltype(auto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #4 from anlauf at gcc dot gnu.org ---
It appears that the issue could be studied with the following code:
program p
implicit none
integer :: a = 65
call val ("A", char(a))
contains
subroutine val (x, c)
++ --disable-werror
--disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230629 (experimental) [master r14-924-gd709841ae0f] (GCC)
[642] %
[642] % gcctk -O2 -fselective-scheduling2 -fno-tree-pre small.c
[643] % ./a.out
34
[644] % gcctk -O2 small.c
[645
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #25 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #24)
> Here is a first reproducer without the need for OCaml, unfortunately a bit
> too big to be uploaded, here is the link:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #9 from CVS Commits ---
The master branch has been updated by Qing Zhao :
https://gcc.gnu.org/g:070a6bf0bdc6761ad77ac97404c98f00a7007d54
commit r14-2197-g070a6bf0bdc6761ad77ac97404c98f00a7007d54
Author: Qing Zhao
Date: Thu Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
Jakub Jelinek changed:
What|Removed |Added
Attachment #55416|0 |1
is obsolete|
> Jonathan Wakely writes:
> Looks good. OK for trunk, and OK to backport after some soak time on trunk.
> Thanks.
AdaCore doesn't need a backport of this, and I don't think it's
extremely important; so unless you want me to do it, I don't plan to.
I did check it in on trunk earlier today.
There's a few spots where a range is being altered in-place, but we
fail to call normalize the range. This patch makes sure we always
call normalize_kind(), and that normalize_kind in turn, calls
verify_range to make sure verything is canonical.
gcc/ChangeLog:
* value-range.cc
gcc/ChangeLog:
* tree-vrp.cc (maybe_set_nonzero_bits): Move from here...
* tree-ssa-dom.cc (maybe_set_nonzero_bits): ...to here.
* tree-vrp.h (maybe_set_nonzero_bits): Remove.
---
gcc/tree-ssa-dom.cc | 65 +
gcc/tree-vrp.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432
--- Comment #11 from Jonathan Wakely ---
(In reply to Iain Sandoe from comment #10)
> do all the other (I guess non-embedded) platforms now have init priority
> support?
It's OK if they don't, as long as (1) the attribute tells the truth, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110478
--- Comment #4 from Bin Meng ---
I can't get the build to pass with the same configure scripts on current GCC
HEAD :(
--host=x86_64-linux-gnu --build=aarch64-linux --target=riscv64-linux
--enable-targets=all
On Thu, Jun 29, 2023 at 05:58:22PM +0200, Martin Jambor wrote:
> Hi,
>
> On Tue, Jun 27 2023, Marek Polacek wrote:
> > On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote:
> >> Hello,
> >>
> >> On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote:
> >> > As promised in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432
--- Comment #10 from Iain Sandoe ---
(In reply to Patrick Palka from comment #9)
> (In reply to Jonathan Wakely from comment #1)
> > Patrick, we talked about this and IIRC your suggestion was to move the
> > __has_attribute check into
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110381
Christophe Lyon changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org
--- Comment
Hi,
On Tue, Jun 27 2023, Marek Polacek wrote:
> On Tue, Jun 27, 2023 at 01:39:16PM +0200, Martin Jambor wrote:
>> Hello,
>>
>> On Tue, May 16 2023, Marek Polacek via Gcc-patches wrote:
>> > As promised in the --enable-host-pie patch, this patch adds another
>> > configure option,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110432
--- Comment #8 from Sascha Scandella ---
I've tested the proposed solution ...
#if !__has_attribute(__init_priority__) || defined __APPLE__
... and it works as expected. I had also done something similar before, so I
wasn't that surprised.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
Andrew Pinski changed:
What|Removed |Added
Summary|-Warray-bounds=2 new false |[14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110252
--- Comment #11 from Andrew Pinski ---
*** Bug 110475 has been marked as a duplicate of this bug. ***
On Thu, Jun 29, 2023 at 11:22:55AM -0400, Patrick Palka via Gcc-patches wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk/13?
>
> -- >8 --
>
> cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding
> a CONSTRUCTOR initializer, which for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110475
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #3 from seurer at gcc dot gnu.org ---
I just tried r14-2190-ge972bdce61cc52 on another BE machine and got:
spawn [open ...]
by value(kind=1): B
by value(kind=1): A
Program received signal SIGSEGV: Segmentation fault - invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110484
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2
gcc/ChangeLog:
* cselib.h (rtx_equal_for_cselib_1):
Change return type from int to bool.
(references_value_p): Ditto.
(rtx_equal_for_cselib_p): Ditto.
* expr.h (can_store_by_pieces): Ditto.
(try_casesi): Ditto.
(try_tablejump): Ditto.
(safe_from_p): Ditto.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101537
--- Comment #9 from wolter.hellmundvega at tevva dot com ---
Will the current fix be released when the C++ FE is patched as well or perhaps
before that?
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Although the copy_file_range(2) man page shows the arguments as off64_t*
that is not portable. For musl there is no off64_t type, as off_t is
always 64-bit. Use the loff_t type which is always 64-bit even if off_t
isn't. We could just use off_t
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13?
-- >8 --
cp_fold is neglecting to propagate CONSTRUCTOR_MUTABLE_POISON when folding
a CONSTRUCTOR initializer, which for the below testcase causes us to fail
to reject a mutable member access of a constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/13/12?
-- >8 --
Here we find ourselves instantiating the NSDMI for A<1>::m when
computing argument conversions during overload resolution, and
thus tf_conv is set. This causes mark_used for the constructor
used in
This build failure for riscv32-esp-elf was "reported" on the gcc-help list:
https://gcc.gnu.org/pipermail/gcc-help/2023-June/142641.html
Tested x86_64-linux. Pushed to trunk.
-- >8 --
Building libstdc++ reportedly fails for targets without lock-free
std::atomic which don't define
Hi, ALexandre,
Thank you for the explanation.
I am now clear with the interaction between hardbool and
-ftrivial-auto-var-init, and also agree
that clarifying the documentation on their interaction is good enough.
Qing
> On Jun 29, 2023, at 6:30 AM, Alexandre Oliva wrote:
>
> On Jun 28,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110479
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110462
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ff29ee6af88f709e08ee467869d8c1b13889a724
commit r14-2191-gff29ee6af88f709e08ee467869d8c1b13889a724
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110472
--- Comment #2 from Ryan Holt ---
(In reply to Andrew Pinski from comment #1)
> I think it is just wrong iv-opt choices.
>
> Works just fine on aarch64-linux-gnu too:
> ubuntu@ubuntu:~/src/upstream-gcc-aarch64\# ~/upstream-gcc/bin/gcc t4.c -O2
On 6/29/23 02:11, Richard Biener wrote:
On Wed, 28 Jun 2023, Jeff Law wrote:
On 6/28/23 22:04, Li, Pan2 wrote:
It seems this patch may result in many test ICE failures on RISC-V backend.
Could you help to double confirm about it follow the possible reproduce
steps like blow? Thank you!
Hi Juzhe,
just looking at the documentation changes.
> +@cindex @code{len_mask_gather_load@var{m}@var{n}} instruction pattern
> +@item @samp{len_mask_gather_load@var{m}@var{n}}
> +Like @samp{gather_load@var{m}@var{n}}, but takes an extra len operand
> +as operand 5 and an extra mask operand as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110486
--- Comment #1 from Andrew Pinski ---
The question is the second lamdba implicitly consteval or not ...
If it is, then the bug is dealing with that. That is adding consteval to the
second lamdba allows GCC to accept the code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #12 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Jonathan Wakely from comment #9)
> > One solution would be to just add the declaration to the header, and adjust
> > the exports so this new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38341
wolter.hellmundvega at tevva dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #11 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> This affects aarch64 too:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620335.html
> And probably other targets where long double uses binary128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #10 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #9)
> One solution would be to just add the declaration to the header, and adjust
> the exports so this new symbol is exported at GLIBCXX_3.4.32 not
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #24 from Jürgen Reuter ---
Here is a first reproducer without the need for OCaml, unfortunately a bit too
big to be uploaded, here is the link:
https://www.desy.de/~reuter/downloads/repro001.tar.xz
the tarball contains Fortran files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110486
Bug ID: 110486
Summary: gcc rejects constant expression with consteval lambda
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
>> Hi Robin:
>>
>>> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc
>>> index 52d7626e92e..14d419c2013 100644
>>> --- a/gcc/lto/lto-lang.cc
>>> +++ b/gcc/lto/lto-lang.cc
>>> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p)
>>>else if (GET_MODE_CLASS (mode) ==
On 6/29/23 01:39, Christoph Müllner wrote:
On Wed, Jun 28, 2023 at 8:23 PM Jeff Law wrote:
On 6/28/23 06:39, Christoph Müllner wrote:
+;; XTheadMemIdx overview:
+;; All peephole passes attempt to improve the operand utilization of
+;; XTheadMemIdx instructions, where one sign or zero
Kito Cheng writes:
> Hi Robin:
>
>> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc
>> index 52d7626e92e..14d419c2013 100644
>> --- a/gcc/lto/lto-lang.cc
>> +++ b/gcc/lto/lto-lang.cc
>> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p)
>>else if
Hi Robin:
> diff --git a/gcc/lto/lto-lang.cc b/gcc/lto/lto-lang.cc
> index 52d7626e92e..14d419c2013 100644
> --- a/gcc/lto/lto-lang.cc
> +++ b/gcc/lto/lto-lang.cc
> @@ -1050,7 +1050,7 @@ lto_type_for_mode (machine_mode mode, int unsigned_p)
>else if (GET_MODE_CLASS (mode) == MODE_VECTOR_BOOL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #9 from Jonathan Wakely ---
Thanks for the quick response!
For x86 both these conditions are false:
#if defined(__STDCPP_FLOAT128_T__) &&
defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128)
...
#elif defined(__STDCPP_FLOAT128_T__) &&
On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote:
>
>
>
>
>
> From: Richard Biener
> Date: Tuesday, June 27, 2023 at 12:58 PM
> To: Tejas Belagod
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] GNU Vector Extension -- Packed Boolean Vectors
>
> On Tue, Jun 27, 2023 at 8:30 AM Tejas
Hello,
On Thu, 29 Jun 2023, Julian Waters via Gcc wrote:
> int main() {
> asm ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
>
> asm volatile ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
> }
>
> objdump --disassemble-all -M intel -M
On Thu, 29 Jun 2023 at 14:50, Jonathan Wakely wrote:
>
>
> On Thu, 1 Jun 2023 at 12:05, Jonathan Wakely
> wrote:
>
>> On Thu, 1 Jun 2023 at 10:30, Christophe Lyon via Libstdc++
>> wrote:
>> >
>> > Hi,
>> >
>> >
>> > On Wed, 31 May 2023 at 14:25, Jonathan Wakely via Gcc-patches <
>> >
On Thu, Jun 29, 2023 at 2:06 PM Krister Walfridsson
wrote:
>
> On Thu, 29 Jun 2023, Richard Biener wrote:
>
> > The thing with signed bools is that the two relevant values are -1 (true)
> > and 0 (false), those are used for vector bool components where we also
> > need them to be of wider type
On Thu, 29 Jun 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > With applying loop masking to epilogues on x86_64 AVX512 we see
> > some significant performance regressions when evaluating SPEC CPU 2017
> > that are caused by store-to-load forwarding fails across outer
> > loop
Richard Biener writes:
> With applying loop masking to epilogues on x86_64 AVX512 we see
> some significant performance regressions when evaluating SPEC CPU 2017
> that are caused by store-to-load forwarding fails across outer
> loop iterations when the inner loop does not iterate. Consider
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #8 from Rainer Orth ---
(In reply to Jonathan Wakely from comment #6)
> This is going to be hard for me to figure out without access to a Solaris
> x86 system.
There's hope that at least one, maybe two, Solaris 11.4/x86 systems can
From: Lulu Cheng
Which may result in implicit references to $fp when frame_pointer_needed is
false,
causing regs_ever_live[$fp] to be true when $fp is not explicitly used,
resulting in $fp being used as the target replacement register in the rnreg
pass.
The bug originates from SPEC2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #7 from Rainer Orth ---
Created attachment 55426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55426=edit
32-bit i386-pc-solaris2.11 charconv.ii
On Thu, 1 Jun 2023 at 12:05, Jonathan Wakely wrote:
> On Thu, 1 Jun 2023 at 10:30, Christophe Lyon via Libstdc++
> wrote:
> >
> > Hi,
> >
> >
> > On Wed, 31 May 2023 at 14:25, Jonathan Wakely via Gcc-patches <
> > gcc-patches@gcc.gnu.org> wrote:
> >
> > > Tested powerpc64le-linux. Pushed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077
--- Comment #6 from Jonathan Wakely ---
This is going to be hard for me to figure out without access to a Solaris x86
system.
Could you please attach the output of this command using GCC trunk on solaris
x86?
g++ -std=c++23 -include charconv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110479
--- Comment #1 from Uroš Bizjak ---
(In reply to Thomas Koenig from comment #0)
> movl%edi, %ecx
This one? It is needed because SAL wants its count argument in %cl and first
argument is passed in %edi (mandated by x86_64 ABI).
With applying loop masking to epilogues on x86_64 AVX512 we see
some significant performance regressions when evaluating SPEC CPU 2017
that are caused by store-to-load forwarding fails across outer
loop iterations when the inner loop does not iterate. Consider
for (j = 0; j < m; ++j)
for
Hello,
On Thu, 29 Jun 2023, Krister Walfridsson wrote:
> > The thing with signed bools is that the two relevant values are -1 (true)
> > and 0 (false), those are used for vector bool components where we also
> > need them to be of wider type (32bits in this case).
>
> My main confusion comes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110485
Bug ID: 110485
Summary: vectorizing simd clone calls without loop masking
applied
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110468
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110457
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110484
--- Comment #1 from chenglulu ---
The following code modification problem can be solved：
--- a/gcc/config/loongarch/loongarch.cc
+++ b/gcc/config/loongarch/loongarch.cc
@@ -1112,7 +1112,9 @@ loongarch_first_stack_step (struct
On Thu, 29 Jun 2023, Richard Biener wrote:
The thing with signed bools is that the two relevant values are -1 (true)
and 0 (false), those are used for vector bool components where we also
need them to be of wider type (32bits in this case).
My main confusion comes from seeing IR doing
> This should probably use GET_MODE_PRECISION as well.
>
> OK if it bootstraps/tests on both aarch64 and riscv.
>
> Richard.
I found a several other instances, also in the frontends that
I'm not exactly sure about. I'm currently testing this but aarch64
bootstrap is still going to take a
On Thu, Jun 29, 2023 at 11:10 AM Robin Dapp via Gcc-patches
wrote:
>
> > Yeah, that part is OK, and was the case I was thinking about when
> > I said OK yesterday. But now that we allow BITSIZE != PRECISION,
> > it's possible for BITSIZE - PRECISION to be more than a full byte,
> > in which case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110484
Bug ID: 110484
Summary: Spec2017 541 after adding the
'-flto-fomit-frame-pointer' optimization, after
optimizing the rnreg, directly replaced other
registers with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476
--- Comment #3 from Jonathan Wakely ---
I think the justification for GCC's behaviour is that "representable value" is
to be interpreted in the context of FLT_EVAL_METHOD, so it means representable
as double (for FLT_EVAL_METHOD==1) or long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110483
Bug ID: 110483
Summary: Several gcc.dg/analyzer/out-of-bounds-diagram-*.c
tests FAIL
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
>> Since nobody else has provided a patch yet, is the attached OK as long
>> as x86 bootstrap and testsuite are clean?
>
> Yes.
Bootstrap and testsuite are good. Going to commit.
Thanks.
Regards
Robin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110476
--- Comment #2 from Peter Dimov ---
Discussion of FLT_EVAL_METHOD notwithstanding, I think that this behavior is
not allowed by https://eel.is/c++draft/lex.fcon#3.
"If the scaled value is not in the range of representable values for its type,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110477
--- Comment #8 from Peter Dimov ---
As I commented on the duplicate bug, I don't think this behavior is allowed by
https://eel.is/c++draft/lex.fcon#3.
"If the scaled value is not in the range of representable values for its type,
the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108742
--- Comment #13 from Peter Dimov ---
I think that https://eel.is/c++draft/lex.fcon#3 disagrees.
"If the scaled value is not in the range of representable values for its type,
the program is ill-formed. Otherwise, the value of a
Adding -mmove-max=128 and -mstore-max=128 to the dg-options of the
recently added gcc.target/i386/pieces-memcmp-2.c avoids changing the
intent of this testcase when adding -march=cascadelake to RUNTESTFLAGS.
Tested on x86_64-pc-linux-gnu. Committed as obvious.
2023-06-29 Roger Sayle
> Ohh, my fault: the `-flto` option should always be skipped, when run test.
Right, if tests run with `-flto` option, they will fail. However, I do believe
they are run only if LTO support is enabled, that's why my tests all passed
without explicitly skipping that option.
Your modification looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110482
Manuel Lauss changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110460
Manuel Lauss changed:
What|Removed |Added
CC||manuel.lauss at googlemail dot
com
---
On Jun 28, 2023, Qing Zhao wrote:
> In summary, Ada’s Boolean variables (whether it’s hardened or not) are
> represented as
> enumeration types in GNU IR.
Not quite. Only boolean types with representation clauses are. Those
without (such as Standard.Boolean) are BOOLEAN_TYPEs. But those
Oluwatamilore Adebayo writes:
> From: oluade01
>
> This patch adds new RTL for ABDL (sabdl, sabdl2, uabdl, uabdl2).
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-simd.md
> (vec_widen_abdl_lo_, vec_widen_abdl_hi_):
> Expansions for abd vec widen optabs.
>
Oluwatamilore Adebayo writes:
> From: oluade01
>
> This updates vect_recog_abd_pattern to recognize the widening
> variant of absolute difference (ABDL, ABDL2).
>
> gcc/ChangeLog:
>
> * internal-fn.cc (widening_fn_p, decomposes_to_hilo_fn_p):
> Add IFN_VEC_WIDEN_ABD to the switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110458
--- Comment #2 from Franz Sirl ---
This has been exposed by commit
r14-2013-gfb0447b1f6b7373f57cb3a3d17a46803cfd9909d "Hide IVOPTs strip_offset".
Yes. Thanks for taking care of it!
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-29 18:07
To: juzhe.zh...@rivai.ai; pan2.li; Richard Biener
CC: rdapp.gcc; gcc-patches; jeffreyalaw; kito.cheng
Subject: Re: [PATCH] Prevent TYPE_PRECISION on VECTOR_TYPEs
Ah, the one sub-thread continued
Ah, the one sub-thread continued before you were CC'ed.
Sorry about that.
Regards
Robin
> Currently, I have no ideal how to walk around this ICE in RISC-V port.
> Do you have any suggestions?
I'm already bootstrapping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/623184.html
I replied to all but it seems you got lost in the thread?
Regards
Robin
101 - 200 of 292 matches
Mail list logo
