https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106798
Bug ID: 106798
Summary: adjacent_view::_Iterator(_Iterator) requires
random_access_iterator
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
In the example below, 'x' is once placed on the stack frame and then read
into registers as the argument value of bar():
/* example */
struct foo {
int a, b;
};
extern struct foo bar(struct foo);
struct foo test(void) {
struct foo x = { 0, 1 };
return bar(x);
This patch eliminates all clobbers for complex hard registers that will
be overwritten entirely afterwards (supersedence of
3867d414bd7d9e5b6fb2a51b1fb3d9e9e1eae9).
gcc/ChangeLog:
* config/xtensa/xtensa.md: Rewrite the split pattern that performs
the abovementioned process so
Hi,
This patch changes the sequence of test directives for 3 test cases.
Originally, these 3 cases got failed or unsupported on some platforms, as
their effective target checks depend on compiling options.
Bootstrapped and tested on powerpc64-linux BE and LE with no regressions.
Is this okay
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106682
--- Comment #2 from CVS Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:023c5b36e476976cb3b45ff32c7c64990c5a6d45
commit r13-2332-g023c5b36e476976cb3b45ff32c7c64990c5a6d45
Author: Kewen Lin
Date: Thu Sep
Hi all,
A reminder that an open meeting to draft the RISC-V V C Intrinsic API v1.0
release is going to
be held on next Monday 2022/09/05 7AM (GMT -7) / 10PM (GMT +8). The planned
agenda will
be to have a roundtable of introductions for participants and briefly go over
milestones for
v1.0
Any feedback regarding this proposal:
https://gcc.gnu.org/pipermail/libstdc++/2021-June/052821.html
On 23/06/21 22:34, François Dumont wrote:
Hi
Following the message to propose an alternative lower_bound and the
reply to use three way comparison I try to implement this.
Before going
The V registers are always clobbered on calls.
gcc/ChangeLog
* config/riscv/riscv.cc (riscv_conditional_register_usage):
Always mark the V registers as clobbered on calls.
---
gcc/config/riscv/riscv.cc | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff
Hi,
Currently, these two splitters (touched in this patch) are using predicate
`int_reg_operand_not_pseudo`, then they work in split2 pass after RA in
most times, and can not run before RA.
It would not be a bad idea to allow these splitters before RA. Then more
passes (between split1 and
Hi,
As mentioned in PR106550, since pli could support 34bits immediate, we could
use less instructions(3insn would be ok) to build 64bits constant with pli.
For example, for constant 0x020805006106003, we could generate it with:
asm code1:
pli 9,101736451 (0x6106003)
sldi 9,9,32
paddi 9,9,
On 8/31/22 6:45 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
>> Changes from v1:
>> * Fix spelling typo in git log entry
>> * Fix broken test checking src_ptr's type
>> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
>> * Change order of dg-options
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101322
--- Comment #2 from CVS Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:2985049049f12b0aa3366ca244d387820385b9e8
commit r13-2331-g2985049049f12b0aa3366ca244d387820385b9e8
Author: Peter Bergner
Date:
Committed with title fix, that should be TARGET_CONDITIONAL_REGISTER_USAGE
On Tue, Aug 30, 2022 at 2:28 PM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_conditional_register_usage): Add RVV
> registers.
>
> ---
> gcc/config/riscv/riscv.cc | 9
Committed.
On Tue, Aug 30, 2022 at 2:21 PM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_const_insns): Add cost of poly_int.
> (riscv_output_move): Add csrr vlenb assembly.
> * config/riscv/riscv.md (move_type): Add csrr vlenb type.
>
Thanks, committed!
On Tue, Aug 30, 2022 at 2:15 PM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/constraints.md (TARGET_VECTOR ? V_REGS : NO_REGS): Add
> "vr" constraint.
> (TARGET_VECTOR ? VD_REGS : NO_REGS): Add "vd" constraint.
> (TARGET_VECTOR ?
Thanks, pushed to trunk.
On Tue, Aug 30, 2022 at 10:58 AM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.h (enum reg_class): Change vype to vtype.
>
> ---
> gcc/config/riscv/riscv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
Thanks, pushed with a few minor style fixes.
On Tue, Aug 30, 2022 at 9:51 AM wrote:
>
> From: zhongjuzhe
>
> gcc/ChangeLog:
>
> * config/riscv/riscv.cc (riscv_convert_vector_bits): Change
> configuration according to TARGET_MIN_VLEN.
> * config/riscv/riscv.h (UNITS_PER_FP_REG):
On Linux/x86_64,
b911ca4231a366ddfd026f190b126bd517f4e640 is the first bad commit
commit b911ca4231a366ddfd026f190b126bd517f4e640
Author: Jonathan Wakely
Date: Fri Aug 26 16:22:21 2022 +0100
libstdc++: Add [[nodiscard]] attribute to and
caused
FAIL: g++.dg/tree-ssa/empty-loop.C
On Linux/x86_64,
61c4c989034548f481d1f10198447be27fb9a55f is the first bad commit
commit 61c4c989034548f481d1f10198447be27fb9a55f
Author: Richard Sandiford
Date: Tue Aug 30 15:43:47 2022 +0100
Extend SLP permutation optimisations
caused
FAIL: gcc.dg/vect/bb-slp-pr54400.c -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #9 from George Pee ---
Thank you for following up even after I closed the ticket.
Unfortunately, I'm unable to switch to a 64-bit kernel at the moment.
Using this works around the issue by treating it via a neon path and enabling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #4 from H.J. Lu ---
This simple change:
diff --git a/gcc/config/i386/i386-modes.def b/gcc/config/i386/i386-modes.def
index e2e1e18d24d..b49daaef253 100644
--- a/gcc/config/i386/i386-modes.def
+++ b/gcc/config/i386/i386-modes.def
@@
I'm implementing a tool for translation validation (similar to Alive2 for
LLVM). The tool uses an SMT solver to verify for each GIMPLE pass that the
output IR is a refinement of the input IR:
* That each compiled function returns an identical result before/after
the pass (for input that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106774
--- Comment #6 from Frank Heckenbach ---
> --- Comment #4 from Eric Gallager ---
> (In reply to Richard Biener from comment #3)
> > that's more coding style though?
>
> Yeah I personally prefer the more explicit way of writing it with both
>
On Wed, Aug 31, 2022 at 06:36:40PM -0500, Peter Bergner wrote:
> Changes from v1:
> * Fix spelling typo in git log entry
> * Fix broken test checking src_ptr's type
> * Use NOP_EXPR rather than VIEW_CONVERT_EXPR
> * Change order of dg-options
>
> When we expand an MMA disassemble built-in with
Changes from v1:
* Fix spelling typo in git log entry
* Fix broken test checking src_ptr's type
* Use NOP_EXPR rather than VIEW_CONVERT_EXPR
* Change order of dg-options
When we expand an MMA disassemble built-in with C++ using a pointer that
is cast to a valid MMA type, the type isn't passed
On 8/31/22 6:08 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
>> The problem goes away if I use use -O1 or above, I drop -flto or I use
>> the code I originally posted without the ptr_vector_*_type
>>
>> The assert in
On Wed, Aug 31, 2022 at 05:01:04PM -0500, Peter Bergner wrote:
> The problem goes away if I use use -O1 or above, I drop -flto or I use
> the code I originally posted without the ptr_vector_*_type
>
> The assert in gimple_canonical_types_compatible_p() we're hitting is:
> 13673 default:
>
A passing build has been detected on builder gccrust-rawhide-x86_64 while
building gccrust.
Full details are available at:
https://builder.sourceware.org/buildbot/#builders/132/builds/167
Build state: build successful
Revision: 63403f0af7203f3b3c4bc2fef52fee884bb728b8
Worker: bbo1-1
Build
Implement some changes to the currently supported C2x standard
attributes that have been made to the specification since they were
first implemented in GCC, and some consequent changes:
* maybe_unused is now supported on labels. In fact that was already
accidentally supported in GCC as a
On Wed, Aug 31, 2022 at 08:35:12PM +, Qing Zhao wrote:
> One of the major purposes of the new option -fstrict-flex-array is to
> encourage standard conforming programming style.
>
> So, it might be reasonable to treat -fstrict-flex-array similar as -pedantic
> (but only for flexible array
On 8/31/22 4:49 PM, Segher Boessenkool wrote:
> But it is incorrect as well. Instead, we should look if -mpowerpc64 is
> enabled explicitly, and not change it if so.
Sure, I agree with checking for explicit use. That said, I'll let
someone else work on this.
Peter
On Wed, Aug 31, 2022 at 08:16:49PM +, Qing Zhao wrote:
>
> > On Aug 31, 2022, at 4:09 PM, Joseph Myers wrote:
> >
> > On Wed, 31 Aug 2022, Qing Zhao wrote:
> >
> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
> [] is treated as a valid flexible array)
On 8/31/22 3:51 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
>> Question for my own education, when would you use VIEW_CONVERT_EXPR over
>> NOP_EXPR?
>
> VIEW_CONVERT_EXPR is essentially a bit_cast. Only use it when you need
> that, it is
On Wed, Aug 31, 2022 at 04:38:02PM -0500, Peter Bergner wrote:
> On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> >> Changing OS_MISSING_POWERPC64 as I mentioned would not add
> >> OPTION_MASK_POWERPC64
> >> to our cpu masks when
On 8/31/22 4:07 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
>> Changing OS_MISSING_POWERPC64 as I mentioned would not add
>> OPTION_MASK_POWERPC64
>> to our cpu masks when -m32 is used.
>
> So you say this is where the bug is?
For linux64.h
> + case GFC_FPE_GFC_FPE_AWAY:
>
> typo?
Absolutely. Didn’t break the build because glibc currently doesn’t define
FE_TONEARESTFROMZERO, but it should in the future (when C2x is included).
FX
This introduces an early exit test to most_specialized_partial_spec for
the common case where we have no partial specializations, which allows
us to avoid some unnecessary work. In passing, clean the function up a
bit.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
On Wed, Aug 31, 2022 at 02:53:07PM -0500, Peter Bergner wrote:
> On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> Right, but haven't the 64-bit Linux kernels been fixed forever to always
> save/restore the full 64-bit hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #11 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #10)
> (In reply to Segher Boessenkool from comment #9)
> > When MMA is not enabled,
> ...
> > the __vector_{quad,pair} types should not exist,
>
>
Hi,
This patch fixes PR106627. I ran the i386.exp tests on my x86_64-linux-gnu
machine with a fully bootstrapped checkout. I also tested manually that no
exception handling code is generated if none of the function versions throws an
exception.
I don't have access to a machine to test the
On Wed, Aug 31, 2022 at 01:53:48PM -0500, Peter Bergner wrote:
> ...and of course, now I can't recreate that issue at all and the
> ptr_vector_*_type use work fine now. Strange! ...so ok, changed.
> Maybe the behavior changed since my PR106017 fix went in???
That is my best guess as well. But,
On 31 August 2022 20:29:12 CEST, FX via Fortran wrote:
+ case GFC_FPE_GFC_FPE_AWAY:
typo?
thanks,
On 8/31/22 07:57, Palmer Dabbelt wrote:
if (flag_pic)
- riscv_cmodel = CM_PIC;
+ riscv_cmodel = CM_MEDANY;
/* We get better code with explicit relocs for CM_MEDLOW, but
worse code for the others (for now). Pick the best default. */
I'm fine either way on this one:
On 8/31/22 07:57, Palmer Dabbelt wrote:
On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 3 ---
1 file changed, 3
> On Aug 31, 2022, at 4:16 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Okay, I am fine with this.
Another thought on this is:
One of the major purposes of the new option -fstrict-flex-array is to encourage
standard conforming programming style.
So, it might be reasonable to treat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106794
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106789
Martin Liška changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106792
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Okay, I am fine with this.
Richard and Kees, what’s your opinion on this?
thanks.
Qing
> On Aug 31, 2022, at 4:09 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao wrote:
>
When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
[] is treated as a valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106795
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
I missed this testsuite fix in the libstdc++ commit.
Tested x86_64-linux, pushed to trunk.
-- >8 --
std::string now has [[nodiscard]] attributes on most members, causing
-Wunused-result warnings for this test.
gcc/testsuite/ChangeLog:
PR testsuite/106795
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106795
--- Comment #1 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2dbe2801df3010c5549a3ca958194aa77737122d
commit r13-2320-g2dbe2801df3010c5549a3ca958194aa77737122d
Author: Jonathan Wakely
On Wed, 31 Aug 2022, Qing Zhao wrote:
> >> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
> >> [] is treated as a valid flexible array) present together,
> >
> > That seems reasonable enough without a warning. If people want a warning
> > for flexible array members in
On Wed, 31 Aug 2022 at 20:27, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
On Wed, 31 Aug 2022 at 20:33, François Dumont wrote:
>
> On 31/08/22 12:11, Jonathan Wakely wrote:
> > On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
> >> After a second thought here is an even cleaner version. No more function
> >> rename, current pretty_print is fine.
> >>
> >>
> On Aug 31, 2022, at 3:52 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao wrote:
>
>> Does the above mean that -std=gnu89 does not support C99 flexible array
>> member, then
>
> No.
>
> Flexible array members are supported by GCC in all C standards modes. The
> C90 standard
On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No. Instead, it just works!
>
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
> x *= 42;
> return (vf){x, x, x, x};
> }
> ===
>
On Wed, 31 Aug 2022, Qing Zhao wrote:
> Does the above mean that -std=gnu89 does not support C99 flexible array
> member, then
No.
Flexible array members are supported by GCC in all C standards modes. The
C90 standard doesn't support them, but that's irrelevant to what GCC
supports; it just
> On Aug 31, 2022, at 3:29 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify
>>> -std=c89? How for -std=gnu89?
>>
>> 1. what’s the major difference between -std=c89 and -std=gnu89
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #10 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #9)
> When MMA is not enabled,
...
> the __vector_{quad,pair} types should not exist,
Unfortunately, target type initialization only occurs once at the very
On 31/08/22 12:11, Jonathan Wakely wrote:
On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.
libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
Add
On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> >> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> >
> > Oh? Why should it disable -maltivec?
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > How is level 3 (thus -fstrict-flex-array) interpreted when you specify
> > -std=c89? How for -std=gnu89?
>
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible
> array? (Checked online, cannot find a concrete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106797
--- Comment #2 from Pavel M ---
Observation: if "static" is removed, then GCC generates:
: In function 'f2':
:10:18: error: conflicting types for 'x'; have 'int (*)[5]'
10 | extern int (*x)[5];
| ^
:5:18: note:
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__advance_fn::operator()): Add
parentheses in assert condition to avoid -Wparentheses warning.
* include/std/ranges: (take_view::take_view): Uglify 'base'.
> On Aug 31, 2022, at 2:55 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote:
>>
>> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>>
"a GNU extension" suggests a particular language feature, but I think
you're actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106797
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21343
Joseph S. Myers changed:
What|Removed |Added
CC||pavel.morozkin at gmail dot com
---
Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>
>> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
>> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>> >
>> >> I was hoping Joseph would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106797
Bug ID: 106797
Summary: Improvement: diagnose undefined behavior: not all
declarations that refer to the same object or function
have compatible type
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106795
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>>> "a GNU extension" suggests a particular language feature, but I think
>>> you're actually referring here to a whole language version rather than an
>>> individual feature.
>>
On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> - tree src_type = TREE_TYPE (src_ptr);
>>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> + ? build_pointer_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
--- Comment #9 from Segher Boessenkool ---
When MMA is not enabled, the movxo and movoo patterns should never be reached
at all; the __vector_{quad,pair} types should not exist, and the
{XO,OO}mode-using
code should then never be created. So
This adds new F2018 features, that are not really enabled (because their
runtime support is optional).
1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known targets,
but could be supported by glibc and AIX as part of the C2x proposal. Testing
for now is minimal, but once a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106796
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106679
--- Comment #4 from Andrew Pinski ---
*** Bug 106796 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106796
Bug ID: 106796
Summary: [13 regression] gcc.dg/tree-prof/cmpsf-1.c fails after
r13-2098-g5adfb6540db95d
Product: gcc
Version: 13.0
Status: UNCONFIRMED
On 8/31/2022 10:40 AM, John David Anglin wrote:
On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too. Those
were so niche that I doubt anyone else would notice.
That should be okay. I have never heard of anyone building these.
There is no
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > "a GNU extension" suggests a particular language feature, but I think
> > you're actually referring here to a whole language version rather than an
> > individual feature.
>
> Is “not supported by GNU extension GNU89” better?
There are
On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> >
> >> I was hoping Joseph would chime in here - I recollect debugging this kind
> >> of thing and a thread
On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
>> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
>
> Oh? Why should it disable -maltivec? -mvsx makes a little sense on
> one hand, but totally none on the other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106794
--- Comment #2 from David Binderman ---
Reduced code seems to be:
template struct Vector3 {
Vector3();
Vector3(T, T, T);
T length() const;
T x, y, z;
};
template
Vector3::Vector3(T _x, T _y, T _z) : x(_x), y(_y), z(_z) {}
Vector3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106795
Bug ID: 106795
Summary: [13 regression] g++.dg/tree-ssa/empty-loop.C fails
with excess errors after r13-2303-gb911ca4231a366
Product: gcc
Version: 13.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
--- Comment #4 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #3)
> Tamar, any thoughts on that?
Apologies, didn't notice that earlier.
That should be "Target does not support vector type for %G\n"
with STMT_VINFO_STMT
On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too. Those were so
niche that I doubt anyone else would notice.
That should be okay. I have never heard of anyone building these. There is no
config for these in config.gcc.
hppa*-*-openbsd*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #8 from Richard Earnshaw ---
I spoke to our kernel experts about this and they think my hypothesis is quite
likely to be correct. They also noted that kernel version 4.9.118 is about 200
releases out of date on the 4.9 LTS series.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106794
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
Jakub Jelinek changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106794
--- Comment #1 from David Binderman ---
Git hash range seems to be 4fbe3e6aa74dae5c..3de9fb3235998a05, a distance of 28
commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106782
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106794
Bug ID: 106794
Summary: ice in vect_transform_slp_perm_load_1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
On 8/31/22 11:07, Jakub Jelinek wrote:
On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
It could be more explicit, but I think we can assume that from the existing
wording; it says it designates the named character. If there is no such
character, that cannot be satisfied, so it
On 8/25/2022 3:39 AM, Kong, Lingling via Gcc-patches wrote:
Hi,
The conditional mult reduction cannot be recognized with current GCC. The
following loop cannot be vectorized.
Now add MULT_EXPR recognition for conditional scalar reduction.
float summa(int n, float *arg1, float *arg2)
{
On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> > Should *any* explicit command line flag ever be disabled like that?
> > (Not talking about things like -m32 -m64, ...
>
> In a general sense, I'd agree that the answer is no, but we
On 8/29/2022 2:11 PM, Jan-Benedict Glaw wrote:
Hi Jeff!
On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches
wrote:
On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:
On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches
wrote:
This makes defaults.h choose DWARF2_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106786
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-08-31
Keywords|
On 8/17/2022 5:11 AM, Richard Biener via Gcc-patches wrote:
The following started as making the backward threader m_imports
use the tree representation. Since that interfaces to a list
representation bitmap in ranger by copying rewriting the tree
to list to perform the copy is inefficient in
Hi!
On Fri, Aug 26, 2022 at 10:50:00PM -0500, Peter Bergner wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
(The perfect tense of cast is "cast").
> machinery and we end up using the base
On 8/25/2022 3:42 AM, Martin Liška wrote:
Hi.
I wrote a scipt that runs autoconf in all folders that have configure.ac
file and same for autoheader (where AC_CONFIG_HEADERS is present) and
this is the output.
The script can be seen here:
1 - 100 of 261 matches
Mail list logo
