https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88587
--- Comment #12 from Martin Liška ---
Author: marxin
Date: Fri Jan 18 07:41:05 2019
New Revision: 268060
URL: https://gcc.gnu.org/viewcvs?rev=268060&root=gcc&view=rev
Log:
Reset proper type on vector types (PR middle-end/88587).
2019-01-18 Mar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897
--- Comment #2 from Andrew Pinski ---
Some of the time, the uninitialized is due to using the object after the
lifetime of the object has gone out of scope. I have not checked if that is
the case here but I would not be suprised.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #12 from Jürgen Reuter ---
I can also confirm that with the provided patch our code completely compiles,
and all tests work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896
--- Comment #3 from Daniel Starke ---
Never mind my question.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88768
--- Comment #3 from martin ---
I have opened a separate PR 88899 for the openmp related invalid memory read,
but I guess it might have the same cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899
martin changed:
What|Removed |Added
Known to fail||8.2.1
--- Comment #2 from martin ---
Related t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899
--- Comment #1 from martin ---
With sufficiently many threads (at least 5 or 6 for me) the address santizer
gives (for gfortran-9, compiled a few weeks ago):
==3485==ERROR: AddressSanitizer: attempting double-free on 0x6020001956d0 in
thread T4:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88899
Bug ID: 88899
Summary: Derived type IO in conjunction with openmp fails with
invalid memory read
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897
--- Comment #1 from Rafael Avila de Espindola ---
Created attachment 45453
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45453&action=edit
reduced the test a bit more
It now compiles with older gcc too.
The warning is there in gcc 7, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896
--- Comment #2 from Daniel Starke ---
You are right. So you are saying that the compiler actually checks all cases of
the loop?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88202
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86205
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Fri Jan 18 03:58:22 2019
New Revision: 268058
URL: https://gcc.gnu.org/viewcvs?rev=268058&root=gcc&view=rev
Log:
PR c++/86205 - ICE with ?: of throw and template-id.
My patch for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88202
--- Comment #1 from ian at gcc dot gnu.org ---
Author: ian
Date: Fri Jan 18 03:29:38 2019
New Revision: 268057
URL: https://gcc.gnu.org/viewcvs?rev=268057&root=gcc&view=rev
Log:
PR go/88202
runtime: in sigprof, skip to sigtrampgo if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #26 from Eric Gallager ---
(In reply to Bernd Edlinger from comment #25)
> Author: edlinger
> Date: Wed Jul 18 19:36:01 2018
> New Revision: 262861
>
> URL: https://gcc.gnu.org/viewcvs?rev=262861&root=gcc&view=rev
> Log:
> libcpp:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
--- Comment #8 from Martin Sebor ---
I agree that GCC would do a better by running -Wshift-count-overflow later (but
that carries a risk of false positives as well). That's also why I
acknowledged the report.
Both solutions appear to be optimiz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
Eric Gallager changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
--- Comment #7 from Scott ---
While that's brilliant,
1) I don't lack for ways to code around the problem, but whether or not
I do, g++ nonetheless has a problem here.
2) At a guess, the recursive solution is avoiding the warnings because
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #9 from Steve Kargl ---
On Fri, Jan 18, 2019 at 12:42:12AM +, sje at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
>
> --- Comment #6 from Steve Ellcey ---
> Author: sje
> Date: Fri Jan 18 00:41:40 2019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
--- Comment #6 from Steve Ellcey ---
Author: sje
Date: Fri Jan 18 00:41:40 2019
New Revision: 268054
URL: https://gcc.gnu.org/viewcvs?rev=268054&root=gcc&view=rev
Log:
2018-01-17 Steve Ellcey
PR fortran/88898
* gfortran.dg/go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45776
Dominique d'Humieres changed:
What|Removed |Added
CC||janus at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
--- Comment #6 from Martin Sebor ---
The C++ solution to this kind of problem is to use template specialization.
It's a been a while since I wrote any real C++ code but this seems to work and
avoids the warnings
class PackRule
{
template
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49108
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88334
--- Comment #2 from emsr at gcc dot gnu.org ---
It looks like this went in.
If so we should check it off on the status page.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
--- Comment #8 from Steve Kargl ---
On Thu, Jan 17, 2019 at 11:55:38PM +, sje at gcc dot gnu.org wrote:
>
> --- Comment #4 from Steve Ellcey ---
> I think this is my fault. My patch shouldn't have affected x86 at all but I
> see my build/test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41650
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from Domin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
kargl at gcc dot gnu.org changed:
What|Removed |Added
Host||x86_64-*-freebsd
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
Steve Ellcey changed:
What|Removed |Added
CC||sje at gcc dot gnu.org
--- Comment #4 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35930
--- Comment #1 from Dominique d'Humieres ---
> I understood -pedantic such that it gives warnings if a construct
> does not match the Fortran standard. Currently, it seems to be partially
> used such but also used to warn for non-Fortran-95 (!) c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
Andrew Stubbs changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
--- Comment #2 from kargl at gcc dot gnu.org ---
In looking at the failures in the log, I see
gfortran: fatal error: GCC is not configured to support amdgcn-unknown-amdhsa
as offload target
This may be du to a commit by Andrew Stubbs ,
but bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
--- Comment #1 from kargl at gcc dot gnu.org ---
The five failures are
FAIL: gfortran.dg/gomp/declare-simd-2.f90 -O (test for warnings, line 3)
FAIL: gfortran.dg/gomp/declare-simd-2.f90 -O (test for warnings, line 15)
Running /safe/sgk/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734
--- Comment #7 from Jakub Jelinek ---
Author: jakub
Date: Thu Jan 17 23:34:42 2019
New Revision: 268049
URL: https://gcc.gnu.org/viewcvs?rev=268049&root=gcc&view=rev
Log:
PR target/88734
* config/aarch64/arm_neon.h: Fix #pragma G
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58200
--- Comment #4 from Dominique d'Humieres ---
> IMO it would be better to add new sections for (2) and (3), put (2) after 2.3
> and () after 2.5.
IMO it would be better to add new sections for (2) and (3), put (2) after 2.3
and (3) after 2.5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58200
--- Comment #3 from Dominique d'Humieres ---
> With most portable compilers, code generation options are traditionally
> used for variations in the target interface, and not to introduce
> functionality. Worse, the top-level entry says:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88898
Bug ID: 88898
Summary: [Regression 9] gomp is broken by r268045
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
Martin Sebor changed:
What|Removed |Added
Summary|[8/9 Regression] warning: |[8 Regression] warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
--- Comment #11 from Martin Sebor ---
Author: msebor
Date: Thu Jan 17 22:52:47 2019
New Revision: 268048
URL: https://gcc.gnu.org/viewcvs?rev=268048&root=gcc&view=rev
Log:
PR middle-end/88273 - [8/9 Regression] warning: 'memcpy' offset [-527, -5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85103
--- Comment #21 from Pat Haugen ---
> Knowing what inline decision matters for VPR, I can try to fix it too.
Gathering some perf data, the hot functions for various revisions are as
follows. All other functions report < 0.5% of execution time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88294
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88875
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88787
Jason Merrill changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50502
simon at pushface dot org changed:
What|Removed |Added
CC||simon at pushface dot org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86740
Jason Merrill changed:
What|Removed |Added
Known to work||9.0
Summary|[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88897
Bug ID: 88897
Summary: Bogus maybe-uninitialized warning on class field
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81107
--- Comment #1 from Thomas Anderson ---
Clang solved this recently by adding a -fvisibility-global-new-delete-hidden
option:
https://reviews.llvm.org/D53787
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
--- Comment #5 from Marc Glisse ---
(In reply to Martin Sebor from comment #2)
> The warning is not specific to C++ but triggers for C code as well
True, but C++ templates somehow make this different. In C, you could use the
preprocessor to test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86740
--- Comment #6 from Jason Merrill ---
Author: jason
Date: Thu Jan 17 20:36:31 2019
New Revision: 268046
URL: https://gcc.gnu.org/viewcvs?rev=268046&root=gcc&view=rev
Log:
PR c++/86740, ICE with constexpr if and nested generic lambdas.
W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #11 from Segher Boessenkool ---
Good point. So we cannot use stfs (etc.) as float_truncate+store ever, not
even with full fast math options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896
Bug ID: 88896
Summary: [8/9 Regression] integer overflow check optimized away
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88273
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
Priority|P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
--- Comment #4 from Scott ---
Um... yes, that would kill the warning; but then I'd be writing
/* The modulo operation is meaningless and will be optimized out, I
promise. It's here
because there's a specific compiler, g++ 7.3.0, that can't fig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #10 from joseph at codesourcery dot com ---
Use of stfs on a double-precision value without frsp first is worse than
simply using the wrong rounding mode; in the case of overflow it does a
bitwise defined operation which is pretty u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #9 from Andrew Pinski ---
(In reply to Segher Boessenkool from comment #8)
> So we should use the current rounding mode for any float_trunc? So we can
> use
> float store instructions for it only with some fast-math option?
No, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #8 from Segher Boessenkool ---
So we should use the current rounding mode for any float_trunc? So we can use
float store instructions for it only with some fast-math option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77293
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88699
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88699
--- Comment #8 from David Malcolm ---
Author: dmalcolm
Date: Thu Jan 17 17:07:20 2019
New Revision: 268041
URL: https://gcc.gnu.org/viewcvs?rev=268041&root=gcc&view=rev
Log:
C++: Fix ICE when adding overloaded operator via using_decl (PR c++/886
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88815
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Segher Boessenkool changed:
What|Removed |Added
Target|powerpc64le-redhat-linux-gn |powerpc64*-*-*
|u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
Bug 85741 depends on bug 80537, which changed state.
Bug 80537 Summary: missing -Wformat-overflow on POSIX %C conversion
specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80537
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80537
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88800
Martin Sebor changed:
What|Removed |Added
Summary|[8/9 Regression] Spurious |[8 Regression] Spurious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88800
--- Comment #5 from Martin Sebor ---
Author: msebor
Date: Thu Jan 17 16:33:55 2019
New Revision: 268037
URL: https://gcc.gnu.org/viewcvs?rev=268037&root=gcc&view=rev
Log:
PR tree-optimization/88800 - Spurious -Werror=array-bounds for non-taken b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88893
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #6 from Florian Weimer ---
(In reply to Eric Gallager from comment #5)
> This is one of the reasons -Wfloat-conversion exists:
>
> $ gcc -c -Wall -Wextra -Wfloat-conversion -Wdouble-promotion
> -Wunsuffixed-float-constants -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88895
Bug ID: 88895
Summary: unnecessary warnings in unreachable code (shift)
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #4 from Florian Weimer ---
Eh, forget what I wrote. The pattern *is* used. r253210 looks definitely to
blame.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
--- Comment #3 from Florian Weimer ---
Started with r253210. I don't think the new pattern is used in this case, so
maybe this is a pre-existing latent bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 17 15:32:05 2019
New Revision: 268035
URL: https://gcc.gnu.org/viewcvs?rev=268035&root=gcc&view=rev
Log:
PR libstdc++/4 fix filesystem::absolute("//") for mingw
PR l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
--- Comment #7 from Jonathan Wakely ---
Author: redi
Date: Thu Jan 17 15:31:59 2019
New Revision: 268034
URL: https://gcc.gnu.org/viewcvs?rev=268034&root=gcc&view=rev
Log:
PR libstdc++/1 adjust filesystem::status and tests for mingw semantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850
--- Comment #2 from Tamar Christina ---
Author: tnfchris
Date: Thu Jan 17 15:17:57 2019
New Revision: 268033
URL: https://gcc.gnu.org/viewcvs?rev=268033&root=gcc&view=rev
Log:
Fix Arm testcase by using NEON.
gcc/testsuite/ChangeLog:
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88845
--- Comment #3 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #2)
> Thinking about this, insn 14 doesn't look legal to me for ppc, since FP
> values in our FP regs are actually stored as 64-bit quantities, even for
> SFmode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88894
Tom de Vries changed:
What|Removed |Added
Keywords||missed-optimization
Severity|no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88894
Bug ID: 88894
Summary: [libbacktrace] share abbrevs between units
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbackt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88893
Bug ID: 88893
Summary: Forward declaring of enum class with visibility
results in -Wattributes false positive.
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659
--- Comment #5 from Daniel Fruzynski ---
I meant pr85684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71659
Daniel Fruzynski changed:
What|Removed |Added
CC||bugzilla@poradnik-webmaster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Florian Weimer changed:
What|Removed |Added
Keywords||wrong-code
Summary|Double-to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531
--- Comment #6 from MCCCS ---
After reading your comment, I noticed that
there were two things I forgot to mention:
1 - availability.h is the file where
"API_AVAILABLE" is defined for Clang.
2 - the part of the file the patch
changes is 1:1 cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88850
Tamar Christina changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #16 from Wilco ---
(In reply to rguent...@suse.de from comment #15)
> which is what I refered to for branch prediction. Your & prompts me
> to a way to do sth similar as duffs device, turning the loop into a nest.
>
> head:
>i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82857
Tom de Vries changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82857
--- Comment #8 from Tom de Vries ---
Author: vries
Date: Thu Jan 17 13:42:20 2019
New Revision: 268031
URL: https://gcc.gnu.org/viewcvs?rev=268031&root=gcc&view=rev
Log:
[libbacktrace] Handle DW_FORM_GNU_ref_alt
Handle DW_FORM_GNU_ref_alt which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82857
--- Comment #9 from Tom de Vries ---
Author: vries
Date: Thu Jan 17 13:42:30 2019
New Revision: 268032
URL: https://gcc.gnu.org/viewcvs?rev=268032&root=gcc&view=rev
Log:
[libbacktrace] Add btest_dwz test-case
Add test-case to verify that libbac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #15 from rguenther at suse dot de ---
On Thu, 17 Jan 2019, wilco at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
>
> --- Comment #14 from Wilco ---
> (In reply to rguent...@suse.de from comment #13)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88734
--- Comment #6 from Tamar Christina ---
Yes, I noticed them as well as was taking a look.
I don't quite understand what was going on before and why they passed but the
option is wrong. Those intrinsics and are all sha3 extensions.
diff --git a/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88892
Bug ID: 88892
Summary: Double-to-float conversion uses wrong rounding mode
when followed by memcpy
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51310
--- Comment #11 from Dominique d'Humieres ---
> Yes, leave it for the time being - I will see if I can do something
> about it (or unassign, if not).
OK.
See also pr33430.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88760
--- Comment #14 from Wilco ---
(In reply to rguent...@suse.de from comment #13)
> Usually the peeling is done to improve branch prediction on the
> prologue/epilogue.
Modern branch predictors do much better on a loop than with this kind of code
1 - 100 of 150 matches
Mail list logo