http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
--- Comment #14 from diggskevin38 at gmail dot com 2011-04-21 05:11:43 UTC ---
I did:
svn co svn://gcc.gnu.org/svn/gcc/tags/gcc_4_3_0_release gcc_4_3-svn
blah blah blah ...
Checked out revision 172810.
then:
svn up -r 122895
Skipped '.'
I do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594
--- Comment #8 from Jason Merrill 2011-04-21
04:28:12 UTC ---
Author: jason
Date: Thu Apr 21 04:28:06 2011
New Revision: 172807
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172807
Log:
PR c++/48594
* decl2.c (build_offset_ref_ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594
--- Comment #6 from Jason Merrill 2011-04-21
03:03:11 UTC ---
Author: jason
Date: Thu Apr 21 03:03:08 2011
New Revision: 172805
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172805
Log:
PR c++/48594
* decl2.c (build_offset_ref_ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594
--- Comment #5 from Jason Merrill 2011-04-21
02:57:31 UTC ---
Author: jason
Date: Thu Apr 21 02:57:28 2011
New Revision: 172804
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172804
Log:
PR c++/48594
* decl2.c (build_offset_ref_ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48594
--- Comment #4 from Jason Merrill 2011-04-21
02:56:42 UTC ---
Author: jason
Date: Thu Apr 21 02:56:39 2011
New Revision: 172803
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172803
Log:
PR c++/48594
* decl2.c (build_offset_ref_ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #62 from PcX 2011-04-21 01:28:02 UTC
---
(In reply to comment #61)
> (In reply to comment #59)
>
> > I review the patch, and found that we can add "-fno-keep-inline-dllexport"
> > to
> > the compiler option, and then, the compiler a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #61 from Dave Korn 2011-04-21 00:40:17
UTC ---
(In reply to comment #59)
> I review the patch, and found that we can add "-fno-keep-inline-dllexport" to
> the compiler option, and then, the compiler and linker stage works well. But
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #19 from Ivan Godard 2011-04-21
00:22:08 UTC ---
I notice that Bugzilla is carrying this as "enhancement" and "unconfirmed".
Seems odd :-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
--- Comment #17 from Easwaran Raman 2011-04-21
00:20:51 UTC ---
On Sun, Apr 17, 2011 at 3:45 AM, rguenther at suse dot de
wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
>
> --- Comment #16 from rguenther at suse dot de
> 2011-04-17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46986
Ian Lance Taylor changed:
What|Removed |Added
Version|4.6.0 |4.5.4
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #18 from Paolo Carlini 2011-04-21
00:02:02 UTC ---
Thanks Ralf, I didn't know AC_CHECK_SIZEOF and AC_CHECK_ALIGNOF even existed,
in similar situations probably I would have dumbly re-invented both basing on
AC_COMPUTE_INT ;)
Otherwis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670
--- Comment #3 from Matt Hargett 2011-04-20 23:59:45 UTC
---
When compiling the example with 4.5.2, memory usage peaks at around 216meg on
my Ubuntu 10.10/amd64 machine. With 4.6, it peaks at 3.2gig(!)
In the non-reduced test case, it gets up to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48670
--- Comment #2 from Matt Hargett 2011-04-20 23:54:54 UTC
---
Created attachment 24065
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24065
reduced test case, commandline to compile in bug comments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48288
--- Comment #7 from John David Anglin 2011-04-20
23:36:22 UTC ---
Author: danglin
Date: Wed Apr 20 23:36:20 2011
New Revision: 172797
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172797
Log:
PR target/48288
* config/pa/predicate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #17 from Ralf Wildenhues 2011-04-20
23:10:26 UTC ---
(In reply to comment #13)
> The last time I checked, the problem boiled down to:
>
> typedef __gthread_mutex_t __c_lock;
>
> in c_io_stdio.h, which we cannot remove right away f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677
--- Comment #10 from ralphengels at gmail dot com 2011-04-20 22:48:54 UTC ---
hmm it seems im getting closer to iron out where the bug appears.
3880#if defined(TARGET_SYSTEM_ROOT_RELOCATABLE) && !defined(VMS)
3881 /* If the no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48657
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
--- Comment #13 from diggskevin38 at gmail dot com 2011-04-20 22:05:34 UTC ---
This time without the cut and paste overlap errors (Sorry):
-(define_insn "ashldi_const32"
- [(set (match_operand:DI 0 "nonimmediate_operand" "=rm")
-(ashift:DI (m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
--- Comment #12 from diggskevin38 at gmail dot com 2011-04-20 21:49:36 UTC ---
Then again I suppose it could be in here:
(define_insn "extendsidi2"
- [(set (match_operand:DI 0 "nonimmediate_operand" "=d")
- (sign_extend:DI
-(match_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
--- Comment #11 from diggskevin38 at gmail dot com 2011-04-20 21:24:31 UTC ---
I don't know what '122895' means???
I'll do the 'svn thing'. But I am not an experienced svn user so it may take
some time.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
--- Comment #10 from diggskevin38 at gmail dot com 2011-04-20 21:22:12 UTC ---
If I were a bettin' man I would double down that the problem is in here
somewhere:
-(define_insn "ashldi_const32"
- [(set (match_operand:DI 0 "nonimmediate_operand" "=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #16 from Ivan Godard 2011-04-20
21:06:39 UTC ---
Would it be possible to wrap each #include of a C file in a namespace,
adjusting the references from the C++ library accordingly? The namespace to be
used could be shared by all such #i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #15 from Paolo Carlini 2011-04-20
20:36:30 UTC ---
Unfortunately the issue seems more complex, because gthr.h is dragged in also
via , which is everywhere...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48707
Summary: [4.6/4.7 Regression] [c++0x] ICE initializing static
const int
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48678
Uros Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48678
--- Comment #15 from uros at gcc dot gnu.org 2011-04-20 19:58:27 UTC ---
Author: uros
Date: Wed Apr 20 19:58:23 2011
New Revision: 172792
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172792
Log:
PR target/48678
* config/i386/i386.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41849
Georg-Johann Lay changed:
What|Removed |Added
CC||gjl at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48657
--- Comment #5 from Jason Merrill 2011-04-20
19:39:29 UTC ---
Author: jason
Date: Wed Apr 20 19:39:26 2011
New Revision: 172791
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172791
Log:
PR c++/48657
* decl.c (cp_finish_decl): Han
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48706
Summary: [OOP] ICE (segfault) with TBP
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48657
--- Comment #4 from Jason Merrill 2011-04-20
19:39:05 UTC ---
Author: jason
Date: Wed Apr 20 19:39:02 2011
New Revision: 172790
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172790
Log:
PR c++/48657
* decl.c (cp_finish_decl): Sim
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48705
Summary: [OOP] ICE with generic TBP
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
Paolo Carlini changed:
What|Removed |Added
CC||rwild at gcc dot gnu.org
--- Comment #14
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
Paolo Carlini changed:
What|Removed |Added
CC||jwakely.gcc at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48611
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48611
--- Comment #4 from Jakub Jelinek 2011-04-20
18:19:50 UTC ---
Author: jakub
Date: Wed Apr 20 18:19:47 2011
New Revision: 172786
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172786
Log:
PR tree-optimization/48611
* tree-eh.c (not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48611
--- Comment #3 from Jakub Jelinek 2011-04-20
18:18:19 UTC ---
Author: jakub
Date: Wed Apr 20 18:18:16 2011
New Revision: 172783
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172783
Log:
PR tree-optimization/48611
* tree-eh.c (not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585
--- Comment #9 from Martin Jambor 2011-04-20
18:17:14 UTC ---
Actually, IPA-CP is clearly involved, the function we're inlinig to
is:
(gdb) call debug_generic_expr(id->dst_fn)
_ZN10xalanc_1_818XalanDOMStringPoolC2Emmm.constprop.15285
Looking at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #11 from Janne Blomqvist 2011-04-20
18:14:20 UTC ---
(In reply to comment #9)
> > But do we actually do this? I did some tests a while ago, and IIRC for
> > assumed
> > shape dummy arguments the procedure always calculates new bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48692
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48692
--- Comment #5 from Tobias Burnus 2011-04-20
18:07:56 UTC ---
Author: burnus
Date: Wed Apr 20 18:07:52 2011
New Revision: 172782
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172782
Log:
2011-04-19 Tobias Burnus
PR fortran/48
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48588
--- Comment #9 from Tobias Burnus 2011-04-20
18:07:56 UTC ---
Author: burnus
Date: Wed Apr 20 18:07:52 2011
New Revision: 172782
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172782
Log:
2011-04-19 Tobias Burnus
PR fortran/48
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
Andreas Tobler changed:
What|Removed |Added
CC||andreast at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
--- Comment #8 from diggskevin38 at gmail dot com 2011-04-20 17:46:09 UTC ---
Would a diff of the 4.2.4 and 4.3.0 m68k.md file be a useful attachment?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48690
--- Comment #7 from diggskevin38 at gmail dot com 2011-04-20 17:42:51 UTC ---
This is also busted in all of 4.3 (0, 1, 2, 3, & 4) and 4.5.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48678
--- Comment #14 from Uros Bizjak 2011-04-20 17:42:45
UTC ---
(In reply to comment #12)
> Hm, if line 14 in the testcase is changed to:
>
> - ((T *) &s.d)[0] = *x;
> + ((T *) &s.d)[1] = *x;
We should go through insv pattern. Patch v2 attached
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48678
Uros Bizjak changed:
What|Removed |Added
Attachment #24061|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48585
--- Comment #8 from Martin Jambor 2011-04-20
17:24:04 UTC ---
Looking into this a bit more, this has probably nothing to do with
IPA-CP at all. When I dump the body of the function being inlined I
get:
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #10 from Thomas Koenig 2011-04-20
16:40:46 UTC ---
(In reply to comment #6)
> Not strictly related to inlining, but in the new descriptor we'll have a field
> specifying whether the array is simply contiguous, so it might make sense
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #12 from Jakub Jelinek 2011-04-20
16:19:05 UTC ---
Well, there is also the expander that can and often does increase the size of
the accesses, see e.g. PR48124 for more details. And e.g. for C++0x memory
model as well as -fopenmp or,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #11 from Linus Torvalds 2011-04-20
16:16:52 UTC ---
(In reply to comment #8)
>
> Unfortunately the underlying type isn't easily available (at least I didn't
> yet find it ...). But I suppose we have to guess anyway considering
> tar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #10 from Jan Hubicka 2011-04-20 15:54:17
UTC ---
> Actually the 4.0.4 compiler is x86_64, the code with -m32. The 4.0.3
> compiler is i586.
>
> /space/rguenther/install/gcc-4.0.3/libexec/gcc/i686-pc-linux-gnu/4.0.3/cc1
> -quiet -v
> Actually the 4.0.4 compiler is x86_64, the code with -m32. The 4.0.3
> compiler is i586.
>
> /space/rguenther/install/gcc-4.0.3/libexec/gcc/i686-pc-linux-gnu/4.0.3/cc1
> -quiet -v t.c -quiet -dumpbase t.c -m32 -mtune=pentiumpro -auxbase t -O2
> -version -o t.s
>
>
> /space/rguenther/install/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47892
--- Comment #7 from Richard Guenther 2011-04-20
15:50:38 UTC ---
Author: rguenth
Date: Wed Apr 20 15:50:26 2011
New Revision: 172774
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172774
Log:
2011-04-20 Richard Guenther
PR tree-op
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #9 from Tobias Burnus 2011-04-20
15:39:47 UTC ---
> But do we actually do this? I did some tests a while ago, and IIRC for assumed
> shape dummy arguments the procedure always calculates new bounds such that
> they
> start from 1. Th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #9 from Richard Guenther 2011-04-20
15:41:09 UTC ---
Btw, the branch from the work "some time ago" created
show_bug:
.LFB2:
movl(%rdi), %eax
andl$-64, %eax
movl%eax, (%rdi)
shrl$6, %eax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #8 from Richard Guenther 2011-04-20
15:39:38 UTC ---
(In reply to comment #7)
> (In reply to comment #2)
> >
> > I'm not sure where to best address this, rather than throwing in again
> > the idea of lowering bitfield accesses early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #7 from Linus Torvalds 2011-04-20
15:30:17 UTC ---
(In reply to comment #2)
>
> I'm not sure where to best address this, rather than throwing in again
> the idea of lowering bitfield accesses early on trees.
So my gut feel is that g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48704
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48677
--- Comment #9 from ralphengels at gmail dot com
2011-04-20 15:17:40 UTC ---
if its any help i noticed that cpp.exe seems to have a dependency on
libstdc++6.dll "somewhere" since dependency walker says it doesnt but it barfs
pretty loudly if its
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36231
--- Comment #12 from Jonathan Wakely 2011-04-20
15:17:37 UTC ---
N.B. same issue reported at https://bugzilla.redhat.com/show_bug.cgi?id=502251
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
Richard Guenther changed:
What|Removed |Added
Known to work|4.7.0 |
Summary|[4.6 Regression]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48704
Summary: ICE: gfortran dies when '-finstrument-functions'
option is used
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48703
Summary: segfault in canonicalize_for_substitution
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassig.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
Richard Guenther changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48678
--- Comment #12 from Uros Bizjak 2011-04-20 14:27:30
UTC ---
Hm, if line 14 in the testcase is changed to:
- ((T *) &s.d)[0] = *x;
+ ((T *) &s.d)[1] = *x;
then gcc does not touch movstrict pattern at all and generates following code:
mov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48576
--- Comment #6 from Ramana Radhakrishnan 2011-04-20
14:20:10 UTC ---
Can an RM reprioritize this one ? It smells of something higher than P3 since
this is a wrong code regression from 4.4 ?
cheers
Ramana
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48702
Summary: optimization regression with gcc-4.6 on
x86_64-unknown-linux-gnu
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48701
Richard Guenther changed:
What|Removed |Added
Target||x86_64-*-*
Status|UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48695
Richard Guenther changed:
What|Removed |Added
Known to work||4.7.0
Summary|[4.6/4.7 Regr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145
Georg-Johann Lay changed:
What|Removed |Added
Keywords|FIXME |
Status|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18145
--- Comment #4 from Georg-Johann Lay 2011-04-20
13:38:09 UTC ---
Author: gjl
Date: Wed Apr 20 13:38:05 2011
New Revision: 172769
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172769
Log:
PR target/18145
* config/avr/avr.h (TARGE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48671
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48678
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|4.6.1 |4.7.0
Summary|[4.6/4.7 Regress
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48678
Uros Bizjak changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48701
--- Comment #1 from Matthias Kretz 2011-04-20 13:26:56
UTC ---
Created attachment 24060
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24060
testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48701
Summary: [missed optimization] GCC fails to use aliasing of ymm
and xmm registers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #3 from Salvatore Filippone
2011-04-20 13:20:48 UTC ---
(In reply to comment #2)
> See also PR 48700 (memleak with polymorphic vars in MOVE_ALLOC), which might
> be
> a duplicate.
They are related in the sense that the test cases fo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48695
--- Comment #8 from Richard Guenther 2011-04-20
13:11:12 UTC ---
Author: rguenth
Date: Wed Apr 20 13:11:06 2011
New Revision: 172768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172768
Log:
2011-04-20 Richard Guenther
PR middle-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #8 from Janne Blomqvist 2011-04-20 13:09:51
UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > > Here is some sample code (extreme, I admit) which profits a lot from
> > > inlining:
> > >
> > > - Strides are known to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48688
--- Comment #6 from Jakub Jelinek 2011-04-20
13:01:40 UTC ---
Created attachment 24059
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24059
gcc47-pr48688.patch
Untested fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #39 from Tobias Burnus 2011-04-20
13:01:34 UTC ---
(In reply to comment #38)
> and compile with -mpc32 -mpc64 -mpc80 respectively.
Then I like Janne's proposal more: compiling libgfortran/io/*.c with
-fexcess-precision=standard.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
Eric Botcazou changed:
What|Removed |Added
Known to work||4.1.0
--- Comment #6 from Eric Botcazou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48688
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|rtl-optimizat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
--- Comment #38 from Thomas Henlich
2011-04-20 12:38:53 UTC ---
As an alternative we might consider leaving the code as it was before and
instead putting
OUTPUT_FLOAT_FMT_G(4)
OUTPUT_FLOAT_FMT_G(8)
OUTPUT_FLOAT_FMT_G(10)
into separate files a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48688
--- Comment #5 from Jakub Jelinek 2011-04-20
12:30:10 UTC ---
Actually, I've managed to handle this by adding a new define_insn_and_split
(*lea_general_4).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
--- Comment #7 from Tobias Burnus 2011-04-20
12:29:02 UTC ---
(In reply to comment #6)
> > Here is some sample code (extreme, I admit) which profits a lot from
> > inlining:
> >
> > - Strides are known to be one when inlining (a common case, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #5 from Richard Guenther 2011-04-20
12:15:14 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > So something changed between 4.0.3 and 4.0.4? Or maybe a typo?
>
> I only have 32bit compilers for both and see, for 4.0.3:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
--- Comment #4 from Richard Guenther 2011-04-20
12:11:56 UTC ---
(In reply to comment #3)
> So something changed between 4.0.3 and 4.0.4? Or maybe a typo?
I only have 32bit compilers for both and see, for 4.0.3:
show_bug:
pushl %ebp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48700
Summary: [OOP] memory leak with MOVE_ALLOC of polymorphic
variables
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
--- Comment #1 from Salvatore Filippone
2011-04-20 12:07:04 UTC ---
Created attachment 24057
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24057
test-case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48699
Summary: [OOP] MOVE_ALLOC of polymorphic variables
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48697
crivello changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from crivello 2011-04-20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48696
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
Janne Blomqvist changed:
What|Removed |Added
CC||jb at gcc dot gnu.org
--- Comment #6 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48492
--- Comment #7 from Eric Botcazou 2011-04-20
11:18:57 UTC ---
Author: ebotcazou
Date: Wed Apr 20 11:18:50 2011
New Revision: 172767
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172767
Log:
Backport from mainline
2011-04-19 Eric
1 - 100 of 131 matches
Mail list logo
