https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86368
Justin Bassett changed:
What|Removed |Added
CC||jbassett271 at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #78 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #77)
> (In reply to Iain Sandoe from comment #76)
> > (In reply to Jürgen Reuter from comment #75)
>
> > > LLVM does not compile, but I
> > > guess this is unrelated to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90124
Iain Sandoe changed:
What|Removed |Added
Target||x86_64-apple-darwin*,
|
ons -fno-exceptions -fno-rtti -o PDBContext.s
GNU C++11 (GCC) version 9.0.1 20190416 (experimental) [trunk revision 270376]
(x86_64-pc-linux-gnu)
compiled by GNU C version 9.0.1 20190416 (experimental) [trunk revision
270376], GMP version 6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86153
bin cheng changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869
Eric Gallager changed:
What|Removed |Added
Keywords||documentation
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120
Eric Gallager changed:
What|Removed |Added
Keywords||easyhack
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121
Eric Gallager changed:
What|Removed |Added
Keywords||easyhack
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90123
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90123
Bug ID: 90123
Summary: "/usr/include/string.h", line 44: syntax error at
token '__dest'
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540
John David Anglin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540
--- Comment #28 from John David Anglin ---
Author: danglin
Date: Wed Apr 17 00:22:23 2019
New Revision: 270402
URL: https://gcc.gnu.org/viewcvs?rev=270402=gcc=rev
Log:
PR libgfortran/79540
* io/write_float.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540
--- Comment #27 from John David Anglin ---
Author: danglin
Date: Tue Apr 16 23:21:13 2019
New Revision: 270398
URL: https://gcc.gnu.org/viewcvs?rev=270398=gcc=rev
Log:
PR libgfortran/79540
* io/write_float.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89819
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90037
--- Comment #7 from Jeffrey A. Law ---
Making some progress here. Working with a reduced testcase we have the
following key blocks as we enter DOM:
;; basic block 3, loop depth 0
;;pred: 2
__builtin_strdup (spec_22(D));
_56 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105
--- Comment #3 from Jonathan Wakely ---
Patch posted to https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00669.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #13 from Martin Sebor ---
As noted in the duplicate pr90122, the test case below shows that GCC already
relies on different extern declarations denoting distinct objects. It just
doesn't fold the address equality expression for some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43565
--- Comment #12 from Martin Sebor ---
*** Bug 90122 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122
--- Comment #1 from H.J. Lu ---
(In reply to Martin Sebor from comment #0)
> In the test case below GCC folds the second test (as expected, on the
> assumption that distinct declarations refer to distinct objects) but fails
> to fold the first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369
Pat Haugen changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90122
Bug ID: 90122
Summary: inequality of addresses of distinct objects not folded
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763
--- Comment #53 from Jeffrey A. Law ---
Realistically the register allocation issues are not going to get addressed
this cycle nor are improvements to the overall handling of RMW insns in
combine. So we're going to be stuck with bandaids.
I've
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121
--- Comment #1 from Roland Illig ---
Same for:
error ("unknown CRIS cpu version specification in %<-mtune=%> : %s",
cris_tune_str);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121
Bug ID: 90121
Summary: extra space in error message
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105
--- Comment #2 from stoyanovmk at ornl dot gov ---
Tested the fix provided by Jonathan Wakely, I can confirm the fix.
Ran several tests with the included small example and the code where I found
the issue in the first place.(In reply to Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119
--- Comment #1 from Roland Illig ---
Next example from avr.c:
%<-fpic%> is not supported
%<-fPIC%> is not supported
%<-fpie%> is not supported
%<-fPIE%> is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90120
Bug ID: 90120
Summary: inconsistent punctuation in translation messages
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79869
--- Comment #1 from Roland Illig ---
ping? Two years later, and I still don't know how to translate this string into
proper German.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86953
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Apr 16 19:06:41 2019
New Revision: 270396
URL: https://gcc.gnu.org/viewcvs?rev=270396=gcc=rev
Log:
PR c++/86953
* g++.dg/cpp0x/constexpr-86953.C: New test.
Added:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90119
Bug ID: 90119
Summary: Merge translation msgids that only differ in
placeholders
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105
--- Comment #1 from Jonathan Wakely ---
I think this is the fix:
--- a/libstdc++-v3/include/bits/forward_list.tcc
+++ b/libstdc++-v3/include/bits/forward_list.tcc
@@ -469,9 +469,9 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90118
Bug ID: 90118
Summary: Missing space between words
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90117
Bug ID: 90117
Summary: Replace %<%s%> with %qs
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: translation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #15 from Marek Polacek ---
(In reply to Marek Polacek from comment #14)
> The problem is that here
> 24072 /* Instantiate a dynamic exception-specification. noexcept will
> be
> 24073 handled below. */
> 24074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90109
--- Comment #2 from Jim Wilson ---
long long and long double did not exist when stabs was invented. Also, 64-bit
machines and C++ did not exist at the time. Also, unfortunately, stabs wasn't
designed to be extensible. So there is no way to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #77 from Iain Sandoe ---
(In reply to Iain Sandoe from comment #76)
> (In reply to Jürgen Reuter from comment #75)
> > LLVM does not compile, but I
> > guess this is unrelated to the problem here:
> > [ 38%] Building CXX object
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #76 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #75)
> (In reply to Iain Sandoe from comment #74)
>
> > Thanks, does that include a test suite run and/or building something
> > substantial (e.g. LLVM)? .. sorry to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #29 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #27)
> > Note: I'm assuming we're missing a \n after p116's empty conflicts above?
>
> The code is
Right. I already whipped up a patch that gives me:
;;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #75 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #74)
> Thanks, does that include a test suite run and/or building something
> substantial (e.g. LLVM)? .. sorry to pass this on, but right now as noted,
> very limited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #28 from Peter Bergner ---
Vlad, in looking at add_insn_allocno_copies(), it looks like it relies on
seeing REG_DEAD notes on whether to record a copy/shuffle that should be
handled. Shouldn't we instead be looking at whether the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #27 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #26)
> ;; a4(r117,l0) conflicts: a3(r112,l0)
> ;; total conflict hard regs:
> ;; conflict hard regs:
>
> ;; a5(r116,l0) conflicts:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90105
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #50 from Jakub Jelinek ---
(In reply to Florian Weimer from comment #49)
> (In reply to Bernd Edlinger from comment #48)
> > (In reply to Florian Weimer from comment #47)
> > > (In reply to Bernd Edlinger from comment #43)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84369
--- Comment #5 from pthaugen at gcc dot gnu.org ---
Author: pthaugen
Date: Tue Apr 16 15:58:02 2019
New Revision: 270394
URL: https://gcc.gnu.org/viewcvs?rev=270394=gcc=rev
Log:
PR target/84369
* config/rs6000/power9.md: Add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #14 from Marek Polacek ---
The problem is that here
24072 /* Instantiate a dynamic exception-specification. noexcept will be
24073 handled below. */
24074 if (tree raises = TYPE_RAISES_EXCEPTIONS (TREE_TYPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116
--- Comment #1 from Moeketsi Raselimo <22374604 at sun dot ac.za> ---
Created attachment 46180
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46180=edit
gccgo-8.2 throws syntax error on this one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90116
Bug ID: 90116
Summary: Segmentation fault and what appears to be an
implementation error in gofrontend (parse.cc)
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
--- Comment #26 from Peter Bergner ---
(In reply to Vladimir Makarov from comment #25)
> (In reply to Peter Bergner from comment #24)
>> I don't know why r0 isn't in profitable_regs for pseudo 116.
>
> Profitable regs there contain also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88809
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82891
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
--- Comment #5 from Jonathan Wakely ---
I'll come back to this for GCC 10.
Slightly better (and not broken) patch:
--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -220,11 +220,11 @@ namespace __debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2018-10-25 00:00:00 |2019-4-16
Known to fail|9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #13 from Marek Polacek ---
Adjusted testcase that is compiled with GCC 8.3 without errors:
namespace a {
template struct d { static constexpr int f = c; };
template struct g;
template h i(int);
template auto ab() ->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87748
Jonathan Wakely changed:
What|Removed |Added
CC||alex at grundis dot de
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90080
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90080
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799
Jonathan Wakely changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004
Bug 55004 depends on bug 65799, which changed state.
Bug 65799 Summary: Allows constexpr conversion from cv void * to other type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
--- Comment #11 from Marek Polacek ---
*** Bug 90003 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003
Marek Polacek changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65799
Martin Sebor changed:
What|Removed |Added
Blocks||55004
--- Comment #6 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection,|ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
Martin Liška changed:
What|Removed |Added
Attachment #46092|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90088
--- Comment #5 from H.J. Lu ---
We should first add an LEA microbenchmark to
https://gitlab.com/x86-benchmarks/microbenchmark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86953
--- Comment #8 from Rémi Ducceschi ---
It seems to be fixed on the last version available on wandbox.org (gcc HEAD
9.0.1 201904): https://wandbox.org/permlink/Tu4T8jEXDDtDw0OS
Though it doesn't work on any other versions (8.3.0...).
Any chance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #74 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #73)
> (In reply to Iain Sandoe from comment #68)
> > Created attachment 46176 [details]
> > revised fixincludes patch.
>
> >
> > The patch attached include the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050
--- Comment #7 from Jonathan Wakely ---
See https://bugs.launchpad.net/ubuntu/+source/gcc-8/+bug/1824721 where I said:
"for now the short answer is "C++17 support in GCC 8 is experimental, the onus
is on you to link correctly"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #73 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #68)
> Created attachment 46176 [details]
> revised fixincludes patch.
>
> The patch attached include the generated files, and I'd be grateful if folks
> would test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89983
Alexandre Oliva changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90050
--- Comment #6 from Mihai Preda ---
OK, thanks.
So if on Ubuntu 19.04, the default compiler produces without errors/warnings,
from valid source code, an executable that crashes, that's programmer error?!
I understand the explanation, but there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790
--- Comment #4 from Segher Boessenkool ---
(Yup, worked).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88790
Segher Boessenkool changed:
What|Removed |Added
CC||daniel.marjamaki at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
Bug 82738 depends on bug 89528, which changed state.
Bug 89528 Summary: Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90017
--- Comment #5 from Alexandre Oliva ---
I think it's more of a missing feature than a bug. I believe GDB folks already
know about this, though maybe not about this specific manifestation thereof.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90110
--- Comment #1 from Ian Lance Taylor ---
The pathnames suggest that this is the -m32 build.
Can you attach the file TARGET/32/libgo/math.gox?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86438
--- Comment #12 from Alexandre Oliva ---
Author: aoliva
Date: Tue Apr 16 12:44:46 2019
New Revision: 270388
URL: https://gcc.gnu.org/viewcvs?rev=270388=gcc=rev
Log:
[PR86438] avoid too-long shift in test
The test fell back to long long and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528
--- Comment #5 from Alexandre Oliva ---
Author: aoliva
Date: Tue Apr 16 12:44:57 2019
New Revision: 270389
URL: https://gcc.gnu.org/viewcvs?rev=270389=gcc=rev
Log:
[PR89528] reset debug uses of return value when dropping dead RTL call
When we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115
Bug ID: 90115
Summary: OpenACC: predetermined private levels for variables
declared in blocks
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: openacc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #5 from Frederico Lamberti Pissarra ---
CLANG 6 creates a similar code:
f:
xorps %xmm1,%xmm1
ucomiss %xmm1,%xmm0
jb .L8 # more intutive test...
sqrtss
ret
.L8:
jmp sqrtf@PLT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90106
--- Comment #4 from Frederico Lamberti Pissarra ---
My suggestion is to do a simple jmp after .L8 label and test the condition
before sqrtss (or fsqrt, or sqrtsd...):
f:
pxor %xmm2,%xmm2
ucomiss %xmm0,%xmm2
ja .L8
sqrtss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90114
Bug ID: 90114
Summary: Predetermined private levels for variables declared in
OpenACC accelerator routines
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
--- Comment #3 from Jonathan Wakely ---
I'm not sure if the original testcase is actually required to compile.
Implementations are allowed to add additional constructors, and they could take
an arbitrary type with a .clear() member.
But as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093
--- Comment #49 from Florian Weimer ---
(In reply to Bernd Edlinger from comment #48)
> (In reply to Florian Weimer from comment #47)
> > (In reply to Bernd Edlinger from comment #43)
> > > does anybody know what is the Ada and/or D syntax for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507
Roman Zhuykov changed:
What|Removed |Added
CC||zhroma at ispras dot ru
--- Comment #12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> A DEBUG::debug vector
s/DEBUG::debug vector/DEBUG::vector/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90003
--- Comment #4 from rene.r...@fu-berlin.de ---
Hi gcc-team,
is there any news about this issue?
Let me know, if you need more information.
Kind regards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90102
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90113
Bug ID: 90113
Summary: Useless torture mode for gfortran.dg tests
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953
Martin Liška changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90001
--- Comment #5 from Roman Zhuykov ---
Retested patch separately, everything works.
Have found 2 more slow Fortran examples on (obsolete) spu platform and with
additional options like -O1/O2 -fomit-frame-pointer -funroll-loops -fpeel-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85164
--- Comment #3 from David Binderman ---
I'd be happy to help out with any testing of any speculative patch
for this bug.
I am surprised that more than 64 bits of precision are required.
Would a data type like float or double do the job ? Less
1 - 100 of 148 matches
Mail list logo
