https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928
--- Comment #7 from Sean Santos ---
Ah, right. Thinking about it again today, my comment 5 is very confused for
several reasons, and I don't agree with it anymore.
My original interpretation is the only one that makes sense to me again. Namely
"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172
--- Comment #16 from Thomas Preud'homme ---
Hi Richard,
could you expand on what you said in comment #13? I don't see how reassoc could
help cse here. From what I understood, reassoc tries to group per rank. In our
case, we have (view of the sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #14 from Hideaki Kimura ---
(In reply to Jonathan Wakely from comment #13)
> This means you are waiting on an object that has gone out of scope. WIthout
> more information it's not possible to tell if this is a bug in your program
> o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
Cary Coutant changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #15 from Cary Coutant ---
Author: ccoutant
Date: Thu May 15 00:34:20 2014
New Revision: 210456
URL: http://gcc.gnu.org/viewcvs?rev=210456&root=gcc&view=rev
Log:
Change -g so that it will override -g1 but not -g3.
Backported from tru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57836
--- Comment #2 from David Edelsohn ---
The affect of deligitimize_address on storing constants in the TOC vs
materializing inline was unintentional, but my JIT experiments on POWER7 did
not show a bad performance affect from materializing inline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #14 from Cary Coutant ---
Author: ccoutant
Date: Wed May 14 21:48:47 2014
New Revision: 210442
URL: http://gcc.gnu.org/viewcvs?rev=210442&root=gcc&view=rev
Log:
Change -g so that it will override -g1 but not -g3.
gcc/
PR deb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001
--- Comment #5 from Hans-Peter Nilsson ---
Well, it sucks as a failure mode. (User: "*Multiple* definitions? But I
provided *one*! Surely a linker bug/misfeature of some sorts!")
(Note: I'd be totally ok with e.g. compiling memcpy into a recur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58038
--- Comment #8 from Matthew Lai ---
Here is another case where this bug caused a hard-to-find problem -
http://stackoverflow.com/questions/17574287/boostthread-attributes-setting-call-stack-size
(last comment)
Since a patch is already available
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969
--- Comment #18 from Richard Henderson ---
(In reply to H.J. Lu from comment #17)
That's probably the best solution long-term. Sometime before
register allocation (but not too far before) inspect the insn
stream and see what's left.
If we see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61190
Bug ID: 61190
Summary: [4.8/4.9/4.10 Regression]
g++.old-deja/g++.mike/p4736b.C FAILs at -O2/-Os/-O3
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969
--- Comment #17 from H.J. Lu ---
As long as both MMX and X87 registers are available to register allocator,
they may be used at the same time even if MMX usage is disparaged. Can we
disable MMX registers when x87 registers used on a per-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #49 from Dmitry Vyukov ---
> However, my first idea would be that, since libgomp is not sanitized, not all
> races in 'user land' would be detected. I'm just guessing ...
If libgomp does not access user data (which I suspect it does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #48 from Joost VandeVondele
---
(In reply to Roland Schulz from comment #47)
> What is the advantage of a TSAN instrumented libgomp over one with
> --disable-linux-futex?
I would be happy to know that '--disable-linux-futex' is a su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56846
--- Comment #4 from npl at chello dot at ---
I just found the similar entry on launchpad.
I have to recall this from memory, as its been a long time since I played
around with it.
The issue of repeating entries occurs if you have a function wihou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #13 from Richard Henderson ---
(In reply to ccoutant from comment #10)
> Sorry, I'm not sure what "both points" are. Does that mean that you
> would support changing -g so that -g1 -g means -g2, but -g3 -g means
> -g3? (I.e., -g will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #47 from Roland Schulz ---
Using 4.9 and --disable-linux-futex I don't get any false positives. Thus the
problem I saw with 4.8.2 is indeed fixed with 4.9. Thanks!
What is the advantage of a TSAN instrumented libgomp over one with
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60969
Uroš Bizjak changed:
What|Removed |Added
Keywords||ra
Component|target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
--- Comment #11 from Daniel Krügler ---
(In reply to pdaouadi from comment #3)
> Still, if the standard says that it is not allowed we can work around it,
> but then should I file a bug to clang?
I have done so,
http://llvm.org/bugs/show_bug.cg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21631
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20332
Jason Merrill changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
--- Comment #8 from Jonathan Wakely ---
That's correct, and the standard is clear that operator""ms(unsigned long long)
is required to return chrono::milliseconds, not some other equivalent duration
with a different Rep.
So I think the question
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21631
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Wed May 14 16:48:07 2014
New Revision: 210436
URL: http://gcc.gnu.org/viewcvs?rev=210436&root=gcc&view=rev
Log:
PR c++/20332
PR c++/21631
* call.c (reference_binding): Treat l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20332
--- Comment #3 from Jason Merrill ---
Author: jason
Date: Wed May 14 16:48:07 2014
New Revision: 210436
URL: http://gcc.gnu.org/viewcvs?rev=210436&root=gcc&view=rev
Log:
PR c++/20332
PR c++/21631
* call.c (reference_binding): Treat l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61085
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126
Matthias Klose changed:
What|Removed |Added
Summary|[4.8/4.9/4.10 Regression] |[4.10 Regression] gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106
Matthias Klose changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106
--- Comment #15 from Matthias Klose ---
Author: doko
Date: Wed May 14 16:22:20 2014
New Revision: 210434
URL: http://gcc.gnu.org/viewcvs?rev=210434&root=gcc&view=rev
Log:
gcc/
2014-05-14 Matthias Klose
Revert:
2014-05-08 Ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106
--- Comment #14 from Matthias Klose ---
Author: doko
Date: Wed May 14 16:18:12 2014
New Revision: 210432
URL: http://gcc.gnu.org/viewcvs?rev=210432&root=gcc&view=rev
Log:
gcc/
2014-05-14 Matthias Klose
Revert:
2014-05-08 Manuel Lóp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61189
Bug ID: 61189
Summary: ICE with __builtin_return_address() in noexcept lambda
on x86
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61001
Emmanuel Blot changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188
--- Comment #3 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Wed May 14 15:53:11 2014
New Revision: 210429
URL: http://gcc.gnu.org/viewcvs?rev=210429&root=gcc&view=rev
Log:
gcc/
PR debug/61188
* print-rtl.c (print_rtx): Su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61084
--- Comment #9 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Wed May 14 15:42:52 2014
New Revision: 210428
URL: http://gcc.gnu.org/viewcvs?rev=210428&root=gcc&view=rev
Log:
gcc/
PR target/61084
* config/sparc/sparc.md: Fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60897
--- Comment #4 from Martin Jambor ---
Author: jamborm
Date: Wed May 14 15:32:31 2014
New Revision: 210426
URL: http://gcc.gnu.org/viewcvs?rev=210426&root=gcc&view=rev
Log:
2014-05-14 Martin Jambor
PR ipa/60897
* ipa-prop.c (ipa_modif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56176
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58616
Bug 58616 depends on bug 56176, which changed state.
Bug 56176 Summary: ICE with call to synthesized default constructor of inner
struct with NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56176
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56176
--- Comment #3 from Paolo Carlini ---
I'm going to add the reduced testcase and close this as fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
--- Comment #12 from ccoutant at google dot com ---
> FWIW this regresses a few gdb tests. It's easy to fix the
> gdb test suite, but if this is going to be fixed before the
> next gcc release, I'd rather not bother. Any word on that?
I'm plann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61013
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #11 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
--- Comment #7 from Kan Liu ---
(In reply to emsr from comment #6)
> Something like parse_number was in the original doc as an implementation
> example. The idea was to select the smallest integral type that could
> accommodate the number string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #11 from Jeffrey A. Law ---
Right, and that's the case I'm still pondering.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #10 from Jakub Jelinek ---
Sure, there, or merge_def_and_ext, or combine_reaching_defs.
In any case, what I'm afraid of is that when there are two extensions, you in
the first round verify that a copy is suitable and so is the new ext
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094
--- Comment #9 from Jeffrey A. Law ---
Just starting to look at this, but my first thought is to validate the copy in
combine_set_extension. We can still abort the transformation at that point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
--- Comment #10 from pdaou...@aldebaran-robotics.com ---
(In reply to Daniel Krügler from comment #9)
> I don' think that this specialization can - according to the language -
> remove const qualifiers of function types, because there is no
> cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #7 from Andrew Macleod ---
Thats part of the fun. There is little rhyme nor reason to what includes what
right now.. it was purely demand driven over many years. For your current
purposes, gimple.h and tree.h were the primary accumu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61166
--- Comment #6 from emsr at gcc dot gnu.org ---
Something like parse_number was in the original doc as an implementation
example. The idea was to select the smallest integral type that could
accommodate the number string with. This is done with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866
Uroš Bizjak changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61090
Martin Jambor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188
--- Comment #2 from Rainer Orth ---
Created attachment 32797
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32797&action=edit
-fcompare-debug dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188
--- Comment #1 from Rainer Orth ---
Created attachment 32796
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32796&action=edit
-fcompare-debug dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61188
Bug ID: 61188
Summary: [4.10 regression] Many -fcompare-debug failures
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61187
Bug ID: 61187
Summary: valgrind errors if stdin is closed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #6 from Matthias Klose ---
Am 14.05.2014 14:21, schrieb amacleod at redhat dot com:
> btw, the long term plan is that #include "gimple.h" will get all the basic
> prerequisites you need to manipulate gimple. And then you just #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #5 from Andrew Macleod ---
btw, the long term plan is that #include "gimple.h" will get all the basic
prerequisites you need to manipulate gimple. And then you just #include any
extras your specific task requires. We're just in a tra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866
Andrey Belevantsev changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
../src/trunk/configure --prefix=/home/dcb/gcc/results
--enable-checking=release --enable-languages=c,c++,fortran --disable-werror
Thread model: posix
gcc version 4.10.0 20140514 (experimental) (GCC)
[dcb@zippy4 testsuite]$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #4 from Andrew Macleod ---
We have to flatten it before we can fix it... its a complete dependency mess.
you could create a plugin-includes.h which includes all the files from the
primary globbing files that were flattened (gimple.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60866
--- Comment #4 from Andrey Belevantsev ---
Author: abel
Date: Wed May 14 12:09:02 2014
New Revision: 210420
URL: http://gcc.gnu.org/viewcvs?rev=210420&root=gcc&view=rev
Log:
PR rtl-optimization/60866
* sel-sched-ir (sel_init_new_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
--- Comment #9 from Daniel Krügler ---
(In reply to Jonathan Wakely from comment #7)
> And Boost. I have to wonder why their remove_const is so much more
> complicated than ours:
>
> template
> struct remove_const
> { typedef _Tp t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
--- Comment #8 from Daniel Krügler ---
(In reply to Paolo Carlini from comment #6)
> I'm adding Daniel in CC, maybe he has a something to say. To be safe, I'm
> also tentatively marking this as a regression.
I agree with Jason as well for the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
--- Comment #7 from Jonathan Wakely ---
(In reply to pdaouadi from comment #3)
> Still, if the standard says that it is not allowed we can work around it,
> but then should I file a bug to clang?
And Boost. I have to wonder why their remove_cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #13 from Jonathan Wakely ---
(In reply to Hideaki Kimura from comment #11)
> Hi, I'm also (seemingly) hitting this issue.
> When I run my program with valgrind, I get what Thomas reported.
>
> ==22319== Invalid read of size 4
> ==223
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904
--- Comment #4 from wangzheyu ---
Hi christophe,
It's ok from my side, the link time is ok. I'm not sure if it's related to your
tool chain version, but would you please provide detailed information of your
toolchain, the cmd you run for the test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928
--- Comment #6 from Jakub Jelinek ---
Array sections are only allowed in depend, map, from and to clauses, other
clauses work only with whole variables, not just portions thereof.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60928
--- Comment #5 from Sean Santos ---
Well, I thought I understood this, but maybe not.
I was thinking that "subobject" in this context meant "component". A "list
item" here is just any variable or common block listed in a clause, in this
case the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185
--- Comment #3 from Jakub Jelinek ---
But, if you want to use the source type before this conversion, make sure to
also
test stuff like:
int
main ()
{
unsigned long long l = 0x0001ULL;
volatile int u = 9;
u <<= l;
return 0;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185
--- Comment #2 from Jakub Jelinek ---
IMHO not a bug. The compiler really uses (int) (i - j) as the shiftcount, and
that is negative.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |4.10.0
--- Comment #1 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
--- Comment #3 from Marek Polacek ---
(In reply to Vittorio Zecca from comment #2)
> I found this one with -fsanitize=shift. The runtime error message says
> "shift exponent -8 is negative". Maybe this is also a sanitizer bug?
Yeah, I opened PR6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61185
Bug ID: 61185
Summary: Wrong value in error message
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901
Andrey Belevantsev changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60901
--- Comment #4 from Andrey Belevantsev ---
Author: abel
Date: Wed May 14 09:46:26 2014
New Revision: 210414
URL: http://gcc.gnu.org/viewcvs?rev=210414&root=gcc&view=rev
Log:
PR rtl-optimization/60901
* config/i386/i386.c (ix86_dependenci
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61182
Paolo Carlini changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61184
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61176
--- Comment #2 from Matthias Klose ---
is this about stability? With trying, you find out that the following will
work:
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100
Kostya Serebryany changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100
--- Comment #3 from Yury Gribov ---
Kostya, please check if this works for you. Also you'll probably want to update
the file list in the upcoming patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61100
--- Comment #2 from ygribov at gcc dot gnu.org ---
Author: ygribov
Date: Wed May 14 08:33:45 2014
New Revision: 210413
URL: http://gcc.gnu.org/viewcvs?rev=210413&root=gcc&view=rev
Log:
2014-05-14 Yury Gribov
PR sanitizer/61100
* Makef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60981
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60966
--- Comment #12 from Thomas Sanchez ---
Hi Hideaki,
I was able to workaround the bug by using boost promise instead of the STL one.
I did not have the time to investigate the bug however, I'm not really familiar
with the STL design :(
Here is w
86 matches
Mail list logo
