https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #16 from rguenther at suse dot de ---
On Thu, 10 Dec 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
>
> --- Comment #15 from Jakub Jelinek ---
> Created attachment 49727
> -->
On Thu, 10 Dec 2020, Dinar Temirbulatov wrote:
> Hi,
> I have observed that STV2 pass added ~20% on CPU2006 456.hmmer with mostly
> by transforming V4SI operations. Looking at the pass itself, it looks like
> it might be transformed into RTL architecture-independent, and the pass
> deals only not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211
--- Comment #9 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:76c09f2af9d8ab9c760d860626f069d12d86f0a9
commit r11-5901-g76c09f2af9d8ab9c760d860626f069d12d86f0a9
Author: Richard Biener
Date:
On Thu, Dec 10, 2020 at 12:14:22PM +0100, Eric Botcazou wrote:
> > 2020-12-10 Jakub Jelinek
> >
> > PR rtl-optimization/98212
> > * dojump.c (do_compare_rtx_and_jump): Change computation of
> > first_prob for and_them and don't invert prob around it.
> >
> > *
> So like this instead (if it passes another bootstrap/regtest)?
>
> 2020-12-10 Jakub Jelinek
>
> PR middle-end/98190
> * expr.c (expand_assignment): If to_rtx is a promoted SUBREG,
> ensure sign or zero extension either through use of store_expr
> or by extending
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> But all GIMPLE operates on "GIMPLE lane order" so this is a defect in how
> the backend handles those tree codes at expansion time?
I can never
Fix an issue with the `casesi' expander using `GEN_INT' to produce the
constant rtx for lower bound adjustment. This generates a VOIDmode
value which may overflow the SImode range required for the operand to
stay within to satisfy `general_operand', resulting in an ICE like:
> 2020-12-10 Jakub Jelinek
>
> PR rtl-optimization/98212
> * dojump.c (do_compare_rtx_and_jump): Change computation of
> first_prob for and_them and don't invert prob around it.
>
> * gcc.dg/predict-8.c: Adjust expected probability.
>
> --- gcc/dojump.c.jj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98212
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:680e4202f23ce74f3b26c7f090b9d22a56765554
commit r11-5899-g680e4202f23ce74f3b26c7f090b9d22a56765554
Author: Jakub Jelinek
Date:
On Thu, Dec 10, 2020 at 10:49:06AM +, Richard Sandiford wrote:
> > The following patch rejects frame and argp registers (unless they are equal
> > to hard frame pointer registers) from local or global register vars.
> > These are just internal implementation details eliminated later into hard
On Dec 3, 2020, Alexandre Oliva wrote:
> +local_define_builtin ("__builtin___clear_cache", ftype,
> + BUILT_IN_CLEAR_CACHE,
> + "__builtin___clear_cache",
> + ECF_NOTHROW);
Ugh, so that somehow worked for
Hi all,
This patch addresses PR97929 by adding a missing case for WIDEN_PLUS/MINUS in
vect_get_smallest_scalar_type. It also introduces a test to check for
regression.
One thing to note is that I saw a failure on c-c++-common/builtins.c which
disappeared when I ran the test again. I assume
Hi all,
This adds missing pretty print for WIDEN_PLUS/MINUS and
VEC_WIDEN_PLUS/MINUS_HI/LO
Bootstrapped and regression tested all together on aarch64.
Ok for trunk?
Add WIDEN_PLUS, WIDEN_MINUS pretty print
Add 'w+'/'w-' as WIDEN_PLUS/WIDEN_MINUS respectively.
Add
> 2020-12-10 Jakub Jelinek
>
> PR rtl-optimization/98212
> * dojump.c (do_compare_rtx_and_jump): When splitting NE and backend
> can do UNEQ, prefer splitting x != y into x unord y || !(x uneq y)
> instead of into x unord y || x ltgt y.
>
> *
Jakub Jelinek writes:
> Hi!
>
> The following patch rejects frame and argp registers (unless they are equal
> to hard frame pointer registers) from local or global register vars.
> These are just internal implementation details eliminated later into hard
> frame pointer or stack pointer and using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98169
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:66dea8899df6475d5cb289491dbbff307c16c1a7
commit r11-5898-g66dea8899df6475d5cb289491dbbff307c16c1a7
Author: Jakub Jelinek
Date:
On Thu, Dec 10, 2020 at 11:15:30AM +0100, Eric Botcazou wrote:
> Are you sure that the optimization is worth the hassle (and maybe the risk,
> i.e. can't store_field clobber the entire field)?
I'm not sure, after all, only the testcases I've mentioned were affected
in the whole
Jim Wilson writes:
> This fixes a riscv64-linux bootstrap failure.
>
> get_constant_section calls the select_section target hook, and select_section
> calls get_named_section which calls get_section. So it is possible to have
> a constant not a decl in both of these functions. They already call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Richard Biener changed:
What|Removed |Added
Summary|[11 regression] Wrong |[10/11 regression] Wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211
--- Comment #8 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #7)
> Hmm, OK, so besides the incomplete bool pattern matching the issue seems to
> be that while we reject the problematic conversion in
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63176
--- Comment #5 from Jonathan Wakely ---
(In reply to TC from comment #3)
> This breaks the complexity requirement in [rand.util.canonical]/p3, though.
That did get fixed eventually, see PR 80137 / r246542
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.0
On Thu, 10 Dec 2020, Xionghu Luo via Gcc wrote:
I have a maybe silly question about whether there is any *standard*
or *options* (like -ffast-math) for GCC that allow double to float
demotion optimization? For example,
1) from PR22326:
#include
float foo(float f, float x, float y) {
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #8 from Jonathan Wakely ---
(In reply to Martin Liška from comment #6)
> I bet it's related to the construction of the s_creator and its usage at
> moduleB.cpp:8
> It's likely Static Initialization Order Fiasco:
>
> 2020-12-10 Jakub Jelinek
>
> PR middle-end/98190
> * expr.c (expand_assignment): If to_rtx is a promoted SUBREG,
> ensure sign or zero extension when the most significant bit has
> been overwritten, either through use of store_expr or by extending
> manually.
>
Hi!
If the loop body doesn't ever continue, we don't have a bb to insert the
updates. Fixed by not adding them at all in that case.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk.
2020-12-10 Jakub Jelinek
PR middle-end/98205
* omp-expand.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98205
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a2a17ae7d85e420db5fe0c7ab2f59a470e2c7a78
commit r11-5897-ga2a17ae7d85e420db5fe0c7ab2f59a470e2c7a78
Author: Jakub Jelinek
Date:
Hi!
When compiling:
void foo (void);
void bar (float a, float b) { if (__builtin_expect (a != b, 1)) foo (); }
void baz (float a, float b) { if (__builtin_expect (a == b, 1)) foo (); }
void qux (float a, float b) { if (__builtin_expect (a != b, 0)) foo (); }
void corge (float a, float b) { if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #7 from Uroš Bizjak ---
Still happens on trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98211
--- Comment #7 from Richard Biener ---
Hmm, OK, so besides the incomplete bool pattern matching the issue seems to be
that while we reject the problematic conversion in vectorizable_conversion it
slips through via vectorizable_assignment because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |9.0
--- Comment #7 from Uroš Bizjak ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95396
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95046
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95750
Uroš Bizjak changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
Andrea Corallo via Gcc-patches writes:
> Hi all,
>
> first patch of the series to backport a number of bfloat16 intrinsics from
> trunk to gcc-10.
>
> These patch are including the fixes to the tests that we have applied
> into master.
>
> Please see refer to:
> ACLE
Hi!
The x86 backend doesn't have EQ or NE floating point comparisons,
so splits x != y into x unord y || x <> y. The problem with that is
that unord comparison doesn't trap on qNaN operands but LTGT does.
The end effect is that it doesn't trap on qNaN operands, because x unord y
will be true for
Hi!
The following patch rejects frame and argp registers (unless they are equal
to hard frame pointer registers) from local or global register vars.
These are just internal implementation details eliminated later into hard
frame pointer or stack pointer and using them as register variable leads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
Martin Liška changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
Martin Liška changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #6
Hi Simon:
Committed, thanks :)
On Thu, Dec 10, 2020 at 4:56 PM Simon Cook wrote:
>
> Hi Kito,
>
> Thanks for reviewing this. Since I don't have commit access, could you
> commit this for me.
>
> On 10/12/2020 02:32, Kito Cheng wrote:
> > Hi Simon:
> >
> > V2 version is LGTM, thanks!
> >
On Thu, Dec 10, 2020 at 9:47 AM Xionghu Luo via Gcc wrote:
>
> Hi,
>
> I have a maybe silly question about whether there is any *standard*
> or *options* (like -ffast-math) for GCC that allow double to float
> demotion optimization? For example,
The only option we have to this effect would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
Hi!
If the backend doesn't have floating point EQ or NE comparison, dojump.c
splits it into ORDERED && UNEQ or UNORDERED || LTGT. If both comparison
operands are the same, we know the result of the second comparison though,
a == b is equivalent to a ord b and a != b is equivalent to a unord b,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Bug ID: 98221
Summary: [11 regression] Wrong unpack operation emitted in
tree-ssa-forwprop.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: major
Hi Kito,
Thanks for reviewing this. Since I don't have commit access, could you
commit this for me.
On 10/12/2020 02:32, Kito Cheng wrote:
> Hi Simon:
>
> V2 version is LGTM, thanks!
>
Hi!
Some target decide to promote certain scalar variables to wider mode,
so their DECL_RTL is a SUBREG with SUBREG_PROMOTED_VAR_P.
When storing to such vars, store_expr takes care of sign or zero extending,
but if we store e.g. through MEM_REF into them, no sign or zero extension
happens and
On Dec 5, 2020, Jakub Jelinek wrote:
> On Sat, Dec 05, 2020 at 06:01:59PM -0300, Alexandre Oliva wrote:
>> On Dec 5, 2020, Andreas Schwab wrote:
>>
>> > ../../../../libffi/src/aarch64/ffi.c: In function 'ffi_prep_closure_loc':
>> > ../../../../libffi/src/aarch64/ffi.c:67:3: internal compiler
Hi,
I have a maybe silly question about whether there is any *standard*
or *options* (like -ffast-math) for GCC that allow double to float
demotion optimization? For example,
1) from PR22326:
#include
float foo(float f, float x, float y) {
return (fabs(f)*x+y);
}
The fabs will return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #4 from wuz73 at hotmail dot com ---
In the attached test case, there is a makefile and source code. Here's the
output without -flto:
$ make
g++ -std=c++11 -Wall -g -O2 -o main.o -c main.cpp
g++ -std=c++11 -Wall -g -O2 -o module.o
On Thu, Dec 10, 2020 at 6:42 AM Dimitar Dimitrov wrote:
>
> On сряда, 9 декември 2020 г. 15:12:49 EET abebeos via Gcc-patches wrote:
> > Essence:
> >
> > I need a confirmation that the testsuite setup as presented in:
> >
> > https://github.com/abebeos/avr-gnu
> >
> > works fine.
> >
> > The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190
--- Comment #15 from Jakub Jelinek ---
Created attachment 49727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49727=edit
gcc11-pr98190.patch
So, I have bootstrapped/regtested this patch last night on x86_64, i686,
aarch64, armv7hl,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #3 from Martin Liška ---
Hello.
The attached libraries are not what we can use as a reproducer:
https://www.gnu.org/software/gcc/bugs/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #2 from wuz73 at hotmail dot com ---
There's no division as can be seen in the test case.
From: pinskia at gcc dot gnu.org
Sent: Thursday, December 10, 2020 4:19 PM
To: wu...@hotmail.com
Subject:
On Thu, Dec 10, 2020 at 1:52 AM Eugene Rozenfeld via Gcc-patches
wrote:
>
> This patch adds a pattern for optimizing
> x < y || x == XXX_MIN to x <= y-1
> if y is an integer with TYPE_OVERFLOW_WRAPS.
Do we already handle x < y || x <= CST to x <= y - CST?
That is, the XXX_MIN case is just a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
--- Comment #1 from Andrew Pinski ---
Are you sure this just not a divide by zero? On x86, an integer divide by zero
will throw an FPU exception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98220
Bug ID: 98220
Summary: LTO causes floating point exception
Product: gcc
Version: 9.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
201 - 260 of 260 matches
Mail list logo
