https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #13 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #12)
> (In reply to Hongtao.liu from comment #11)
> > (In reply to Jakub Jelinek from comment #3)
> > > Seems they are vectorizing __builtin_ctz (x) as bitsize - .CLZ (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
Xi Ruoyao changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
--- Comment #3 from CVS Commits ---
The releases/gcc-12 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:eb50091457a789e2f2a15c2e5d08e0d79d3195b1
commit r12-9225-geb50091457a789e2f2a15c2e5d08e0d79d3195b1
Author: Xi Ruoyao
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109000
--- Comment #2 from CVS Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:75eccddef5784bc5e262af31f535267a9c4e993e
commit r13-6500-g75eccddef5784bc5e262af31f535267a9c4e993e
Author: Xi Ruoyao
Date: Thu Mar 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
Xi Ruoyao changed:
What|Removed |Added
Ever confirmed|0 |1
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109035
Bug ID: 109035
Summary: meaningless memory store on RISC-V and LoongArch
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #12 from Jakub Jelinek ---
(In reply to Hongtao.liu from comment #11)
> (In reply to Jakub Jelinek from comment #3)
> > Seems they are vectorizing __builtin_ctz (x) as bitsize - .CLZ ((x - 1) &
> > ~x) for CLZ_DEFINED_VALUE_AT_ZERO 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109011
--- Comment #11 from Hongtao.liu ---
(In reply to Jakub Jelinek from comment #3)
> Seems they are vectorizing __builtin_ctz (x) as bitsize - .CLZ ((x - 1) &
> ~x) for CLZ_DEFINED_VALUE_AT_ZERO 2 with value bitsize.
> Perhaps we should pattern ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109024
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #1 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
--- Comment #18 from Andrew Pinski ---
(In reply to Costas Argyris from comment #17)
> Created attachment 54589 [details]
> Link utf8 resource object in both driver and compiler
>
> The proposed patch addresses the issue of the resource (utf8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865
Costas Argyris changed:
What|Removed |Added
Attachment #54559|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109034
--- Comment #1 from Roland Illig ---
While here:
> "you can silence this warning by using a hexadecimal constant"
> " (%wx rather than %wd)",
%x requires an unsigned argument, %wd requires a signed argument, so %wd should
probably be %wu inste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109034
Bug ID: 109034
Summary: Missing space in diagnostics about '^' and '<<'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109033
--- Comment #1 from Roland Illig ---
> "%@ %s (fndecl %qD, depth %i)",
Why am I supposed to translate this string? It just doesn't make sense to
translate this into German, or any other natural language.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109033
Bug ID: 109033
Summary: Some messages are not understandable by ordinary user
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032
--- Comment #5 from Roland Illig ---
While here:
> dependancies
Typo; should be dependencies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032
--- Comment #4 from Roland Illig ---
While here:
> (*
>BuildDivM2 - build and return ((op2 < 0) : (op1 divtrunc op2) ? (op1
> divfloor op2))
> when -fiso, -fpim4 or -fpositive-mod-floor-div is present else
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032
--- Comment #3 from Roland Illig ---
While here:
> specify the library order, currently legal entries include: log, min, pim,
> iso or their directory name equivalent m2log, m2min, m2pim, m2iso.
In what legislation are these entries "legal"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032
--- Comment #2 from Roland Illig ---
While here:
> turns on runtime checking to check whether a floating point number is about
> to exceed range
What exactly does "is about to" mean, and why didn't you just write "exceeds
the range"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032
--- Comment #1 from Roland Illig ---
While here:
> turns on runtime checking to check whether a CASE statement requires an ELSE
> clause when on was not specified
Did you mean "when one was not"?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032
Bug ID: 109032
Summary: message 'compiler checks to force' is too complicated
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #17 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #16)
> Or just make sure the libraries are still built with -mcpu=power8 even when
> the compiler defaults to something else.
That doesn't scale.
> That said,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109031
Bug ID: 109031
Summary: csmith: possible bad code with -O2
-fno-strict-aliasing
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856
--- Comment #8 from CVS Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:6aa1f40a3263741d964ef4716e85a0df5cec83b6
commit r13-6497-g6aa1f40a3263741d964ef4716e85a0df5cec83b6
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #16 from Jakub Jelinek ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to bugreporter66 from comment #14)
> > I should be able to workaround that by emulating all LE targets on POWER9,
> > with a comment that buildi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
--- Comment #11 from Andrew Pinski ---
(In reply to dingd from comment #10)
> I wonder what's the status of this bug. It has been 15 years.
It still is a bug.
>
> As far as I know, Clang doesn't have this bug, so it should not be
> impossible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108563
Patrick Palka changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108937
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
Bug 96024 depends on bug 96025, which changed state.
Bug 96025 Summary: [10/11/12/13 Regression] ICE in expr_check_typed_help, at
fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
--- Comment #15 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:22031c5868bbb434b51ea4010ccae0cf8c890d6b
commit r10-11240-g22031c5868bbb434b51ea4010ccae0cf8c890d6b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109030
Patrick Palka changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108937
--- Comment #12 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:570828e84f751730743093e5f060eeaf98c08cac
commit r10-11241-g570828e84f751730743093e5f060eeaf98c08cac
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025
--- Comment #13 from CVS Commits ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:9db1287c8ced5425f6ef9d26b05a3eb9cbcc4b8d
commit r10-11239-g9db1287c8ced5425f6ef9d26b05a3eb9cbcc4b8d
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108937
--- Comment #11 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:adc4c8eb79a75bd0f38a461c299b37c643a1153c
commit r11-10560-gadc4c8eb79a75bd0f38a461c299b37c643a1153c
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96024
--- Comment #14 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:7db643a17e8c862b4c758fd69d62a45c6de43d38
commit r11-10559-g7db643a17e8c862b4c758fd69d62a45c6de43d38
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025
--- Comment #12 from CVS Commits ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:8412f78621f6dcb7cee23dda49afb28299d8083b
commit r11-10558-g8412f78621f6dcb7cee23dda49afb28299d8083b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109030
Bug ID: 109030
Summary: ICE in cxx_eval_call_expression with aggregate
initialization inside noexcept
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #12 from Segher Boessenkool ---
What David says :-)
We really could use something good for this, it has been a problem for all
GCC targets since forever; it hurts rs6000 more than most though.
Before RA this is a diamond, one side
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #17 from Tamar Christina ---
(In reply to Segher Boessenkool from comment #13)
> Hi!
>
> Either this should not be P1, or the proposed patch is taking completely the
> wrong direction. P1 means there is a regression. There is no r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #15 from Segher Boessenkool ---
(In reply to bugreporter66 from comment #14)
> I should be able to workaround that by emulating all LE targets on POWER9,
> with a comment that building for POWER8 natively on target should work too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #11 from David Edelsohn ---
Have you looked on the GCC mailing list for zero-extend elimination (zee) and
sign-extend elimination (see)? The many, previous proposals for such passes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109007
--- Comment #14 from bugreporter66 at gmail dot com ---
I should be able to workaround that by emulating all LE targets on POWER9, with
a comment that building for POWER8 natively on target should work too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #16 from Segher Boessenkool ---
(In reply to Roger Sayle from comment #14)
> This really is a regression, that points to a previously latent/unnoticed
> bug in combine.
>
> In GCC 12, combine would take the input RTL and based on ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #4 from Segher Boessenkool ---
Alternatively (or in addition), you can look how to make the shrink-wrap pass
transform the code with some simple added move instructions, maybe even
involving an extra pseudo, so that it can shrink-wra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #17 from niXman ---
(In reply to niXman from comment #15)
> (In reply to Jakub Jelinek from comment #13)
> > Fixed now on the trunk. I'd wait a little bit with backports, though I
> > think the gmp-param.h change doesn't need backpor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
dingd changed:
What|Removed |Added
CC||ntysdd at qq dot com
--- Comment #10 from dingd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108379
Sam James changed:
What|Removed |Added
CC||eggert at cs dot ucla.edu
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109009
--- Comment #3 from Surya Kumari Jangala ---
For the working case:
* Input RTL to the IRA pass:
BB2:
set r123, r4
set r122, r3
set r120, compare(r123, 0)
set r118, r122
if r120 jump BB4 else jump BB3
BB3:
call bar()
BB4:
set r3,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #1 from g.peterh...@t-online.de ---
Ok in english
std::signbit(double) generates very inefficient code and thus cannot be
vectorized (https://godbolt.org/z/se6Ea8bo9).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
Bug ID: 109029
Summary: std::signbit(double) generiert sehr ineffizienten code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #15 from Roger Sayle ---
An example of combine's temporary lapses of sanity can be seen on powerpc:
Trying 14 -> 15:
14: %3:SI=sign_extend(r128:SI#2)*sign_extend(r127:SI#2)
REG_DEAD r128:SI
REG_DEAD r127:SI
15: use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103784
--- Comment #10 from Surya Kumari Jangala ---
After the expand pass, we have a single return bb which first zero extends r117
(this reg holds the return value which has been set by predecessor blocks).
Zero extension is done because r117 is of m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109028
--- Comment #3 from Uroš Bizjak ---
(In reply to Andrew Pinski from comment #1)
> X87 code generation is definitely not as optimized as other code really.
You are wrong here.
> Also fcmov is newish.
It is because fcmov would require two memor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109028
--- Comment #2 from g.peterh...@t-online.de ---
> X87 code generation is definitely not as optimized as other code really.
Ok
> Also fcmov is newish.
New?
fcmov was introduced with the PentiumPro (1995) - that's 27 years ago. :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109028
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #16 from niXman ---
trying to build x86_64-mingw-w64 and check...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94756
--- Comment #15 from niXman ---
(In reply to Jakub Jelinek from comment #13)
> Fixed now on the trunk. I'd wait a little bit with backports, though I
> think the gmp-param.h change doesn't need backporting.
unfortunately, the bug is still prese
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109028
Bug ID: 109028
Summary: fcmov will not be generated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027
Bug ID: 109027
Summary: [13 Regression] ICE: SIGSEGV (infinite recursion in
ana::constraint_manager::eval_condition /
ana::constraint_manager::impossible_derived_conditions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109025
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109025
--- Comment #7 from David Binderman ---
(In reply to David Binderman from comment #6)
> Range now seems to be g:d699d32f47833cfa .. g:3b54cc9d04c2efb2,
> with 52 commits in the range.
Now downto g:0cbb756fe9c8e13a .. g:7e3ce73849fef8b5, with 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109025
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #4)
> > I will have a go at a bisection. 825 git commits in the range.
>
> Current range seems to be g:59ad8b684dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109025
--- Comment #5 from David Binderman ---
(In reply to David Binderman from comment #4)
> I will have a go at a bisection. 825 git commits in the range.
Current range seems to be g:59ad8b684dd67e17 .. g:1191a412bb17a734,
with 206 commits in the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109025
--- Comment #4 from David Binderman ---
(In reply to Andrew Pinski from comment #3)
> Note using &, | or ^ causes the ICE. Using + or - or * does not.
Interesting.
> Here is more simplified testcase:
Thanks for that. I will have a go at a bis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594
--- Comment #14 from Roger Sayle ---
This really is a regression, that points to a previously latent/unnoticed bug
in combine.
In GCC 12, combine would take the input RTL and based on target costs transform
it into the better of implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83670
Andrew Pinski changed:
What|Removed |Added
CC||jbg...@lug-owl.de
--- Comment #11 from A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109026
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
71 matches
Mail list logo
