On Nov 26, 2009, yunfeng zhang 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 fighterhttp://FSFLA.org/~lxoliva/
You
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 {
The result is the same
#include
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
0x1
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 a
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
Quoting Basile STARYNKEVITCH :
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 GCC that the result
becomes
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
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 wrote:
> Sorry for that. I did send an email and though it was an obvious fix. I guess
> t
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
> S
Richard Guenther wrote:
On Thu, Nov 26, 2009 at 12:04 AM, Tom Tromey wrote:
"Basile" == Basile STARYNKEVITCH 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
On Wed, 25 Nov 2009, Tom Tromey wrote:
> > "Basile" == Basile STARYNKEVITCH 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
On Nov 25, 2009, Daniel Jacobowitz 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, given tha
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
usernam
On Thu, Nov 26, 2009 at 12:04 AM, Tom Tromey wrote:
>> "Basile" == Basile STARYNKEVITCH 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 automaticall
> "Basile" == Basile STARYNKEVITCH 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.
I looked at t
Joern Rennecke wrote:
Quoting Basile STARYNKEVITCH :
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 ge
Quoting Basile STARYNKEVITCH :
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 getting a copyright assig
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
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/[ \t]*$//
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 I
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
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 com
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
>>
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 vario
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
From: "Richard Kenner"
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, whether in code or comments,
Kaveh R. Ghazi wrote:
> From: "Dave Korn"
>
>> 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
From: "Dave Korn"
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 syntactic effect, certainly
Kaveh R. Ghazi wrote:
> From: "Dave Korn"
>
>> 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
>>> s
> >> 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.
Ye
From: "Richard Guenther"
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 than existing
pr
From: "Dave Korn"
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 in the fix and copy it to gcc
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 t
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 poli
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
> heat
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 hun
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 regis
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 t
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 Anvi
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 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 caus
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 min
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 i
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 fo
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
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, w
> 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 t
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 l
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 wil
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
> 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
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 | 3
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 wit
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
> >>
> > 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
> wo
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
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 reve
> 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 dow
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 lat
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
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 f
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 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, Nov 25, 2009 at 04:44:52PM +0100, Ingo Molnar wrote:
>
> * Thomas Gleixner 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
> > >
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
http://www.mpfr.org/mpfr-2.4.2/mpfr-2.4.2-rc3
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=gcc&view=rev&rev=154645
> Log:
> Remove trailing white spaces.
>
> WTF?
>
> Thankyouverymuch.
>
> This 1) wasn't posted or approved 2)
Author: hjl
Date: Wed Nov 25 10:55:54 2009
New Revision: 154645
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=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
* Thomas Gleixner wrote:
> On Wed, 25 Nov 2009, Ingo Molnar wrote:
> > * Thomas Gleixner 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-outgoin
On Mon, Nov 23, 2009 at 10:17 AM, Ian Bolton wrote:
> David Edelsohn wrote:
>> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton
>> wrote:
>> > From some simple experiments (see below), it appears as though GCC
>> aims
>> > to
>> > create a lop-sided tree when there are constants involved (func1
>> be
On Wed, 25 Nov 2009, Ingo Molnar wrote:
> * Thomas Gleixner 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
> > > > > n
* Thomas Gleixner 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?
> > >
>
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
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
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, a
On Wed, Nov 25, 2009 at 2:52 PM, Bingfeng Mei 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 over
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. Thoug
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 wrote:
> 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
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 wrote:
> On Wed, Nov 25, 2009 at 1:17 AM, Andrew Haley wrote:
>>
>> Is the symbol
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
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 re
On Wed, Nov 25, 2009 at 10:30 AM, Piotr Wyderski
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 whitespace changes. Please
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 1:17 AM, Andrew Haley 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 variable to
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
> http://gcc.gnu.org/bugzilla
84 matches
Mail list logo
