Ehren Metcalfe wrote:
I've recently come across a couple of issues trying to compile Firefox
trunk with 4.5 (I have a very simple plugin that I need to run on
mozilla-central). I've posted two bugs here
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42139 and here
On Wed, Nov 25, 2009 at 1:17 AM, Andrew Haley a...@redhat.com wrote:
Is the symbol
`nsAccessibleWrap::ReturnString(nsAString_internal)::returnedString'
defined anywhere?
This sounds like bug 41611. Is
nsAccessibleWrap::ReturnString(nsAString_internal) an inline function
(which causes that
Trunk 154492 is uncompilable on Cygwin because
of incorrect data types in LTO. It compiles with the
attached fixes, but I have no write access to the
repository. Could someone please apply them?
Best regards
Piotr Wyderski
Index: gcc/lto-streamer-out.c
On Wed, Nov 25, 2009 at 10:30 AM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
Trunk 154492 is uncompilable on Cygwin because
of incorrect data types in LTO. It compiles with the
attached fixes, but I have no write access to the
repository. Could someone please apply them?
I see only
After upgrade to trunk-20091124:
class C {
protected:
C(const C) = default;
};
main.cpp:1506:23: error: 'C::C(const C)' declared with non-public access cannot
be defaulted in the class body
But I can't find anything about it in the N3000 draft.
Should I file a GCC bug
On 11/19/09 18:28, Larry Evans wrote:
On 11/19/09 17:23, Jason Merrill wrote:
On 11/17/2009 09:36 AM, Larry Evans wrote:
Could g++ provide this feature? How hard would it be to implement.
It probably wouldn't be difficult to implement, but I'd want someone
to champion the extension with the
Yup, ReturnString is inline:
http://hg.mozilla.org/mozilla-central/file/d76583175408/accessible/src/atk/nsAccessibleWrap.h#l114
I'll change it and try a build,
Ehren
On Wed, Nov 25, 2009 at 4:24 AM, Andrew Pinski pins...@gmail.com wrote:
On Wed, Nov 25, 2009 at 1:17 AM, Andrew Haley
I just changed it,
Firefox now compiles with 4.5!
Thanks for your help,
Ehren
On Wed, Nov 25, 2009 at 8:11 AM, Ehren Metcalfe ehre...@gmail.com wrote:
Yup, ReturnString is inline:
http://hg.mozilla.org/mozilla-central/file/d76583175408/accessible/src/atk/nsAccessibleWrap.h#l114
I'll change
Hello,
It seems to me that tree balancing risk of producing wrong result due
to overflow of subexpression.
Say a = INT_MIN, b = 10, c = 10, d = INT_MAX.
If
((a + b) + c) + d))
becomes
((a + b) + (c + d))
c + d will overflow and the original won't. So the behaviour of
two are different.
On Wed, Nov 25, 2009 at 2:52 PM, Bingfeng Mei b...@broadcom.com wrote:
Hello,
It seems to me that tree balancing risk of producing wrong result due
to overflow of subexpression.
Say a = INT_MIN, b = 10, c = 10, d = INT_MAX.
If
((a + b) + c) + d))
becomes
((a + b) + (c + d))
c + d will
Hi All :
It's possible to define multi delay slots for branch insns by using
define_delay,
and different slot should satisfy its own attribute test delay-n.
Here comes question, in function fill_simple_delay_slots, seems
it only uses
slots_filled to record how many slots needs to fill, and
On Tue, 24 Nov 2009, Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and there's
no need to use -mtune=generic. Is that right?
Seems to work. What other side effects has that ?
I'm am fixing some reload bugs for AVR.
In a couple of situations an address is formed which included a SUBREG
expression.
I am not sure how I should be handling these. Initial attempts produce
sub-optimal code - and/or reload failures, so thought is a good idea to
get some advise!
Either
* Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 Nov 2009, Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and
there's
no need to use -mtune=generic. Is that right?
On Wed, 25 Nov 2009, Ingo Molnar wrote:
* Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 Nov 2009, Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and
there's
no
On Mon, Nov 23, 2009 at 10:17 AM, Ian Bolton bol...@icerasemi.com wrote:
David Edelsohn wrote:
On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton bol...@icerasemi.com
wrote:
From some simple experiments (see below), it appears as though GCC
aims
to
create a lop-sided tree when there are
* Thomas Gleixner t...@linutronix.de wrote:
On Wed, 25 Nov 2009, Ingo Molnar wrote:
* Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 Nov 2009, Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with
Author: hjl
Date: Wed Nov 25 10:55:54 2009
New Revision: 154645
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154645
Log:
Remove trailing white spaces.
WTF?
Thankyouverymuch.
This 1) wasn't posted or approved 2) is bad as it breaks svn blame
3) chokes all branches.
What's up?
Richard.
On Wed, 25 Nov 2009, Richard Guenther wrote:
Author: hjl
Date: Wed Nov 25 10:55:54 2009
New Revision: 154645
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154645
Log:
Remove trailing white spaces.
WTF?
Thankyouverymuch.
This 1) wasn't posted or approved 2) is bad as it
The release of GNU MPFR 2.4.2 (andouillette sauce moutarde
patch level 2) is imminent. Please help to make this release
as good as possible by downloading and testing this second
release candidate:
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc3.tar.xz
On Wed, Nov 25, 2009 at 04:44:52PM +0100, Ingo Molnar wrote:
* Thomas Gleixner t...@linutronix.de wrote:
On Tue, 24 Nov 2009, Jakub Jelinek wrote:
On Tue, Nov 24, 2009 at 03:55:49PM +0100, Thomas Gleixner wrote:
you should compile your code with -maccumulate-outgoing-args, and
Can someone please remove this revision from the subversion database
on the server and fix things up? If that's not possible at least
the revision should be reverted.
Why the latter? I agree with the problems this can cause, but if they
can't be fixed by removing it from the database, why
On Wed, 25 Nov 2009, Richard Kenner wrote:
Can someone please remove this revision from the subversion database
on the server and fix things up? If that's not possible at least
the revision should be reverted.
Why the latter? I agree with the problems this can cause, but if they
can't
On 11/25/09 09:51, Richard Kenner wrote:
Can someone please remove this revision from the subversion database
on the server and fix things up? If that's not possible at least
the revision should be reverted.
Why the latter? I agree with the problems this can cause, but if they
can't be
Hi,
On Wed, 25 Nov 2009, Richard Guenther wrote:
Remove trailing white spaces.
WTF?
Thankyouverymuch.
This 1) wasn't posted or approved 2) is bad as it breaks svn blame
3) chokes all branches.
What's up?
Can someone please remove this revision from the subversion
Hi,
On Wed, 25 Nov 2009, Jeff Law wrote:
On 11/25/09 09:51, Richard Kenner wrote:
Can someone please remove this revision from the subversion database
on the server and fix things up? If that's not possible at least
the revision should be reverted.
Why the latter? I agree
And local patches. Basically _no_ patch will apply anymore as HJ changed
every single file.
That's an exaggeration since only a few lines in each file were change. The
vast majority of outstanding patches won't be affected.
In an ideal world, yes. But it's not a clever idea to burn down
On 11/25/09 10:09, Michael Matz wrote:
Hi,
On Wed, 25 Nov 2009, Jeff Law wrote:
On 11/25/09 09:51, Richard Kenner wrote:
Can someone please remove this revision from the subversion database
on the server and fix things up? If that's not possible at least
the revision should be
On Wed, 25 Nov 2009, Jeff Law wrote:
In many ways I prefer the bulk change -- once done you don't have to worry
about it again for a long time. Of course one could claim HJ's timing is
terrible.
Doing it right at the end of branch-to-trunk merges for a release (which
is where we are right
Not as bulk changes that don't do anything else, rather only as part of
changes that touch the relevant parts anyway.
Yes we have allowed this kind of change in-bulk without changing
anything else.
In many ways I prefer the bulk change -- once done you don't have to
worry about
Michael Matz wrote:
Someone with the appropriate rights needs to shutdown the svn server so
that no additional commits can be done, then the revision files in
db/revs/ and db/revprops/ starting with the wrong revision need to be
removed, then db/current needs to be changed appropriately.
Joseph S. Myers wrote:
Doing it right at the end of branch-to-trunk merges for a release (which
is where we are right now, just after merges from Graphite) is probably
the optimal timing in terms of minimising the amount of branches that will
need fixing up. The problem is doing it
Hi,
On Wed, 25 Nov 2009, Richard Kenner wrote:
And local patches. Basically _no_ patch will apply anymore as HJ changed
every single file.
That's an exaggeration since only a few lines in each file were change.
The top 12 from the 2.2 MB patch:
tree-vect-loop.c | 386
In my mind it's very simple: trailing whitespace poses exactly _no_
problem (except of being against the coding standard),
It's against the coding standards for a very good reason, which is that it
makes patching harder because you have lines that compare differently but
look identical. So
On Wed, 25 Nov 2009, Richard Kenner wrote:
And local patches. Basically _no_ patch will apply anymore as HJ changed
every single file.
That's an exaggeration since only a few lines in each file were change. The
vast majority of outstanding patches won't be affected.
In an ideal
On Wed, 25 Nov 2009, Dave Korn wrote:
Joseph S. Myers wrote:
Doing it right at the end of branch-to-trunk merges for a release (which
is where we are right now, just after merges from Graphite) is probably
the optimal timing in terms of minimising the amount of branches that will
On Wed, 25 Nov 2009, Richard Kenner wrote:
In my mind it's very simple: trailing whitespace poses exactly _no_
problem (except of being against the coding standard),
It's against the coding standards for a very good reason, which is that it
makes patching harder because you have lines
On Wed, 25 Nov 2009, Dave Korn wrote:
Joseph S. Myers wrote:
Doing it right at the end of branch-to-trunk merges for a release
(which
is where we are right now, just after merges from Graphite) is
probably
the optimal timing in terms of minimising the amount of branches that
will
On Wed, 25 Nov 2009, Richard Guenther wrote:
On Wed, 25 Nov 2009, Richard Kenner wrote:
In my mind it's very simple: trailing whitespace poses exactly _no_
problem (except of being against the coding standard),
It's against the coding standards for a very good reason, which is
On Wed, Nov 25, 2009 at 08:31:27PM +0100, Richard Guenther wrote:
And patch doesn't have an option to ignore whitespace changes.
Sure it does. -l (for loose, or --ignore-whitespace).
QUILT_PATCH_OPTS for quilt.
--
Daniel Jacobowitz
CodeSourcery
May I make a subject line change please ?
This issue is trivial trailing whitespace changes I think and procedures,
process and notice of such changes.
--
Dennis Clarke
dcla...@opensolaris.ca - Email related to the open source Solaris
dcla...@blastwave.org - Email related to open source for
Richard Guenther wrote:
Btw, I'd be happy with a commit hook that forces you to fix
whitespace in the area you patch (basically just make sure there
is no trailing whitespace in ^[+ ] lines of a unified diff
(maybe even only in ^+ lines to not cause continuous rejects
if you fixup the ^ lines
On 11/25/09 12:33, Richard Guenther wrote:
On Wed, 25 Nov 2009, Dave Korn wrote:
Joseph S. Myers wrote:
Doing it right at the end of branch-to-trunk merges for a release (which
is where we are right now, just after merges from Graphite) is probably
the optimal timing in terms of
On 11/25/09 12:55, Basile STARYNKEVITCH wrote:
Richard Guenther wrote:
Btw, I'd be happy with a commit hook that forces you to fix
whitespace in the area you patch (basically just make sure there
is no trailing whitespace in ^[+ ] lines of a unified diff
(maybe even only in ^+ lines to not
On 11/25/09 12:41, Dennis Clarke wrote:
Gentlemen, a point of order please.
Many people read these lists and we place high regard on the quality of
the GCC project as well as the people involved. A personal slight as well
as an error may happen from time to time but this is simply the nature
On 11/24/2009 09:30 AM, Steven Rostedt wrote:
For other archs, Linus showed some examples:
http://lkml.org/lkml/2009/11/19/349
Yes; the key here is that the ABI-defined entry state is readily
mappable onto the state on entry to the __fentry__ function.
-hpa
--
H. Peter Anvin,
Jeff Law wrote:
Ultimately I think there are X issues here.
1. What to do in the immediate term with the repo. I've got no strong
opinions here.
I do understand most of the opinions, but I would rather prefer that we don't
revert the trailing whitespace patch.
I definitely can live with
On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
then certainly coming up with a new gcc switch and new profiling ABI is
desirable. -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
makes code on these register
On Wed, 25 Nov 2009, Richard Guenther wrote:
That's not an option. That would basically tell you that you can get
away with breaking the rules if you just take the blame. And I just
checked and none of my 12 local patches I queued for stage1 apply
anymore. And as usual there are big hunks
Jeff Law wrote:
On 11/25/09 12:41, Dennis Clarke wrote:
Gentlemen, a point of order please.
Let us not degrade into a base argument
I don't see anything in this discussion that's out of the ordinary for
this group of engineers. We've had (and will certainly have) far more
heated
Kaveh R. GHAZI wrote:
I think we need to take a deep breath and relax. First of all, HJ didn't
need approval for this patch. Whether it's useful or not, it aligns with
our stated coding standards and it clearly qualifies as obvious under the
Free for all category in our checkin policies.
On Wed, 25 Nov 2009, Dave Korn wrote:
Kaveh R. GHAZI wrote:
I think we need to take a deep breath and relax. First of all, HJ didn't
need approval for this patch. Whether it's useful or not, it aligns with
our stated coding standards and it clearly qualifies as obvious under the
From: Dave Korn dave.korn.cyg...@googlemail.com
But does it, though? From http://gcc.gnu.org/svnwrite.html:
Free for all
The following changes can be made by everyone with SVN write access:
Fixes for obvious typos in ChangeLog files, docs, web pages, comments and
similar stuff. Just check
From: Richard Guenther rguent...@suse.de
The change certainly didn't fall under the obvious rule because of its
size. One might argue that 'and similar stuff' covers coding-style
changes, but here again I'd fear of a certain kind of people going
wild and follow the coding-style by word rather
Fixes for obvious typos in ChangeLog files, docs, web pages, comments and
similar stuff. Just check in the fix and copy it to gcc-patches. We don't
want to get overly anal-retentive about checkin policies.
Incorrect whitespace is a typo. I.e. an error in typed material.
Yes, but it's
Kaveh R. Ghazi wrote:
From: Dave Korn dave.korn.cyg...@googlemail.com
But does it, though? From http://gcc.gnu.org/svnwrite.html:
Free for all
The following changes can be made by everyone with SVN write access:
Fixes for obvious typos in ChangeLog files, docs, web pages, comments
and
From: Dave Korn dave.korn.cyg...@googlemail.com
Agreed, but what I'm not at all certain is whether it counts as *in*
ChangeLog files, docs, web pages, comments and similar stuff,
specifically
when it's at the end of a line of functional C code in a source file.
Since whitespace in C has no
Kaveh R. Ghazi wrote:
From: Dave Korn dave.korn.cyg...@googlemail.com
Agreed, but what I'm not at all certain is whether it counts as *in*
ChangeLog files, docs, web pages, comments and similar stuff,
specifically
when it's at the end of a line of functional C code in a source file.
From: Richard Kenner ken...@vlsi1.ultra.nyu.edu
I suspect the web page in question needs to be updated to
more accurately reflect current standard practice. It appears wrong to me
on more counts than just this one (my understanding has always been that
no
approval is needed to fix typos,
Hello,
Is it possible to use -fprofile-generate on shared libraries,
which are loaded at runtime (dlopen'ed) by an executable not compiled
with profiling support?
The library loads and runs fine, but doesn't generate any profile output.
Thank you in advance, Clemens
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
My wish would be that every C source file in GCC would be indent-ed by GNU
indent with --gnu option. But since this has not been done, I suppose it is
(sadly) not realistic. I don't understand all the issues involved (but I do
There are various
H. Peter Anvin wrote:
On 11/25/2009 08:44 AM, Jakub Jelinek wrote:
If you compile kernels 90%+ people out there run with -p on i?86/x86_64,
then certainly coming up with a new gcc switch and new profiling ABI is
desirable. -p on i?86/x86_64 e.g. forces -fno-omit-frame-pointer, which
makes
Jeff Law wrote:
Ultimately I think there are X issues here.
1. What to do in the immediate term with the repo. I've got no
strong opinions here.
2. What to do longer term. I'd like to see us fix the whitespace
stuff then use hooks or a cron job to make sure they don't come back
On Wed, 25 Nov 2009, Vincent Lefevre wrote:
The release of GNU MPFR 2.4.2 (andouillette sauce moutarde
patch level 2) is imminent.
I tested mpfr-2.4.2rc3 on sparc-sun-solaris2.9 in 32 and 64 bit modes. I
compiled with both gcc-3.4.6 and Sun C 5.5. All four configurations built
and passed
Joseph S. Myers wrote:
On Wed, 25 Nov 2009, Basile STARYNKEVITCH wrote:
My wish would be that every C source file in GCC would be indent-ed by GNU
indent with --gnu option. But since this has not been done, I suppose it is
(sadly) not realistic. I don't understand all the issues involved (but
On 11/25/2009 08:38 PM, Richard Guenther wrote:
If you can offer advice on how to teach quilt
(which I belive uses patch) to ignore whitespace changes when
applying patches then more power to you - the only tool that
seems to be able to ignore whitespace changes is diff.
sed -i '/^-/s/[
On 11/25/2009 06:45 PM, Dave Korn wrote:
Michael Matz wrote:
Someone with the appropriate rights needs to shutdown the svn server so
that no additional commits can be done, then the revision files in
db/revs/ and db/revprops/ starting with the wrong revision need to be
removed, then db/current
Quoting Basile STARYNKEVITCH bas...@starynkevitch.net:
I would imagine that patching GNU indent (in its source code form)
requires a copyright assignment specific to it (and uncovered by a, or
at least mine, GCC copyright assigment to FSF). If this is the case,
I [Basile] won't do it (because
Joern Rennecke wrote:
Quoting Basile STARYNKEVITCH bas...@starynkevitch.net:
I would imagine that patching GNU indent (in its source code form)
requires a copyright assignment specific to it (and uncovered by a, or
at least mine, GCC copyright assigment to FSF). If this is the case,
I [Basile]
Basile == Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Basile Of course, not every one has it (notably those working on non-linux
Basile systems), but for those who have it, requiring that every C file
Basile inside GCC has been automatically indented with GNU indent could
Basile help.
On Thu, Nov 26, 2009 at 12:04 AM, Tom Tromey tro...@redhat.com wrote:
Basile == Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Basile Of course, not every one has it (notably those working on non-linux
Basile systems), but for those who have it, requiring that every C file
Basile
On Wed, 2009-11-25 at 15:17 -0500, Kaveh R. GHAZI wrote:
Finally, we have a process for reverting a patch. If anyone wants to
revert some part, it needs to be followed. Otherwise *that* would be
breaking the rules...
Won't reverting the patch just attribute all of the lines to the
username
On Nov 25, 2009, Daniel Jacobowitz d...@false.org wrote:
On Wed, Nov 25, 2009 at 08:31:27PM +0100, Richard Guenther wrote:
And patch doesn't have an option to ignore whitespace changes.
Sure it does. -l (for loose, or --ignore-whitespace).
QUILT_PATCH_OPTS for quilt.
And even without this,
On Wed, 25 Nov 2009, Tom Tromey wrote:
Basile == Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Basile Of course, not every one has it (notably those working on non-linux
Basile systems), but for those who have it, requiring that every C file
Basile inside GCC has been automatically
Richard Guenther wrote:
On Thu, Nov 26, 2009 at 12:04 AM, Tom Tromey tro...@redhat.com wrote:
Basile == Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Basile Of course, not every one has it (notably those working on non-linux
Basile systems), but for those who have it, requiring that
Sorry for that. I did send an email and though it was an obvious fix. I guess
the patch may be too big, 400K with bz2.
H.J.
-Original Message-
From: Richard Guenther [mailto:rguent...@suse.de]
Sent: Wednesday, November 25, 2009 8:39 AM
To: gcc@gcc.gnu.org
Cc: Lu, Hongjiu
FWIW, I have been using git to maintain my patches. I created a branch
for each patch.
Update and merge are almost automatic. It works quite well for me.
H.J.
On Wed, Nov 25, 2009 at 3:51 PM, Lu, Hongjiu hongjiu...@intel.com wrote:
Sorry for that. I did send an email and though it was an
2009/11/25 Piotr Wyderski:
After upgrade to trunk-20091124:
class C {
protected:
C(const C) = default;
};
main.cpp:1506:23: error: 'C::C(const C)' declared with non-public access
cannot
be defaulted in the class body
But I can't find anything about it in the N3000
Quoting Basile STARYNKEVITCH bas...@starynkevitch.net:
Why would the GCC code written in C become less readable if we decided
to GNU indent it? There might be some corner cases which could be
handled by clever /* *INDENT-OFF* */ comments.
GNU indent becomes so confused by some constructs in
It seems that original limitation isn't clear or sufficient
For a sample:
// f.c
int g;
void foo(void)
{
g = 1;
}
compile with `gcc -shared -fPIC -Wl,-soname,f.so,-Map,f.map -o f.so f.c',
according to f.map, offsetof(g - foo) in library is 0x1550 - 0x3cc = 0x1184,
however let's load the
On 11/25/2009 06:24 PM, yunfeng zhang wrote:
It seems that original limitation isn't clear or sufficient
For a sample:
// f.c
int g;
void foo(void)
{
g = 1;
}
compile with `gcc -shared -fPIC -Wl,-soname,f.so,-Map,f.map -o f.so f.c'...
With -fPIC, the variable G may be overridden by
The result is the same
#includestdio.h
extern int g __attribute__((visibility(hidden)));
int g;
int foo(int a, int b)
{
g = a + b;
printf(%x, %x, g, foo);
return g;
}
load and call `foo' in the library, an outputting (with vdso) is
cc15bc, cc03fc
and open f.map
Jonathan Wakely wrote:
This is DR906
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#906
Thanks.
Note it shall be public
And what's the reason for such restrictions?
I've used the following construction as a very
useful idiom to create an abstract class:
class Base {
On Nov 26, 2009, yunfeng zhang zyf.zer...@gmail.com wrote:
The result is the same
But the code isn't. See how, with hidden, we use the fixed offset.
Now remove the hidden attribute, define g also in the main program, and
see what it prints.
--
Alexandre Oliva, freedom fighter
--- Comment #18 from jakub at gcc dot gnu dot org 2009-11-25 08:59 ---
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01392.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18624
The attached test case contains several continuous bit fields assignment,
compile it with options -mthumb -Os, gcc generates
.fnstart
.LFB1:
ldrbr3, [r0]
mov r2, #7
bic r3, r3, r2
strbr3, [r0]
ldrbr3, [r0]
mov r2, #56
--- Comment #1 from carrot at google dot com 2009-11-25 09:16 ---
Created an attachment (id=19147)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19147action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42172
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-25 09:24 ---
This sounds like bug 41611. Is
nsAccessibleWrap::ReturnString(nsAString_internal) an inline function (which
causes that variable to be vague linkage)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42171
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-25 09:40 ---
*** This bug has been marked as a duplicate of 37135 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jakub at gcc dot gnu dot org 2009-11-25 09:40 ---
*** Bug 42172 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from johan dot gill at gmail dot com 2009-11-25 10:02
---
I get this error when building swfdec with gcc 4.4.2 on Fedora 12.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
--- Comment #7 from johan dot gill at gmail dot com 2009-11-25 10:06
---
Also tried the simple test case described in the bug description, although it
needs to add #include string.h at the top.
The warning is still there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36513
--- Comment #6 from hjl dot tools at gmail dot com 2009-11-25 10:10 ---
Gcc 4.5 generates:
---
.file pr41611.cc
.weak _ZGVZN1A4InitEvE1i
.section
.bss._ZGVZN1A4InitEvE1i,awG,@nobits,_ZZN1A4InitEvE1i,comdat
.align 8
.type
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42168
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu dot
|
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-11-25 10:19
---
testcase from comment #7 still fails on the 4.4 branch. 4.4.1 doesn't work.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from johan dot gill at gmail dot com 2009-11-25 10:26
---
Created an attachment (id=19148)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19148action=view)
Preprocessed source file
Created a preprocessed source file producing the warning.
--
--- Comment #6 from zsojka at seznam dot cz 2009-11-25 10:45 ---
Also it causes bootstrap comparison failures for me at x86_64-pc-linux-gnu,
r154643
export CFLAGS=-O2 -fgcse-sm
export CXXFLAGS=-O2 -fgcse-sm
../configure --enable-languages=c,c++
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-11-25 11:01
---
Subject: Bug 42170
Author: ebotcazou
Date: Wed Nov 25 11:01:26 2009
New Revision: 154646
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154646
Log:
PR ada/42170
* ada/acats/run_acats: Bump
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-11-25 11:03
---
Thanks for reporting this.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 148 matches
Mail list logo
