does not do this either.)
I'm not particularly concerned about differing from MSVC on these
points; I'm just noting them for posterity.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
remove it is pre-approved after testing.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
GCC release (including both its strengths and its weaknesses), then the
only practical choice is to carry around that your release yourself.
Regards,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
create
the first release candidate.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
nges.
I still think we need to drive the numbers lower before we branch. I
know everyone's eager to start on 4.2, but I bet we can fix a lot of
these bugs with relatively small amounts of effort, if we focus on those
problems.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
e
variations in quality; that's why we freeze in the period immediately
before the release.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
rect; we just need to sort out the
details now.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
27;s worth fixing a wrong-code regression, but not
worth risking trouble to improve scheduling, but we're not at that point
yet.
If you have a particular patch in hand, and you're not comfortable
deciding whether it's reasonable to include it, feel free to ask me.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
also missing the status link for the 4.0.1 series.
Typically, Gerald has done this, but I've taken care of updating the
links, with the attached patch.
I'll address your other comment (re. bugzilla queries) shortly.
--
Mark Mitchell
CodeSourcery, LLC
[EM
TED
friends, and then call is_friend (fn, c) for each c in the set of
argument-dependent classes. That's wort-case quadratic, and we could
make it cleverer, but I'd start with that.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Ian Lance Taylor wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>
>
>>Let's start with the simpler friend10.C. There, the "operator bool()"
>>conversion operator is irrelevant, as far as I can see. However, we
>>*should* still call the friend
ooking at
benchmark performance. I think that, for good or ill, SPEC numbers are
incredibly important to people. Making those numbers good is a key
aspect of making FSF GCC competitive. I'm not suggesting we ignore
"real" code, but I am suggesting that benchmark performance is one o
it really a bug?
>
> Andrew.
>
> quoted message ----
> From: "Mark Nelson" <[EMAIL PROTECTED]>
> Newsgroups: gnu.gcc.help
> Subject: uncaught exception in g++ 3.4 and 4.0
> Date: 13 Aug 2005 08:35:46 -07
e the patch URL; I'll give it a quick
once-over, and then, very likely, ask you to go ahead and check it in.
All as-of-yet unapproved patches require my explicit proposal between
now and the actual 4.0.2 release.
I will update the web page shortly to reflect current status.
--
Mark Mitchell
Code
for all of GCC's architectures
will be present in any back end other than the FSF back end.
> Competition and exchange of ideas are always a good idea, though.
Indeed.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
e gcc-testresults mailing list with and
contrib/test_summary. If you encounter problems, please file them in
bugzilla, and add me to the CC: list.
Assuming that no critical problems emerge, I'll do the final release
within the next week.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>
>>It's important to test the actual tarballs, rather than CVS, to check
>>for any packaging issues. If you can, download and build the tarballs,
>>post test results to the gcc-testresults mailing list with and
Laurent GUERBY wrote:
> On Wed, 2005-09-14 at 08:13 -0700, Mark Mitchell wrote:
>
>>Assuming that no critical problems emerge, I'll do the final release
>>within the next week.
>
>
> Looks good on x86-linux and x86_64-linux for Ada:
Thanks.
--
Mark Mitchell
Co
Paul Brook wrote:
> On Wednesday 14 September 2005 16:13, Mark Mitchell wrote:
>
>>GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org
>
>
> arm-none-elf results look good:
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg00780.html
Thanks.
--
Mark Mi
Ian Lance Taylor wrote:
> Mark, in PR c++/11987 you added a comment saying that it was a
> regression. But the more I look at it, the less I understand it.
>
> The test case is:
>
> ==
> template struct X
oo () {}
>
> template struct Y<1>;
> ==
This should be invalid too, assuming I'm remembering correctly. I think
you have to say X::I::foo() when you make the definition.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
l if I had the standardese to
justify that, wouldn't it? :-) I'll see if I can find it.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Eric Botcazou wrote:
>>GCC 4.0.2 RC1 is now available from FTP mirrors of gcc.gnu.org, in the:
>
>
> OK on SPARC/Solaris:
Thanks.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
f the test results from 4.0.2 RC1 have been good, I expect
that there will be no changes between RC2 and the final release, which I
expect to make sometime next week.
Please test, post test results to gcc-testresults, and send me an email
pointing at the results.
Thanks,
--
Mark Mitchell
CodeSou
with multiple entry points.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
gression from 4.0.x. The
primary goal for 4.0.2 is to provide an upgrade path for anyone who is
already using 4.0.1.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
of world.
Frankly, I agree that -Wall is a poor name. Yes, people should read
docmentation, but -Wall really does suggest that it should turn on all
warnings. I understand why it doesn't, and it probably can't be
changed, but that doesn't make it a great name.
--
Mark Mitchell
Cod
As of now, the GCC 4.0 branch is completely frozen for the GCC 4.0.2
release. The release will be announced as soon as it has had time to
propagate to the various FTP mirror sites.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
I can't be entirely objective about this situation, so
I'd appreciate any feedback.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
Index: init.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/init.c,v
retrieving revision 1.429
diff -c
Giovanni Bajo wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
>
>>1. Release 4.0.2 without fixing this PR. (The bits are ready, sitting
>> on my disk.)
>>
>>2. Apply the patch, respin the release, and release it.
>>
>>3. Apply the pa
The GCC 4.0.2 RC3 prerelease is spinning now.
If all goes well, it will be available later today.
FYI,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
-19 Jakub Jelinek <[EMAIL PROTECTED]>
to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you
investigating these failures? We need to get this resolved ASAP.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
+.log output for these failures?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Benjamin Kosnik wrote:
>>to libstdc++ is the only obvious culprit. Benjamin, Jakub, are you
>>investigating these failures? We need to get this resolved ASAP.
>
>
> I'm on it.
Thanks!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
t
libstdc++, in particular, is working for them.
Any thoughts on this plan?
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
H. J. Lu wrote:
> On Tue, Sep 27, 2005 at 07:58:46AM -0700, Mark Mitchell wrote:
>
>>Now that Benjamin and Eric have fixed the Solaris issues in libstdc++
>>(yay!), I know of no reason not to spin a release. I'm going to take a
>>final pass through the open PRs an
4.1 branch has been created. I
think the 4.0 branch is relatively stable at this point; our challenge
is to get the bugs out -- and the performance into -- 4.1 so that we can
start making 4.1.x releases.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Index: bugzilla/contrib
release is in the gcc/gcc-4.0.2 subdirectory.
As usual, a vast number of people contributed to this release -- far too
many to thank by name!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
sing to do a release that
had a totally broken Ada compiler on IA32 GNU/Linux. Knowing RTH, I'm
sure that he'll look into the problem.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Ulrich Weigand wrote:
> Mark Mitchell wrote:
>
>
>>GCC 4.0.2 has been released.
>
>
> Results on s390(x)-ibm-linux are here:
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01323.html
> http://gcc.gnu.org/ml/gcc-testresults/2005-09/msg01324.html
>
> Unfo
2005-09-25 Benjamin Kosnik <[EMAIL PROTECTED]>
Eric Botcazou <[EMAIL PROTECTED]>
* include/ext/mt_allocator.h
(__per_type_pool<...true>::_S_initialize_once): Always call
_M_initialize_once.
(__common_pool<...true>::_S_initialize_once
g out 4.0.3 right now? I think in this case the
answer is clearly no. I think the Solaris problem is the only one which
might merit that kind of recation.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ll plan to do that primarily, but I'll work in a 4.0.3 at some point.
I very much apologize for the mistake.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
-pthreads) and the link:
> http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.html
Roger that. I'll take care of it as soon as I can.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Mark Mitchell wrote:
> 1. Move the ChangeLog entries on the 4.0 branch to accurately reflect
> the released bits.
>
> 2. Modify Bugzilla to reset the target milestone for the three PRs in
> question.
>
> 3. Modify gcc_release to prevent this situation in future.
These step
Eric Botcazou wrote:
> Agreed. But I'm requesting a "caveat" note about the Solaris regression here:
> http://gcc.gnu.org/gcc-4.0/changes.html#4.0.2
> mentioning the workaround (g++ -pthreads) and the link:
> http://gcc.gnu.org/ml/gcc-cvs/2005-09/msg00984.htm
Then, we'll re-open briefly to allow any
queued-up critical non-regression bug-fixes. Then we'll branch.
All of the usual suspects (Berlin, Bosscher, Henderson, Hubicka,
Mitchell, Novillo, etc.) have bugs with our names on them. I think we
can knock quite a few these down relatively e
retargeting some of
the bugs -- so that we can create the 4.1 release branch.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Steven Bosscher wrote:
> On Monday 10 October 2005 19:35, Mark Mitchell wrote:
>
>>As previously announced, here:
>>
>>http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html
>>
>>the mainline is now subject to the usual release-branch rules: only
>>fixes for
ns in performance critical loops, whether
or not your hierarchy uses virtual bases.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
g similar test programs, to show that there is little or no cost.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Frans Englich wrote:
> On Monday 10 October 2005 22:29, Mark Mitchell wrote:
>
>>Frans Englich wrote:
>>
>>>Followup question: what is the increased cost of calling a non-virtual,
>>>inlined function('inline' keyword) on a virtual base?
>>
>
d allow the use of the
attribute. Thoughts?
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
We're down from 219 4.1 regressions yesterday to 208 today.
That's much better than the 1-per-day progress rate over the last few weeks!
If we can sustain that rate, we'll be looking good pretty quickly.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
vely at CodeSourcery, and I think everyone
is uniformly in favor. The superior branch facilities are a key
benefit. You got us through the Bugzilla transition, and that's working
well. Make it happen.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ack. Let's not introduce last-minute feature creep.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
or snapshots,
> if all we need to record is the global revision number.
That would be my suggestion; just use revision number in lieu of the
datestamp in the snapshot, and never mind the tag. The tag was just a
way of imposing a global revision number on CVS.
--
Mark Mitchell
CodeSourc
would
expect that the type_info objects and the corresponding type_info
strings are local symbols. If that is not the case, then that is the bug.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
x27;t much like new command-line options, but I agree that
this is a situation in which both sides have valid points, there's
legacy code around that depends on both behaviors, and having a switch
makes sense.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
4.2 before we branch; please note that on your project pages.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
e DW.ref._ZTIZ3foovE1S#, 8
> DW.ref._ZTIZ3foovE1S:
> data8 _ZTIZ3foovE1S#
>
> Found both in u.S and t.S and merged by the linker.
Yes, that's wrong. I'd expect that to be a front-end bug, but if it
doesn't happen on all platforms, then, maybe it's not?
--
Alexandre Oliva wrote:
> If the strings turn out to be identical and the linker merges them, we
> fail...
The linker should not do that. These are not random string literals;
these are the equivalent of the
static char c[12] = "..."
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL
be identical at link-time.
I agree; that seems wrong to me.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
cross compile, it needs to use the cross compiler, not the
canadian cross compiler.
I will submit a patch if I get the canadian cross compile to work
properly. I have not achived this since gcc-2.8.1/gnat-3.14p.
I hope this is of use for future revisions of the compiler/configure
scripts.
Regards
Mark Fortescue.
can.
So, I'll approve it, conditional on no objections for 72 hours.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Daniel Berlin wrote:
> Diego already said it was okay, and since they were his tags, i did
> it :)
Well, then. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
the branch name is
> no longer hardcoded. I have therefore also applied the following patch to
> branching.html to remove mention of updating gcc_update.
Swell!
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Daniel Berlin wrote:
> [ Mark, my emails to gcc-announce are dropped on the floor, can you
> forward this there? ]
I've posted a slightly more user-centric announcement. I hope that's OK.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
dd links to the main web page to query for the
regressions I think are important enough to block a release.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
and "fix" the milestone.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
iority
> field.
I think it's an appropriate use of the priority field; the priority
field is supposed to say how important the bug is, which is another way
of saying how excited we should be about fixing it in an upcoming release.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Mike Stump wrote:
> On Oct 30, 2005, at 10:23 AM, Mark Mitchell wrote:
>
>> I'm not quite sure who can approve this, but I think probably I can.
>> So, I'll approve it, conditional on no objections for 72 hours.
>
>
> Would be nice to have a general well es
it a little harder for me to plow through them all...)
Sorry for the short-term confusion!
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
o 100, we'll lift the
regression-only rule on the mainline before the scheduled November 11th
date.
I've updated the main web page (patch attached) to have a "serious
regressions" link, which is the P3-or-higher regressions for 4.1.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
for the
sake of anyone who might want to fix the bug. Optimizer folks, please
help with this -- your time might be as well spent analyzing some of
these PRs as implementing additional stuff.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
t; should not preclude the warning!
Maybe it would help to move the checks closer to the front of the
optimizer chain. We'd have less accuracy, but, probably, more consistency.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Jeffrey A Law wrote:
> On Sun, 2005-10-30 at 23:40 -0800, Mark Mitchell wrote:
>
>>In reviewing the PR list, I saw several (maybe 5?) PRs about problems
>>with -Wuninitialized.
> Where I suspect we're falling down more often is not issuing warnings
> because t
Jeffrey A Law wrote:
> On Mon, 2005-10-31 at 17:11 -0800, Mark Mitchell wrote:
>
>
>>>Certainly if we can't prove f always returns a nonzero value, then a
>>>warning should be issued. If we do prove f always returns a nonzero
>>>value, then I think i
may be used uninitialized.
Indeed; I definitely agree that we shouldn't warn about this. The users
have spoken definitively, if nothing else.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Hi DJ Delorie,
I did not specify all the commandline arguments used in my email. I am
using --build= in the GCC builds (as required). The build arguments
in use when things go pair shaped are:
'/L64/src/gcc-4.0.0/gcc-4.0.2-p01/configure --build=i686-pc-linux-gnu
--target=sparc-linux --host=sparc-l
-O0, or go away
completely with higher levels of optimization isn't good.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
, we must reject the instantiation.
I know that sounds backwards. The point is that when tf_error is set,
we're committed to the instantiation. When tf_error is not set, SFINAE
applies. And, in a conforming program, we must reject the instantiation
in that case.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
to x86_64 builds in full.
Regards
Mark Fortescue.
-Original Message-
From: Nathanael Nerode [mailto:[EMAIL PROTECTED]
Sent: 02 November 2005 00:29
To: [EMAIL PROTECTED]
Cc: gcc@gcc.gnu.org; [EMAIL PROTECTED]
Subject: Re: GCC 4.0.2 Canadian Cross Compile
Mark Fortesque wrote:
&g
option.
My point was that conforming programs should compile and behave
identically in all modes; therefore -fpermissive must not alter the
behavior.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
em like you're moving in a direction that would
give us a mode where warnings would perhaps oscillate between your two
classes, but not come and go completely. I think that's pretty good.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
;m sorry you're upset; I actually think we're closer to consensus
than we've ever been before on this issue. :-)
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
more consistent across the
various parameters we've discussed, but less accurate.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ssions under 100 -- and it's just 104 right
now! -- I'll reopen the mainline for general bug fixes until November
18th, when we'll create the branch. (If you think there's some PR so
serious that we shouldn't even create the branch until its fixed, let me
know; I think that to qualify, a PR would have to have no fix other than
major surgery on the compiler.)
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ill consider
asking for patches to be reverted if they prove disruptive.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
ly for a single-CPU, single-threaded system?
I think that to satisfy everyone, you may need a configure option to
decide between inlining support for a particular processor (for maximum
performance when you know the target performance) and making a library
call (when you don't).
--
Mark Mi
function that will just do that one sequence, with the only benefit
being that someone might later be able to replace that function if some
as-of-yet uknown IA32 processor needs a different sequence.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
rinciple, at least, this would be useful for other things, too; we
might want different versions of integer division routines for ARM, or
maybe, even, use real FP instructions in our software floating-point
routines, if we happened to be on a hardware floating-point processor.
--
Mark Mitchell
Code
seems like we could put these routines
into libgcc, and just have libstdc++ call them. And, that if
__exchange_and_add is showing up on the top of the profile, the fix
probably isn't inlining -- it's to work out a way to make less use of
atomic operations.
--
Mark Mitchell
CodeSourcery, LL
Ulrich Drepper wrote:
> Mark Mitchell wrote:
>
>>Yes, GLIBC does that kind of thing, and we could do. In the simplest
>>form, we could have startup code that checks the CPU, and sets up a
>>table of function pointers that application code could use.
>
>
> That&
So that is option (2),
Yes, I think we should do option (2). There's otherwise no point at all
in putting a zero-width bitfield into a packed structure; it seems
better to assume the user had a purpose in having the zero-width bitfield.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304
Can anyone shed some light on this? I've done some googling and turned up
some talk of 32 bit versus 64 bit architectures, but trying the build with
an -m32 or -m64 made no difference. I've had this work before, so I'm
probably missing something obvious...
Thanks
Mark
Mark C
One other thing to note - even though the compiler / linker complains about
these library incompatiblilties, the resulting a.out executes as expected on
a Solaris box wierd.
Mark
Mark Cuss, B. Sc.
Software Developer
Systems Administrator
CDL Systems Ltd.
Suite 220
3553 31 Street NW
ure, or
??? . I've dug around and can't seem to track this info down... I'm a bit
of a newbie at this stuff so any help is greatly appreciated.
Thanks
Mark
Mark Cuss, B. Sc.
Software Developer
Systems Administrator
CDL Systems Ltd.
Suite 220
3553 31 Street NW
Calgary, AB, Can
- Original Message -
From: "Markus Trippelsdorf" <[EMAIL PROTECTED]>
To: "Mark Cuss" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>;
Sent: Tuesday, November 08, 2005 9:29 AM
Subject: Re: Skipping incompatable libaries on a SPARC cross compile
On
is is valid under flexible arrays:
>
> http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Zero-Length.html#Zero-Length
>
> Mark has a note on the PR that says C++ does not support flexible arrays,
> but our documentation seems to imply we do.
What I actually said is that I'm not sure w
501 - 600 of 1839 matches
Mail list logo
