https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78425
Bug ID: 78425
Summary: Atrtibute warning message location incorrect
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68180
--- Comment #3 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 18 23:51:30 2016
New Revision: 242610
URL: https://gcc.gnu.org/viewcvs?rev=242610&root=gcc&view=rev
Log:
PR c++/68180
* g++.dg/cpp1y/pr68180.C: Add -Wno-psabi as d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 18 22:21:31 2016
New Revision: 242608
URL: https://gcc.gnu.org/viewcvs?rev=242608&root=gcc&view=rev
Log:
PR middle-end/78419
* multiple_target.c (get_attr_len): St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78424
Bug ID: 78424
Summary: intl reincludes sysroot into searching for ld
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77285
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 18 21:56:50 2016
New Revision: 242607
URL: https://gcc.gnu.org/viewcvs?rev=242607&root=gcc&view=rev
Log:
PR c++/77285
* mangle.c (mangle_tls_init_fn, mangle_tls_wr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78191
--- Comment #6 from Jakub Jelinek ---
Author: jakub
Date: Fri Nov 18 21:55:46 2016
New Revision: 242606
URL: https://gcc.gnu.org/viewcvs?rev=242606&root=gcc&view=rev
Log:
* dwarf2out.c (size_of_discr_list): Fix typo in function comment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25112
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25112
--- Comment #3 from Jeffrey A. Law ---
Author: law
Date: Fri Nov 18 21:52:32 2016
New Revision: 242605
URL: https://gcc.gnu.org/viewcvs?rev=242605&root=gcc&view=rev
Log:
PR target/25112
* config/m68k/m68k.c (moveq feeding equalit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
Jason Merrill changed:
What|Removed |Added
Component|c++ |libstdc++
--- Comment #8 from Jason Merr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #7 from Tomasz Kamiński ---
> No, it's very much allowed to do that. But I'm skeptical that it's allowed
> to turn !(a{}(a,b) && !std::less(b,a)
being false, when std::less{}(a,b) and std::less{}(b,a) are both false,
and in contrast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77536
--- Comment #3 from Pat Haugen ---
pr78116 contains a couple testcases that showed degradation on x86 caused by
spill inside a vectorized loop due to messed up BB frequencies.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631
--- Comment #10 from Howard Hinnant ---
Thanks much Jason!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Fri Nov 18 20:27:41 2016
New Revision: 242604
URL: https://gcc.gnu.org/viewcvs?rev=242604&root=gcc&view=rev
Log:
PR c++/67631 - list-init and explicit conversions
* seman
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631
--- Comment #7 from Jason Merrill ---
Author: jason
Date: Fri Nov 18 20:27:26 2016
New Revision: 242603
URL: https://gcc.gnu.org/viewcvs?rev=242603&root=gcc&view=rev
Log:
PR c++/67631 - list-init and explicit conversions
* seman
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116
Pat Haugen changed:
What|Removed |Added
Depends on||77536
--- Comment #8 from Pat Haugen ---
M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #6 from Jason Merrill ---
(In reply to Tomasz Kamiński from comment #4)
> Oh, you mean that compiler is not allowed to turn comparison of p == b into
> false at compile time, using 5.10 [expr.eq] p2.1?
No, it's very much allowed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #5 from Andrew Pinski ---
I think this deserves a Defect report to the C++ committee because even though
std::less requires total order, < and <= usage are undefined if used with two
different arrays.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78423
--- Comment #2 from Jonathan Wakely ---
(In reply to Bharath from comment #0)
> Due to project constraints we are not supposed to upgrade our gcc to version
> 5 & above.Can you please guide is there any other way we can fix above
> errors without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78423
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54316
Andrew Pinski changed:
What|Removed |Added
CC||snbraj at sasken dot com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78423
Bug ID: 78423
Summary: [c+11] error: use of deleted function
'std::basic_ostringstream
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411
--- Comment #5 from Jakub Jelinek ---
Yeah, I've also noticed that in my working-directory gcc build (-O0,
reconfigured hundreds of times, ...) the test fails, while in my cleanly
bootstrapped one it succeeds, with the same -march=/-mtune= option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411
--- Comment #4 from Martin Sebor ---
The test fails for me as well (that's how I noticed it). This is on trunk,
with a straightforward build with -mtune=generic and -march=x86-64 passed by
the driver. But it only fails on one of my machines (my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411
--- Comment #3 from H.J. Lu ---
I tried r242601 with -mtune=generic -march=x86-64. There is no cmov at all.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #8 from Walter Spector ---
Hi Janus,
The ifort compiler has no problem with your example in Comment #5. That
example should be Standard Fortran 90.
The newer F2008 data pointer initialization stuff is largely in §4.5.4.6,
paragraph
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392
--- Comment #6 from janus at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #5)
> Related to pr42122?
Don't think so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392
--- Comment #5 from Dominique d'Humieres ---
> As an alternative to removing the assert, one could possibly prevent SAVEd
> variables in the main PROGRAM from being declared as "static" (which might
> also cure the performance regressions that Do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54613
--- Comment #3 from Dominique d'Humieres ---
At https://gcc.gnu.org/ml/fortran/2016-11/msg00179.html I wrote
pr54613, sixth and eighth tests,
Actually the tests were extracted from
https://groups.google.com/forum/?fromgroups=#!topic/comp.lang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78411
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25112
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #11 from Jerry DeLisle ---
One could consider running a reference matrix multiply of size 32 in a loop and
do timing tests to determine whether to use -mprefer-avx128. 0n this machine
from comment 8
mavx = 1.276 mavx mprefer-avx1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78422
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #10 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #9)
> Next question - what happens if you add
>
> -mvzeroupper -mavx
>
> to the line in the Makefile? Does that make a difference in speed?
-mvzeroupper slows all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #5 from nsz at gcc dot gnu.org ---
i plan to backport the fix, but it seems my fix is not correct and broke the
ieee_8.fp90 test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to Walter Spector from comment #6)
> Your test case in Comment #5 is fine - because it is not attempting to
> initialize the pointer at compile time. Initializing a pointer at compile
> t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78408
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68717
--- Comment #6 from Dominique d'Humieres ---
Is this PR (and pr68649) related to pr33097, pr40976, pr42122, and/or pr44471?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #6 from Walter Spector ---
Hi Janus,
Your test case in Comment #5 is fine - because it is not attempting to
initialize the pointer at compile time. Initializing a pointer at compile time
is a F2008 feature. I was testing this F2008
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #26 from Andreas Schwab ---
Note that the patch in comment 8 is already included in r242526.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #25 from Dominik Vogt ---
A quick regression test with both patches; s390x with just -m64 and
-languages=c has only two failures left:
+FAIL: gcc.target/s390/risbg-ll-1.c scan-assembler
f43:\\n\\trisbg\\t%r2,%r2,32,128+61,64-12
+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #9 from Thomas Koenig ---
Next question - what happens if you add
-mvzeroupper -mavx
to the line in the Makefile? Does that make a difference in speed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413
--- Comment #5 from Bill Schmidt ---
Patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01951.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #24 from Andreas Schwab ---
This also fixes bootstrap on ia64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #23 from Michael Matz ---
(In reply to Dominik Vogt from comment #22)
> Does this patch replace the one in comment 8 or should they both be used?
I checked it in isolation, but the former one does fix a bug as well, so
probably use b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78416
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314
--- Comment #4 from Dominique d'Humieres ---
Any plan to back-port the fix? If no, could you please close the PR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78324
amker at gcc dot gnu.org changed:
What|Removed |Added
Target||arm-none-eabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78422
Bug ID: 78422
Summary: FAIL: gcc.c-torture/execute/cbrt.c execution failure
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78324
--- Comment #3 from David Malcolm ---
Candidate patch:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01942.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #22 from Dominik Vogt ---
Does this patch replace the one in comment 8 or should they both be used?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #21 from Dominik Vogt ---
(In reply to Michael Matz from comment #16)
> Uhh:
>
> Successfully matched this instruction:
> (set (subreg:DI (reg:SI 73) 0)
> -(lshiftrt:DI (reg/v:DI 63 [ X ])
> -(const_int 56 [0x38])))
> +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #4 from Tomasz Kamiński ---
Oh, you mean that compiler is not allowed to turn comparison of p == b into
false at compile time, using 5.10 [expr.eq] p2.1?
Some reference from clang: https://llvm.org/bugs/show_bug.cgi?id=13507. Note
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #3 from Tomasz Kamiński ---
> I don't see this as prohibiting the transformation. The standard seems to be
> saying that they might or might not compare as equal, which presumably
> depends on how variables are laid out in memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78400
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #20 from Michael Matz ---
The below patch fixes at least the gcc.c-torture/execute/20030408-1.c
testcase. Checking others as well, perhaps I manage to bootstrap later.
But if Dominik is faster... :)
diff --git a/gcc/combine.c b/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #23 from Andreas Krebbel ---
Author: krebbel
Date: Fri Nov 18 14:44:54 2016
New Revision: 242590
URL: https://gcc.gnu.org/viewcvs?rev=242590&root=gcc&view=rev
Log:
Re-apply: Drop excess size used for run time allocated stack variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #19 from Dominik Vogt ---
(In reply to Segher Boessenkool from comment #17)
> Combine should probably not try to generate this extract, I wonder if it
> can exist on any target. So where is it coming from?
>
> Of course the target s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #18 from Michael Matz ---
(In reply to Segher Boessenkool from comment #17)
> Combine should probably not try to generate this extract, I wonder if it
> can exist on any target. So where is it coming from?
Easy:
(subreg:SI (lshif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78307
--- Comment #9 from Maxim Ostapenko ---
Can we close this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #22 from Andreas Krebbel ---
Author: krebbel
Date: Fri Nov 18 14:28:49 2016
New Revision: 242589
URL: https://gcc.gnu.org/viewcvs?rev=242589&root=gcc&view=rev
Log:
RS6000: Fix PR 77359: Properly align local variables in functions cal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71723
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Walter Spector from comment #0)
>
> type(data_t), pointer :: data
> integer, pointer :: idata => data%i
Thinking about it some more, I'm actually not sure why this should be illeg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78421
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51652
--- Comment #8 from Dominique d'Humieres ---
AFAICT this PR is mostly fixed since gcc-5. However I see a remaining glitch
with the following variant of the original test
module settings
type keyword
! character(60), allocatable :: c(:) ! wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #17 from Segher Boessenkool ---
Combine should probably not try to generate this extract, I wonder if it
can exist on any target. So where is it coming from?
Of course the target should not "successfully" match it ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78413
Bill Schmidt changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #16 from Michael Matz ---
Uhh:
Successfully matched this instruction:
(set (subreg:DI (reg:SI 73) 0)
-(lshiftrt:DI (reg/v:DI 63 [ X ])
-(const_int 56 [0x38])))
+(zero_extract:DI (reg/v:DI 63 [ X ])
+(const_i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78390
--- Comment #15 from Michael Matz ---
(In reply to Dominik Vogt from comment #14)
> With the fix I couldn't reproduce the error message in four attempts, but
> genattrtab still hangs. Maybe this is bad luck, but maybe the error is
> gone. Runni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395
vehre at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
--- Comment #1 from Tomasz Kamiński ---
This is probably effect on changing !lt(a,b) && !lt(b, a) into !(a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78421
Bug ID: 78421
Summary: vect-strided-a-u8-i2-gap.c fails on armeb
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78420
Bug ID: 78420
Summary: std::less is not an total order with optimization
enabled
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78352
Iain Sandoe changed:
What|Removed |Added
Target||*darwin*
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419
--- Comment #1 from Thomas Koenig ---
Valgrind has some more info:
ig25@linux-fd1f:~/Krempel/Target> valgrind
/home/ig25/lib/gcc/x86_64-pc-linux-gnu/7.0.0/cc1 t2.c
==23596== Memcheck, a memory error detector
==23596== Copyright (C) 2002-2013, an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78419
Bug ID: 78419
Summary: ICE with target_clone on invalid target
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78398
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin16 |x86_64-apple-darwin*
Host|x8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78392
--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> As an alternative to removing the assert, one could possibly prevent SAVEd
> variables in the main PROGRAM from being declared as "static" (which might
> also c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418
--- Comment #2 from Dominique d'Humieres ---
Created attachment 40082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40082&action=edit
Reference results for the obj-c++ test suite before r242377
Note that due to pr63651 I am using the 10.9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418
--- Comment #1 from Dominique d'Humieres ---
Created attachment 40081
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40081&action=edit
Results for the obj-c++ test suite after r242377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78418
Bug ID: 78418
Summary: [7 Regression] Several failures in the obj-c++ test
suite after revision r242377 on x86_64-apple-darwin16
Product: gcc
Version: 7.0
Status: UNCONFI
epo/gcc-trunk//binary-trunk-242583-checking-yes-rtl-df-extra-nobootstrap-nographite-amd64
Thread model: posix
gcc version 7.0.0 20161118 (experimental) (GCC)
All tested 64bit targets seem to be affected:
aarch64-unknown-linux-gnu
powerpc64-unknown-linux-gnu
sparc64-unknown-linux-gnu
x86_64-pc-li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78417
Bug ID: 78417
Summary: target_clones default for powerpc64
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68360
Roman Perepelitsa changed:
What|Removed |Added
CC||roman.perepelitsa at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78267
Rainer Orth changed:
What|Removed |Added
Target|x86_64-apple-darwin16 |x86_64-apple-darwin1[4-6]
U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78395
--- Comment #7 from vehre at gcc dot gnu.org ---
(In reply to janus from comment #2)
> (In reply to janus from comment #1)
> > gfortran 6.2.0 says:
> >
> >v6 = 3 * v4%get_t2() ! This line is the one which causes ICE
> > 1
> > Error: Assignm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78415
Bug ID: 78415
Summary: sqrtq does not round correctly when round mode is
upward
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78414
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77265
Uroš Bizjak changed:
What|Removed |Added
CC||walter.mascarenhas at gmail
dot co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78414
Bug ID: 78414
Summary: libquamath converts (long double) INFINITY to NAN
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78400
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
-
1 - 100 of 112 matches
Mail list logo
