http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53934
Bug #: 53934
Summary: Better CPP macro diagnostics
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
Dmitry Bespalov changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53935
Bug #: 53935
Summary: [avr][c++] missing warning for non-const data in
progmem
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53935
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P5
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53933
jaewon ha changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859
Ramana Radhakrishnan changed:
What|Removed |Added
CC||ramana at gcc dot gnu.org
Target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
--- Comment #6 from Dmitry Bespalov 2012-07-12
10:03:14 UTC ---
It really works as expected if put A into some namespace, but it really as well
that implementation differs in Microsoft's VC and GCC. Under VC you always gets
right result, there is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53936
Bug #: 53936
Summary: Adding a PRETTY_ARGUMENT and ARGUMENT_COUNT
macro/variable
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
--- Comment #7 from Jonathan Wakely 2012-07-12
10:09:10 UTC ---
ISO 14882:2011 3.2
"There can be more than one definition of a class type (Clause 9), [...] in a
program provided that each definition appears in a different translation unit,
and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
Bug #: 53937
Summary: Pack'ing struct causes gcc to not recognize that an
field's address is aligned
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
--- Comment #1 from Krzysztof Gongolewski
2012-07-12 10:49:57 UTC ---
Created attachment 27780
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27780
Compiled example code
Assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
--- Comment #8 from Dmitry Bespalov 2012-07-12
10:51:51 UTC ---
Jonathan,
I'm not sure if we're talking about the same thing. You've asked:
<< If that was the case how would you ever use any type (e.g. std::string) in
more
<< than one file, it w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
--- Comment #9 from Dmitry Bespalov 2012-07-12
10:54:31 UTC ---
Correction of typo:
...So I actually do not redefine std::string again, I just USE the type defined
in third file.
Sorry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938
Bug #: 53938
Summary: ARM target generates sub-optimal code (extra
instructions) on load from memory
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53659
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938
Richard Guenther changed:
What|Removed |Added
Target||arm*-*-*
Status|UNCONFIRME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53930
--- Comment #10 from Richard Guenther 2012-07-12
12:18:11 UTC ---
(In reply to comment #9)
> Correction of typo:
> ...So I actually do not redefine std::string again, I just USE the type
> defined
> in third file.
Preprocessing makes the std::s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
--- Comment #3 from Krzysztof Gongolewski
2012-07-12 12:24:42 UTC ---
But the compiler knows address of the struct at compilation time, it's
hard-coded. So gcc knows that both struct and member are perfectly aligned.
If you access only the struc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939
Bug #: 53939
Summary: allows assignment to INTENT(IN) nested component
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: minor
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
Richard Guenther changed:
What|Removed |Added
Keywords||missed-optimization
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940
Bug #: 53940
Summary: warn about duplicate USE
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
Krzysztof Gongolewski changed:
What|Removed |Added
Keywords|missed-optimization |
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941
Bug #: 53941
Summary: "Range-based for" feature is not implemented for
std::pair<>.
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
Krzysztof Gongolewski changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|INVAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53937
Krzysztof Gongolewski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940
--- Comment #2 from Bil Kleb 2012-07-12 13:25:29 UTC
---
I guess I see the USE ONLY as similar to a declaration, and to have two of the
same declarations in a program is an error, e.g.,
$ cat duplicate_declaration.f90 << EOF
program duplicate_de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939
--- Comment #2 from Tobias Burnus 2012-07-12
13:29:08 UTC ---
(In reply to comment #1)
> However, both "elem" and "cl2g" are pointers - thus the "intent(in)" doesn't
> apply. [Or more precisely, for "cl2g" the intent doesn't apply at all (as it
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53939
--- Comment #3 from Bil Kleb 2012-07-12 13:32:07 UTC
---
OK, fair enough (and sincere thanks for taking the time to explain it).
I see that if I change to the more modern ALLOCATABLE declarations, then I get
a warning about assigning to an INTEN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53940
Tobias Burnus changed:
What|Removed |Added
Keywords||diagnostic
Summary|warn about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53941
--- Comment #2 from Maxim Yegorushkin
2012-07-12 14:36:52 UTC ---
Fair enough.
I wasn't sure whether std::pair<> should work as a range, so I went to
http://gcc.gnu.org/gcc-4.7/cxx0x_status.html which refers to
http://www.open-std.org/JTC1/SC22
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919
Erik Schnetter changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423
--- Comment #20 from chrbr at gcc dot gnu.org 2012-07-12 15:36:59 UTC ---
> I'm having a look at your implementation to see how they compare and
> > possibly combined together. Both approaches look interesting.
>
> I guess folding the mul-add sequ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53933
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938
--- Comment #2 from Andrew Pinski 2012-07-12
16:10:09 UTC ---
I think this is the standard volatile vs combine issue.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53919
--- Comment #9 from Andrew Pinski 2012-07-12
16:12:50 UTC ---
I think the install instructions for released versions should never be on the
website and only in the release itself.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53942
Bug #: 53942
Summary: unable to find a register to spill in class 'CREG'
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53943
Bug #: 53943
Summary: Compiler ICE with -fobjc-direct-dispatch flag on Linux
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53944
Bug #: 53944
Summary: Can't catch C++ exception in Objective C
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priorit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53944
Konstantin Osipov changed:
What|Removed |Added
Host||Linux atlas
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53944
--- Comment #1 from Steven Bosscher 2012-07-12
18:23:33 UTC ---
Try obj-c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
--- Comment #8 from Tom Tromey 2012-07-12 18:34:08
UTC ---
I'd like to ping this again.
I've been working on adding support for new and delete to gdb.
The missing debuginfo here is a barrier to this.
I think gdb would generally like to call the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53938
--- Comment #3 from Greg Smith 2012-07-12
19:09:41 UTC ---
(In reply to comment #1)
> Can you verify if the situation improves with GCC 4.7 or current development
> trunk?
I am an end user of the Rowley CrossWorks system and they are not on to 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53945
Bug #: 53945
Summary: Scalar element of assumed-shape dummy array not
recognized as C interoperable
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: U
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53176
--- Comment #25 from Hans-Peter Nilsson 2012-07-12
21:14:19 UTC ---
Author: hp
Date: Thu Jul 12 21:14:14 2012
New Revision: 189441
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189441
Log:
PR rtl-optimization/53176
* rtlanal.c (r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
Bug #: 53946
Summary: gcc emits warning when intmax_t is long long and
format string %jd is used
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
--- Comment #1 from Andrew Pinski 2012-07-12
23:43:17 UTC ---
Looks like you are using the wrong definition for intmax_t .
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
--- Comment #2 from Roger Meyer 2012-07-12 23:44:40
UTC ---
reproducable at least on:
X86_64 using gcc 4.5.1 and 4.5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
Roger Meyer changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
Roger Meyer changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53946
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53845
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51678
--- Comment #3 from Gavin Lambert 2012-07-13
01:36:52 UTC ---
Created attachment 27782
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27782
Proposed fix
Confirmed on mingw32 with MiKTeX.
I've attached a patch which fixes this; basically Te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53908
--- Comment #10 from Hans-Peter Nilsson 2012-07-13
06:53:30 UTC ---
Created attachment 27783
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27783
patch from Richard Sandiford
Updated patch, from http://gcc.gnu.org/ml/gcc-patches/2012-07/msg
61 matches
Mail list logo
