http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57766
Balaji V. Iyer changed:
What|Removed |Added
CC||bviyer at gmail dot com
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57794
Bug ID: 57794
Summary: using keyword for function alias doesn't work with
plus suffix return type
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: norma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57793
Bug ID: 57793
Summary: Cross-Compiler Templates and Bitfields Ask to Report
Problem
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792
Bug ID: 57792
Summary: --with-native-system-header-dir confuses -isysroot
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57753
--- Comment #4 from Jack Howarth ---
Actually, FSF gcc doesn't know about the SDKROOT path that xcrun sets. A change
similar to…
http://permalink.gmane.org/gmane.comp.compilers.clang.scm/56103
needs to be implemented on darwin so that FSF checks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57766
--- Comment #1 from Hans-Peter Nilsson ---
Looks like the same situation as PR57692.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #14 from Mikael Pettersson ---
(In reply to Bernd Edlinger from comment #13)
> Created attachment 30431 [details]
> another example of wrong compilation
>
> This is another example where the optimization can
> go wrong.
>
> The attac
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
--- Comment #13 from Bernd Edlinger ---
Created attachment 30431
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30431&action=edit
another example of wrong compilation
This is another example where the optimization can
go wrong.
The attached
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #12 from M.S. Babaei ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to M.S. Babaei from comment #8)
> > But this is a bug, and I see no reason why it hasn't been fixed anyway.
>
> I see plenty of reasons: It is a o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #11 from M.S. Babaei ---
(In reply to James Kanze from comment #9)
> Re using the init list syntax: it won't work if you have to be compatible
> with other compilers (like Sun CC). Using something like (Doh (x)), ++x
> seems to be the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57765
AaronNGray changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #8 from Julian Ospald ---
tested with gcc-4.7.3, and it works as well
for clarification: the previous test was with 4.8.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #7 from Julian Ospald ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 30425 [details]
> gcc49-pr5.patch
>
> Untested fix.
I have tested that patch on gcc-4.8 and was able to compile the python module
successf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
Andy Lutomirski changed:
What|Removed |Added
Summary|rejected valid |Invalid specializations of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #7 from Daniel Krügler ---
(In reply to Andy Lutomirski from comment #4)
> Daniel, I'm unconvinced that your interpretation is the intended one.
Well, [temp.spec] p5 says more strongly that an explicit instantiation shall
only follow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787
--- Comment #1 from Andrew Pinski ---
The first one you cannot do because of error messages that could be outputted.
The second one looks correct. Again patches should be sent to gcc-patches@.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57788
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57791
Bug ID: 57791
Summary: Waste work in gfc_check_pointer_assign()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57789
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57790
Bug ID: 57790
Summary: Waste work in can_move_insns_across()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57789
Bug ID: 57789
Summary: Waste work in repo_emit_p()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57788
--- Comment #1 from Po-Chun Chang ---
(In reply to Po-Chun Chang from comment #0)
> Created attachment 30427 [details]
> Suggested patch
>
> The problem appears in revision 200588 in version 4.9. I have attached a
> one-line patch that fixes it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57788
Bug ID: 57788
Summary: Waste work in maybe_deduce_size_from_array_init
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57787
Bug ID: 57787
Summary: Waste work in ix86_valid_target_attribute_inner_p()
and ix86_pad_returns()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: norma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |4.7.4
Summary|Python module fa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57363
Richard Henderson changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57786
Bug ID: 57786
Summary: Waste work in distribute_notes()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #6 from Andy Lutomirski ---
Jonathan Wakely wrote in comment #4:
> (In reply to Andy Lutomirski from comment #4)
>> [temp.explicit].4 says "A declaration of [list including member function]
>> ... A definition of [list not including me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #21 from Vittorio Zecca ---
If the cost is the same, this is a good reason to let the library handle this
special case and let the programmer think about his/her business.
Shouldn't system software ease the life of programmers?
Should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #20 from Vittorio Zecca ---
I did try Intel ifort and NAG nagfor, as I already wrote, and also
Solaris sunf90,
and all of them accept complex zero raised to an integer or real power
greater than zero, without raising any exception end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57785
Bug ID: 57785
Summary: DOT_PRODUCT error with constant complex array
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #19 from Harald Anlauf ---
(In reply to Vittorio Zecca from comment #16)
> You are being a little too hard on me, but so be it.
>
> I believe there is only one special case, base==0,
> and that there are only two ifs to put in cpow to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57784
Bug ID: 57784
Summary: GCC inadvertedly truncates source text
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: driver
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57783
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57783
Bug ID: 57783
Summary: Silly instantiation of class template when using
dependent type
Product: gcc
Version: 4.4.7
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
Martin Jambor changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57208
--- Comment #30 from Martin Jambor ---
Author: jamborm
Date: Thu Jun 27 13:49:28 2013
New Revision: 200468
URL: http://gcc.gnu.org/viewcvs?rev=200468&root=gcc&view=rev
Log:
2013-06-27 Martin Jambor
PR lto/57208
* ipa-ref.h (ipa_maybe_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57770
Paolo Carlini changed:
What|Removed |Added
CC||larsmans at gmail dot com
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57781
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57782
Bug ID: 57782
Summary: Waste work in remove_path()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57781
Bug ID: 57781
Summary: g++ 4.7 segfaults on trivial example program
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57780
Bug ID: 57780
Summary: Waste work in subst_dup()
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Ass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57779
Bug ID: 57779
Summary: vector insert fails to diagnose iterators pointing
into *this in debug mode
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: enha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
--- Comment #12 from Jonathan Wakely ---
Yes it will probably work on all platforms using the Itanium exception-handling
ABI, unless the OS's pthread_create (or equiv) has explicit exception-handling.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57701
--- Comment #5 from sqweek ---
Hahaha, that amuses me probably more than it should! Thanks for chiming in
Hans, it would have taken me forever to figure that out :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57778
--- Comment #1 from Tobias Burnus ---
Additionally, I wonder whether one wants to have a means to require an explicit
interface, i.e. not just an explicit EXTERNAL (with implicit interface).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57778
Bug ID: 57778
Summary: Missing warning for -Wimplicit-procedure for dummy
arguments
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: diagnostic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #9 from James Kanze ---
Re using the init list syntax: it won't work if you have to be compatible with
other compilers (like Sun CC). Using something like (Doh (x)), ++x seems to be
the most portable work-around.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #13 from Pierre Ossman ---
This was tested using gcc 4.7.2 and gcc 4.5.3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #12 from Pierre Ossman ---
Created attachment 30420
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30420&action=edit
Makefile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53083
--- Comment #11 from Pierre Ossman ---
Created attachment 30419
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30419&action=edit
main.c
We've also been hitting this, so here is a reduced test case to provoke the
bug. Output in the failing ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Julian Ospald changed:
What|Removed |Added
CC||julian.ospald at googlemail
dot co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
--- Comment #11 from Yuri Aksenov ---
> Where is that guaranteed? Where is it implemented?
And here is stack trace of patched version, it seems to be implemented in
__cxxabiv1::__cxa_throw
(gdb) bt
#0 0x7703ad25 in __GI_raise (sig=sig@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #8 from M.S. Babaei ---
(In reply to Jonathan Wakely from comment #7)
> You can use list-initialization to workaround it:
>
> Doh{x}, ++x;
Thanks for the reply. Yeah, it did the trick for GCC 4.4+. And, I've never
thought of that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
--- Comment #10 from Yuri Aksenov ---
OK, [thread.thread.constr]/4 says:
> If the invocation of INVOKE(decay_copy( std::forward(f)),
> decay_copy(std::forward(args))...) terminates with an uncaught
> exception,
> std::terminate shall be called.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57741
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #2 from Jonathan Wakely ---
Please provide preprocessed source of _randommodule.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
--- Comment #9 from Jonathan Wakely ---
P.S. I do want to improve the behaviour, and I think we can make a change for
targets where we know the behaviour is OK, but we need to check carefully that
it works correctly, not just remove the catch(...)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
--- Comment #1 from Dirkjan Ochtman ---
See https://bugs.gentoo.org/show_bug.cgi?id=475482 for more information.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5
Bug ID: 5
Summary: Python module fails compilation with "-march=core-avx2
-O3"
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
--- Comment #8 from Jonathan Wakely ---
(In reply to Yuri Aksenov from comment #7)
> > If it's guaranteed that an uncaught exception leaving that function will
> > still
> > call terminate, then the catch(...) block could be removed. Maybe I cou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #18 from Steve Kargl ---
On Tue, Jul 02, 2013 at 07:21:54AM +, zeccav at gmail dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
>
> --- Comment #16 from Vittorio Zecca ---
> and that there are only two ifs to p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #7 from Jonathan Wakely ---
You can use list-initialization to workaround it:
Doh{x}, ++x;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57746
--- Comment #5 from Jonathan Wakely ---
(In reply to Andy Lutomirski from comment #4)
> Daniel, I'm unconvinced that your interpretation is the intended one.
The definition is also a declaration, see [basic.def] p2, as Daniel pointed
out.
> [te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55917
Yuri Aksenov changed:
What|Removed |Added
CC||yuri.aksenov at gmail dot com
--- Comment
All,
I noticed that files in the c-family directory compiled during stage3 arn't
using -Werror along
with many other Warning flags usually applied during stage3
This to me appears to be because nothing is definng "c-family-warn =
$(STRICT_WARN)" so
any warnings specified as parrt of STRICT_W
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29834
--- Comment #6 from M.S. Babaei ---
Hi,
I'm wondering if this bug is ever going to be fixed?
Unfortunately I don't know C and do not understand how inner parts of GCC
works. But, it's mid 2013 and the bug first appeared on late 2006, with anothe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57762
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57522
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57469
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48786
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57776
Bug ID: 57776
Summary: [4.9 Regression] FAIL: gcc.dg/lto/pr56297
c_lto_pr56297_0.o-c_lto_pr56297_1.o link, -flto
-fno-common (internal compiler error)
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #17 from Dominique d'Humieres ---
> The actual code where the original issue occurred had the exponentiation
> in the deep of nested loops, it would have been rather time consuming
> to test base==0
> at the Fortran level
Sorry, but I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044
--- Comment #7 from Dimitris Papavasiliou ---
I made a patch for this (as well as some other minor features) and submitted it
to the gcc-patches list but, since it was ignored there I'm also attaching it
here in case someone decides to look at it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56044
--- Comment #6 from Dimitris Papavasiliou ---
Created attachment 30417
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30417&action=edit
Proposed patch adding switches controlling ivar scope in Objective-C.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57775
Bug ID: 57775
Summary: default argument for template parameter error for
friend definition in template
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57749
--- Comment #16 from Vittorio Zecca ---
You are being a little too hard on me, but so be it.
I believe there is only one special case, base==0,
and that there are only two ifs to put in cpow to avoid the floating exception
and give the expected r
87 matches
Mail list logo
