https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
--- Comment #3 from Jonathan Wakely ---
Apparently ext/special_functions/hyperg/check_value.cc is also failing on i686.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69295
--- Comment #4 from Jakub Jelinek ---
FAIL: ext/special_functions/hyperg/check_value.cc execution test
seen also on i686-linux (dunno about x86_64, that is still doing make check).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69301
Bug ID: 69301
Summary: std::atomic::load() won't compile if T doesn't have
a default constructor
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: norma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64841
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65929
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69266
--- Comment #4 from tprince at computer dot org ---
This works only when building libstdc++ with an older g++ version.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68037
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552
Bug 67552 depends on bug 68037, which changed state.
Bug 68037 Summary: x86 interrupt attribute doesn't work with DRAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68037
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69301
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63890
Bernd Schmidt changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69259
--- Comment #1 from Jonathan Wakely ---
The implementation follows the specification correctly, as far as I can see:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4099.html#fs.op.copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69259
--- Comment #2 from Jonathan Wakely ---
(We are missing tests for filesystem::copy() though, I accidentally duplicated
the tests for fs::absolute())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
Jeffrey A. Law changed:
What|Removed |Added
Priority|P4 |P2
--- Comment #5 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #11 from Ivan Godard ---
OP here; better late than never :-)
IANALL, but the portions of the standard cited by Jonathan all refer to
argument evaluation, while the problem here is in the result type. Why is the
result even being cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69030
--- Comment #7 from Vladimir Makarov ---
Author: vmakarov
Date: Fri Jan 15 19:33:33 2016
New Revision: 232445
URL: https://gcc.gnu.org/viewcvs?rev=232445&root=gcc&view=rev
Log:
2016-01-15 Vladimir Makarov
PR rtl-optimization/69030
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #12 from Jonathan Wakely ---
Template argument deduction requires substituting the template arguments where
they appear. If that is in the return type, it gets substituted into the return
type. If that causes a substitution error then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
--- Comment #13 from Jonathan Wakely ---
(In reply to Ivan Godard from comment #11)
> IANALL, but the portions of the standard cited by Jonathan all refer to
> argument evaluation,
Maybe you're confusing template arguments with function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68446
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69302
Bug ID: 69302
Summary: Using bswap in template function with
-ftrack-macro-expansion=0 results in a false compiler
error
Product: gcc
Version: 5.2.0
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69303
Bug ID: 69303
Summary: Fortran character common block equivalence lto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68976
--- Comment #13 from vries at gcc dot gnu.org ---
new patch: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01139.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68976
--- Comment #14 from vries at gcc dot gnu.org ---
(In reply to vries from comment #13)
> new patch: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01139.html
new patch does not fix dup. Will reopen dup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69302
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68955
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68692
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69304
Bug ID: 69304
Summary: Fortran logical common block equivalence lto
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69302
--- Comment #2 from Alexander Kondratskiy ---
Created attachment 37363
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37363&action=edit
Preprocessed source that results in error
g++ -std=c++1y -c -Werror -Wall -Wextra preprocessed.cpp -o t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60593
--- Comment #7 from Paul Thomas ---
Author: pault
Date: Fri Jan 15 20:33:58 2016
New Revision: 232450
URL: https://gcc.gnu.org/viewcvs?rev=232450&root=gcc&view=rev
Log:
2016-01-15 Paul Thomas
PR fortran/64324
* resolve.c (che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64324
--- Comment #2 from Paul Thomas ---
Author: pault
Date: Fri Jan 15 20:33:58 2016
New Revision: 232450
URL: https://gcc.gnu.org/viewcvs?rev=232450&root=gcc&view=rev
Log:
2016-01-15 Paul Thomas
PR fortran/64324
* resolve.c (che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60795
--- Comment #10 from Paul Thomas ---
Author: pault
Date: Fri Jan 15 20:33:58 2016
New Revision: 232450
URL: https://gcc.gnu.org/viewcvs?rev=232450&root=gcc&view=rev
Log:
2016-01-15 Paul Thomas
PR fortran/64324
* resolve.c (ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #29 from Paul Thomas ---
Author: pault
Date: Fri Jan 15 20:33:58 2016
New Revision: 232450
URL: https://gcc.gnu.org/viewcvs?rev=232450&root=gcc&view=rev
Log:
2016-01-15 Paul Thomas
PR fortran/64324
* resolve.c (ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630
--- Comment #6 from Paul Thomas ---
Author: pault
Date: Fri Jan 15 20:33:58 2016
New Revision: 232450
URL: https://gcc.gnu.org/viewcvs?rev=232450&root=gcc&view=rev
Log:
2016-01-15 Paul Thomas
PR fortran/64324
* resolve.c (che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61147
--- Comment #2 from Paul Thomas ---
Author: pault
Date: Fri Jan 15 20:33:58 2016
New Revision: 232450
URL: https://gcc.gnu.org/viewcvs?rev=232450&root=gcc&view=rev
Log:
2016-01-15 Paul Thomas
PR fortran/64324
* resolve.c (che
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
--- Comment #21 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 15 20:57:54 2016
New Revision: 232451
URL: https://gcc.gnu.org/viewcvs?rev=232451&root=gcc&view=rev
Log:
PR bootstrap/68271
* parser.h (cp_token): Remove pragma_k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67515
--- Comment #10 from Roger Orr ---
Hello Yury, yes the problem with boost was reported as
https://svn.boost.org/trac/boost/ticket/11632
and the ticket contains a proposed solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69304
kargl at gcc dot gnu.org changed:
What|Removed |Added
Component|fortran |lto
--- Comment #1 from kargl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69284
--- Comment #1 from Daniel Starke ---
I have tried a couple of things to find the cause of this bug.
- using -O1 instead of -O3 when building GCC
- using -O2 instead of -O3 when building GCC
- using -fno-lto when building GCC
- using the defaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66420
--- Comment #4 from David Binderman ---
Still wrong in gcc trunk 20160115
==3767== Conditional jump or move depends on uninitialised value(s)
==3767==at 0x8FD097: improve_allocation() (ira-color.c:2774)
==3767==by 0x901F2D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69303
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69296
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69126
David Malcolm changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68271
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69296
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69296
--- Comment #4 from Jerry DeLisle ---
With Latest Trunk: hmm not a good thing. This is a regression.
gcc version 6.0.0 20160115 (experimental) (GCC)
pr69296.f03:1:0:
program p
Error: non-trivial conversion at assignment
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69299
--- Comment #4 from H.J. Lu ---
Created attachment 37364
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37364&action=edit
A patch
Does it make sense?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69304
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076
--- Comment #61 from Jan Hubicka ---
It seems we regressed slightly further.
GCC 4.9: 27.87s
GCC 5: 32.2
trunk: 37.78
furhter GGC memory use went up from 1053147 kB to 1221321 kB.
GCC 4.9:
phase parsing : 1.55 ( 5%) usr 1.24 (22%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69270
--- Comment #4 from Jeffrey A. Law ---
Author: law
Date: Fri Jan 15 22:32:05 2016
New Revision: 232453
URL: https://gcc.gnu.org/viewcvs?rev=232453&root=gcc&view=rev
Log:
PR tree-optimization/69270
* tree-ssanames.c (ssa_name_has_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305
Bug ID: 69305
Summary: [5/6 Regression] wrong code with -O and int128 @
aarch64
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69306
Bug ID: 69306
Summary: wrong code with int128 @ x32
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69030
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69307
Bug ID: 69307
Summary: [6 Regression] wrong code with -O2
-fselective-scheduling @ armv7a
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
Bug ID: 69308
Summary: ifcombine joins together floating point expression
with side effects
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #1 from Mike Liang ---
Created attachment 37367
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37367&action=edit
Makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #2 from Mike Liang ---
Created attachment 37369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37369&action=edit
run tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69294
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 15 23:00:30 2016
New Revision: 232455
URL: https://gcc.gnu.org/viewcvs?rev=232455&root=gcc&view=rev
Log:
PR libstdc++/69294 Check for isinf and isnan on AIX
PR libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69307
--- Comment #1 from Zdenek Sojka ---
Created attachment 37368
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37368&action=edit
reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69294
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69306
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68609
--- Comment #5 from David Edelsohn ---
Author: dje
Date: Fri Jan 15 23:04:23 2016
New Revision: 232456
URL: https://gcc.gnu.org/viewcvs?rev=232456&root=gcc&view=rev
Log:
PR target/68609
* gcc.target/powerpc/recip-1.c: Adjust for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69306
--- Comment #2 from H.J. Lu ---
*** Bug 69305 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69305
Zdenek Sojka changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69293
--- Comment #3 from Jonathan Wakely ---
Author: redi
Date: Fri Jan 15 23:12:13 2016
New Revision: 232457
URL: https://gcc.gnu.org/viewcvs?rev=232457&root=gcc&view=rev
Log:
Use static assertion for uses-allocator construction
PR libstdc+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69306
--- Comment #3 from Zdenek Sojka ---
(In reply to H.J. Lu from comment #1)
> typedef unsigned long int uint64_t;
> It should be long long.
Sorry, you are right, originally it was __UINT64_TYPE__, but the macr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69197
Bogdan changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #6 from Bogdan ---
Thank you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69293
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|ASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69306
--- Comment #4 from Zdenek Sojka ---
(In reply to Zdenek Sojka from comment #3)
> (In reply to H.J. Lu from comment #1)
> > typedef unsigned long int uint64_t;
> > It should be long long.
>
> Sorry, you are r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #3 from joseph at codesourcery dot com ---
This has nothing to do with signaling NaNs; ordered comparisons raise
exceptions for quiet NaNs as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #4 from Mike Liang ---
The test case passes both a signaling NaN and a quiet NaN through the
expression and FPE is only triggered by the signaling NaN.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69252
--- Comment #10 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #5)
> b) try make check -jN
> RUNTESTFLAGS='--target_board=unix/fmodulo-sched/-fmodulo-sched-allow-
> regmoves/-fsched-pressure' with unpatched vs. patched, see if it d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #5 from joseph at codesourcery dot com ---
Maybe you're encountering one of the known bugs where on some
architectures GCC wrongly generated unordered comparison instructions for
ordered comparisons.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69252
--- Comment #11 from Martin Sebor ---
The following is a list of names of tests that fail in the baseline but not
with the patch:
c-c++-common/torture/pr53505.c
gcc.c-torture/execute/pr54471.c
gcc.c-torture/execute/pr61682.c
gcc.dg/vect/costmode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69309
Bug ID: 69309
Summary: Implement CWG 1780
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67193
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69259
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #6 from Mike Liang ---
Oh, I see. You're saying this can be a problem for both QNaN and SNaN because
an ordered comparison instruction could be generated. Does this mean floating
point expressions should never be combined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #7 from Andrew Pinski ---
Does adding -ftrapping-math allow it to work?
Also what target are you running on?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67252
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2016-1-15
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #8 from Mike Liang ---
No, -ftrapping-math does not change the outcome.
I'm building x86_64 on RHEL 6.6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67314
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69308
--- Comment #9 from joseph at codesourcery dot com ---
Code should not be moved to evaluate a floating-point expression when it
would not be evaluated in the abstract machine, if that expression could
raise an exception. Whether this should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68936
--- Comment #3 from Patrick Palka ---
Author: ppalka
Date: Sat Jan 16 02:27:36 2016
New Revision: 232461
URL: https://gcc.gnu.org/viewcvs?rev=232461&root=gcc&view=rev
Log:
Fix PR c++/68936
gcc/cp/ChangeLog:
PR c++/68936
* tree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091
--- Comment #2 from Patrick Palka ---
Author: ppalka
Date: Sat Jan 16 02:37:09 2016
New Revision: 232463
URL: https://gcc.gnu.org/viewcvs?rev=232463&root=gcc&view=rev
Log:
Fix PR c++/69091 (ICE with operator overload having 'auto' return type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69091
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68936
Patrick Palka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68899
--- Comment #1 from David Malcolm ---
Author: dmalcolm
Date: Sat Jan 16 04:38:19 2016
New Revision: 232465
URL: https://gcc.gnu.org/viewcvs?rev=232465&root=gcc&view=rev
Log:
PR diagnostic/68899: fix read-beyond-buffer when printing very wide sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68899
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
Jeffrey A. Law changed:
What|Removed |Added
Summary|[6 Regression] code size|[5/6 Regression] code size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196
--- Comment #7 from Jeffrey A. Law ---
It's definitely the FSM threader. The FSM threader has 3 knobs for tuning. If
I crank them all down to minimal values, then the trunk & gcc-5 actually
generate slightly smaller code than gcc-4.9.
I don't
101 - 190 of 190 matches
Mail list logo
