http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46845
--- Comment #5 from Sebastian Pop 2010-12-14 07:30:07
UTC ---
Patch
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01062.html
Hi ,
Actually while compling i am getting the error " Relocation
Truncated to fit : R_PPC_PLTREL24 " in
Eabi PowerPC GNU compiler.
Previousely we have used the optimisation " -01" . if we use that
optimisation we didnt get any error.
After removing that optimisation we are getting t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934
Summary: gcc ICE: error: unrecognizable insn: in extract_insn,
at recog.c:2109
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46933
Summary: [4.6 Regression] Revision 167781 failed
g++.dg/other/first-global.C
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46931
--- Comment #1 from H.J. Lu 2010-12-14 05:59:50
UTC ---
It may be related to PR 46834.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
--- Comment #12 from Paul Thomas 2010-12-14 05:35:00
UTC ---
(In reply to comment #11)
> (In reply to comment #9)
> > The attached fixes the PR and is regtesting right now. I do not believe
> > that
> > there will be any ere regressions since
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46542
--- Comment #3 from Jeffrey A. Law 2010-12-14 04:35:45
UTC ---
Created attachment 22749
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22749
Patch to combine several distinct arrays into a single VEC
Patch to move various reg_equiv_xxx arra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46932
Summary: Inefficient code sequence to access local variable
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #57 from H.J. Lu 2010-12-14 01:31:56
UTC ---
My current patch is on hjl/init-array branch at
http://git.kernel.org/?p=devel/gcc/hjl/x86.git;a=summary
It uses .init_array only if linker supports mixing .init_array.* and
.ctors.* inpu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388
--- Comment #12 from Jan Hubicka 2010-12-14
01:26:51 UTC ---
Author: hubicka
Date: Tue Dec 14 01:26:47 2010
New Revision: 167781
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167781
Log:
This time really commit
PR middle-end/45388
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #56 from Cary Coutant 2010-12-14
01:24:30 UTC ---
> H.J, Cary is talking about multiple global constructors in a single file, none
> of which use constructor priorities. In other words, the normal case. gcc
> generates those in a sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #55 from H.J. Lu 2010-12-14 01:14:22
UTC ---
(In reply to comment #54)
> H.J, Cary is talking about multiple global constructors in a single file, none
> of which use constructor priorities. In other words, the normal case. gcc
> ge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #54 from Ian Lance Taylor 2010-12-14 00:38:41
UTC ---
H.J, Cary is talking about multiple global constructors in a single file, none
of which use constructor priorities. In other words, the normal case. gcc
generates those in a spec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44374
--- Comment #6 from Bernd Schmidt 2010-12-14
00:23:48 UTC ---
Author: bernds
Date: Tue Dec 14 00:23:40 2010
New Revision: 167779
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167779
Log:
gcc/
PR rtl-optimization/44374
Reapply pat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46300
Aldy Hernandez changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #3 from Aldy Hernande
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #11 from Mike Stump 2010-12-13
22:55:12 UTC ---
I don't think this should be necessary. One section should be enough. If you
have specific concerns, let me know, I could just be missing something.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46931
Summary: Subversion id 167184 breaks building perlbench on
power7 with debug
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46887
--- Comment #2 from Michael Haubenwallner 2010-12-13 22:18:57 UTC ---
It did hit me in gcc-4.2.4 (languages=c,c++) in Gentoo Prefix on AIX, where I
do have some automagic patches to enable runtime linking by default as well as
full "soname" suppor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46371
--- Comment #2 from Tobias Burnus 2010-12-13
22:13:53 UTC ---
Created attachment 22747
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22747
Draft patch
Draft patch fixes "2 VALID" and "3 VALID" - however, I see failures for the
following ex
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46201
--- Comment #9 from Dominique d'Humieres 2010-12-13
22:13:32 UTC ---
> Sure, they're not meant to be runtime tests.
I just wanted to be sure that I had understood the problem. Thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
--- Comment #9 from Dmitry Gorbachev
2010-12-13 22:02:02 UTC ---
Marking bar() externally_visible does not help..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46849
--- Comment #4 from janus at gcc dot gnu.org 2010-12-13 21:59:21 UTC ---
(In reply to comment #3)
> Here is a reduced test case for the rejects-valid part, without CLASS and
> ISO_C_BINDING:
Not sure if it's the perfectly right thing to do, but t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46201
--- Comment #8 from janus at gcc dot gnu.org 2010-12-13 21:51:49 UTC ---
(In reply to comment #7)
> The tests in comments #2 and #3 compile now but segfault at run-time. Am I
> right to say that they are invalid because the pointers point to nowher
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46201
--- Comment #7 from Dominique d'Humieres 2010-12-13
21:38:49 UTC ---
The tests in comments #2 and #3 compile now but segfault at run-time. Am I
right to say that they are invalid because the pointers point to nowhere?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46888
--- Comment #3 from Andrew Pinski 2010-12-13
21:37:37 UTC ---
(In reply to comment #1)
> Two different patches have been posted to fix this:
>
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00778.html
>
> http://gcc.gnu.org/ml/gcc-patches/201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #12 from joseph at codesourcery dot com 2010-12-13 21:32:15 UTC ---
On Mon, 13 Dec 2010, iains at gcc dot gnu.org wrote:
> > > (gdb) print plugindir_string
> > > $1 = 0x
> > >
> > > which is the origin of the current fail (t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677
--- Comment #14 from joseph at codesourcery dot com 2010-12-13 21:31:11 UTC ---
On Mon, 13 Dec 2010, amylaar at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677
>
> --- Comment #13 from Jorn Wolfgang Rennecke
> 2010-1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46701
Paolo Carlini changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
--- Comment #11 from Mikael Morin 2010-12-13
21:24:35 UTC ---
(In reply to comment #9)
> Created attachment 22739 [details]
> A tentative fix for the PR
Yeah, trying to share the code with gfc_trans_arrayfunc_assign was plain pain.
Copy'n'paste w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46930
Paolo Carlini changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46930
Summary: [C++0x] ICE with static constexpr data member
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
Depend
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46920
Vladimir Makarov changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46873
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46877
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #53 from H.J. Lu 2010-12-13 20:47:44
UTC ---
(In reply to comment #52)
> (In reply to comment #51)
> > > If gcc switches from .ctors to .init_array, it needs to make sure to
> > > generate
> > > the constructors in forward order with
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46877
--- Comment #1 from Jason Merrill 2010-12-13
20:47:04 UTC ---
Author: jason
Date: Mon Dec 13 20:46:58 2010
New Revision: 167770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167770
Log:
PR c++/46873
PR c++/46877
* semantics.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46873
--- Comment #6 from Jason Merrill 2010-12-13
20:47:03 UTC ---
Author: jason
Date: Mon Dec 13 20:46:58 2010
New Revision: 167770
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167770
Log:
PR c++/46873
PR c++/46877
* semantics.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Cary Coutant changed:
What|Removed |Added
CC||ccoutant at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #51 from H.J. Lu 2010-12-13 20:30:58
UTC ---
(In reply to comment #50)
>
> If gcc switches from .ctors to .init_array, it needs to make sure to generate
> the constructors in forward order within the TU, rather than backwards order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
Thomas Koenig changed:
What|Removed |Added
Attachment #22724|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #50 from Cary Coutant 2010-12-13
20:24:43 UTC ---
Sorry for jumping in so late here, but it sounds like the conclusions here
match my recollections:
- We added .init_array/.fini_array in order to blend the SVR4 version of .init,
whic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #11 from Iain Sandoe 2010-12-13 20:23:40
UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > hm although we have:
> >
> > gcc/common.opt:Common Joined Var(plugindir_string) Init(0)
> >
> > I get
>
>
> > (gdb) pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #10 from Iain Sandoe 2010-12-13 20:16:23
UTC ---
perhaps it would be safer to name the fallback section:
>> : darwin_sections[text_unlikely_fallback_section]);
>> DEF_SECTION (text_unlikely_fallback_section, SECTION_CODE|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #10 from Iain Sandoe 2010-12-13 20:09:10
UTC ---
(In reply to comment #9)
> hm although we have:
>
> gcc/common.opt:Common Joined Var(plugindir_string) Init(0)
>
> I get
> (gdb) print plugindir_string
> $1 = 0x
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #9 from Iain Sandoe 2010-12-13 20:05:52
UTC ---
hm although we have:
gcc/common.opt:Common Joined Var(plugindir_string) Init(0)
I get
Breakpoint 1 at 0x886ea4: file /GCC/gcc-live-trunk/gcc/plugin.c, line 880.
(gdb) run
Startin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46625
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46625
--- Comment #5 from Tobias Burnus 2010-12-13
19:44:51 UTC ---
Author: burnus
Date: Mon Dec 13 19:44:38 2010
New Revision: 167768
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167768
Log:
2010-12-13 Tobias Burnus
PR fortran/46
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #49 from H.J. Lu 2010-12-13 19:41:15
UTC ---
A linker patch is posted at
http://sourceware.org/ml/binutils/2010-12/msg00439.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
--- Comment #5 from Sebastian Pop 2010-12-13 19:30:19
UTC ---
The code from comment #4 comes from
./cc1 -O2 -ftree-loop-distribution -fdump-tree-ldist-details
as on -O3 we end up unrolling all the loops.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #8 from Dominique d'Humieres 2010-12-13
19:22:56 UTC ---
On x86_64-apple-darwin10.5.0, the first test passes as:
Executing on host: /opt/gcc/build_w/gcc/xgcc -B/opt/gcc/build_w/gcc/
/opt/gcc/work/gcc/testsuite/gcc.dg/plugin/finish_un
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46201
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46201
--- Comment #5 from janus at gcc dot gnu.org 2010-12-13 19:18:08 UTC ---
Author: janus
Date: Mon Dec 13 19:17:46 2010
New Revision: 167767
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167767
Log:
2010-12-13 Janus Weil
PR fortran/4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677
--- Comment #13 from Jorn Wolfgang Rennecke
2010-12-13 19:16:47 UTC ---
(In reply to comment #12)
> On Sat, 11 Dec 2010, amylaar at gcc dot gnu.org wrote:
>
> > We don't have any current decimal floating or fixed-point type size macros
> > to re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46929
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46929
Summary: Xutil.h and Complex - some trouble
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
--- Comment #9 from Dominique d'Humieres 2010-12-13
19:10:55 UTC ---
> here is fix ... but I dunno if it's the "Right" fix --- so I'll let Mike &|
> Honza comment...
The patch fixed the failures. I am regstrapping. Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
--- Comment #4 from sebpop at gmail dot com
2010-12-13 19:05:58 UTC ---
The code that is produced looks like this just after loop
distribution, i.e., we generate memset zero only by distributing the
innermost loop:
mad_synth_mute (struct mad_syn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #6 from Dominique d'Humieres 2010-12-13
19:05:18 UTC ---
Note that adding ' -iplugindir=my-plugindir' to the option does not change the
results.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #5 from Dominique d'Humieres 2010-12-13
19:02:59 UTC ---
GDB session:
(gdb) watch -location global_options.x_plugindir_string
Hardware watchpoint 1: *(const char **) 12424292
(gdb) run -fplugin=foo
/opt/gcc/gcc-4.6-work/gcc/testsuite
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
--- Comment #3 from Sebastian Pop 2010-12-13 18:58:41
UTC ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01016.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883
Ulrich Weigand changed:
What|Removed |Added
CC||bernds at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #4 from joseph at codesourcery dot com 2010-12-13 18:53:41 UTC ---
On Mon, 13 Dec 2010, dominiq at lps dot ens.fr wrote:
> I am fluent neither in C nor gdb. Does not "first=0x 0x out of bounds>" answer the first quest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46895
--- Comment #5 from asharif at gcc dot gnu.org 2010-12-13 18:49:50 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Yeah, if #c2 tests what the test meant to test, then it is much preferrable
> > over the thing that got committed, wh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926
--- Comment #3 from joseph at codesourcery dot com 2010-12-13 18:48:22 UTC ---
On Mon, 13 Dec 2010, pinskia at gcc dot gnu.org wrote:
> I think this is invalid as GNU/Linux defaults to including sincos as a
> builtin. If you want to disable the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #3 from Dominique d'Humieres 2010-12-13
18:44:50 UTC ---
> > #0 0x94afe928 in strlen ()
> > #1 0x008b6414 in concat (first=0x > bounds>)
> > at ../../gcc-4.6-work/libiberty/concat.c:76
> > #2 0x0051e660 in add_new_plugin (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926
--- Comment #2 from James Kuyper Jr.
2010-12-13 18:41:55 UTC ---
info gcc says:
Functions which would normally be built in but do not have
semantics defined by ISO C (such as `alloca' and `ffs') are not
built-in functions with `-ansi'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46607
--- Comment #4 from joseph at codesourcery dot com 2010-12-13 18:39:47 UTC ---
On Mon, 13 Dec 2010, rwild at gcc dot gnu.org wrote:
> So is this only about the MinGW case? Because there, we should just fix
> libtool to not ever relink.
No, it's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
davidxl changed:
What|Removed |Added
CC||xinliangli at gmail dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46650
--- Comment #6 from ian at gcc dot gnu.org 2010-12-13
18:34:48 UTC ---
Author: ian
Date: Mon Dec 13 18:34:45 2010
New Revision: 167764
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167764
Log:
PR bootstrap/46650
* system.h: Inclu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
m...@gcc.gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4
--- Comment #6 from Rainer Orth 2010-12-13 18:30:31 UTC
---
Author: ro
Date: Mon Dec 13 18:30:20 2010
New Revision: 167762
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167762
Log:
Backport from mainline:
2010-04-28 Rainer Orth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46908
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46916
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46902
--- Comment #2 from joseph at codesourcery dot com 2010-12-13 18:20:16 UTC ---
On Sun, 12 Dec 2010, dominiq at lps dot ens.fr wrote:
> The backtrace is
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #48 from joseph at codesourcery dot com 2010-12-13 18:08:00 UTC ---
On Sat, 11 Dec 2010, hjl.tools at gmail dot com wrote:
> We introduced .init_array into gABI 10 years ago so that we can avoid
> those crazy things in crt*.o. It is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46928
Summary: data dependence analysis fails on constant array
accesses
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388
Alexander Monakov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46677
--- Comment #12 from joseph at codesourcery dot com 2010-12-13 17:58:13 UTC ---
On Sat, 11 Dec 2010, amylaar at gcc dot gnu.org wrote:
> We don't have any current decimal floating or fixed-point type size macros
> to replace. As discussed elsewh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46895
asharif at gcc dot gnu.org changed:
What|Removed |Added
CC||asharif at gcc dot gnu.org
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46879
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46867
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46201
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|una
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46879
--- Comment #6 from Jakub Jelinek 2010-12-13
17:37:27 UTC ---
Author: jakub
Date: Mon Dec 13 17:37:20 2010
New Revision: 167755
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167755
Log:
PR lto/46879
* lto-streamer-out.c (output_g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46867
--- Comment #3 from Jakub Jelinek 2010-12-13
17:36:31 UTC ---
Author: jakub
Date: Mon Dec 13 17:36:26 2010
New Revision: 167754
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167754
Log:
PR debug/46867
* var-tracking.c (emitted_no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46797
--- Comment #3 from Tobias Burnus 2010-12-13
17:35:24 UTC ---
(In reply to comment #2)
> Well, I'd say works as it should: relinking is used to avoid run paths to
> in-tree directories. What am I missing here? Thanks.
Well, if it is supposed t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46371
--- Comment #1 from Tobias Burnus 2010-12-13
17:32:22 UTC ---
(In reply to comment #0)
> type(foo), allocatable :: o_foo[:]
That should be "CLASS(foo)" - sorry for the typo.
TODO:
a) There is a gfc_is_coindexed() check missing for ASSOCIATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388
Jan Hubicka changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45388
--- Comment #9 from Jan Hubicka 2010-12-13
17:29:17 UTC ---
Author: hubicka
Date: Mon Dec 13 17:29:14 2010
New Revision: 167753
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167753
Log:
PR middle-end/45388
* decl2.c (start_objec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46758
Alexander Monakov changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|amonakov at gc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926
--- Comment #1 from Andrew Pinski 2010-12-13
17:23:05 UTC ---
I think this is invalid as GNU/Linux defaults to including sincos as a builtin.
If you want to disable the builtin then use -fno-builtin-sincos.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46720
Ralf Wildenhues changed:
What|Removed |Added
CC||rwild at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46927
Summary: flag -fstrict-volatile-bitfields affects volatile
non-bitfields
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46300
Aldy Hernandez changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46895
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46926
Summary: Paired sin() cos() calls optimized to sincos() call.
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46201
--- Comment #3 from janus at gcc dot gnu.org 2010-12-13 16:57:20 UTC ---
Here is an even more compact version of the test case (getting rid of the
INTERFACE statement):
type t
procedure(character), nopass, pointer :: ppc
end type
type(t),dimens
1 - 100 of 168 matches
Mail list logo
