http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57640
--- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> ---
Created attachment 30317
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30317&action=edit
Add declarator_p to checks to trigger warning.
Testing this fully but I think this
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57640
Bug ID: 57640
Summary: Explicit call of system literal operator complains
about leading underscore.
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #19 from Ryo Furue ---
(In reply to Ryo Furue from comment #18)
Sorry again. I made English error.
> > Yeah, I get it. You don't like the choice that gfortran
> > made 10+ years ago.
>
> Not quite.
I meant, You are not quite rig
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #18 from Ryo Furue ---
(In reply to Steve Kargl from comment #17)
> > real, parameter:: a = -1.0
> > if (a > 0) write(*,*) sqrt(a)
> >
> > With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN
> > and
> > le
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
--- Comment #4 from Jerry DeLisle ---
We need to audit all places where '\n' is used and make sure we are taking care
of the '\r' properly in read.c , etc.
Then review what were are doing when we get a premature end of record.
Maybe we are skipp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
--- Comment #3 from Bas Vodde ---
Thanks for the comments. I understand the problems in implementing a compiler,
when this is also unclear in the language itself.
Whatever is decided related to this, it would probably be a good idea to give a
be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #9 from Martin Liška ---
Simple error case:
/tmp/x.c
char dnet_ntoa();
int main() {
dnet_ntoa()
; return 0; }
gcc -flto /tmp/x.c
Result:
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #1 from Martin Liška ---
gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #8 from Martin Liška ---
Sorry, comment was not added to related linker kernel bug 57483.
#7 from Martin Liška ---
gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto-symtab.c:644
0x50afe4 lto_fixup_prevailing_decls
../../gcc/lto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #17 from Steve Kargl ---
On Mon, Jun 17, 2013 at 10:07:32PM +, furue at hawaii dot edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
>
> --- Comment #16 from Ryo Furue ---
> (In reply to Steve Kargl from comment #12)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #16 from Ryo Furue ---
(In reply to Steve Kargl from comment #12)
> On Sun, Jun 16, 2013 at 11:33:49PM +, furue at hawaii dot edu wrote:
> >
> > Is this an inconsistency in the implementation of -no-range-check ?
>
> No.
Then, w
used just bfd in my
compilation).
gcc --version:
gcc (GCC) 4.9.0 20130617 (experimental)
I finally reached WPA stage of LTO, memory usage was about 8GB for ld and 11 GB
for lto1.
lto1 was running for about 20 minutes and following error occured:
lto1: error: ELF section name out of range
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #15 from Ryo Furue ---
(In reply to Harald Anlauf from comment #13)
Hi Harald,
Thanks for your message.
> I would also prefer if gfortran behaved as you suggested.
> Other compilers appear to generate warnings only, or no comment.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #14 from Ryo Furue ---
(In reply to Steve Kargl from comment #11)
> > Overall, I think this kind of thing is better be a "warning" and that at
> > least
> > the compiler should allow the user to run such a code as this. The result
ortran --version
GNU Fortran (GCC) 4.9.0 20130617 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Bug ID: 57638
Summary: warning container: 'integer_cst’ not supported by
dump_type#
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #13 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773
--- Comment #5 from Alan Hourihane ---
any news ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #183 from Jan Hubicka ---
type merging stats
[WPA] read 43156894 SCCs of average size 2.270660
[WPA] 97994652 tree bodies read in total
[WPA] tree SCC table: size 8388593, 3830511 elements, collision ratio: 0.684487
[WPA] tree SCC max
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53950
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |NEW
Summary|1.5 times s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
--- Comment #4 from Paolo Carlini ---
For comment #1, it looks like there is something wrong in
instantiation_dependent_expression_p: when finish_decltype_type calls it for
arr it returns false, where it seems obvious that it should be true.
This
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #182 from Jan Hubicka ---
OK, after a while I should update the stats here. Richard's new tree merging
patch makes libxul linking a lot faster and less memory consuming.
Peak memory usage (in TOP) is now just bellow 10GB, with bit of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #5 from Jan Hubicka ---
(gdb) p debug_tree (fn->decl)
unit size
align 32 symtab 0 alias set -1 canonical type 0x76f155e8
precision 32 min max
pointer_to_this >
QI
size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
--- Comment #3 from Paolo Carlini ---
The original testcase (in Comment #0) is fixed in 4.8.1 and mainline as
duplicate of PR56794.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55895
Dominique d'Humieres changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #2 from Domini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
Dominique d'Humieres changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #6 from Domini
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16128
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53394
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #9 from Paolo Carlini ---
... and of course a clearer wording for the warning itself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #8 from Paolo Carlini ---
Somebody could suggest an appropriate name for the warning. Then a patchlet
would be easy to do and also easy to approve I think (naming warnings is in
general a sensible idea)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #7 from Jonathan Wakely ---
I've just come across a case where an option to disable that warning would be
handy: We have a foo.cc file defining some classes in an anon namespace. A unit
test does #include "foo.cc" so it can test the im
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57637
Bug ID: 57637
Summary: Miscompare on 178.galgel in SPEC2000 on arm
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
--- Comment #3 from lailavrazda1979 at gmail dot com ---
Looks good to me.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57636
Bug ID: 57636
Summary: cr16: ICE while building libgcc
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek changed:
What|Removed |Added
Attachment #30315|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
--- Comment #1 from vijay Nag ---
Let me know if you will need any additional information. It is also difficult
to isolate one single huge file from my project to attach it here. It will be
great if you can suggest me to proceed in some direction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
Bug ID: 57635
Summary: gcc hanging while compiling huge files
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
--- Comment #2 from Tobias Burnus ---
Another comment, which I missed to pass on from the original report:
It is crucial that the first line ends with a comma; without comma it works.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57634
Bug ID: 57634
Summary: Missed vectorization for a "fixed point
multiplication" reduction
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
Tobias Burnus changed:
What|Removed |Added
Summary|I/O: Problem with formatted |I/O: Problem with formatted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
Bug ID: 57633
Summary: I/O: Problem with formatted read: reading an
incomplete record under Windows
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #5 from Jakub Jelinek ---
Actually, seems the 3 argument Intel intrinsic is _bextr_u{32,64}, while the
GCC
intrinsic is __bextr_u{32,64}, so guess the two can coexist, we just need to
add the 3 argument one.
53 matches
Mail list logo
