http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #5 from Uros Bizjak 2011-05-04 07:04:50
UTC ---
Created attachment 24176
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24176
Band-aid patch for broken assemblers
You have broken assembler, see Intel instruction set reference, M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863
Summary: A Bug When Assembler Instructions with C Expression
Operands in arm-elf-gcc 4.5
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #7 from Jakub Jelinek 2011-05-04
07:42:55 UTC ---
Does it fix (at least some of) the x32 issues as well? If some (e.g. ICEs) are
left, please post backtraces and other relevant details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
Tobias Burnus changed:
What|Removed |Added
Keywords||rejects-valid
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48834
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48837
--- Comment #8 from Zdenek Dvorak 2011-05-04
08:33:51 UTC ---
Created attachment 24177
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24177
Fix for the issue
Indeed, once the accumulator transformation is performed, the other tail calls
in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48863
Mikael Pettersson changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48864
Summary: -Ofast should imply -fno-protect-parens
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
Summary: gcc hangs when -g is set
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: debug
AssignedTo: unassig...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48749
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865
Summary: It would be useful to have a way to check the value of
a #define at preprocessing time
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48597
--- Comment #13 from Jakub Jelinek 2011-05-04
09:14:07 UTC ---
Author: jakub
Date: Wed May 4 09:14:00 2011
New Revision: 173357
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173357
Log:
Backport from mainline
2011-04-28 Jakub J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48774
--- Comment #15 from Jakub Jelinek 2011-05-04
09:21:15 UTC ---
Author: jakub
Date: Wed May 4 09:21:09 2011
New Revision: 173359
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173359
Log:
Backported from mainline
2011-05-03 Uros
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48809
--- Comment #11 from Jakub Jelinek 2011-05-04
09:19:10 UTC ---
Author: jakub
Date: Wed May 4 09:19:07 2011
New Revision: 173358
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173358
Log:
Backport from mainline
2011-04-30 Jakub J
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48867
Summary: Using the compilation flag -mfpmath=sse breaks Snes9x
build.
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48809
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574
--- Comment #13 from vincenzo Innocente
2011-05-04 10:00:02 UTC ---
is this really fixed?
with gcc version 4.6.1 20110422 (prerelease) (GCC)
the reduced test do compile but
I still get
g++ -c produceICE.ii -std=c++0x -Wall -mavx
In file inclu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #6 from uros at gcc dot gnu.org 2011-05-04 10:05:23 UTC ---
Author: uros
Date: Wed May 4 10:05:20 2011
New Revision: 173361
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173361
Log:
PR target/48860
* config/i386/i386.m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574
Paolo Carlini changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48574
--- Comment #15 from Jakub Jelinek 2011-05-04
10:54:48 UTC ---
Indeed, unlike the reduced testcase, for the original one it triggers during
fold_non_dependent_expr_sfinae which means that processing_template_decl is 0
and thus type_dependent_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851
--- Comment #8 from Richard Guenther 2011-05-04
11:04:28 UTC ---
(In reply to comment #7)
> 0 is a valid null pointer constant in C. If you want to use NULL as a
> sentinel
> you must always cast it.
I'm sure that is something nobody does. Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48842
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-05-04 11:13:24 UTC ---
> --- Comment #1 from Jan Hubicka 2011-05-02 11:54:47
> UTC ---
> I've fixed identical falure happening on HP and AIX. Does it still reproduce
> for you?
Mainl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865
--- Comment #2 from bero at arklinux dot org 2011-05-04 11:16:01 UTC ---
It does - if you know how to read it.
It's easy to tell a student who has never used a compiler outside of an IDE how
to add a #warning -- teaching him how to read the output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48842
Rainer Orth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48864
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48856
--- Comment #8 from Richard Guenther 2011-05-04
11:08:30 UTC ---
Works for me with 4.6.0 and on the tip of the branch on x86_64 with -m32.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
Richard Guenther changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #3 from Jakub Jelinek 2011-05-04
12:07:42 UTC ---
cselib actually. Shorter testcase:
struct S { struct S *d[2]; };
struct S *
foo (struct S *x)
{
struct S *y, *z;
y =
x->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1]->d[1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38634
Paolo Carlini changed:
What|Removed |Added
Keywords|error-recovery, |diagnostic
|ice-checkin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851
--- Comment #9 from Michael Matz 2011-05-04 12:02:44
UTC ---
Also defining NULL as "0" creates problems when passing it to varargs
functions on LP64 platforms, not just for sentinels. As Andreas says, it's a
valid null pointer constant, but a te
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
Lionel GUEZ changed:
What|Removed |Added
CC||ebay.20.tedlap at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865
--- Comment #3 from Jonathan Wakely 2011-05-04
12:11:04 UTC ---
Teach them to how to pipe the output of gcc -E -dD to grep, it'll do them good
in the long run.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859
--- Comment #3 from Jonathan Wakely 2011-05-04
12:33:38 UTC ---
(In reply to comment #0)
>
> The workaround, of course, is to define the empty default constructor in
> ConstMember.
Or simply add an empty new-initializer, which works when you ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
--- Comment #14 from Jason Merrill 2011-05-04
12:38:03 UTC ---
It was discussed on the reflector in messages 15450-3 and 80, but seems never
to have made it into the issues list...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #49 from Thomas Henlich
2011-05-04 12:48:28 UTC ---
(In reply to comment #47)
> (In reply to comment #46)
> > I have started on the second phase of this effort which is to get rid of the
> > floating point issue on -m32 machines.
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #8 from Jack Howarth 2011-05-04
12:52:02 UTC ---
The assembler is from...
Xcode 4.0.2
Build version 4A2002a
but the assembler from...
Xcode 3.2.6
Component versions: DevToolsCore-1809.0; DevToolsSupport-1806.0
BuildVersion: 10M2518
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #7 from Jack Howarth 2011-05-04
12:49:27 UTC ---
Created attachment 24180
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24180
assembly file for libgcc/../gcc/config/soft-fp/extenddftf2.c with -dp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #9 from Jack Howarth 2011-05-04
12:58:41 UTC ---
Opened radr://9381460 with extenddftf2.s generated with -dp as the testcase.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
--- Comment #1 from Ryan Mansfield 2011-05-04
13:01:31 UTC ---
The change that introduced this ICE is rev171033.
http://gcc.gnu.org/viewcvs?view=revision&revision=171033
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
Summary: OpenMP task construct fails to instantiate copy
constructor(same as Bug 36523)
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #48 from jvdelisle at frontier dot com 2011-05-04 12:30:59 UTC ---
On 05/04/2011 05:15 AM, ebay.20.tedlap at spamgourmet dot com wrote:
> --- Comment #47 from Lionel GUEZ
> 2011-05-04 12:15:16 UTC ---
> (In reply to comment #46)
--- s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48868
Summary: There are no -mtls-dialect=gnu2 run-time tests
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
Paolo Carlini changed:
What|Removed |Added
CC||paolo.carlini at oracle dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #10 from Jack Howarth 2011-05-04
13:10:23 UTC ---
Could this be similar to the required change from...
http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01024.html
to adapt to the darwin assembler's usage of movq?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #11 from Uros Bizjak 2011-05-04 13:25:28
UTC ---
(In reply to comment #10)
> Could this be similar to the required change from...
>
> http://gcc.gnu.org/ml/gcc-patches/2010-08/msg01024.html
>
> to adapt to the darwin assembler's usa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #8 from H.J. Lu 2011-05-04 13:33:57
UTC ---
I still got
FAIL: gcc.dg/torture/stackalign/alloca-1.c -O1 (internal compiler error)
FAIL: gcc.dg/torture/stackalign/alloca-1.c -O1 (test for excess errors)
FAIL: gcc.dg/torture/stackal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48859
fabien at gcc dot gnu.org changed:
What|Removed |Added
CC||fabien at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47723
--- Comment #14 from Jason Merrill 2011-05-04
13:42:19 UTC ---
(In reply to comment #10)
> struct S { };
> S* p = new S::S();
EDG 4.0-4.3 all reject this as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #9 from Jakub Jelinek 2011-05-04
14:06:56 UTC ---
Can you track down on which mem_loc_descriptor call these new
DW_OP_GNU_*_type/DW_OP_GNU_{convert,reinterpret}
locs have been added, and for that post a backtrace and debug_rtx on the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48870
Summary: operator== overload of vector types
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassig...@
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
Ryan Mansfield changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48871
Summary: gcc doesn't accept null pointer value as a template
non-type argument
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48866
--- Comment #4 from Jakub Jelinek 2011-05-04
14:21:28 UTC ---
The problem is the MEMs nested in other MEM addresses, cselib isn't prepared to
handle it efficiently.
So, either we should break very deep MEM nests using extra DEBUG_INSNs and
debug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48818
--- Comment #2 from Melanie Cappelaere 2011-05-04
14:19:01 UTC ---
Created attachment 24181
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24181
Example with custom allocator
Thank you for the workaround.
Little side note: this bug also ap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
--- Comment #12 from Jack Howarth 2011-05-04
14:13:04 UTC ---
This looks similar to this bug...
http://www.mail-archive.com/mpir-devel@googlegroups.com/msg04286.html
where is claimed these are bugs in the older gas on darwin.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48871
--- Comment #1 from Jonathan Wakely 2011-05-04
14:37:05 UTC ---
I think this is a dup of PR 10541
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48826
--- Comment #3 from Jakub Jelinek 2011-05-04
14:10:20 UTC ---
Most probably the backend is reordering insns after var-tracking, it shouldn't
be doing that. ARM/SH/S390 backends all have fixed similar bugs very quickly
after this patch went in.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48860
Jack Howarth changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48868
--- Comment #1 from Andrew Pinski 2011-05-04
15:31:21 UTC ---
Can't you run the testsuite with -mtls-dialect=gnu2 to see if there are any
failures?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
Summary: [C++0x][noexcept] Placement-new problem with non-empty
arguments
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #10 from H.J. Lu 2011-05-04 15:37:43
UTC ---
(In reply to comment #9)
> Can you track down on which mem_loc_descriptor call these new
> DW_OP_GNU_*_type/DW_OP_GNU_{convert,reinterpret}
> locs have been added, and for that post a backt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48873
Summary: [C++0x][noexcept] Placement-new problem with deleted
destructors
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48868
--- Comment #2 from H.J. Lu 2011-05-04 15:42:11
UTC ---
(In reply to comment #1)
> Can't you run the testsuite with -mtls-dialect=gnu2 to see if there are any
> failures?
90% of gcc testsuites don't use TLS. Run the whole testsuite with
-mtls-di
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
Jakub Jelinek changed:
What|Removed |Added
Known to work||4.4.6
Target Milestone|---
", REALPART_EXPR ,
IMAGPART_EXPR );
}
return 0;
so it seems the negative sign of the real part of c is lost already in the
frontend.
Version of the compiler:
gcc version 4.7.0 20110504 (experimental) (GCC)
Target: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
--- Comment #3 from rguenther at suse dot de
2011-05-04 15:46:47 UTC ---
On Wed, 4 May 2011, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
>
> Jakub Jelinek changed:
>
>What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #12 from Jan Hubicka 2011-05-04
16:09:19 UTC ---
Hi,
I discussed some of the issues today with Martin. For the array descriptor
testcase, we really want ipa-cp to be propagate the constant array bounds
instead of making Inliner to bl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773
--- Comment #6 from Matthew Fortune 2011-05-04
16:19:32 UTC ---
(In reply to comment #5)
> This is a known issue introduced by the DF merge. I think that the current
> state of affairs is that the passes consuming REG_DEAD/REG_UNUSED notes have
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
--- Comment #1 from joseph at codesourcery dot com 2011-05-04 16:17:12 UTC ---
On Wed, 4 May 2011, jb at gcc dot gnu.org wrote:
> #include
> #include
>
> int main()
> {
> double _Complex a = 0.0 + I*0.0;
> double _Complex b = 0.0 - I*0.0;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
--- Comment #4 from Jakub Jelinek 2011-05-04
16:25:46 UTC ---
Not sure if it would be ok to request instantiation of say copy ctor when we
are unsure if the var will be firstprivate or not. The copy ctor can be marked
as =delete, or perhaps say
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #21 from Marc Glisse 2011-05-04
16:27:28 UTC ---
Created attachment 24182
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24182
first iteration in patch format
Inserted in , with some cleanup of dead code, rewrite of ratio_less.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
--- Comment #5 from Jakub Jelinek 2011-05-04
16:37:40 UTC ---
Say:
template
struct B
{
B () {}
B (const B&) = delete;
~B () {}
};
template
struct A
{
A () {}
A (const A&) { B b; B c = b; }
void foo () {}
~A() {}
};
int
main()
{
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773
--- Comment #7 from Eric Botcazou 2011-05-04
16:38:54 UTC ---
> Can anyone speculate as to which passes consume REG_DEAD notes or is it a case
> of trawling the source? invoking df_note_add_problem in the final pass should
> resolve the bug I hav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773
--- Comment #8 from froydnj at codesourcery dot com 2011-05-04 16:47:52 UTC ---
On Wed, May 04, 2011 at 04:25:19PM +, mfortune at gmail dot com wrote:
> Can anyone speculate as to which passes consume REG_DEAD notes or is it a case
> of trawli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48787
--- Comment #18 from Jerry DeLisle 2011-05-04
16:49:17 UTC ---
Ne patch submitted to list for approval.
http://gcc.gnu.org/ml/fortran/2011-05/msg00022.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48865
--- Comment #4 from Jonathan Wakely 2011-05-04
17:10:49 UTC ---
Or, as I've just done, learn how to do it in your favourite editor. For mine
(vim) it's [i to display the value and [^i to jump to the definition, which
seems at least as good as the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48864
--- Comment #2 from Tobias Burnus 2011-05-04
17:10:20 UTC ---
Author: burnus
Date: Wed May 4 17:10:15 2011
New Revision: 173385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173385
Log:
gcc/
2011-05-04 Tobias Burnus
PR fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
Jakub Jelinek changed:
What|Removed |Added
Attachment #24170|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48874
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #13 from Tobias Burnus 2011-05-04
17:30:31 UTC ---
(In reply to comment #12)
> Perhaps frontend could help us here since the descriptors are probably
> constant after they are initialized, or is there way to change existing
> descript
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #12 from H.J. Lu 2011-05-04 17:24:24
UTC ---
(In reply to comment #11)
> Created attachment 24183 [details]
> gcc47-pr48853.patch
>
> Is this better?
No, it doesn't handle DW_OP_GNU_const_type:
(gdb) f 0
#0 mem_loc_descriptor (rtl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40315
--- Comment #10 from Jonathan Wakely 2011-05-04
17:38:37 UTC ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1001 is NAD so I
think we can close this bug as INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
--- Comment #1 from Daniel Krügler
2011-05-04 17:38:16 UTC ---
(In reply to comment #0)
an error happended when I tryied to transform my original example (using
std::declval) to a form with a minimum of library support. So let me provide
this f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
--- Comment #2 from Paolo Carlini 2011-05-04
17:53:25 UTC ---
As I side remark, I'm not sure to understand why your testcases often include
an 'int main { }' line, I don't think are about link-time problems, no? If you
compile only what's the mai
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48869
--- Comment #6 from Jason Merrill 2011-05-04
17:46:33 UTC ---
I think it would be fine to mark_used the copy ctor in cases where it might or
might not be used.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
Charles Wilson changed:
What|Removed |Added
CC||gcc.20.cwilson at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47913
--- Comment #23 from Paolo Carlini 2011-05-04
17:56:19 UTC ---
Nit (for the future): library patches are diffed from where the library
ChangeLog is.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
Jakub Jelinek changed:
What|Removed |Added
Attachment #24183|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48872
--- Comment #3 from Daniel Krügler
2011-05-04 17:59:21 UTC ---
(In reply to comment #2)
> As I side remark, I'm not sure to understand why your testcases often include
> an 'int main { }' line, I don't think are about link-time problems, no? If y
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48853
--- Comment #14 from H.J. Lu 2011-05-04 18:10:24
UTC ---
(In reply to comment #13)
> Created attachment 24184 [details]
> gcc47-pr48853.patch
>
> So like this? CONST_DOUBLEs really shouldn't appear in the addresses...
It looks much better. I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48749
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40315
Jason Merrill changed:
What|Removed |Added
Status|SUSPENDED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48708
--- Comment #4 from uros at gcc dot gnu.org 2011-05-04 18:25:33 UTC ---
Author: uros
Date: Wed May 4 18:25:25 2011
New Revision: 173389
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173389
Log:
Backport from mainline
2011-04-21 U
1 - 100 of 132 matches
Mail list logo
