[Bug tree-optimization/106020] Spurious warnings about stringop overflows only with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 --- Comment #4 from Andrew Pinski --- I suspect it is warning on some unreachable code which is not optimized away until later. Until a full testcase is attached, it is going to be hard. Also it would be better if not using cmake, just use a

[Bug tree-optimization/106020] Spurious warnings about stringop overflows only with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 --- Comment #3 from Andrew Pinski --- Can you attach both files instead of the godbolt link?

[PATCH] c: Handle initializations of opaque types [PR106016]

The initial commit that added opaque types thought that there couldn't be any valid initializations for variables of these types, but the test case in the bug report shows that isn't true. The solution is to handle OPAQUE_TYPE initializations just like the other scalar types. This passed

[Bug c/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 Peter Bergner changed: What|Removed |Added Component|target |c --- Comment #9 from Peter Bergner

[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105991 --- Comment #4 from Segher Boessenkool --- (In reply to Marek Polacek from comment #0) > It doesn't look like a wrong code problem, but it seems more optimal to use > rldimi (rotate left, mask insert) rather than rotate left by 0 bits, AND >

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 --- Comment #8 from Peter Bergner --- (In reply to Peter Bergner from comment #7) > (In reply to Segher Boessenkool from comment #6) > > Like that yes. Pre-approved if it survives regcheck, too. Thanks! > > > > Please add the testcase as

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022 --- Comment #1 from H.J. Lu --- SLP thinks that it needs 4 stores to store 4 bytes of integer constant. But it takes only 1 4-byte store.

gcc-11-20220617 is now available

Snapshot gcc-11-20220617 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20220617/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch

[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #8

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED

[PATCH] libcpp: Support raw strings with newlines while processing directives [PR55971]

Hello- The attached fixes PR preprocessor/55971: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 , which is the issue that we don't currently allow raw string literals containing embedded newlines to appear in #define. With the patch, they can be used in any preprocessing directive. While I

Re: [RFC] analyzer: allocation size warning

On Fri, 2022-06-17 at 22:23 +0200, Tim Lange wrote: > On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote: > > On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote: [...snip...] > > > > I have resent the patch using git send-email as a reply to my original > message. > The new message

[Bug target/106022] New: [12/13 Regression] Enable vectorizer generates extra load

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022 Bug ID: 106022 Summary: [12/13 Regression] Enable vectorizer generates extra load Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 Peter Bergner changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org

Re: [RFC] analyzer: allocation size warning

On Fri, 2022-06-17 at 21:23 +0200, Tim Lange wrote: > > > On Fr, Jun 17 2022 at 22:45:42 +0530, Prathamesh Kulkarni > wrote: > > On Fri, 17 Jun 2022 at 21:25, Tim Lange wrote: > > > > > >  Hi everyone, > > Hi Tim, > > Thanks for posting the POC patch! > > Just a couple of comments (inline) >

Re: [PATCH] libgo: Recognize off64_t / loff_t type definition of musl libc

On Tue, May 31, 2022 at 12:41 PM Sören Tempel wrote: > > PING. > > If there is anything else that needs to be addressed please let me know. Thanks. Committed as follows. Sorry for the delay. Ian e584afe7976a40df42eed4df6ce6852abab74030 diff --git a/gcc/go/gofrontend/MERGE

[Bug analyzer/106021] New: RFE: more sources of taint: scanf and its cousins

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106021 Bug ID: 106021 Summary: RFE: more sources of taint: scanf and its cousins Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3

[PATCH RFA] ubsan: do return check with -fsanitize=unreachable

Related to PR104642, the current situation where we get less return checking with just -fsanitize=unreachable than no sanitize flags seems undesirable; I propose that we do return checking when -fsanitize=unreachable. Looks like clang just traps on missing return if not -fsanitize=return, but the

[Bug lto/106020] Spurious warnings about stringop overflows only with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 --- Comment #2 from Matt Godbolt --- There are many hundreds of similar errors in that example; perhaps this example is more of a clue: /opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/move.h:205:11: warning: writing 1 byte into a

[Bug lto/106020] Spurious warnings about stringop overflows only with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 --- Comment #1 from Matt Godbolt --- Apologies for the unreduced issue, if I get a chance I'll try and shorten it, but I hoped someone might recognise what the issue is from just this.

[Bug lto/106020] New: Spurious warnings about stringop overflows only with LTO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106020 Bug ID: 106020 Summary: Spurious warnings about stringop overflows only with LTO Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 --- Comment #6 from Segher Boessenkool --- FWIW, reinterpret_cast allows exactly the same things as C casts (but with the obvious C++ extensions: member objects, member functions, C++'s concept of lvalue, that kins of thing). It is not similar

Re: [PATCH]middle-end Add optimized float addsub without needing VEC_PERM_EXPR.

On Thu, Jun 16, 2022 at 3:59 AM Tamar Christina via Gcc-patches wrote: > > Hi All, > > For IEEE 754 floating point formats we can replace a sequence of alternative > +/- with fneg of a wider type followed by an fadd. This eliminated the need > for > using a permutation. This patch adds a

Re: [RFC] analyzer: allocation size warning

On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote: > On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote: > > Hi everyone, > > Hi Tim. > > Thanks for the patch. > > Various comments inline below, throughout... > > > > > tracked in PR105900 [0], I'd like to add support for a new

Re: [PATCH] alpha: Introduce target specific store_data_bypass_p function [PR105209]

On 6/17/2022 9:22 AM, Uros Bizjak via Gcc-patches wrote: This patch introduces alpha-specific version of store_data_bypass_p that ignores TRAP_IF that would result in assertion failure (and internal compiler error) in the generic store_data_bypass_p function. While at it, also remove

Re: GSoC Blog Post 0 - GCCprefab build system

On Fri, 17 Jun 2022 at 19:45, Bernhard Reutner-Fischer wrote: > > On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran > wrote: > > >https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh > > s/[[/[/ > s/==/=/ > > The former are deprecated or

Re: GSoC Blog Post 0 - GCCprefab build system

On Fri, Jun 17, 2022 at 08:45:04PM +0200, Bernhard Reutner-Fischer via Gcc wrote: > PS: we should rm https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=contrib/gcc_build No. gcc_build is used by maintainer-scripts/gcc_release, so by killing it you'd make gcc unreleasable. > It was not updated since

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 --- Comment #6 from Segher Boessenkool --- Like that yes. Pre-approved if it survives regcheck, too. Thanks! Please add the testcase as well of course :-)

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 Segher Boessenkool changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 --- Comment #5 from Peter Bergner --- (In reply to Peter Bergner from comment #4) > diff --git a/gcc/expr.cc b/gcc/expr.cc > index 78c839ab425..1675198a146 100644 > --- a/gcc/expr.cc > +++ b/gcc/expr.cc > @@ -6423,13 +6423,13 @@

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 --- Comment #4 from Peter Bergner --- (In reply to Segher Boessenkool from comment #3) > Yeah. It should just return 1 like the other scalar types? So the code did look for OPAQUE_TYPE and expected never to see it, so it was on an error path.

Re: [RFC] analyzer: allocation size warning

On Fr, Jun 17 2022 at 22:45:42 +0530, Prathamesh Kulkarni wrote: On Fri, 17 Jun 2022 at 21:25, Tim Lange wrote: Hi everyone, Hi Tim, Thanks for posting the POC patch! Just a couple of comments (inline) Hi Prathamesh, thanks for looking at it. tracked in PR105900 [0], I'd like to

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 --- Comment #4 from Nemanja Ivanovic --- (In reply to Peter Bergner from comment #2) > (In reply to Segher Boessenkool from comment #1) > > So the restriction in rs6000_invalid_conversion errors for valid C programs. > > What was it intended to

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

> Am 17.06.2022 um 19:09 schrieb Gaius Mulley via Gcc-patches > : > >  > New linking implementation is complete, gcc bootstraps and hello > world links. I'll git push the changes, then test/debug/polish and > produce new patch sets Great! Thanks, Richard > regards, > Gaius

[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #5

[Bug preprocessor/53920] "gcc -E" does not honor #pragma GCC diagnostic ignored "-Wunused-macro"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53920 --- Comment #4 from Lewis Hyatt --- *** Bug 64698 has been marked as a duplicate of this bug. ***

[Bug preprocessor/64698] preprocessor ignores #pragma GCC diagnostic when using -save-temps

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64698 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

Re: GSoC Blog Post 0 - GCCprefab build system

On 13 June 2022 17:26:59 CEST, Jonathan Wakely via Fortran wrote: >https://gist.github.com/jwakely/95b3a790157f55d75e18f577e12b50d7#file-build_gcc_versions-sh s/[[/[/ s/==/=/ The former are deprecated or obsolescent notations of test(1) syntax, fwiw. PS: we should rm

[Bug tree-optimization/105973] Wrong branch prediction for if (COND) { if(x) noreturn1(); else noreturn2(); }

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105973 --- Comment #7 from hubicka at kam dot mff.cuni.cz --- > I can try implementing that. That would be nice. I think if path predictor logic hits the same predictor both ways, it can simply predict that basic block with the same predictor (i.e.

[RFC] analyzer: add allocation size warning

I think my mail client did apply auto-wrap and reduced multiple spaces to a single one while doing so. Here again, the full patch as well as the ASCII diagnostics. This should look better now. On constant size allocations: /path/to/allocation-size-3.c:22:14: warning: Allocated buffer size is not

Re: [PATCH] ubsan: Add -fsanitize-trap= support

On 6/17/22 11:34, Jakub Jelinek via Gcc-patches wrote: On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote: It looks like clang has addressed this deficiency now: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage Thanks, that is roughly what I'd implement anyway

Re: [PATCH, rs6000] Use CC for BCD operations [PR100736]

Hi! On Fri, Jun 17, 2022 at 04:19:37PM +0800, HAO CHEN GUI wrote: > On 16/6/2022 下午 7:24, Segher Boessenkool wrote: > > You shouldn't need anything like this, bcdinvalid will work just fine if > > written as bcdadd_ov (with vector of 0 as the second op)? > > The vector of 0 is not equal to BCD

[Bug tree-optimization/106019] New: Surprising SLP failure on trivial code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106019 Bug ID: 106019 Summary: Surprising SLP failure on trivial code Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal

Re: [RFC] analyzer: allocation size warning

On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote: > Hi everyone, Hi Tim. Thanks for the patch. Various comments inline below, throughout... > > tracked in PR105900 [0], I'd like to add support for a new warning on > dubious allocation sizes. The new checker emits a warning when the >

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 --- Comment #3 from Segher Boessenkool --- Yeah. It should just return 1 like the other scalar types?

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 --- Comment #3 from Segher Boessenkool --- (In reply to Peter Bergner from comment #2) > We do not want or allow automatic conversions between the opaque > __vector_pair and __vector_quad types and other types and those are > correctly

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 --- Comment #2 from Peter Bergner --- Given where this is ICEing, I'm guessing this is non-target specific issue in handling opaque types.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 --- Comment #2 from Peter Bergner --- (In reply to Segher Boessenkool from comment #1) > So the restriction in rs6000_invalid_conversion errors for valid C programs. > What was it intended to accomplish? We do not want or allow automatic

[Bug target/106015] [PowerPC] pointer to MMA accumulator not convertible to char pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106015 --- Comment #2 from Segher Boessenkool --- Confirmed. Likely the same cause as PR106017.

[Bug target/106015] [PowerPC] pointer to MMA accumulator not convertible to char pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106015 Peter Bergner changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug target/106016] [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

kernel sparse annotations vs. compiler attributes and debug_annotate_{type,decl} WAS: Re: [PATCH 0/9] Add debug_annotate attributes

Hi Yonghong. > On 6/15/22 1:57 PM, David Faust wrote: >> >> On 6/14/22 22:53, Yonghong Song wrote: >>> >>> >>> On 6/7/22 2:43 PM, David Faust wrote: Hello, This patch series adds support for: - Two new C-language-level attributes that allow to associate (to

Re: [RFC] analyzer: allocation size warning

On Fri, 17 Jun 2022 at 21:25, Tim Lange wrote: > > Hi everyone, Hi Tim, Thanks for posting the POC patch! Just a couple of comments (inline) > > tracked in PR105900 [0], I'd like to add support for a new warning on > dubious allocation sizes. The new checker emits a warning when the > allocation

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to set the lowpart.

Tamar Christina writes: >> -Original Message- >> From: Richard Sandiford >> Sent: Monday, June 13, 2022 9:41 AM >> To: Tamar Christina >> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de >> Subject: Re: [PATCH]middle-end Use subregs to expand COMPLEX_EXPR to >> set the lowpart. >>

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

New linking implementation is complete, gcc bootstraps and hello world links. I'll git push the changes, then test/debug/polish and produce new patch sets regards, Gaius

[PATCH] c++, v2: Add support for __real__/__imag__ modifications in constant expressions [PR88174]

On Fri, Jun 10, 2022 at 09:57:06PM +0200, Jakub Jelinek via Gcc-patches wrote: > On Fri, Jun 10, 2022 at 01:27:28PM -0400, Jason Merrill wrote: > > Doesn't this assert mean that complex_expr will always be == valp? > > No, even when handling the pushed *PART_EXPR, it will set > valp = _OPERAND

[Bug c/106018] New: Feature Request: Add function attribute fn_enter, and fn_exit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106018 Bug ID: 106018 Summary: Feature Request: Add function attribute fn_enter, and fn_exit Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal

Re: Signed vs. unsigned compares

> On Jun 17, 2022, at 11:51 AM, Andreas Schwab wrote: > > On Jun 17 2022, Paul Koning via Gcc wrote: > >> In expanding a longer-than-word compare, I need to do things differently >> depending on whether a signed vs. unsigned compare is needed. But it seems >> the compare operation applies

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 --- Comment #6 from Steve Kargl --- On Fri, Jun 17, 2022 at 02:56:50PM +, wileamyp at outlook dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 > > --- Comment #5 from Wileam Yonatan Phan --- > Hi Steve, > > I think I

[Bug analyzer/105900] RFE: -fanalyzer could check malloc sizes when casting the result to a pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105900 --- Comment #3 from Tim Lange --- See also this mailing list thread: https://gcc.gnu.org/pipermail/gcc/2022-June/238907.html

[RFC] analyzer: allocation size warning

Hi everyone, tracked in PR105900 [0], I'd like to add support for a new warning on dubious allocation sizes. The new checker emits a warning when the allocation size is not a multiple of the type's size. With the checker, following mistakes are detected: int *arr = malloc(3); // forgot to

Re: Signed vs. unsigned compares

On Jun 17 2022, Paul Koning via Gcc wrote: > In expanding a longer-than-word compare, I need to do things differently > depending on whether a signed vs. unsigned compare is needed. But it seems > the compare operation applies to either. How can I do this in the target > code? There are

[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a284fadcce8ef443cc3cc047a8017745efb51758 commit r13-1158-ga284fadcce8ef443cc3cc047a8017745efb51758 Author: Jakub Jelinek Date:

[PATCH] ubsan: Add -fsanitize-trap= support

On Thu, Jun 16, 2022 at 09:32:02PM +0100, Jonathan Wakely wrote: > It looks like clang has addressed this deficiency now: > > https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html#usage Thanks, that is roughly what I'd implement anyway and apparently they have it already since 2015, we've

Signed vs. unsigned compares

Question for target code: In expanding a longer-than-word compare, I need to do things differently depending on whether a signed vs. unsigned compare is needed. But it seems the compare operation applies to either. How can I do this in the target code? paul

Re: [PATCH] varasm: Fix up ICE in narrowing_initializer_constant_valid_p [PR105998]

> Am 17.06.2022 um 11:20 schrieb Jakub Jelinek via Gcc-patches > : > > On Fri, Jun 17, 2022 at 10:37:45AM +0200, Richard Biener wrote: >>> --- gcc/varasm.cc.jj2022-06-06 12:18:12.792812888 +0200 >>> +++ gcc/varasm.cc2022-06-17 09:49:21.918029072 +0200 >>> @@ -4716,7 +4716,8 @@

[PATCH] alpha: Introduce target specific store_data_bypass_p function [PR105209]

This patch introduces alpha-specific version of store_data_bypass_p that ignores TRAP_IF that would result in assertion failure (and internal compiler error) in the generic store_data_bypass_p function. While at it, also remove ev4_ist_c reservation, store_data_bypass_p can handle the patterns

[Bug target/105209] internal compiler error: in store_data_bypass_p_1

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105209 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:cc378e655740e93743e7f43e14faaff707aef6c1 commit r13-1157-gcc378e655740e93743e7f43e14faaff707aef6c1 Author: Uros Bizjak Date: Fri

[PATCH] i386: Fix assert in ix86_function_arg [PR105970]

The mode of pointer argument should equal ptr_mode, not Pmode. 2022-06-17 Uroš Bizjak gcc/ChangeLog: PR target/105970 * config/i386/i386.cc (ix86_function_arg): Assert that the mode of pointer argumet is equal to ptr_mode, not Pmode. gcc/testsuite/ChangeLog: PR

[Bug c/105970] ICE in ix86_function_arg, at config/i386/i386.cc:3351

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105970 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:1f8278bfcfc7f7157bf2b405471e67dd5097636b commit r13-1156-g1f8278bfcfc7f7157bf2b405471e67dd5097636b Author: Uros Bizjak Date: Fri

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 --- Comment #5 from Wileam Yonatan Phan --- Hi Steve, I think I recognize you from the Fortran-lang Discourse forum! > The committee is ready to vote, but it is still a non-existent standard. That's technically true, since the votes haven't

[Bug c++/106011] [12 Regression] ICE: unexpected expression 'ElemSize' of kind template_parm_index

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106011 Sam James changed: What|Removed |Added CC||sam at gentoo dot org --- Comment #2 from

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 --- Comment #4 from Steve Kargl --- On Fri, Jun 17, 2022 at 02:31:20PM +, wileamyp at outlook dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 > > --- Comment #2 from Wileam Yonatan Phan --- > Wait, I thought the

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 --- Comment #3 from Steve Kargl --- On Fri, Jun 17, 2022 at 02:31:20PM +, wileamyp at outlook dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 > > --- Comment #2 from Wileam Yonatan Phan --- > Wait, I thought the

[Bug c/106017] New: [PowerPC] No array-to-pointer conversion for MMA accumulator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106017 Bug ID: 106017 Summary: [PowerPC] No array-to-pointer conversion for MMA accumulator Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/106005] (F2023) Support for REDUCE clause in DO CONCURRENT loop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106005 --- Comment #2 from Wileam Yonatan Phan --- Wait, I thought the committee is ready to vote on it? I've seen the draft of the summary paper by Reid linked from here:

[Bug c/106016] New: [PowerPC] crash with attempt to initialize array of MMA accumulators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106016 Bug ID: 106016 Summary: [PowerPC] crash with attempt to initialize array of MMA accumulators Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/105993] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -O -mxop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105993 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|---

[PATCH] i386: Fix VPMOV splitter [PR105993]

REGNO should not be used with register_operand before reload because subregs of registers or even subregs of memory match the predicate. The build with RTL checking enabled does not tolerate REGNO with non-reg operand. The patch splits the splitter into two related splitters and uses (match_dup

[Bug c/106015] New: [PowerPC] pointer to MMA accumulator not convertible to char pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106015 Bug ID: 106015 Summary: [PowerPC] pointer to MMA accumulator not convertible to char pointer Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug target/105993] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -O -mxop

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105993 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:1d6044c250e3badfa2a403fee670b295106bf4fc commit r13-1155-g1d6044c250e3badfa2a403fee670b295106bf4fc Author: Uros Bizjak Date: Fri

Re: [PATCH v1 2/3] RISC-V: Split slli+sh[123]add.uw opportunities to avoid zext.w

Kito, thanks: you were a few minutes ahead of my fix there. On Fri, 17 Jun 2022 at 16:00, Kito Cheng wrote: > Hi Andreas: > > Fixed via > https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d6b423882a05d7b4f40ae1e9d942c9c4c13761b7 > , > thanks! > > On Fri, Jun 17, 2022 at 4:34 PM Andreas Schwab >

Re: [PATCH] Add operators / and * for profile_{count,probability}.

> PING^2 Sorry, I thought it is approved once we settled down the multiplicatoin datatype, but apparently never sent the email. Patch is oK. Honza > > On 5/24/22 13:35, Martin Liška wrote: > > PING^1 > > > > On 5/5/22 20:15, Martin Liška wrote: > >> On 5/5/22 15:49, Jan Hubicka wrote: > >>> Hi,

[PATCH] rs6000: Fix some error messages for invalid conversions

"* something" isn't a type. "something *" is. Tested and committed. Segher 2022-06-17 Segher Boessenkool * config/rs6000/rs6000.cc (rs6000_invalid_conversion): Correct some types. --- gcc/config/rs6000/rs6000.cc | 8 1 file changed, 4 insertions(+), 4

Re: [PATCH] c: Extend the -Wpadded message with actual padding size

On Thu, Jun 16, 2022 at 09:37:32PM +0200, Vit Kabele wrote: > When the compiler warns about padding struct to alignment boundary, it > now also informs the user about the size of the alignment that needs to > be added to get rid of the warning. > > This removes the need of using pahole or similar

Re: [PATCH v1 2/3] RISC-V: Split slli+sh[123]add.uw opportunities to avoid zext.w

Hi Andreas: Fixed via https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d6b423882a05d7b4f40ae1e9d942c9c4c13761b7, thanks! On Fri, Jun 17, 2022 at 4:34 PM Andreas Schwab wrote: > > ../../gcc/config/riscv/bitmanip.md: In function 'rtx_insn* > gen_split_44(rtx_ins\ > n*, rtx_def**)': >

Re: [PATCH] xtensa: Defer storing integer constants into litpool until reload

erratum: - extern unsigned int value; + extern unsigned short value; On 2022/06/17 22:47, Takayuki 'January June' Suwa via Gcc-patches wrote: > Storing integer constants into litpool in the early stage of compilation > hinders some integer optimizations. In fact, such integer

[PATCH] xtensa: Defer storing integer constants into litpool until reload

Storing integer constants into litpool in the early stage of compilation hinders some integer optimizations. In fact, such integer constants are not subject to the constant folding process. For example: extern unsigned int value; extern void foo(void); void test(void) { if

[Bug target/106004] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106004 Richard Earnshaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

Re: [PATCH] c++: Use fold_non_dependent_expr rather than maybe_constant_value in __builtin_shufflevector handling [PR106001]

On 6/17/22 03:28, Jakub Jelinek wrote: Hi! In this case the STATIC_CAST_EXPR expressions in the call aren't type nor value dependent, but maybe_constant_value still ICEs on those when processing_template_decl. Calling fold_non_dependent_expr on it instead fixes the ICE and folds them to

[committed] arm: fix checking ICE in arm_print_operand [PR106004]

Sigh, another instance where I incorrectly used XUINT instead of UINTVAL. I've also made the code here a little more robust (although I think this case can't in fact be reached) if the 32-bit clear mask includes bit 31. This case, if reached, would print out an out-of-range value based on the

[Bug target/106004] [13 Regression] ICE: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in arm_print_operand, at config/arm/arm.cc:24202

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106004 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Earnshaw : https://gcc.gnu.org/g:040f8224617ad3924f606c8982da369f898693d1 commit r13-1152-g040f8224617ad3924f606c8982da369f898693d1 Author: Richard Earnshaw

Re: [PATCH] c: Extend the -Wpadded message with actual padding size

On Thu, Jun 16, 2022 at 3:37 PM Vit Kabele wrote: > > When the compiler warns about padding struct to alignment boundary, it > now also informs the user about the size of the alignment that needs to > be added to get rid of the warning. Hi, thanks for taking the time to improve -Wpadded; I have

Re: [committed] libstdc++: Support constexpr global std::string for size < 15 [PR105995]

On Thu, 16 Jun 2022 at 20:23, Jonathan Wakely via Libstdc++ wrote: > > Tested x86_64-linux, pushed to trunk. Somehow I messed up the test in the commit I pushed (but not the one I tested ... weird). Fixed at r13-1151-g0f96ac43fa0a5f by the attached patch. -- >8 -- libstdc++: Add missing

[PATCH 2/2] aarch64: Fix bit-field alignment in param passing [PR105549]

While working on enabling DFP for AArch64, I noticed new failures in gcc.dg/compat/struct-layout-1.exp (t028) which were not actually caused by DFP types handling. These tests are generated during 'make check' and enabling DFP made generation different (not sure if new non-DFP tests are generated,

[PATCH 1/2] aarch64: fix warning emission for ABI break since GCC 9.1

While looking at PR 105549, which is about fixing the ABI break introduced in GCC 9.1 in parameter alignment with bit-fields, I noticed that the GCC 9.1 warning is not emitted in all the cases where it should be. This patch fixes that and the next patch in the series fixes the GCC 9.1 break. I

[Bug libstdc++/106014] Overload std::distance for filesystem::recursive_directory_iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106014 --- Comment #3 from Jonathan Wakely --- Also, ranges::advance doesn't use the custom advance for path::iterator. Maybe we should make path::iterator satisfy the random_access_iterator concept. We can't do that for directory iterators though, so

[Bug libstdc++/106014] Overload std::distance for filesystem::recursive_directory_iterator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106014 --- Comment #2 from Jonathan Wakely --- We already have a custom std::distance for filesystem::path::iterator, and std::ranges::distance doesn't use that either. Maybe we want to add a customization point for std::ranges::distance that we can

[PATCH][pushed] docs: add missing table header

libgomp/ChangeLog: * libgomp.texi: Add table header for new features of OpenMP 5.2. --- libgomp/libgomp.texi | 1 + 1 file changed, 1 insertion(+) diff --git a/libgomp/libgomp.texi b/libgomp/libgomp.texi index a5e54456746..2c4622c1092 100644 --- a/libgomp/libgomp.texi +++

  1   2   >