http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898
--- Comment #2 from Masaki MURANAKA 2010-12-12
03:37:21 UTC ---
Created attachment 22720
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22720
testcase after applied attachment 22719
(In reply to comment #1)
> We will get the another issue a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898
--- Comment #1 from Masaki MURANAKA 2010-12-12
03:26:03 UTC ---
Created attachment 22719
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22719
Patch to config/lm32.[ch] (incomplete)
This issue was discussed at gcc-patches ML on 2010-10-29 b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
--- Comment #2 from Andrew Pinski 2010-12-12
01:55:56 UTC ---
(In reply to comment #1)
> There is no integer overflow in the code provided at all.
Even if there was, the standard says the behavior is undefined which means
anything can happen.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
--- Comment #1 from Andrew Pinski 2010-12-12
01:54:16 UTC ---
There is no integer overflow in the code provided at all.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
Jerry DeLisle changed:
What|Removed |Added
Target Milestone|4.6.0 |---
--- Comment #3 from Jerry DeLisle 20
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46899
Summary: compiler optimization
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
Re
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46898
Summary: libgcc build failure on lm32-elf
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #44 from H.J. Lu 2010-12-12 00:32:06
UTC ---
(In reply to comment #43)
> On 12/11/2010 4:20 PM, hjl.tools at gmail dot com wrote:
>
> > That means we only guarantee constructor priorities in one TU and
> > my testcase confirms it.
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #43 from Mark Mitchell 2010-12-12
00:24:30 UTC ---
On 12/11/2010 4:20 PM, hjl.tools at gmail dot com wrote:
> That means we only guarantee constructor priorities in one TU and
> my testcase confirms it.
HJ, this isn't true.
The exp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #42 from H.J. Lu 2010-12-12 00:24:26
UTC ---
Hi Mark,
Did you mean one may interleave constructor priorities? But I don't
think it is a documented feature.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #41 from H.J. Lu 2010-12-12 00:19:54
UTC ---
(In reply to comment #40)
> On 12/11/2010 4:08 PM, hjl.tools at gmail dot com wrote:
>
> > We only support constructor priority in single source file:
>
> H.J., this is false.
>
> Please
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #40 from Mark Mitchell 2010-12-12
00:11:56 UTC ---
On 12/11/2010 4:08 PM, hjl.tools at gmail dot com wrote:
> We only support constructor priority in single source file:
H.J., this is false.
Please try writing three constructors, w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #39 from H.J. Lu 2010-12-12 00:08:29
UTC ---
(In reply to comment #38)
> On 12/11/2010 4:00 PM, hjl.tools at gmail dot com wrote:
>
> > Really? Here is a testcase. Do you think goo's constructor
> > will be called before another con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #38 from Mark Mitchell 2010-12-12
00:03:22 UTC ---
On 12/11/2010 4:00 PM, hjl.tools at gmail dot com wrote:
> Really? Here is a testcase. Do you think goo's constructor
> will be called before another constructor in another file
> w
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #37 from H.J. Lu 2010-12-12 00:00:53
UTC ---
(In reply to comment #36)
> > That is the constructor order between A and B. We don't support
> > "interleaving constructor priorities" between object files.
>
> Yes, we do. We have for a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #36 from Mark Mitchell 2010-12-11
23:54:44 UTC ---
On 12/11/2010 3:48 PM, hjl.tools at gmail dot com wrote:
> 1. __attribute__((init_priority(1005))) doesn't map to
> .ctors.1005 section.
It probably maps to .ctors.(65535-1005). T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
H.J. Lu changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #35 from H.J. Lu 2010-12-11 23:48:29
UTC ---
(In reply to comment #34)
> On 12/11/2010 3:28 PM, hjl.tools at gmail dot com wrote:
>
> > 1. How do you find out what priority "foo" constructor has?
>
> If you're looking at source code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46705
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #34 from Mark Mitchell 2010-12-11
23:30:19 UTC ---
On 12/11/2010 3:28 PM, hjl.tools at gmail dot com wrote:
> 1. How do you find out what priority "foo" constructor has?
If you're looking at source code, read the source. If you're
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #33 from H.J. Lu 2010-12-11 23:28:01
UTC ---
(In reply to comment #32)
> On 12/11/2010 2:56 PM, hjl.tools at gmail dot com wrote:
>
> > It works at source code level. I don't believe we ever support
> > "interleaving constructor prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46705
--- Comment #7 from Jerry DeLisle 2010-12-11
23:26:11 UTC ---
Author: jvdelisle
Date: Sat Dec 11 23:26:07 2010
New Revision: 167717
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167717
Log:
2010-12-11 Jerry DeLisle
PR fortran/467
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #32 from Mark Mitchell 2010-12-11
23:19:05 UTC ---
On 12/11/2010 2:56 PM, hjl.tools at gmail dot com wrote:
> It works at source code level. I don't believe we ever support
> "interleaving constructor priorities" between object files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46705
--- Comment #6 from Jerry DeLisle 2010-12-11
23:14:48 UTC ---
Author: jvdelisle
Date: Sat Dec 11 23:14:45 2010
New Revision: 167716
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167716
Log:
2010-12-11 Jerry DeLisle
PR fortran/467
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #31 from H.J. Lu 2010-12-11 22:56:35
UTC ---
Just to make it clear. We support
---
`init_priority (PRIORITY)'
In Standard C++, objects defined at namespace scope are guaranteed
to be initialized in an order in strict accord
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897
Summary: [OOP] Polymorphic type - defined ASSIGNMENT(=) not
used
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46370
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46370
--- Comment #3 from Tobias Burnus 2010-12-11
22:04:10 UTC ---
Author: burnus
Date: Sat Dec 11 22:04:06 2010
New Revision: 167715
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167715
Log:
2010-12-11 Tobias Burnus
PR fortran/46
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #30 from H.J. Lu 2010-12-11 21:06:49
UTC ---
(In reply to comment #27)
> On 12/11/2010 12:17 PM, hjl.tools at gmail dot com wrote:
>
> > I don't think GCC really supports interleaving constructor priority
> > at binary level. Unless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #29 from Mark Mitchell 2010-12-11
21:06:41 UTC ---
On 12/11/2010 1:01 PM, hubicka at ucw dot cz wrote:
> So I take that, the ctor order is to support priotities, since the
> .ctor.priority sections get merged into single and ordered
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #28 from Jan Hubicka 2010-12-11 21:01:08
UTC ---
So I take that, the ctor order is to support priotities, since the
.ctor.priority sections get merged into single and ordered in increasing rather
than decreasing order, while init_arra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46705
--- Comment #5 from Jerry DeLisle 2010-12-11
20:41:52 UTC ---
I think this does the trick for the original and a few variations. I would
like to use an enumerator rather than 0 , 1, and 2 for the in_string flag.
That will touch a few more place
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46896
Summary: Wrong code with transpose(a) passed to subroutine
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: major
Priority: P3
Compone
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46370
--- Comment #2 from Tobias Burnus 2010-12-11
20:29:01 UTC ---
Patch: http://gcc.gnu.org/ml/fortran/2010-12/msg00061.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #27 from Mark Mitchell 2010-12-11
20:19:23 UTC ---
On 12/11/2010 12:17 PM, hjl.tools at gmail dot com wrote:
> I don't think GCC really supports interleaving constructor priority
> at binary level. Unless GCC can guarantees one can i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #26 from H.J. Lu 2010-12-11 20:16:56
UTC ---
(In reply to comment #24)
> Well, it sounds to me, then, that we would be introducing a binary
> compatibility problem to make this change. If we're going to do it, I
> think that means ad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842
--- Comment #27 from Jerry DeLisle 2010-12-11
20:11:31 UTC ---
Fixed, thanks to Mikael concept.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842
--- Comment #26 from Jerry DeLisle 2010-12-11
20:10:06 UTC ---
Author: jvdelisle
Date: Sat Dec 11 20:09:59 2010
New Revision: 167714
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167714
Log:
2010-12-11 Jerry DeLisle
PR fortran/46
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842
--- Comment #25 from Jerry DeLisle 2010-12-11
20:05:26 UTC ---
Author: jvdelisle
Date: Sat Dec 11 20:05:20 2010
New Revision: 167713
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167713
Log:
2010-12-11 Mikael Morin
Jerry DeLi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #25 from H.J. Lu 2010-12-11 20:04:23
UTC ---
(In reply to comment #24)
> > I have said "If you have constructor priorities in .o files and .c
> > files, you may get different behaviors if .o files are compiled with
> > a different co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #24 from Mark Mitchell 2010-12-11
19:56:43 UTC ---
On 12/11/2010 11:53 AM, hjl.tools at gmail dot com wrote:
>> You have to be more specific about what you meant by "interleaving".
Constructor priorities are a GNU C extension:
__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #23 from H.J. Lu 2010-12-11 19:53:05
UTC ---
(In reply to comment #22)
> (In reply to comment #21)
> > H.J. --
> >
> > Let's just answer the yes-or-no question: is the interleaving going to work
> > or
> > isn't it?
> >
>
> You
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #22 from H.J. Lu 2010-12-11 19:51:00
UTC ---
(In reply to comment #21)
> H.J. --
>
> Let's just answer the yes-or-no question: is the interleaving going to work or
> isn't it?
>
You have to be more specific about what you meant b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #21 from Mark Mitchell 2010-12-11
19:47:38 UTC ---
H.J. --
Let's just answer the yes-or-no question: is the interleaving going to work or
isn't it?
I can't see how it possibly can, given the linker script fragment you posted.
And
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #20 from H.J. Lu 2010-12-11 19:46:46
UTC ---
(In reply to comment #12)
> OK, do you know why the order of execution of .ctor was chosen to be reversed
> even if it would make more sense to reverse .dtors?
>
Now I remembered. The rev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #19 from H.J. Lu 2010-12-11 19:44:30
UTC ---
Created attachment 22717
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22717
A demo of mixing .init_array and .ctors
Here is a demo of mixing .init_array and .ctors with
priority. in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #18 from Mark Mitchell 2010-12-11
19:33:17 UTC ---
On 12/11/2010 11:03 AM, hjl.tools at gmail dot com wrote:
> I am not sure about GOLD. But it usually follows GNU linker.
> For GNU linker, the constructor priority is honored within
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #17 from H.J. Lu 2010-12-11 19:02:40
UTC ---
(In reply to comment #16)
> On 12/11/2010 10:47 AM, hjl.tools at gmail dot com wrote:
>
> > Linker supports sorting .ctors.N and .init_array..
> > Within .ctors.N and .init_arr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #16 from Mark Mitchell 2010-12-11
18:50:11 UTC ---
On 12/11/2010 10:47 AM, hjl.tools at gmail dot com wrote:
> Linker supports sorting .ctors.N and .init_array..
> Within .ctors.N and .init_array., the order is define
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #15 from H.J. Lu 2010-12-11 18:46:48
UTC ---
(In reply to comment #14)
> H.J. --
>
> Some of the statements that you're making in Comment #11 are inaccurate or
> unclear:
>
> Given:
>
> Foo foo(...);
> Bar bar(...);
>
> within
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
Mark Mitchell changed:
What|Removed |Added
CC||mmitchel at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46625
--- Comment #4 from Tobias Burnus 2010-12-11
17:48:16 UTC ---
Submitted patch: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00929.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46895
Summary: FAIL: gcc.target/i386/max-stack-align.c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #13 from H.J. Lu 2010-12-11 16:53:41
UTC ---
(In reply to comment #12)
> > > 2) I believe that the backwarding order of .ctor section was concious
> > > QOI issue. I wonder how much legacy code this might break when
> > > sta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #12 from Jan Hubicka 2010-12-11 16:17:38
UTC ---
> > 2) I believe that the backwarding order of .ctor section was concious
> > QOI issue. I wonder how much legacy code this might break when static
> > libraries start init
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45201
Dave Korn changed:
What|Removed |Added
CC||davek at gcc dot gnu.org
--- Comment #10 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46705
--- Comment #4 from Jerry DeLisle 2010-12-11
16:02:51 UTC ---
This appears to resolve the double warning issue. Regression testing now.
Index: scanner.c
===
--- scanner.c(revis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46705
--- Comment #3 from Jerry DeLisle 2010-12-11
15:54:38 UTC ---
If you look at the test case you will see that the '&' issue is outside of the
quotes in the format statement. Right away this told me we should not be
getting the warning at all sinc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
H.J. Lu changed:
What|Removed |Added
CC||ccoutant at google dot com
--- Comment #11 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
--- Comment #8 from Jan Hubicka 2010-12-11 15:03:44 UTC
---
Note that while working on mozilla, I noticed that SUN's compiler extends the
toplevel asm syntax by allowing parameters (and the usual %n references to
them). It probably makes sense t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #10 from Jan Hubicka 2010-12-11 15:01:34
UTC ---
> This explanation doesn't stand: for instance, ARM EABI exclusively uses
> .init_array, and the execution order for those is forward. And when linking
> static libraries, the order of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #9 from Mike Hommey 2010-12-11
14:36:36 UTC ---
(In reply to comment #7)
> Hi,
> thanks for testcase. What I was concerned about is the static linking case.
> When you have static library with constructors and main program with
> con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #8 from H.J. Lu 2010-12-11 14:28:35
UTC ---
(In reply to comment #7)
> Hi,
> thanks for testcase. What I was concerned about is the static linking case.
> When you have static library with constructors and main program with
> constru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770
--- Comment #7 from Jan Hubicka 2010-12-11
14:15:04 UTC ---
Hi,
thanks for testcase. What I was concerned about is the static linking case.
When you have static library with constructors and main program with
constructors, my understanding was t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46894
--- Comment #1 from Dominique d'Humieres 2010-12-11
13:55:27 UTC ---
Also seen on powerpc64-unknown-linux-gnu [trunk revision 167644]:
http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg00829.html (but for
tmpdir-gcc.dg-struct-layout-1/t027)
Runni
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46820
--- Comment #7 from Jan Hubicka 2010-12-11 13:31:21 UTC
---
> int __attribute__((used)) bar(void)
> {
> return 0;
> }
> __asm__(".weak\tfoo\n\t.set\tfoo,bar");
>
> bar ends up in a different partition than the asm which then of course
> doesn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46842
--- Comment #23 from Dominique d'Humieres
2010-12-11 13:00:10 UTC ---
The patch in comment #21 also fixes the test in comment #16, but not the one in
comment #12.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
--- Comment #5 from Thomas Koenig 2010-12-11
12:38:01 UTC ---
gfc_check_same_strlen does not check for references.
Ouch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46856
--- Comment #4 from Mikael Pettersson 2010-12-11
12:17:46 UTC ---
Jakub's r166371 is innocent, all it did was to revert an expansion mode change
in r162618 (2nd PR44790 patch). Trunk actually started to ICE for this test
case on m68k in r162270:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710
--- Comment #7 from Dave Korn 2010-12-11 10:46:22
UTC ---
(In reply to comment #6)
> Although I haven't verified that this is the same as the original problem
> report, it really looks like it, modulo various changes to the compiler's
> internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46894
Summary: [4.6 Regression] vector fails on powerpc-darwin9
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
As
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710
Dave Korn changed:
What|Removed |Added
Last reconfirmed|2006-11-10 19:32:46 |2010-12-11 19:32:46
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31821
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861
--- Comment #5 from Jay 2010-12-11 09:40:39 UTC
---
No problem with 4.4.5 either.
j...@alphalinux:~$ $HOME/gcc-4.4.5/bin/gcc -v
Using built-in specs.
Target: alphaev5-unknown-linux-gnu
Configured with: /home/jay/src/gcc-4.4.5/configure -prefix=/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861
--- Comment #4 from Jay 2010-12-11 08:47:22 UTC
---
It appears to also be ok in 4.3.5.
j...@alphalinux:~$ $HOME/gcc-4.3.5/bin/gcc -v
Using built-in specs.
Target: alphaev5-unknown-linux-gnu
Configured with: /home/jay/src/gcc-4.3.5/configure -pr
79 matches
Mail list logo
