http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682
Bug ID: 57682
Summary: Uniform initialization syntax rejected in
function-try-block
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #8 from Allan McRae ---
I really have no idea what I am looking for... but adding a breakpoint at
linemap_add I see (reason, file):
LC_ENTER "foo.c"
LC_RENAME ""
LC_ENTER "/usr/include/stdc-predef.h"
LC_LEAVE 0x0
LC_RENAME "foo.c"
<-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52483
--- Comment #4 from Oleg Endo ---
Loads from volatile mems have been fixed on 4.9 trunk.
While working on it I noticed that stores to volatile mems have basically the
same issue. I'll try to come up with a fix for that, too.
http://gcc.gnu.org/v
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57683
Bug ID: 57683
Summary: Parallel build failure: generated prerequisite header
not built in time (insn-opinit.h)
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57683
Nicolas Hannekum changed:
What|Removed |Added
CC||nix at binaryboy dot net
Sev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682
--- Comment #2 from Paolo Carlini ---
Something is already going wrong as early as
cp_parser_save_member_function_body: at line #22818 the whole
function-try-block is not properly handled in case of uniform initialization
syntax, apparently becaus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
--- Comment #18 from Manuel López-Ibáñez ---
(In reply to David Binderman from comment #17)
> (In reply to Daniel Marjamäki from comment #7)
> > In my experience this type of check is really noisy if there is a warning
> > for every fall through.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #10 from Manuel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
Bug ID: 57684
Summary: [c++11] Lambda is not convertible to std::function
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
Dominique d'Humieres changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #11 from Allan McRae ---
Created attachment 30345
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30345&action=edit
log of gdb session
Here is the log from my gdb session.
Arch builds with no patches, just a could of small sed li
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
--- Comment #1 from Jonathan Wakely ---
I think the problem is that unordered_map requires its template arguments to be
complete at the time of instantiation, otherwise it's undefined behaviour.
When the static member is instantiated the type Der
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
--- Comment #2 from Francesco Biscani ---
(In reply to Jonathan Wakely from comment #1)
> I think the problem is that unordered_map requires its template arguments to
> be complete at the time of instantiation, otherwise it's undefined behaviour.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #25 from Jan Hubicka ---
Updated patch.
Honza
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652
Chung-Ju Wu changed:
What|Removed |Added
CC||jasonwucj at gmail dot com
--- Comment #19 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
--- Comment #3 from Jonathan Wakely ---
Yes, because std::unique_ptr has a special exception that says it can be
instantiated with incomplete types, so that should work OK (like your case
where the static member is a raw pointer, which prevents un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #6 from Francois-Xavier Coudert ---
The current patch is also lacking handling of the sign if signed zero is used.
This should do the trick:
if (mpfr_sgn (x->value.real) == 0)
{
- mpfr_set_ui (result->value.real, 0, GFC_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #7 from Francois-Xavier Coudert ---
I forgot in the last comment to say: handling of sign for non-zero cases, in
old MPFR versions, is done by this line which was missing in the existing code:
+ mpfr_copysign (result->value.real, re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
--- Comment #4 from Francesco Biscani ---
(In reply to Jonathan Wakely from comment #3)
> Yes, because std::unique_ptr has a special exception that says it can be
> instantiated with incomplete types, so that should work OK (like your case
> where
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Statu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57684
--- Comment #5 from Jonathan Wakely ---
The standard says it is undefined to instantiate any std template with
incomplete types (with exceptions for shared_ptr and unique_ptr and maybe a few
others). As an extension libstdc++ allows all container
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #8 from Dominique d'Humieres ---
Before going to the machinery in comment #6, the following patch (i.e., without
any mpfr_copysign)
--- ../_clean/gcc/fortran/simplify.c2013-06-08 21:50:33.0 +0200
+++ gcc/fortran/simplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54012
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57682
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #12 from Manuel López-Ibáñez ---
(In reply to Allan McRae from comment #11)
> Created attachment 30345 [details]
> log of gdb session
>
> Here is the log from my gdb session.
>
> Arch builds with no patches, just a could of small sed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57653
--- Comment #13 from Allan McRae ---
The Arch gcc does the full bootstrap. The debug build I am using was compiled
with DEBUG_CFLAGS="-g -fvar-tracking-assignments".
The file "/usr/include/stdc-predef.h" is from glibc (v2.17 on Arch) and is
spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46299
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46271
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #9 from Francois-Xavier Coudert ---
> Before going to the machinery in comment #6, the following patch (i.e.,
> without any mpfr_copysign)
Yep, you're right, no need for mpfr_copysign. Your patch looks good, if we
don't want to introd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46485
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: antoine.balestrat at gmail dot com
Hello !
Using GCC 4.9.0 as of 20130623 :
$ cat inf.c
unsigned f(void)
{
unsigned a;
int b, c, d, e;
for(c = 27; c < 40; c++)
b |= d |= b;
if(b)
a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41604
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423
--- Comment #36 from Oleg Endo ---
This is annoying:
int
foo (int tab[], int index)
{
return tab[index+1] + tab[index+2];
}
-O2 -m4 -mb:
add #1,r5
mov r4,r1
shll2 r5
add r5,r1
mov r5,r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50550
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Here is a simple patch to accept the code in comment 0:
... which unfortunately introduces a large amount of ICEs in the testsuite,
e.g. on bounds_check_7.f90:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #10 from Dominique d'Humieres ---
Here is the patch I plan to package and submit:
--- ../_clean/gcc/fortran/simplify.c2013-06-08 21:50:33.0 +0200
+++ gcc/fortran/simplify.c2013-06-23 17:19:55.0 +0200
@@ -2342,1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #11 from Dominique d'Humieres ---
Last question: should I include some tests for the other available kinds?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #12 from Francois-Xavier Coudert ---
(In reply to Dominique d'Humieres from comment #10)
> + y=fraction (-2.0)
> + write (buf, *) y
> + if (buf(1:10) /= " -0.50") call abort ()
Why involve I/O in your test, and not just test t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686
Bug ID: 57686
Summary: FAIL: gcc.dg/torture/pr57584.c with -m32
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsui
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
Bug ID: 57687
Summary: FAIL: c-c++-common/cilk-plus/AN/comma_exp.c on
x86_64-apple-darwin10
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52413
--- Comment #13 from Dominique d'Humieres ---
> Why involve I/O in your test, and not just test the value like that:
>
> if (fraction(-2.0) /= -0.5) call abort()
>
> and, slightly more complicated to handle negative zero, checking both
> value
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Created attachment 30347
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30347&action=edit
C++ source code
I just noticed that -march=native support broke from
date 20130621 to 20130623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
--- Comment #1 from Mikael Pettersson ---
Run it in gdb, wait for the fault, and disassemble the code around the faulting
PC. That valgrind report doesn't really say anything useful.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
Paolo Carlini changed:
What|Removed |Added
Component|c++ |target
--- Comment #2 from Paolo Carlini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
--- Comment #1 from Paolo Carlini ---
On x86_64-linux, c-c++-common/cilk-plus/AN/gather_scatter.c fails, not sure if
it's a related issue or I should open a Bugzilla. See also gcc-testresults.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42945
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
--- Comment #2 from Dominique d'Humieres ---
> On x86_64-linux, c-c++-common/cilk-plus/AN/gather_scatter.c fails,
> not sure if it's a related issue or I should open a Bugzilla.
> See also gcc-testresults.
AFAICT the failures for comma_exp.c ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
--- Comment #4 from David Binderman ---
(In reply to Mikael Pettersson from comment #1)
> Run it in gdb, wait for the fault, and disassemble the code around the
> faulting PC. That valgrind report doesn't really say anything useful.
0x000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
--- Comment #5 from Andrew Pinski ---
Can you provide the full output of "cat /proc/cpuinfo" and not just the head?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
--- Comment #6 from David Binderman ---
Created attachment 30348
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30348&action=edit
preprocessed C++ source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57685
--- Comment #2 from Mikael Pettersson ---
Started with the PR55079 fix in r193098.
The test case uses the values of uninitialized auto variables, perhaps that's
confusing the compiler.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
--- Comment #7 from David Binderman ---
(In reply to Andrew Pinski from comment #5)
> Can you provide the full output of "cat /proc/cpuinfo" and not just the head?
processor: 0
vendor_id: AuthenticAMD
cpu family: 16
model: 4
m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
--- Comment #8 from David Binderman ---
(In reply to Jakub Jelinek from comment #3)
> Also, for any bugreport with -march=native or -mtune=native you need to
> specify what options have been passed to cc1plus/cc1 (add -v), plus you
> haven't provi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57689
Bug ID: 57689
Summary: [4.8 Regression] ICE (segfault) building libgo on
ia64-linux-gnu
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57688
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57690
Bug ID: 57690
Summary: bextr sometimes used instead of shr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57691
Bug ID: 57691
Summary: freestanding libstdc++ has compile error
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
Shane changed:
What|Removed |Added
CC||w.shane.grant at gmail dot com
--- Comment #16 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57639
--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> The following patch fixes both variants:
... and regtests cleanly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57692
Bug ID: 57692
Summary: FAIL: c-c++-common/cilk-plus/AN/gather_scatter.c
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57687
Dominique d'Humieres changed:
What|Removed |Added
Version|unknown |4.9.0
--- Comment #3 from Dominiqu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #7 from Bernd Edlinger ---
aehmm sorry, the object "g" from above code is actually from PR#48784
#pragma pack(1)
volatile struct S0 {
signed a : 7;
unsigned b : 28;
} g = {0,-1};
=> sizeof(g) = 5
but the code from this example
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51213
--- Comment #17 from Paolo Carlini ---
But this example works in mainline (would be 4.9.0) and I don't think it's a
regression.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #3 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46982
--- Comment #4 from Dominique d'Humieres ---
> ... So I think that the code in comment #0 is not legal.
Then, should not this PR closed as INVALID?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997
--- Comment #8 from Sandra Loosemore ---
Thanks for giving it a try. Do you think that in a case such as this where a
single access of the appropriate size cannot be generated due to the struct
having unaligned fields we should generate the same
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57686
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958
--- Comment #14 from Joost VandeVondele
---
(In reply to Janne Blomqvist from comment #13)
I believe a lot of progress has been made indeed.
> However, the fundamental(?) issue of module sizes growing exponentially with
> deep module hierarchie
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606
Dominique d'Humieres changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #8 from Dominique
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267
Dominique d'Humieres changed:
What|Removed |Added
Status|ASSIGNED|NEW
--- Comment #6 from Dominique
76 matches
Mail list logo
