https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69205
--- Comment #4 from mohsen ---
This bug tagged rejects-valid, although, Andrew Pinski has told that he did not
know variadic templates well. After that I do not know I must wait still to get
a certain answer about that or it really accepted and i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69575
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69575
Bug ID: 69575
Summary: [interrupt] The direction flag DF in the FLAGS
register may be wrong in interrupt handler
Product: gcc
Version: 6.0
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69574
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target|
: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160130 (experimental) [trunk revision 233007] (GCC)
$ gcc-trunk -O3 -c abc.c
abc.c: In function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #2 from Martin Sebor ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02372.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18154
--- Comment #10 from David Edelsohn ---
isel is not generally performance win for Power using GCC. It is enabled for
LLVM because LLVM has a simplistic basic block scheduler and isel allows LLVM
to form larger basic blocks to provide the schedul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
--- Comment #1 from Martin Sebor ---
Created attachment 37529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37529&action=edit
Proposed patch.
The attached patch should cure the failing test on the two targets. It passes
on x86_64-*-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61053
Martin Sebor changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69573
Bug ID: 69573
Summary: FAIL: gcc.dg/pr61053.c (test for excess errors)
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61053
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2014-05-04 00:00:00 |2016-1-30
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60202
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
Martin Sebor changed:
What|Removed |Added
CC||ilja.honkonen at helsinki dot
fi
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69572
Bug ID: 69572
Summary: [C++11] invalid alignas accepted in many contexts
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69571
Bug ID: 69571
Summary: [C++11] invalid alignas on a typedef accepted, reduces
alignment
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69359
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #13 from Manuel López-Ibáñez ---
(In reply to Dominique d'Humieres from comment #11)
> I think you need to add a line
>
> ! { dg-options "-pedantic" }
>
> to elemental_optional_args_6.f90 (untested).
I'd suggest to use -Wpedantic,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Dominique d'Humieres from comment #8)
> This seems a lot of work for big patches. Note that this is not specific to
> gfortran: any one committing a patch should look at the Intel results!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66707
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
Jakub Jelinek changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69570
Bug ID: 69570
Summary: [6 Regression] if-conversion bug on i?86
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18154
--- Comment #9 from Martin Sebor ---
I noticed while looking at an unrelated bug that when targeting power7 or
power8 Clang makes use of the isel instruction and emits the following:
min:# @min
cmpw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #9 from David Malcolm ---
(In reply to Thomas Koenig from comment #5)
> No patch is needed to expose this bug.
>
> Test case:
Thanks. This is almost certainly my fault, probably due to r229884. Sorry.
I plan to fix this once I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69569
Bug ID: 69569
Summary: unnecessary branches on an if followed by a switch
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|6.0 |5.4
Summary|[5/6 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69546
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Sat Jan 30 18:04:13 2016
New Revision: 233012
URL: https://gcc.gnu.org/viewcvs?rev=233012&root=gcc&view=rev
Log:
PR tree-optimization/69546
* wide-int.cc (wi::divmod_inter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
--- Comment #3 from Paul Thomas ---
Author: pault
Date: Sat Jan 30 17:44:56 2016
New Revision: 233011
URL: https://gcc.gnu.org/viewcvs?rev=233011&root=gcc&view=rev
Log:
2016-01-30 Paul Thomas
PR fortran/69566
* trans-expr.c (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69540
--- Comment #1 from Arkadiusz Drabczyk ---
Patch sent for review here:
https://gcc.gnu.org/ml/gcc-patches/2016-01/msg02368.html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68490
--- Comment #2 from Martin Sebor ---
Author: msebor
Date: Sat Jan 30 17:30:32 2016
New Revision: 233010
URL: https://gcc.gnu.org/viewcvs?rev=233010&root=gcc&view=rev
Log:
PR r++/68490 - error initializing a structure with a flexible array membe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
--- Comment #2 from Paul Thomas ---
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 233009)
--- gcc/fortran/trans-expr.c(working copy)
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59746
--- Comment #8 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jan 30 17:13:29 2016
New Revision: 233009
URL: https://gcc.gnu.org/viewcvs?rev=233009&root=gcc&view=rev
Log:
2016-01-30 Bud Davis
Mikael Morin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66707
--- Comment #5 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jan 30 17:13:29 2016
New Revision: 233009
URL: https://gcc.gnu.org/viewcvs?rev=233009&root=gcc&view=rev
Log:
2016-01-30 Bud Davis
Mikael Morin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
Segher Boessenkool changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
--- Comment #3 from Segher Boessenkool ---
Confirmed. It's a combine problem. Mine.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
--- Comment #2 from Martin Sebor ---
In fact, the test case can be simplified even further to this:
typedef __UINT16_TYPE__ uint16_t;
typedef __UINT32_TYPE__ uint32_t;
typedef __INT64_TYPE__ int64_t;
typedef __UINT64_TYPE__ uint64_t;
static ui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69568
Bug ID: 69568
Summary: Invalid HSAIL opcode when using builtin vector
Product: gcc
Version: hsa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071
--- Comment #17 from Dominique d'Humieres ---
> Any opinions on this?
It's fine for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071
janus at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
Martin Sebor changed:
What|Removed |Added
Target|powerpc64le-linux |powerpc64*-linux
Status|UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #12 from Dominique d'Humieres ---
I have tested that the following patch fixes the failures
--- ../_clean/gcc/testsuite/gfortran.dg/elemental_optional_args_6.f90
2012-06-18 21:04:16.0 +0200
+++ gcc/testsuite/gfortran.dg/ele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #11 from Dominique d'Humieres ---
I think you need to add a line
! { dg-options "-pedantic" }
to elemental_optional_args_6.f90 (untested).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #10 from Dominique d'Humieres ---
> Created attachment 37527 [details]
> patch
>
> The attached patch should take care of all cases mentioned above.
>
> Unfortunately it causes a testsuite failure of elemental_optional_args_6.f90
> an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37262
--- Comment #7 from Martin Sebor ---
Yes, sorry, I meant to say "still there at -O1" because that's the optimization
level mentioned in comment #1. (I had to guess at the level based on that. I
also accidentally used -m32 when the target is pow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
--- Comment #8 from Dominique d'Humieres ---
Likely caused by revision r29884.
> Please take this as a humble general suggestion: Fortran maintainers
> should enforce during patch review that any new diagnostic has
> a corresponding testcase tri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69567
Bug ID: 69567
Summary: PowerPC64: cstore optimisation produces bad code
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69535
--- Comment #6 from Segher Boessenkool ---
That patch looks fine. But are the SCALAR_INT_MODE_P checks necessary?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37262
--- Comment #6 from Segher Boessenkool ---
(In reply to Martin Sebor from comment #4)
> I built the gcc-5-branch on powerpc64-linux and the duplicate instructions
> are still there with the second test case compiled at -O2 (see below).
>
> $ /bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69495
--- Comment #9 from janus at gcc dot gnu.org ---
Created attachment 37527
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37527&action=edit
patch
The attached patch should take care of all cases mentioned above.
Unfortunately it causes a te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Component|othe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007
--- Comment #10 from Dominique d'Humieres ---
Could this PR be closed as FIXED?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31560
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53867
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392
Bug 31392 depends on bug 31243, which changed state.
Bug 31243 Summary: Detect strings longer than 2**32 characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30932
Bug 30932 depends on bug 31243, which changed state.
Bug 31243 Summary: Detect strings longer than 2**32 characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
Bug 19276 depends on bug 31243, which changed state.
Bug 31243 Summary: Detect strings longer than 2**32 characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31243
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66707
--- Comment #4 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sat Jan 30 14:07:19 2016
New Revision: 233008
URL: https://gcc.gnu.org/viewcvs?rev=233008&root=gcc&view=rev
Log:
2016-01-30 Dominique d'Humieres
PR fortran/66707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69566
Bug ID: 69566
Summary: [6 Regression] ICE with unlimited polymorphic array
pointer function
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69565
--- Comment #1 from Morwenn ---
The labels on the image are cropped, but each label corresponds to a specific
distribution of the data. The full names are as follows:
Shuffled
Shuffled (16 values)
All equal
Ascending
Descending
Pipe organ
Push f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69565
Bug ID: 69565
Summary: Heap operations could surely be faster
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libst
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578
--- Comment #18 from Dominique d'Humieres ---
> It seems that this has been fixed for gfortran 5 and all test cases
> are handled properly now. Can we close the PR?
This is true for the gcc-5 branch. However compiling the test in comment 6
gives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64578
--- Comment #17 from janus at gcc dot gnu.org ---
It seems that this has been fixed for gfortran 5 and all test cases are handled
properly now. Can we close the PR?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69049
Georg-Johann Lay changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68226
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67091
--- Comment #4 from janus at gcc dot gnu.org ---
Since this is not a regression, I don't see a strong need to backport it. But
if you still want to do it, that's fine with me as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69560
--- Comment #10 from Jonathan Wakely ---
(In reply to David Merillat from comment #8)
> One thing remains. As a result of 52023, C11 _Alignof was "fixed" to return
> the smallest possible alignment, but C++11 was left alone "deliberately",
> alt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67091
--- Comment #3 from Dominique d'Humieres ---
> What's the status here? Can this be closed?
Fixed on trunk but not on the gcc-5 branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69533
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67091
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544
--- Comment #5 from janus at gcc dot gnu.org ---
Note that there are other ways to generate a "recursive" interface, like:
module m
implicit none
contains
real function f(z)
procedure(f), pointer :: z
end
end module
This one is compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544
--- Comment #4 from janus at gcc dot gnu.org ---
Btw, I don't fully understand why "implicit none" should make any difference
here.
I can see that it would make a difference if you don't specify an interface in
the procedure statement:
module m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66544
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69563
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69554
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |6.0
Summary|Multi-location di
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564
Bug ID: 69564
Summary: lto makes scimark2 LU slower
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69534
--- Comment #2 from rguenther at suse dot de ---
On January 30, 2016 8:37:59 AM GMT+01:00, "pinskia at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69534
>
>--- Comment #1 from Andrew Pinski ---
>Try using -fno-delete-n
84 matches
Mail list logo
