https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #23 from Daniel Lundin ---
(In reply to jos...@codesourcery.com from comment #21)
> On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
>
> > First of all, it is questionable if gcc is still conforming after
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
--- Comment #7 from Iain Sandoe ---
(In reply to ibuclaw from comment #6)
> There's r13-1113 with introduced the use of visible().
>
> Can't see anything odd about the virtual function declaration that would
> suggest there's a mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108899
Bug ID: 108899
Summary: [13 Regression] ERROR: can't rename to
"saved-unsupported": command already exists on i386
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
--- Comment #3 from Kewen Lin ---
The attached patch can be bootstrapped and regress-tested and solve the
reported issue right after r13-5107-g6224db0e4d6d3b, but I can not reproduce
the failure with the latest trunk, interesting... I suspected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
--- Comment #2 from Kewen Lin ---
Created attachment 54512
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54512=edit
Consider debug insn in no_real_insns_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108273
Kewen Lin changed:
What|Removed |Added
Last reconfirmed||2023-02-23
Assignee|unassigned
On Wed, Feb 22, 2023 at 07:46:46PM +0100, Richard Biener wrote:
> Ok for stage1
Thanks. In that case, can we get at least following into GCC 13,
another spot that handles in IPA just BUILT_IN_UNREACHABLE and
not BUILT_IN_UNREACHABLE_TRAP?
Bootstrapped/regtested on x86_64-linux and i686-linux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
Bug ID: 108898
Summary: [13 Regression] Test introduced by
r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d
failed on i386
Product: gcc
Version: 13.0
Hi Jeff,
We do not have two independent implementations: my work is 100% based on
the vector intrinsic foundation in upstream GCC. In fact I have only
added two core patterns, vector add and subtract, that are based on the
existing vector intrinsics implementation:
(define_expand "add3"
>> I would object to anyone trying to push forward an autovec implementation
>> into
>> gcc-13. We're well past that point IMHO, even if the changes only
>> affected the RISC-V backend.
Yes, I am agree with Jeff's opinion. I finished infrastructure (intrinsic and
VSETVL PASS) of RVV now.
Now,
On 2/22/23 10:54, Michael Collison wrote:
Juzhe,
I disagree with this comment. There are many stakeholders for
autovectorization and waiting until GCC 14 is not a viable solution for
us as well as other stakeholders ready to begin work on autovectorization.
As we discussed I have been
gcc/ChangeLog:
* config/xtensa/xtensa.md
(zero_cost_loop_start, zero_cost_loop_end, loop_end):
Add missing "SI:" to PLUS RTXes.
---
gcc/config/xtensa/xtensa.md | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/config/xtensa/xtensa.md
In commit b2ef02e8cbbaf95fee98be255f697f47193960ec, the sibling call
insn included (use (reg:SI A0_REG)) to fix the problem, which added
a USE chain unconditionally to the data flow of register A0 during
the sibling call.
As a result, df_regs_ever_live_p (A0_REG) returns true, so even if
register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108897
--- Comment #2 from danakj at orodu dot net ---
Thank you for the workaround!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944
Patrick Palka changed:
What|Removed |Added
CC||danakj at orodu dot net
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108897
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108897
Bug ID: 108897
Summary: Comparing pointer to field in rvalue class is not
considered constant expression
Product: gcc
Version: 13.0
Status: UNCONFIRMED
On Tue, 21 Feb 2023, Arsen Arsenović wrote:
> Ping. Like last time, I rebased the series.
Thank you!
> The first two times around, I did not notice there's dedicated
> maintainers for the documentation component, and so, I am adding Gerald,
> Joseph and Sandra to CC this time. Apologies for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
ibuclaw at gcc dot gnu.org changed:
What|Removed |Added
CC||ibuclaw at gcc dot gnu.org
On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote:
> Some patches from this patchset appear to have been dropped due to size
> limits. I neglected to compress them last night. Here they are again:
I pushed 2/8 after spot checking the huge patch.
Just 2 out of 970 hunks FAILED (for
Just noticed this by chance:
How does this patch constitute a functional change (that matches the
ChangeLog)? It looks it only adds an empty line to the source code?
Gerald
On Tue, 21 Feb 2023, arthur.co...@embecosm.com wrote:
> From: Arthur Cohen
>
> gcc/rust/ChangeLog:
>
> *
Just noticed this by chance:
How does this patch constitute a functional change (that matches the
ChangeLog)? It looks it only adds an empty line to the source code?
Gerald
On Tue, 21 Feb 2023, arthur.co...@embecosm.com wrote:
> From: Arthur Cohen
>
> gcc/rust/ChangeLog:
>
> *
Hi Arsen,
On Fri, 27 Jan 2023, Arsen Arsenović via Gcc-patches wrote:
> gcc/d/ChangeLog:
>
> * implement-d.texi: Reorder index entries around @items.
>
> gcc/ChangeLog:
>
> * doc/cfg.texi: Reorder index entries around @items.
> * doc/cpp.texi: Ditto.
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106977
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords|
In this test, we get a bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer::value;
to bool. Then ensure_literal_type_for_constexpr_object thinks the object
isn't literal and an error is reported.
This is another case of the interaction between tf_partial
Besides, since GCC 13 currently is on stage 4.
Unlike the infrastructure that I am building for intrinsic && auto-vec which is
safe and will not affect the original RISC-V port functionality.
Auto-vectorization will potentially affect the orignal RISC-V port
functionality which is not safe to
Currently, upstream GCC is not ready to support auto-vec.
I am building the basic infrastructure of RVV and need more testing.
I can't support auto-vec now since it depends on the infrastructure tha I am
building.
I have open source "rvv-next" in RISC-V foundation repo which fully support
On Wed, 22 Feb 2023, Tobias Burnus wrote:
> Comments? Suggestions?
OpenMP update for gcc-13/changes.html + projects/gomp/
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
+ Reverse offload is now supported with nvptx and AMD GCN devices.
Would it make sense to sort AMD
This is on top of what Qing nicely added back in 2018 - backlog on my
disk.
Pushed.
Gerald
---
htdocs/gcc-9/changes.html | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index 7dfae89c..89c20985 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
Marek Polacek changed:
What|Removed |Added
Summary|[11/12/13 Regression] slow |[11/12 Regression] slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #15 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1370014f2ea02ec185cf1199027575916f79fe63
commit r13-6290-g1370014f2ea02ec185cf1199027575916f79fe63
Author: Marek Polacek
Date:
On Wed, Feb 22, 2023 at 05:37:45PM -0500, Marek Polacek wrote:
> This fixes a compile-time hog with UBSan. This only happened in cc1 but
> not cc1plus. The problem is ultimately that c_genericize_control_stmt/
> STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
> nodes, so
This fixes a compile-time hog with UBSan. This only happened in cc1 but
not cc1plus. The problem is ultimately that c_genericize_control_stmt/
STATEMENT_LIST -> walk_tree_1 doesn't use a hash_set to remember visited
nodes, so it kept on recursing for a long time. We should be able to
use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670
Michael N. Moran changed:
What|Removed |Added
CC||mike at mnmoran dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #3 from Jakub Jelinek ---
-fstrict-flex-array= option doesn't affect the sanitization, if you want strict
sanitization of bounds, you should use -fsanitize=bounds-strict rather than
-fsanitize=bounds.
Furthermore, it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #1 from Kees Cook ---
The corresponding Clang feature request is here:
https://github.com/llvm/llvm-project/issues/60928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
Bug ID: 108896
Summary: provide "element_count" attribute to give more context
to __builtin_dynamic_object_size() and
-fsanitize=bounds
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108895
Bug ID: 108895
Summary: [13.0.1 (exp)] Fortran + gfx90a !$acc update device
produces a segfault.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Kees Cook changed:
What|Removed |Added
Attachment #54508|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
--- Comment #1 from Kees Cook ---
The matching Clang bug is: https://github.com/llvm/llvm-project/issues/60926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894
Bug ID: 108894
Summary: -fsanitize=bounds missing bounds provided by
__builtin_dynamic_object_size()
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #4 from Jonny Grant ---
My apologies, I had understood attribute access read_only was different from
the attribute nonnull. So I filed a different report for this.
I didn't want to use __attribute__((nonnull)) because the optimizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #14 from Marek Polacek ---
(In reply to Jakub Jelinek from comment #13)
> (In reply to Marek Polacek from comment #12)
> > Sure, it worked for the testcase because the STATEMENT_LIST only had two
> > stmts. I'm testing:
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #13 from Jakub Jelinek ---
(In reply to Marek Polacek from comment #12)
> Sure, it worked for the testcase because the STATEMENT_LIST only had two
> stmts. I'm testing:
>
> --- a/gcc/c-family/c-gimplify.cc
> +++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #3 from Andrew Pinski ---
(In reply to Jonny Grant from comment #0)
>
> void f(const char * const str) __attribute__((access(read_only, 1)));
> void f(const char * const str)
> {
> __builtin_puts(str);
> }
>
> int main()
> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871
--- Comment #3 from Andrew Pinski ---
*** Bug 108893 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
--- Comment #1 from Andrew Pinski ---
Isn't this the same as PR 108871 ?
Also, the access attribute does not imply the attribute nonnull; it may be
appropriate to add both attributes at the declaration of a function that
unconditionally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108893
Bug ID: 108893
Summary: attribute access read_only
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #12 from Marek Polacek ---
Sure, it worked for the testcase because the STATEMENT_LIST only had two stmts.
I'm testing:
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -516,7 +516,8 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #11 from Jakub Jelinek ---
(In reply to Marek Polacek from comment #10)
> Another simple patch is
>
> --- a/gcc/c-family/c-gimplify.cc
> +++ b/gcc/c-family/c-gimplify.cc
> @@ -516,7 +516,7 @@ c_genericize_control_stmt (tree
On Feb 17, 2023, Iain Sandoe wrote:
> As a matter of interest, do you know of any other compiler claiming
> “__clang__” (I have
> treated that as safe so far).
We've had (or found it more convenient, not sure) to do that to gcc on
some recent combinations of version and target of vxworks, for
On Feb 21, 2023, Richard Earnshaw wrote:
> Rather than scanning for the triplet, a better test would be
> { xfail { arm_eabi } }
Indeed, thanks. Here's the updated patch, retested. Ok to install?
[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods
From: Alexandre Oliva
thms: zlib zstd
gcc version 13.0.1 20230222 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #10 from Marek Polacek ---
Another simple patch is
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -516,7 +516,7 @@ c_genericize_control_stmt (tree *stmt_p, int
*walk_subtrees, void *data,
tree t =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #9 from Jakub Jelinek ---
(In reply to Richard Biener from comment #4)
> It's not only "slow", it also produces a gigantic executable, the .original
> dump was 7.1GB when I stopped the compilation ...
Well, original dump for deeply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts. This shouldn't make a
difference here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889
kargl at gcc dot gnu.org changed:
What|Removed |Added
Depends on||106089
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108891
Bug ID: 108891
Summary: libatomic: AArch64 SEQ_CST 16-byte load missing
barrier
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
> Am 22.02.2023 um 19:34 schrieb Jakub Jelinek :
>
> On Wed, Feb 22, 2023 at 12:35:24PM +, Jonathan Wakely wrote:
>> Yes, I was right, it doesn't work in gcc 4.8. This does though (with
>> typos above fixed too, and actually tested on GCC 4.8.5):
>
> I think we don't need the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108830
--- Comment #3 from David Malcolm ---
(In reply to David Malcolm from comment #0)
> There are also a huge number of spammy "'new_vals' is NULL" messages.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105958#c1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105958
--- Comment #1 from David Malcolm ---
A particularly bad example seems to be gcc.dg/analyzer/null-deref-pr108830.c:
https://godbolt.org/z/rabfxeaxz
which currently emits:
: In function 'apr_hash_merge':
:82:24: warning: dereference of NULL
On 2/22/23 13:03, Tamar Christina wrote:
-Original Message-
From: Andrew MacLeod
Sent: Wednesday, February 22, 2023 4:42 PM
To: Tamar Christina ; Richard Biener
; Richard Sandiford
Cc: Tamar Christina via Gcc-patches ; nd
; j...@ventanamicro.com
Subject: Re: [PATCH 1/2]middle-end:
On Wed, Feb 22, 2023 at 12:35:24PM +, Jonathan Wakely wrote:
> Yes, I was right, it doesn't work in gcc 4.8. This does though (with
> typos above fixed too, and actually tested on GCC 4.8.5):
I think we don't need the DECL_FUNCTION_CODE (node) in every recursive call,
we can just pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #8 from Marek Polacek ---
We generate HUGE trees for the div sanitization, but I notice that
c_genericize_control_r doesn't use pset, like cp_genericize_r does. So I think
the fix would be to add a hash_set to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
--- Comment #8 from Steve Kargl ---
On Wed, Feb 22, 2023 at 08:48:07AM +, rguenth at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108878
>
> --- Comment #6 from Richard Biener ---
> For the specific testcase I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108879
David Malcolm changed:
What|Removed |Added
Blocks||97110
--- Comment #1 from David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108890
Bug ID: 108890
Summary: Translation mistakes 2023
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
On Wed, Feb 22, 2023 at 06:37:39PM +0800, Kewen.Lin wrote:
> Thanks for working on this! If updating libgcc source to workaround this
> issue
> is the best option we can have at this moment, it's fine.
Thanks. Yes, I agree that it does not fix the root issue.
> Comparing to one
> previous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889
Bug ID: 108889
Summary: [12/13 Regression] (Re)Allocate in assignment shows
used uninitialized memory warning with -Wall if LHS is
unallocated
Product: gcc
> -Original Message-
> From: Andrew MacLeod
> Sent: Wednesday, February 22, 2023 4:42 PM
> To: Tamar Christina ; Richard Biener
> ; Richard Sandiford
> Cc: Tamar Christina via Gcc-patches ; nd
> ; j...@ventanamicro.com
> Subject: Re: [PATCH 1/2]middle-end: Fix wrong overmatching of
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Romanian team of translators. The file is available at:
https://translationproject.org/latest/cpplib/ro.po
(This file,
cpplib-13.1-b20230212.ro.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Wed, Feb 22, 2023 at 06:13:07PM +0800, Kewen.Lin wrote:
> These two above paragraphs look a bit out of date (two patches now). :)
Thanks.
> IIUC this patch actually fixes a latent issue, so it is independent of the one
> fixing the bootstrapping issue, right? This updated version of patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
--- Comment #12 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:31303c9b5bab200754cdb7ef8cd91ae4918f3018
commit r13-6289-g31303c9b5bab200754cdb7ef8cd91ae4918f3018
Author: Harald Anlauf
Date:
Juzhe,
I disagree with this comment. There are many stakeholders for
autovectorization and waiting until GCC 14 is not a viable solution for
us as well as other stakeholders ready to begin work on autovectorization.
As we discussed I have been moving forward with patches for
> From: Qing Zhao
> Date: Wed, 15 Feb 2023 20:30:00 +0100
> Thank you for fixing this issue.
Thanks! Although you're not holding an approver position
I'm tempted to take that as approval, as you're the author
of that test. This being a patch of no particular
significance and having seen no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #29 from Jonathan Wakely ---
It adds a new symbol to the library, which is not usually considered an ABI
change, because it's backwards compatible. Compiling with a new GCC and linking
to an old libstdc++ is never supported anyway.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/cpplib/de.po
(This file,
cpplib-13.1-b20230212.de.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
On Feb 20, 2023, Jason Merrill wrote:
> This seems like an ugly kludge around that problem, but I don't have
> any clever ideas of a better approach short of rewriting everything.
> So, OK with a comment explaining the rationale above your overridden
> "unsupported".
> Also, your commit subject
Hello, Kyrylo,
On Feb 20, 2023, Kyrylo Tkachov wrote:
> So rather than overriding this awkward part with
> -mno-fix-cortex-a57-aes-1742098 I'd rather just select a different
> CPU that enables that fusion and isn't afflicted by this workaround,
> such as -mcpu=cortex-a53.
Sounds good to me.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329
--- Comment #28 from yan12125 <49tbwddbqeazdawz at chyen dot cc> ---
Thanks, so that commit changes ABI - objects built by patched GCC will not link
to unpatched libstdc++. I will stick to -Wno-restrict for now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219
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=69960
--- Comment #22 from joseph at codesourcery dot com ---
I do however expect there may be cases in GCC 13 where constexpr
initializers of floating type are accepted that do not meet the definition
of arithmetic constant expressions, since GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
--- Comment #21 from joseph at codesourcery dot com ---
On Wed, 22 Feb 2023, daniel.lundin.mail at gmail dot com via Gcc-bugs wrote:
> First of all, it is questionable if gcc is still conforming after the change
> discussed here and implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Marek Polacek changed:
What|Removed |Added
Keywords||ice-on-valid-code
Richard how would I check for a full masked main vector loop?
On 2/22/23 03:20, Richard Biener wrote:
On Wed, Feb 22, 2023 at 12:03 AM Michael Collison wrote:
While working on autovectorizing for the RISCV port I encountered an
issue where vect_do_peeling assumes that the vectorization factor
On 2/15/23 13:42, Andrew MacLeod wrote:
On 2/15/23 12:50, Andrew MacLeod wrote:
On 2/15/23 12:13, Tamar Christina wrote:
On 2/15/23 07:51, Tamar Christina wrote:
void
operator_plus::wi_fold (irange , tree type,
const wide_int _lb, const wide_int _ub,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: error: definition in block 26 follows the use
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Thank you for your response Martin. Actually I sent this mail a week ago
and yeah now the wiki page of gcc has been updated (although I'm very much
sure these topics were listed over there but that's totally fine) and so
today itself I sent another mail with expressing an interest in working on
Hello Kritika,
we are delighted that you decided to apply for GSoC and that you are
interested in choosing GCC as the project to contribute to.
On Mon, Feb 13 2023, Kritika Rag via Gcc wrote:
> Hello Sir/Mam,
>
> I’m Kritika Rag, a Computer Science pre-final year undergraduate student
> from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108880
--- Comment #7 from Marek Polacek ---
The C90/C99 difference is due to ubsan_instrument_shift:
193 /* For signed x << y, in C99 and later, the following:
194 (unsigned) x >> (uprecm1 - y)
195 if non-zero, is undefined. */
196
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108858
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
1 - 100 of 219 matches
Mail list logo
