https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66846
vries at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66846
--- Comment #6 from vries at gcc dot gnu.org ---
Author: vries
Date: Fri Jul 31 06:26:44 2015
New Revision: 226427
URL: https://gcc.gnu.org/viewcvs?rev=226427&root=gcc&view=rev
Log:
Don't cancel loop tree in parloops
2015-07-31 Tom de Vries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
--- Comment #5 from Louis Krupp ---
Created attachment 36097
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36097&action=edit
Possible patch
The problem seems to be with an array constructor with an array element whose
value is a character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
--- Comment #4 from Louis Krupp ---
Created attachment 36096
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36096&action=edit
Executable test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62242
Louis Krupp changed:
What|Removed |Added
CC||t56xjcu6dh at snkmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072
--- Comment #4 from Peter Cordes ---
I just timed with Linux perf:
time taskset 0x04 perf stat -e
task-clock,cycles,instructions,r1b1,r10e,r2c2,r1c2,stalled-cycles-frontend,stalled-cycles-backend
./rs-asmbench
my code averages 3.57 fused-domain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072
--- Comment #3 from Peter Cordes ---
@Andrew Pinski: same code is generated with -march=sandybridge (-march=native
on Sandybridge). (Except of course the intrinsics use the VEX version.)
-mtune=intel doesn't help either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072
--- Comment #2 from Peter Cordes ---
I restructured the intrinsics loop to match the asm. This gave a small
speedup, but it's still ~30% slower than my asm. clang-3.5 is even slower than
gcc.
I still don't software-pipeline the loads in C the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #3 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The following program is ill-formed (proc.cc):
> >
> > int main;
> >
> > Compile it with the following c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
--- Comment #2 from Anders Granlund ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Anders Granlund from comment #0)
> > The following program is ill-formed (proc.cc):
> >
> > int main;
> >
> > Compile it with the following c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67063
--- Comment #2 from HEMMI, Shigeru ---
Thanks for the reply.
My output of 'gfortran -v' is:
PS E:\tmp> gfortran -v
Using built-in specs.
COLLECT_GCC=E:\mingw-w64\mingw64\bin\gfortran.exe
COLLECT_LTO_WRAPPER=E:/mingw-w64/mingw64/bin/../libexec/gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67074
--- Comment #1 from Anders Granlund ---
I have reported the same bug in clang also:
https://llvm.org/bugs/show_bug.cgi?id=24324
Richard Smith confirmed it and added this additional test case:
And likewise:
namespace N {}
namespace N = N;
() { X::i; }
Command line:
g++ prog.cc -std=c++14 -pedantic-errors
This results in name-lookup ambiguity errors when looking up X in main. This is
not a name-lookup ambiguity since the two names founds denotes the same entity.
I tried this with gcc HEAD 6.0.0 20150730 here:
http://melpon.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072
--- Comment #1 from Andrew Pinski ---
Have you tried adding -march=intel ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67073
Bug ID: 67073
Summary: short program produces ICE
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67072
Bug ID: 67072
Summary: Slow code generated for getting each byte of a 64bit
register as a LUT index.
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67071
Bug ID: 67071
Summary: GCC misses an optimization to load vector constants
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66870
--- Comment #15 from boger at us dot ibm.com ---
I have submitted my patch to gcc-patches to check for the no_split_stack
attribute after revising it based on Alan's comments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67007
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Thu Jul 30 20:38:27 2015
New Revision: 226415
URL: https://gcc.gnu.org/viewcvs?rev=226415&root=gcc&view=rev
Log:
PR c++/67007
* constraint.cc (normalize_predicate_constrai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67007
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034
--- Comment #2 from dave.anglin at bell dot net ---
On 2015-07-30, at 2:18 PM, aoliva at gcc dot gnu.org wrote:
> John, if you can help with that, would you like
> the asm for this one testcase, or is it easy enough for you to give the branch
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000
--- Comment #4 from Gary Funck ---
(In reply to Alexandre Oliva from comment #3)
> The problem initially reported in this bug is now fixed in the git branch
> aoliva/pr64164. I'm not sure how to go about duplicating the one in comment
> 1, but,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67070
Bug ID: 67070
Summary: [concepts] Concept with negation and disjunction not
checked correctly
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
--- Comment #3 from Alex Lai ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Alex Lai from comment #1)
> > the error apparently is due to the missing space between -static and
> > -libstdc++.
>
> There is no missing space, that'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #14 from Jason Merrill ---
(In reply to Ville Voutilainen from comment #13)
> It is correct that currently none of the pedantic-flags diagnose the use of
> this extension; perhaps that should be fixed while fixing this bug...
'-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #13 from Ville Voutilainen ---
It is correct that currently none of the pedantic-flags diagnose the use of
this extension; perhaps that should be fixed while fixing this bug...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #12 from Daniel Gutson ---
I tried them all, and none of those flags reject a global variable declared as
register. I still think a separate issue should be filed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #11 from Ville Voutilainen ---
or simply -pedantic/-pedantic-errors :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66842
Richard Henderson changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066
--- Comment #5 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #3)
> Are you playing "use as many configure options as possible"?
Yeah, basically (as many interesting-looking ones as possible, at least). I can
confirm that remov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068
--- Comment #3 from Steve Kargl ---
On Thu, Jul 30, 2015 at 06:24:19PM +, mwglass at sandia dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068
>
> --- Comment #2 from Mike Glass ---
> Yes, all the FORTRAN code is compiled w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #9 from Daniel Gutson
---
Thanks Ville and Jens for looking into this.
I'll be able to fix this during next week, so if nobody is available to solve
this sooner, then please assign it to me.
Regarding the global register variables,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068
--- Comment #2 from Mike Glass ---
Yes, all the FORTRAN code is compiled with those options. We want to mimic the
behavior of the Intel compiler when we add the '-r8' flag to their compiler:
Makes default real and complex declarations, constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
--- Comment #48 from Alexandre Oliva ---
The errors reported in comments 44, 45, 46, and 47 are fixed in the git branch
aoliva/pr64164. I'm giving it all some more testing before posting an updated,
consolidated patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828
Markus Trippelsdorf changed:
What|Removed |Added
CC||trippels at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65828
Vittorio Zecca changed:
What|Removed |Added
CC||zeccav at gmail dot com
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #8 from Jens Maurer ---
In general, "x" and "(x)" have the same meaning as per 5.1.1p6.
There are a few (spelled-out) exceptions, though.
One exception is inside a decltype-specifier, where decltype(e) is different
from decltype((e)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Ville Voutilainen changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66849
--- Comment #3 from simon at pushface dot org ---
(In reply to Ramana Radhakrishnan from comment #2)
> (In reply to simon from comment #0)
> > Having configured with
> >
> > --target=arm-eabi
> > --with-arch=armv7
> > --with-mode=thumb
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
Mikhail Maltsev changed:
What|Removed |Added
CC||miyuki at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
--- Comment #2 from Jonathan Wakely ---
(In reply to Alex Lai from comment #1)
> the error apparently is due to the missing space between -static and
> -libstdc++.
There is no missing space, that's a valid gcc option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67069
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67069
Bug ID: 67069
Summary: ld: fatal: file .libs/lto-plugin.o: wrong ELF class:
ELFCLASS32 during gcc compilation on Solaris 10 x86-64
Product: gcc
Version: 5.2.0
Status: UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066
--- Comment #3 from Jonathan Wakely ---
Are you playing "use as many configure options as possible"?
Most of those options are on by default anyway, others don't do anything.
I'm pretty sure --enable-libstdcxx-time is redundant on darwin.
--en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066
--- Comment #2 from Jonathan Wakely ---
Don't use --enable-concept-checks
It enforces C++03 semantics, so doesn't really make much sense these days.
Maybe I'll remove the option.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #6 from Daniel Gutson
---
Please discard my previous comment, I read too fast.
I'll do some debugging and get back with some analysis.
It seems that cxx_mark_addressable() is wrongly called.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67068
Bug ID: 67068
Summary: Ambiguous interfaces generated when including open mip
fortran header
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
Alex Lai changed:
What|Removed |Added
Summary|#error -static-libstdc++|"Trouble closing elf file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67067
Bug ID: 67067
Summary: #error -static-libstdc++ not implemented
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
Daniel Gutson changed:
What|Removed |Added
CC||daniel.gutson@tallertechnol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #15 from Richard Biener ---
For both loads and stores we do
else if (DR_MISALIGNMENT (first_dr) == -1)
{
TREE_TYPE (data_ref)
= build_aligned_type (TREE_TYPE (data_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #14 from rguenther at suse dot de ---
On Thu, 30 Jul 2015, rearnsha at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
>
> Richard Earnshaw changed:
>
>What|Removed |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
hannes_weisbach at gmx dot net changed:
What|Removed |Added
CC||hannes_weisbach at gmx do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Earnshaw changed:
What|Removed |Added
Component|target |tree-optimization
--- Comment #12 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521
--- Comment #8 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Eric Gallager from comment #5)
> > this one; I think I had to pass the '--disable-libstdcxx-filesystem-ts' flag
> > to configure last time to get p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57271
--- Comment #11 from Mark H Weaver ---
FYI, there's now a suggested fix for bug #66917. It would be interesting to
know whether it fixes the problem reported here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066
--- Comment #1 from Eric Gallager ---
Created attachment 36092
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36092&action=edit
(compressed) preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67066
Bug ID: 67066
Summary: libstdc++-v3/src/filesystem/dir.cc fails to compile,
preventing bootstrapping with libstdcxx-filesystem-ts
Product: gcc
Version: 6.0
Status: UNCONF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #11 from Oleg Endo ---
(In reply to John Paul Adrian Glaubitz from comment #10)
>
> Looking at the build log, it's only gcc/real.o where the comparison fails,
> all the others (except for the checksum files) are find. I think chances
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766
--- Comment #4 from Dominique d'Humieres ---
The patch in comment 3 fixes the PR without regression, as well as pr61676,
pr63494, and pr66562 (duplicates?).
Note that patches should be posted to gcc-patc...@gcc.gnu.org and for gfortran
to fort.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521
--- Comment #7 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #5)
> this one; I think I had to pass the '--disable-libstdcxx-filesystem-ts' flag
> to configure last time to get past it... I'll open a new PR about it.
Please do,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521
--- Comment #6 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #2)
> (CC-ing someone on a bug doesn't count as contacting them directly, right?
> Just making sure I'm not violating that line from MAINTAINERS...)
Right, you did t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
Jonathan Wakely changed:
What|Removed |Added
Keywords||accepts-invalid
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67052
--- Comment #3 from Richard Biener ---
This means that the ABS_EXPR < 0 code is correct in simplifying
NaN < 0 to true and it is correct to _not_ simplify NaN >= 0 to true.
But at the same time it has to do the same as fold_relational_const and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67065
Bug ID: 67065
Summary: Missing diagnostics for ill-formed program with main
variable instead of function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from Richard Biener
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790
--- Comment #6 from Pierre-Marie de Rodat ---
Thanks for your answer, Richard!
(In reply to Richard Biener from comment #5)
> So what is the issue with replacing zero-extending an uninitialized %ebp
> with a random other value? Both are essenti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67063
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67002
--- Comment #10 from John Paul Adrian Glaubitz ---
(In reply to Oleg Endo from comment #9)
> Not sure if this is a good idea.
I actually think it is the best option as chances are dim otherwise that we
find what's actually causing this register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
--- Comment #20 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jul 30 08:53:48 2015
New Revision: 226389
URL: https://gcc.gnu.org/viewcvs?rev=226389&root=gcc&view=rev
Log:
Backport from mainline:
2015-07-17 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66891
--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Thu Jul 30 08:53:48 2015
New Revision: 226389
URL: https://gcc.gnu.org/viewcvs?rev=226389&root=gcc&view=rev
Log:
Backport from mainline:
2015-07-17 Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63304
--- Comment #22 from Ramana Radhakrishnan ---
(In reply to David Abdurachmanov from comment #21)
> I am on vacations now, but I already marked this on my TODO list. Once I
> find a free time slot I will give it a spin. I will try to report in a f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63679
--- Comment #36 from rguenther at suse dot de ---
On Wed, 29 Jul 2015, alalaw01 at gcc dot gnu.org wrote:
> but also feel that those two statements hashing differently is not really
> helpful!
Well, it still uses hash_tree_expr (now 'add_expr')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65706
Andreas Herrmann changed:
What|Removed |Added
CC||andreash87 at gmx dot ch
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
--- Comment #11 from Richard Biener ---
Suggested fix:
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 226348)
+++ gcc/config/arm/arm.c(working cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |target
--- Comment #10 from Richard Bie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67053
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66917
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.4
Summary|[4.9/5/6 regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67064
--- Comment #3 from Andrew Pinski ---
(In reply to Sebastian Huber from comment #2)
> Indeed -std=gnu++98 gets rid of this error. So this is working as intended
> for C++11 and later? This is really nice in combination with defines and
> macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67053
--- Comment #2 from Richard Biener ---
Author: rguenth
Date: Thu Jul 30 07:09:20 2015
New Revision: 226384
URL: https://gcc.gnu.org/viewcvs?rev=226384&root=gcc&view=rev
Log:
2015-07-30 Richard Biener
PR middle-end/67053
* mat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67060
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.0
89 matches
Mail list logo
