http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53425
jbeulich at novell dot com changed:
What|Removed |Added
CC||jbeulich at novell dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
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.
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Summary|I/O: Problem with formatted |I/O: Problem
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
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
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=57633
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
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=57630
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635
--- Comment #1 from vijay Nag vijunag at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57630
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Attachment #30315|0 |1
is
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
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=57632
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
CC||jason at
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56977
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57613
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53184
--- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com ---
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 #9 from Paolo Carlini paolo.carlini at oracle dot com ---
... and of course a clearer wording for the warning itself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53394
Richard Earnshaw rearnsha at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16128
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49802
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44604
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51610
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55895
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com ---
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=57334
--- Comment #5 from Jan Hubicka hubicka at gcc dot gnu.org ---
(gdb) p debug_tree (fn-decl)
function_decl 0x77045f00 soap_getindependent
type function_type 0x77042e70
type integer_type 0x76f155e8 int public SI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #182 from Jan Hubicka hubicka at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53211
--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53950
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
Status|WAITING |NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #183 from Jan Hubicka hubicka at gcc dot gnu.org ---
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773
--- Comment #5 from Alan Hourihane alanh at fairlite dot co.uk ---
any news ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
Harald Anlauf anlauf at gmx dot de changed:
What|Removed |Added
CC||anlauf at gmx dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Bug ID: 57638
Summary: warning container: 'integer_cst’ not supported by
dump_type#type error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
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 about these matters, see the file named
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #14 from Ryo Furue furue at hawaii dot edu ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #15 from Ryo Furue furue at hawaii dot edu ---
(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
is used for some stuff, I 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #16 from Ryo Furue furue at hawaii dot edu ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #17 from Steve Kargl sgk at troutmask dot apl.washington.edu ---
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 furue at
at gmail dot com
--- Comment #7 from Martin Liška marxin.liska at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #8 from Martin Liška marxin.liska at gmail dot com ---
Sorry, comment was not added to related linker kernel bug 57483.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57483
--- Comment #1 from Martin Liška marxin.liska at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334
--- Comment #9 from Martin Liška marxin.liska at gmail dot com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632
--- Comment #3 from Bas Vodde b...@odd-e.com ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57633
--- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #18 from Ryo Furue furue at hawaii dot edu ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628
--- Comment #19 from Ryo Furue furue at hawaii dot edu ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57604
Vladimir Makarov vmakarov at redhat dot com changed:
What|Removed |Added
CC||vmakarov at
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:
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=30317action=edit
Add declarator_p to checks to trigger warning.
Testing this fully but I think this
54 matches
Mail list logo
