https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110202
--- Comment #11 from CVS Commits ---
The master branch has been updated by Alexander Monakov :
https://gcc.gnu.org/g:567d06bb357a39ece865cef67ada44124f227e45
commit r14-2999-g567d06bb357a39ece865cef67ada44124f227e45
Author: Yan Simonaytes
On Fri, 4 Aug 2023, Martin Uecker via Gcc-patches wrote:
> Here is a patch to reduce false positives in _Generic.
>
> Bootstrapped and regression tested on x86_64-linux.
>
> Martin
>
> c: _Generic should not warn in non-active branches [PR68193,PR97100]
>
> To avoid false
On 2023-08-04 11:27, Qing Zhao wrote:
On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901
Bug ID: 110901
Summary: -march does not override -mcpu on aarch64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Hello,
On Wed, Aug 02 2023, Richard Biener wrote:
> On Mon, Jul 31, 2023 at 7:05 PM Martin Jambor wrote:
>>
>> Hi,
>>
>> when IPA-SRA detects whether a parameter passed by reference is
>> written to, it does not special case CLOBBERs which means it often
>> bails out unnecessarily, especially
On 8/4/23 03:52, Manolis Tsamis wrote:
Hi all,
It is true that regcprop currently does not propagate sp and hence
leela is not optimized, but from what I see this should be something
we can address.
The reason that the propagation fails is this check that I have added
when I introduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
--- Comment #6 from danakj at orodu dot net ---
Thanks for the link, I used the godbolt from that bug to set up the right
environment and that let me minimize it. I posted it into the dupe bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158
--- Comment #4 from danakj at orodu dot net ---
Here's a repro without the std::string inside a union. It is the SSO union
inside the string that causes the error.
https://gcc.godbolt.org/z/T8oM8vYnq
```
#include
template
constexpr T fold(T
On Fri, Aug 04, 2023 at 01:25:07PM +, Richard Biener wrote:
> > @@ -144,6 +144,9 @@ DEFTREECODE (BOOLEAN_TYPE, "boolean_type
> > and TYPE_PRECISION (number of bits used by this type). */
> > DEFTREECODE (INTEGER_TYPE, "integer_type", tcc_type, 0)
Thanks.
> > +/* Bit-precise integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
--- Comment #5 from danakj at orodu dot net ---
> Can you please read https://gcc.gnu.org/bugs/ on what we need?
Yeah, sorry I can't reproduce this locally on my Mac or Windows machine. It
reproduces on github Linux CI bots, and I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
--- Comment #4 from danakj at orodu dot net ---
The error message is the same as 110158 but to be clear the std::string is not
in a union. The error message is about the union _inside_ std::string.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158
Andrew Pinski changed:
What|Removed |Added
CC||danakj at orodu dot net
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109465
Xi Ruoyao changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
Thomas Koenig changed:
What|Removed |Added
Component|middle-end |fortran
--- Comment #4 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
--- Comment #1 from danakj at orodu dot net ---
I am going to try work around this by not using std::string in constant
expressions..
So in the meantime I pushed a branch where this bug will continue to reproduce.
With gcc-13:
git clone
On Fri, 2023-08-04 at 11:02 -0400, Eric Feng wrote:
> Hi Dave,
>
> Tests related to our plugin which depend on Python-specific
> definitions have been run by including /* { dg-options "-fanalyzer
> -I/usr/include/python3.9" } */. This is undoubtedly not ideal; is it
> best to approach this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110888
Thomas Koenig changed:
What|Removed |Added
Component|fortran |middle-end
--- Comment #3 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110900
Bug ID: 110900
Summary: std::string initializes SSO object subfield without
making the SSO object active in the union
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
> On Aug 4, 2023, at 10:42 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-04 10:40, Siddhesh Poyarekar wrote:
>> On 2023-08-03 13:34, Qing Zhao wrote:
>>> One thing I need to point out first is, currently, even for regular fixed
>>> size array in the structure,
>>> We have this same issue, for
> On Aug 4, 2023, at 10:40 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-03 13:34, Qing Zhao wrote:
>> One thing I need to point out first is, currently, even for regular fixed
>> size array in the structure,
>> We have this same issue, for example:
>> #define LENGTH 10
>> struct fix {
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110717
--- Comment #15 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:c572f09a751cbd365e2285b30527de5ab9025972
commit r14-2998-gc572f09a751cbd365e2285b30527de5ab9025972
Author: Roger Sayle
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88873
--- Comment #10 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:faa2202ee7fcf039b2016ce5766a2927526c5f78
commit r14-2997-gfaa2202ee7fcf039b2016ce5766a2927526c5f78
Author: Roger Sayle
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #16 from JuzheZhong ---
(In reply to Richard Biener from comment #15)
> Well, the question is why we arrive here with the two different vector types.
> Can you tell me a relevant cc1 compiler command like for a x86->riscv cross
>
ping
From: Wilco Dijkstra
Sent: 02 June 2023 18:28
To: GCC Patches
Cc: Richard Sandiford ; Kyrylo Tkachov
Subject: [PATCH] libatomic: Enable lock-free 128-bit atomics on AArch64
[PR110061]
Enable lock-free 128-bit atomics on AArch64. This is backwards compatible with
existing binaries,
Full review this time, sorry for the skipping the tests earlier.
Prathamesh Kulkarni writes:
> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> index 7e5494dfd39..680d0e54fd4 100644
> --- a/gcc/fold-const.cc
> +++ b/gcc/fold-const.cc
> @@ -85,6 +85,10 @@ along with GCC; see the file
Add support for ifunc selection based on CPUID register. Neoverse N1 supports
atomic 128-bit load/store, so use the FEAT_USCAT ifunc like newer Neoverse
cores.
Passes regress, OK for commit?
libatomic/
config/linux/aarch64/host-config.h (ifunc1): Use CPUID in ifunc
selection.
Hi Dave,
Tests related to our plugin which depend on Python-specific
definitions have been run by including /* { dg-options "-fanalyzer
-I/usr/include/python3.9" } */. This is undoubtedly not ideal; is it
best to approach this problem by adapting a subset of relevant
definitions like in gil.h?
On 2023-08-04 10:40, Siddhesh Poyarekar wrote:
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular
fixed size array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int
On 2023-08-03 13:34, Qing Zhao wrote:
One thing I need to point out first is, currently, even for regular fixed size
array in the structure,
We have this same issue, for example:
#define LENGTH 10
struct fix {
size_t foo;
int array[LENGTH];
};
…
int main ()
{
struct fix *p;
p =
Thanks.
I just updated the doc per your suggestion and committed as:
https://gcc.gnu.org/pipermail/gcc-cvs/2023-August/387588.html
Qing
> On Aug 3, 2023, at 1:29 PM, Joseph Myers wrote:
>
> On Thu, 3 Aug 2023, Qing Zhao via Gcc-patches wrote:
>
>> +@opindex Wflex-array-member-not-at-end
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #16 from Stefan Schulze Frielinghaus ---
Turns out that my dejagnu foo is weak ;-) I came up with a wrong target
selector. Should be fixed in the new attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #15 from Stefan Schulze Frielinghaus ---
Created attachment 55688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55688=edit
Increase optimization and skip sparc for 4-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Martin Uecker changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
Tamar Christina changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 106346, which changed state.
Bug 106346 Summary: [11/12/13/14 Regression] Potential regression on
vectorization of left shift with constants since r11-5160-g9fc9573f9a5e94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110899
Bug ID: 110899
Summary: RFE: Attributes preserve_most and preserve_all
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
> On Aug 4, 2023, at 3:38 AM, Kees Cook wrote:
>
> On Thu, Aug 03, 2023 at 09:31:24PM +, Qing Zhao wrote:
>> So, the basic question is:
>>
>> Given the following:
>>
>> struct fix {
>> int others;
>> int array[10];
>> }
>>
>> extern struct fix * alloc_buf ();
>>
>> int main ()
>> {
Richard Biener writes:
> The following fixes a problem with my last attempt of avoiding
> out-of-bound shift values for vectorized right shifts of widened
> operands. Instead of truncating the shift amount with a bitwise
> and we actually need to saturate it to the target precision.
>
> The
The following patch fixes a problem found by LRA port for avr target.
The problem description is in the commit message.
The patch was successfully bootstrapped and tested on x86-64 and aarch64.
commit abf953042ace471720c1dc284b5f38e546fc0595
Author: Vladimir N. Makarov
Date: Fri Aug 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106346
--- Comment #8 from CVS Commits ---
The master branch has been updated by Tamar Christina :
https://gcc.gnu.org/g:451391a6477f5b012faeca42cdba1bfb8e6eecc0
commit r14-2991-g451391a6477f5b012faeca42cdba1bfb8e6eecc0
Author: Tamar Christina
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110848
--- Comment #12 from Aaron Ballman ---
(In reply to Eric Gallager from comment #11)
> How about:
>
> -std=c++XY: enabled by default (as per the proposal)
> -std=gnu++XY: enabled by -Wall and/or -Wextra (in addition to being enabled
> by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110779
Gaius Mulley changed:
What|Removed |Added
Attachment #55683|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81981
--- Comment #9 from Vincent Lefèvre ---
Note, however, that there is a small regression in GCC 11: the warning for t is
output as expected, but if -fsanitize=undefined is given, the message for t is
suboptimal, saying "*[0]" instead of "t[0]":
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #15 from Richard Biener ---
Well, the question is why we arrive here with the two different vector types.
Can you tell me a relevant cc1 compiler command like for a x86->riscv cross
that exposes the issue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110066
--- Comment #25 from Aurelien Jarno ---
(In reply to Andrew Pinski from comment #23)
> Fixed on the trunk will backport to GCC 13 after 13.2.0 is released (since
> the branch is frozen except for RM approvals).
Now that GCC 13.2.0 has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838
--- Comment #11 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:1a599caab86464006ea8c9501aff6c6638e891eb
commit r14-2987-g1a599caab86464006ea8c9501aff6c6638e891eb
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9903
--- Comment #3 from CVS Commits ---
The master branch has been updated by Matthew Malcomson :
https://gcc.gnu.org/g:0782b01c9ea43d43648071faa9c65a101f5068a2
commit r14-2986-g0782b01c9ea43d43648071faa9c65a101f5068a2
Author: Matthew Malcomson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110316
--- Comment #4 from CVS Commits ---
The master branch has been updated by Matthew Malcomson :
https://gcc.gnu.org/g:0782b01c9ea43d43648071faa9c65a101f5068a2
commit r14-2986-g0782b01c9ea43d43648071faa9c65a101f5068a2
Author: Matthew Malcomson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110857
--- Comment #5 from prathamesh3492 at gcc dot gnu.org ---
Hi Honza,
Sorry for late response, and thanks for the fix! I am currently running
profiledbootstrap on aarch64 with your fix, and will let you know the results
after it completes.
The following fixes a problem with my last attempt of avoiding
out-of-bound shift values for vectorized right shifts of widened
operands. Instead of truncating the shift amount with a bitwise
and we actually need to saturate it to the target precision.
The following does that and adds test
>
> Like I mentioned in the other thread, I think things went wrong when
> we generated the subreg in this sign_extend. The operation should
> have been a truncate of (reg/v:DI 200) followed by a sign extension
> of the result.
>
Sorry for my misunderstanding.
So you mean that in the RTL, for
On Fri, 4 Aug 2023, Matthew Malcomson wrote:
> Hopefully last update ...
>
> > Specifically, please try compiling with
> >-ftime-report -fdiagnostics-format=sarif-file
> > and have a look at the generated .sarif file, e.g. via
> >python -m json.tool foo.c.sarif
> > which will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110838
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:04aa0edcace22a7815cfc57575f1f7b1f166ac10
commit r14-2985-g04aa0edcace22a7815cfc57575f1f7b1f166ac10
Author: Richard Biener
Date:
The following adjusts the shift simplification patterns to avoid
touching out-of-bound shift value arithmetic right shifts of
possibly negative values. While simplifying those to zero isn't
wrong it's violating the principle of least surprise.
Bootstrapped and tested on x86_64-unknown-linux-gnu,
Ping!
please review.
Thanks & Regards
Jeevitha
On 19/07/23 10:16 pm, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> There are no instructions that do traditional AltiVec addresses (i.e.
> with the low four bits of the address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110857
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
Ping!
please review.
Thanks & Regards
Jeevitha
On 20/07/23 10:05 am, jeevitha wrote:
> Hi All,
>
> The following patch has been bootstrapped and regtested on powerpc64le-linux.
>
> When the user specifies PTImode as an attribute, it breaks. Created
> a tree node to handle PTImode types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #14 from JuzheZhong ---
(In reply to rsand...@gcc.gnu.org from comment #12)
> (In reply to JuzheZhong from comment #11)
> > You can see "_9 = _5 >> _8;". We should vectorize SImode instead of HImode.
> > The correct follow should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106293
Jan Hubicka changed:
What|Removed |Added
Summary|[13/14 Regression] |[13 regression] 456.hmmer
On Thu, 3 Aug 2023 at 18:15, Richard Sandiford
wrote:
>
> can_div_trunc_p (a, b, , ) tries to compute a Q and r that
> satisfy the usual conditions for truncating division:
>
> (1) a = b * Q + r
> (2) |b * Q| <= |a|
> (3) |r| < |b|
>
> We can compute Q using the constant component
On Thu, 3 Aug 2023 at 18:46, Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > Prathamesh Kulkarni writes:
> >> On Tue, 25 Jul 2023 at 18:25, Richard Sandiford
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Thanks for the rework and sorry for the slow review.
> >> Hi Richard,
> >> Thanks for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #13 from JuzheZhong ---
I just checked ARM SVE has the same behavior with RISC-V:
https://godbolt.org/z/vY6ecY6Mx
You can see this compiler explorer. ARM trunk GCC SVE failed to vectorize it
too same as RISCV wheras ARM GCC 13.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #12 from rsandifo at gcc dot gnu.org
---
(In reply to JuzheZhong from comment #11)
> You can see "_9 = _5 >> _8;". We should vectorize SImode instead of HImode.
> The correct follow should be first extend HI -> SImode, Then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110898
--- Comment #1 from Marc Poulhiès ---
I get the following error when compiling the adacl-assert-integer.ads file:
```
src/adacl-assert-integer.ads:21:10: warning: unit "GNAT.Source_Info" is not
referenced [-gnatwu]
Hi all,
It is true that regcprop currently does not propagate sp and hence
leela is not optimized, but from what I see this should be something
we can address.
The reason that the propagation fails is this check that I have added
when I introduced maybe_copy_reg_attrs:
else if (REG_POINTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #11 from JuzheZhong ---
I debug vectorizable_shift:
Breakpoint 1, vectorizable_shift (vinfo=0x3fb45d0, stmt_info=0x3fb5ea0,
gsi=0x0, vec_stmt=0x0, slp_node=0x0, cost_vec=0x7fffc648) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #14 from Stefan Schulze Frielinghaus ---
For -3 and -4 I can confirm that we do not end up with a proper comparison
during combine which means we should just ignore these on Sparc.
I'm currently puzzled that -5 and -6 are actually
Hopefully last update ...
> Specifically, please try compiling with
>-ftime-report -fdiagnostics-format=sarif-file
> and have a look at the generated .sarif file, e.g. via
>python -m json.tool foo.c.sarif
> which will pretty-print the JSON to stdout.
Rebasing onto the JSON output was
YunQiang Su writes:
> PR #104914
>
> On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
> zero_extract (SI, SI) can be sign-extended. So, if a zero_extract (DI,
> DI) following with an sign_extend(SI, DI) can be merged to a single
> zero_extract (SI, SI).
>
> gcc/ChangeLog:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #10 from rsandifo at gcc dot gnu.org
---
(In reply to JuzheZhong from comment #9)
> I seems that we must support widen shift pattern in RISCV port even though
> we don't have widen shift instructions ?
I doubt it. Seems like one
On Thu, Aug 03, 2023 at 01:20:00 AM Jeff Law wrote:
>
>
>
>So we're being a bit too aggressive with the .opt zicond patterns.
>
>
>> (define_insn "*czero.eqz..opt1"
>> [(set (match_operand:GPR 0 "register_operand" "=r")
>> (if_then_else:GPR (eq (match_operand:X 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #9 from JuzheZhong ---
The name is correct, since the same pattern works for uint32 but fail to work
for uint16
I checked the build file:
CODE_FOR_vlshrrvvm1hi3 = 10350,
>> Well, that means we do not have a vector mode for HImode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #8 from Richard Biener ---
(In reply to JuzheZhong from comment #6)
> (In reply to Richard Biener from comment #3)
> > it looks like you don't support vector short logical shift? For some reason
> > vect_recog_over_widening_pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #7 from Richard Biener ---
(In reply to JuzheZhong from comment #5)
> (In reply to Richard Biener from comment #3)
> > it looks like you don't support vector short logical shift? For some reason
> > vect_recog_over_widening_pattern
On Fri, Aug 4, 2023 at 10:52 AM Jan Hubicka wrote:
>
> Hi,
> so I found the problem. We duplicate multiple paths and end up with:
>
> ;; basic block 6, loop depth 0, count 365072224 (estimated locally, freq
> 0.3400)
> ;; prev block 12, next block 7, flags: (NEW, REACHABLE, VISITED)
> ;;
On Thu, Aug 3, 2023 at 4:24 PM Andrzej Turko via Gcc-patches
wrote:
>
> Currently fprintf calls logging to a dump file take line numbers
> in the match.pd file directly as arguments.
> When match.pd is edited, referenced code changes line numbers,
> which causes changes to many fprintf calls and,
This adds some more Xmega like devices to the avr backend.
Johann
AVR: Add some more devices: AVR16DD*, AVR32DD*, AVR64DD*, AVR64EA*,
ATtiny42*, ATtiny82*, ATtiny162*, ATtiny322*, ATtiny10*.
gcc/
* config/avr/avr-mcus.def (avr64dd14, avr64dd20, avr64dd28,
avr64dd32)
> On Fri, Aug 4, 2023 at 9:16 AM Jan Hubicka via Gcc-patches
> wrote:
> >
> > Hi,
> > this prevents useless loop distribiton produced in hmmer. With FDO we now
> > correctly work out that the loop created for last iteraiton is not going to
> > iterate however loop distribution still produces a
This fixes some minor typos in avr-mcus.def.
Johan
gcc/
* config/avr/avr-mcus.def (avr128d*, avr64d*): Fix their
FLASH_SIZE
and PM_OFFSET entries.
diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def
index ca99116adab..d0056c960ee 100644
---
Hi,
so I found the problem. We duplicate multiple paths and end up with:
;; basic block 6, loop depth 0, count 365072224 (estimated locally, freq 0.3400)
;; prev block 12, next block 7, flags: (NEW, REACHABLE, VISITED)
;; pred: 4 [never (guessed)] count:0 (estimated locally, freq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Stefan Schulze Frielinghaus ibm.com> ---
> I have done a test with a cross-compiler and it looks to me as if we need -O2
> instead of -O1 on Sparc in order to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #6 from JuzheZhong ---
(In reply to Richard Biener from comment #3)
> it looks like you don't support vector short logical shift? For some reason
> vect_recog_over_widening_pattern doesn't check whether the demoted operation
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #12 from Stefan Schulze Frielinghaus ---
I have done a test with a cross-compiler and it looks to me as if we need -O2
instead of -O1 on Sparc in order to trigger the optimization. Can you give the
attached patch a try? Sorry for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #11 from Stefan Schulze Frielinghaus ---
Created attachment 55686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55686=edit
Increase optimization
On Fri, Aug 4, 2023 at 9:16 AM Jan Hubicka via Gcc-patches
wrote:
>
> Hi,
> this prevents useless loop distribiton produced in hmmer. With FDO we now
> correctly work out that the loop created for last iteraiton is not going to
> iterate however loop distribution still produces a verioned loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110898
Bug ID: 110898
Summary: compilation of adacl-assert-integer.ads failed
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82446
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82397
Bug 82397 depends on bug 82446, which changed state.
Bug 82446 Summary: [11/12/13/14 Regression] Missed equalities in
dr_group_sort_cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82446
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891
Richard Biener changed:
What|Removed |Added
CC||amacleod at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #10 from Rainer Orth ---
The tests still FAIL on Solaris/SPARC:
FAIL: gcc.dg/cmp-mem-const-1.c scan-rtl-dump combine "narrow comparison from
mode .I to QI"
FAIL: gcc.dg/cmp-mem-const-2.c scan-rtl-dump combine "narrow comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #9 from Rainer Orth ---
Created attachment 55684
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55684=edit
64-bit sparc-sun-solaris2.11 cmp-mem-const-1.c.289r.combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #5 from JuzheZhong ---
(In reply to Richard Biener from comment #3)
> it looks like you don't support vector short logical shift? For some reason
> vect_recog_over_widening_pattern doesn't check whether the demoted operation
> is
On Thu, Aug 03, 2023 at 09:31:24PM +, Qing Zhao wrote:
> So, the basic question is:
>
> Given the following:
>
> struct fix {
> int others;
> int array[10];
> }
>
> extern struct fix * alloc_buf ();
>
> int main ()
> {
> struct fix *p = alloc_buf ();
>
On Thu, Aug 03, 2023 at 07:55:54PM +, Qing Zhao wrote:
>
>
> > On Aug 3, 2023, at 1:51 PM, Kees Cook wrote:
> >
> > On August 3, 2023 10:34:24 AM PDT, Qing Zhao wrote:
> >> One thing I need to point out first is, currently, even for regular fixed
> >> size array in the structure,
> >> We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110874
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110874
--- Comment #15 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:91c963ea6f845a0c59b7523a5330b8d3ed1beb6a
commit r14-2978-g91c963ea6f845a0c59b7523a5330b8d3ed1beb6a
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897
--- Comment #4 from JuzheZhong ---
(In reply to Richard Biener from comment #3)
> it looks like you don't support vector short logical shift? For some reason
> vect_recog_over_widening_pattern doesn't check whether the demoted operation
> is
101 - 200 of 219 matches
Mail list logo
