On Mon, Jul 11, 2016 at 4:27 PM, Ian Lance Taylor <i...@google.com> wrote:
> On Mon, Jul 11, 2016 at 1:05 PM, Brooks Moses <bmo...@google.com> wrote:
>> Ping?
>
> This is fine, but please add a comment explaining why the code avoids
> 0-length VLAs. Thanks.
Ping?
(I suspect I should have added a libiberty maintainer to cc in the first place.)
On Mon, Jun 13, 2016 at 9:05 AM, Brooks Moses <bmo...@google.com> wrote:
> Zero-length variable-length-arrays are not allowed in standard C99,
> and perhaps more importantly, they cause ASAN to com
libiberty/ChangeLog
--- a/libiberty/ChangeLog
+++ b/libiberty/ChangeLog
@@ -1,3 +1,8 @@
+2016-06-12 Brooks Moses <bmo...@google.com>
+
+ * cp-demangle.c (cplus_demangle_print_callback): Avoid zero-length
+ VLAs.
+
2016-05-31 Alan Modra <amo...@
copy)
@@ -1,3 +1,7 @@
+2014-01-31 Brooks Moses bmo...@google.com
+
+ * gcc_update (files_and_dependencies): Add aarch64-tune.md.
+
2013-10-21 Mike Stump mikest...@comcast.net
* gcc_update (configure): Update to handle svn 1.8.1.
Index: contrib/gcc_update
I'm trying to reproduce a test failure outside the Dejagnu testsuite,
and I noticed that the file I'm trying to recompile is linked with a
gcc_tg.o file. Based on the missing-symbol errors I get when I don't
include it, it seems to provide things like __wrap_main and so forth.
Where on earth
On Fri, Oct 11, 2013 at 2:49 PM, Andrew Pinski pins...@gmail.com wrote:
On Fri, Oct 11, 2013 at 2:39 PM, Brooks Moses bmo...@google.com wrote:
Where on earth does this gcc_tg.o file come from? I'm completely lost
here -- I can't find any log that indicates it getting built, or any
reference
symbols with the old mangling.
Ok to commit?
(An alternate approach would be to force -mabi-version=2, and check
for the presence of both sets of symbols. That seems overkill to me,
but I can alter the test to do that if desired.)
Thanks,
- Brooks
2013-10-11 Brooks Moses bmo...@google.com
On Fri, Oct 11, 2013 at 4:59 PM, Brooks Moses bmo...@google.com wrote:
I committed a patch to update the xfail file for our 32-bit Power
build configuration. As with the others, this ends up being a
significant reorganization, so the diff is less interesting than the
revised file. Thus, I've
This patch updates the powerpc64le xfails file on the google/gcc-4_8
branch to reflect two new failures caused by the addition of a new
vectorization testcase. Committed as obvious.
- Brooks
2013-09-23_powerpc64le-xfails.diff
Description: Binary data
Diego -
In http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00174.html I proposed
a patch to fix PR58312, which is that libssp when cross-compiled
assumes that vnsprintf is broken [1]. This is causing our libssp.so
to be missing some symbols that are referenced by some pre-existing
binaries.
The
On Thu, Sep 12, 2013 at 8:42 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
On Wed, 11 Sep 2013, Brooks Moses wrote:
Joseph, I'd been cc'ing you on this because it's driver-related and I
didn't find a more-obvious reviewer. Is there someone else I should
be asking to review
On Thu, Sep 12, 2013 at 11:19 AM, DJ Delorie d...@redhat.com wrote:
The patch is OK with me from a build machinery point of view.
Thanks, DJ. Based on that and Joseph's comments elsewhere that
removing these binaries is the right thing to do, I've committed the
patch.
At Ian Taylor's
at 9:32 AM, Brooks Moses bmo...@google.com wrote:
Ping^2?
On 08/22/2013 02:00 PM, Brooks Moses wrote:
Ping?
On 08/08/2013 02:10 PM, Brooks Moses wrote:
As discussed in PR/42955, when GCC is built as a cross-compiler, it
will install gcc, g++, c++, and gfortran binaries in
$(target)/bin
On Wed, Sep 4, 2013 at 12:01 AM, Jakub Jelinek ja...@redhat.com wrote:
That looks wrong, the test was intentionally looking for badly implemented
vsnprintf, see
http://www.gnu.org/software/gnulib/manual/html_node/snprintf.html
This function does not return a byte count as specified in C99 on
Ping^2?
On 08/22/2013 02:00 PM, Brooks Moses wrote:
Ping?
On 08/08/2013 02:10 PM, Brooks Moses wrote:
As discussed in PR/42955, when GCC is built as a cross-compiler, it
will install gcc, g++, c++, and gfortran binaries in
$(target)/bin, as well as installing the $target-gcc and so forth
relatively innocuous.
Jakub, I'm cc'ing you in hopes that you're a reasonably appropriate
person to review this.
Ok for trunk?
Thanks,
- Brooks
2013-09-03 Brooks Moses bmo...@google.com
* configure.ac: Replace runtime vsnprintf check with
compile-time
Ping?
On 08/08/2013 02:10 PM, Brooks Moses wrote:
As discussed in PR/42955, when GCC is built as a cross-compiler, it
will install gcc, g++, c++, and gfortran binaries in
$(target)/bin, as well as installing the $target-gcc and so forth in
bin. However, these binaries in $(target)/bin do
I fixed the bits in our DejaGNU powerpc64 board file to transfer
profile output back to the build system from the remote target, which
means that a bunch of test failures now go away, and we uncover a
small handful of new ones.
This patch updates the xfail file accordingly. Committed as obvious.
One of the Fortran failures in the powerpc64le xfail file I committed
to the Google 4.8 branch last week is no longer failing. This patch
removes it from the xfails file.
Committed as obvious.
- Brooks
2013-08-12_xfail-fixup.diff
Description: Binary data
, which simply removes these broken executables.
Tested by building a cross-compiler and confirming that they are gone,
and by building a native compiler and confirming that the expected
bin/gcc, bin/g++, bin/c++, and bin/gfortran are still present.
Ok to commit?
- Brooks
2013-08-08 Brooks
A not-yet-reviewed libtool patch is needed for powerpc64le
shared-library support:
http://lists.gnu.org/archive/html/libtool-patches/2013-06/msg1.html
(See also
http://lists.gnu.org/archive/html/libtool-patches/2013-07/msg1.html)
This patch merges that change into the google/gcc-4_8
Diego -
The attached patch corrects the fact that we were not picking up the
GRTE-specific spec files in our non-x86 GCC builds, and incidentially
simplifies the logic for these spec files since they do not appear to
be changing from one GRTE version to another.
* gcc/configs/linux-grtev2.h:
Diego -
The attached patch adds a little more analysis info to the powerpc64
xfails file. Ok to commit?
Thanks,
- Brooks
2013-07-22_xfail-more-info.diff
Description: Binary data
On 06/04/2013 03:57 PM, Diego Novillo wrote:
OK with this predicate factored into a predicate function (maybe
SummaryLineHasAttributes?)
Thanks! Once I dove into that, I ended up doing a bit more refactoring;
it really makes sense to pull the whole line-splitting into a separate
function
.
This patch fixes the problem: If an entire line is a valid summary line,
we don't try to split it.
Ok to commit?
- Brooks
2013-05-31 Brooks Moses bmo...@google.com
* validate_failures.py: Don't split already-valid summary lines.
The validate_failures.py script in contrib
reviewer to the Write
After Approval section.
Committed.
Index: ChangeLog
===
--- ChangeLog (revision 198467)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-04-30 Brooks Moses bmo...@google.com
+
+ * MAINTAINERS: Update
Robert Dewar wrote:
One could of course just take a blanket view that everything
on the site is, as of a certain moment, licensed under GPLv3
(note you don't have to change file headers to achieve this,
the file headers have no particular legal significance in
any case).
I'm going to pull a
At 06:33 AM 7/15/2007, Robert Dewar wrote:
Richard Kenner wrote:
Actually the whole notion of violating a license is a confused one. The
violation is of the copyright, the license merely gives some cases in
which copying is allowed. If you copy outside the license you have not
violated the
Geoffrey Keating wrote:
Speaking as an individual developer who nonetheless needs to follow
his company's policies on licensing, I need it to be *absolutely
clear* whether a piece of software can be used under GPLv2 or not.
If there's a situation where 'silent' license upgrades can occur,
where
Diego Novillo wrote:
On 7/12/07 11:43 AM, Richard Kenner wrote:
My personal preference would be to acknowledge that for our users
there is no significant difference between GPLv2 and GPLv3.
I agree with this. I think renaming 4.2.2 to 4.3.3 will result in
lots of unnecessary confusion.
Michael Eager wrote:
Ian Lance Taylor wrote:
I believe that we should make a clear statement with that release that
any future backport from a later gcc release requires relicensing the
changed files to be GPLv3 or later. I believe this is consistent with
the two different licensing
Mark Mitchell wrote:
David Edelsohn wrote:
Let me try to stop some confusion and accusations right here. RMS
*did not* request or specify GCC 4.3.3 following GCC 4.2.2. That was a
proposal from a member of the GCC SC. The numbering of the first GPLv3
release was not a requirement
DJ Delorie wrote:
I read these as 4.2.1 is the last 4.2 release. Pulling a 4.3.3 from
that branch is, IMHO, stupid and confusing. If 4.2.1 is the last 4.2
release, the 4.2 branch is DEAD (svn topology notwithstanding). The
next release cannot be 4.3.3, that makes no sense. The next release
Diego Novillo wrote:
On 7/6/07 1:14 PM, Steve Kargl wrote:
One other thing. Can you post the contents of
perf/sbox/gcc/local.ppc64/src/libgfortran/intrinsics/selected_int_kind.f90
This is file is autogenerated. If it's mangled you'll get the
failure.
Attached. The failure still exists
Robert Dewar wrote:
OK, interesting, thanks for info, I had always thought that this
was purely conceptual.
One thing (which Erik didn't mention) that I noticed in the articles is
that Ken said that in his implementation he also hacked the disassembler
to cover up the evidence.
Of course
Dave Korn wrote:
On 23 June 2007 22:53, Brooks Moses wrote:
Indeed. It would be interesting to confirm whether or not a copy of gcc
bootstrapped with a non-gcc compiler matched byte-for-byte with a copy
of gcc bootstrapped from gcc. Not so much to look for intentional
things like
Giovanni Bajo wrote:
Both our goals are legitimate. But that's not the point. The point is
what -ffast-math semantically means (the simplistic list of suboptions
activated by it is of couse unsufficiente because it doesn't explain how
to behave in face of new options, like -mrecip). My
michael.a wrote:
It would be interesting for someone to try to make a practical argument that
is anything but a nest of technicalities, as to why ctors and unions
shouldn't be mixable.
The Fortran language specification allows essentially this, although the
terms are initializers and
(Because this concerns policy rather than code, I've cc'ed it to the
main gcc list rather than the patches list.)
FX Coudert wrote:
I noticed in MAINTAINERS that there is a new category of Non-
Autopoiesis Maintainers (I certainly missed the original
announcement), for maintainers who cannot
At 09:40 PM 6/14/2007, Steve Kargl wrote:
On Thu, Jun 14, 2007 at 08:48:22PM -0700, Brooks Moses wrote:
I have no objection to this as a custom for GFortran, certainly -- I
think it's a very good idea, and as a custom I very much support it.
However, there have historically been reasonable
Brooks Moses wrote (on the Fortran BIND(C) project):
I don't believe this project has been documented very well (if at all)
on the standard Wiki page for Stage-1 projects, but I haven't looked at
it in a while. I am also not entirely certain whether this qualifies as
a Stage 1 or a Stage 2
Mark Mitchell wrote:
Brooks Moses wrote:
Several members of the GFortran team (primarily Chris Rickett and Steve
Kargl) have been working on a project to add the BIND(C) functionality
from the Fortran 2003 standard. This provides for a standard means of
linking Fortran code with code that uses
Dave Korn wrote:
On 25 May 2007 15:34, Eric Botcazou wrote:
It's no different than any other library used by any other program.
I wouldn't object to configure support to request static gmp/mpfr for
developer convenience, but GCC is a perfectly normal dynamically
linked program and should behave
Mark Mitchell wrote:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
PR straight to the checkin. This field value ought to be the
Mike Stump wrote:
On May 21, 2007, at 2:43 PM, AaronCloyd wrote:
I need to edit a gcc source code, then recompile.
Wrong list... gcc-help is closer that what you want...
Is it? Changing the internals of what GCC puts into .s files seems a
topic that's more appropriate here, I would
Wei Chen wrote:
i think http://gcc.gnu.org/svn.html have a error.
Using the SVN repository
Assuming you have version 1.0.0 and higher of Subversion installed,
you can check out the GCC sources using the following command:
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
the right is
Bernardo Innocenti wrote:
(the next proposal is likely to cause some dissent)
What about moving 4.3 to stage 3 *now* and moving everything
else in 4.4 instead? Hopefully, it will be a matter of just
a few months. From http://gcc.gnu.org/gcc-4.3/changes.html,
it looks like it would already be
Steven Bosscher wrote:
On 5/9/07, Mike Stump [EMAIL PROTECTED] wrote:
In ipa-type-escape.c we have:
/* Return either TYPE if this is first time TYPE has been seen an
compatible TYPE that has already been processed. */
I'd fix it, if I knew I knew what it meant. either, an and that
Philippe Schaffnit wrote:
Sorry about the (possibly off) question: would this apply also to
GMP/MPFR, if not, wouldn't it make sense?
It wouldn't make sense -- GMP and MPFR are never linked into the
compiled output at all. (They're only used within the compiler itself,
for processing
Daniel Berlin wrote:
On 4/15/07, Mark Mitchell [EMAIL PROTECTED] wrote:
However, I would consider asking the SC for permission to institute a
rule that would prevent contributors responsible for P1 bugs (in the
only possible bright-line sense: that the bug appeared as a result of
their patch)
Dave Korn wrote:
On 12 April 2007 22:22, FX Coudert wrote:
Note2: I also omitted a couple of gfortran.dg/secnds.f failures; this
testcase should be reworked
I was about to report that myself! Both secnds.f /and/ secnds-1.f have some
kind of race condition or indeterminacy.
It's an
FX Coudert wrote:
wrt to the Subject of the mail, I'm not sure Call to arms means
what I thought it meant, after all... I really wanted it to sound
like call for help or call for more arms. Sorry if there was any
confusion in the tone.
The literal meaning of call to arms is a call for
I was looking through how to convert real numbers between various
representations for the Fortran TRANSFER patch that I'm working on, and
came across something that I'm curious about.
We've currently got two different bits of code for converting an MPFR
real number to a REAL_VALUE_TYPE. One
Robert Dewar wrote:
Ian Lance Taylor wrote:
The new option -fstrict-overflow tells gcc that it can assume the
strict signed overflow semantics prescribed by the language standard.
This option is enabled by default at -O2 and higher. Using
-fno-strict-overflow will tell gcc that it can not
the two lines of context in the top of the patch
-- and so I'm now proposing to remove it.
---
2007-03-23 Brooks Moses [EMAIL PROTECTED]
* error.c (show_locus): Remove always-false test
Annapoorna R wrote:
steps i followed:
1. downloaded GCJ4.1.2 core and java tar from GNU site. and extracted it
to GCC4.1
after extracting folder GCC-4.1.2 is created(automatically while
extracting).
the frontend part (java tar) was extraced to /gcc-4.1.2/libjava.
Did ./configure from
(crossposting to fortran@)
Ian Lance Taylor wrote:
Now that the gcc 4.2 release is getting closer, I am resending this
e-mail from Martin Michlmayr. I've removed options which I believe
are sufficiently internal to not require mention in the changes file,
and I've removed options which are now
Tarmo Pikaro wrote:
If you consider different languages - c, c++, java - they are not much different
- syntax somehow vary, but you can basically create the same application using
different languages. Generic tries to generalize structures available in all
languages
into common form. I think
Karthikeyan M wrote:
Oh ! So the releases on http://gcc.gnu.org/releases.html are for
those who just want to use gcc and not hack it ?
Is the latest release not done from the top of the trunk ?
No; the top of the trunk is far too unstable for releasing. Release
branches are split off of
Steven Bosscher wrote:
On 3/20/07, Mark Mitchell [EMAIL PROTECTED] wrote:
I think it's fair for front ends to pay for their
largesse. There are also relatively cheap changes in the C++ front end
to salvage a few codes, and postpone the day of reckoning.
I think that day of reckoning will
Kai Ruottu wrote:
Paul Brook wrote:
How can I get the build scripts to use the precompiled gcc throughout
the build process ?
Short answer is you can't. The newly build gcc is always used to build the
target libraries.
Nice statement but what does this really mean?
Does this for
[EMAIL PROTECTED] wrote:
I sincerely apologize for the spammish nature of this e-mail - I
don't mean to abuse this list. I am trying to collect responses
from as many open source developers and users as possible and a
mailing list like can be the only way to reach many developers.
FWIW, one
Mark Mitchell wrote:
However, I do think that it's important to eliminate some of the 139
open P2 and P1 regressions [2], especially those P1 regressions which
did not appear in GCC 4.1.x.
133, not 139. Your search url returns six P3 bugs, one of which (29441)
is not even a regression.
Manuel López-Ibáñez wrote:
On 02/03/07, Andrew Pinski [EMAIL PROTECTED] wrote:
A week is too short of time to ping a patch.
Ups! I actually believed that a week was the recommended time to ping
a patch. What is it then?
I remembered a week as well, but http://gcc.gnu.org/contribute.html
Kaveh R. GHAZI wrote:
Perhaps a middle ground between what we have now, and trust but verify,
would be to have a without objection rule. I.e. certain people are
authorized to post patches and if no one objects within say two weeks,
then they could then check it in. I think that would help
Andrew Pinski wrote:
100 good patches != good knowledge in one area.
Also I think I already submitted 100 good patches but every once in a
while I submit a bad one though I think it is good to begin with.
To tangent off this in a rather different direction: One of the things
that I've noticed
Christian Joensson wrote:
Í just tried to build gcc-4.1.2 for cygwin... but failed. My old way
of test building does not seem to work anymore for me.
[...]
grep '^#' kinds.h kinds.inc
/bin/sh: kinds.h: No such file or directory
[...]
Any ideas of what might be going wrong?
A quick bit of
Brooks Moses wrote:
However, this seems to be hardcoding something that texinfo has
perfectly good macros for, and it's also missing the standard GCC-manual
subtitle; the usual form is:
--
@titlepage
@title Installing GCC
@subtitle for GCC
Brian Dessent wrote:
Brooks Moses wrote:
In short, from what I could tell from a quick scan of that PR, the
problem is that you've got LD_LIBRARY_PATH set in such a way that it's
not including the GMP header files.
If you're using the standard Cygwin-package installation of GMP, I'd
guess
The install.texi manual has the following bit of code for the title page:
--
@titlepage
@sp 10
@comment The title is printed in a large font.
@center @titlefont{Installing GCC}
--
However,
Mark Mitchell wrote:
I've heard various comments about whether or not it's worth doing a 4.2
release at all. For example:
[...]
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll
Paolo Bonzini wrote:
Am I correct in guessing that the missing lines in Makefile.def are
not currently needed? Or are they merely present in the GCC fixincludes
but missing in the fixincludes directories in some other trees that
share the top-level build files?
Yes, a patch that removes the
Why is it that Makefile.def includes:
// missing indicates that that module doesn't supply
// that recursive target in its Makefile.
[...]
host_modules= { module= fixincludes;
missing= info;
missing= dvi;
missing= pdf;
missing=
Andrew Pinski wrote:
In http://gcc.gnu.org/gcc-4.3/changes.html appears
Support for SSSE3 built-in functions and code generation are available
via |-mssse3|.
Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)?
Is it -mssse3 or -msse3?
-mssse3 is S-SSE3 which was added for code dual 2.
Yes
[EMAIL PROTECTED] wrote:
With following code:
[CODE]
struct B {
int c;
int d;
};
#define X(a, b, c) \
do\
{\
if (a)\
printf(%d, %d\n, b.c, c);\
else\
printf(%d\n, c);\
}while(0);
[/CODE]
Why
int d = 24;
X(1, b, d);
icrashedtheinternet wrote:
I guess I could have worded my email a bit better. Of course I don't
assume that the GCC developers are ignoring standards. Nor do I think
any of us are unaware of GCC's ability to support a standard and have
extensions to it that go beyond the standard. So I simply
Ferad Zyulkyarov wrote:
Also, I referred to some tutorials and articles in the net about
writing gcc front-end. And here are they:
1. http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/Print_version
2. http://www.faqs.org/docs/Linux-HOWTO/GCC-Frontend-HOWTO.html (old)
3.
Paul Schlie wrote:
Just as:
volatile int* port = (int*)PORT_ADDRESS;
int input = *port; supposedly invoking an undefined behavior.
is required to be well specified, effectively reading through a pointer
an un-initialized object's value, and then assigning that unspecified value
to the
I've been trying to track down an build failure that I was pretty sure
came about from some patches I've been trying to merge, but I've now
reduced things to a bare unmodified tree and it's still failing. I
could have sworn that it wasn't doing that until I started adding
things, though, so
Paul Schlie wrote:
Robert Dewar wrote
Paul Schlie wrote:
- However x ^= x :: 0 for example is well defined because absent any
intervening assignments, all reference to x must semantically yield the
same value, regardless of what that value may be.
Nope, there is no such requirement in the
Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-01-24, o godz23:52, przez Mike Stump:
On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote:
It could be a starting point to help avoiding quite a lot of
overhead needed to iterate over command line options for example.
Odd. You think that
Marcin Dalecki wrote:
A trivial by nature change like the
top level build of libgcc took actually years to come by.
I'm not sure how much that's inherently evidence that it was
inappropriately difficult to do, though.
For example, the quite trivial change of having make pdf support for
Richard Stallman wrote:
If not, I think one ought to be implemented. I have a suggestion for
what it could look like:
#define FIXNUM_OVERFLOW_P(i) \
((EMACS_INT)(int)(i) MOST_POSITIVE_FIXNUM \
|| (EMACS_INT)(int)(i) MOST_NEGATIVE_FIXNUM)
The casts to int could be interpreted as meaning
Mike Stump wrote:
Yeah, spending large amounts of time in stage2 and 3 does have
disadvantages. I'd rather have people that have regressions spend a
year at a time in stage2-3... :-( Maybe we should have trunk be
stage1, and then snap over to a stage2 branch when the stage1
compiler is
I just noticed what looks like an anomaly in the gfortran testsuite.
All of the tests that have dg-do compile headers are only being
compiled once, with an empty -O option, rather than iterating over the
usual list of -O1, -O2, -O3, etc.
(This is, I note, also what's happening with
Paul Thomas wrote:
Brooks,
Is this the expected/desired behavior for dg-do compile?
I had always thought so :-)
and Steve Kargl wrote in the Fix PR 30235 thread on fortran@:
It's my understanding the dg-do compile in the gfortran
testsuite should only run once. It is normally used to
Andrew Pinski wrote:
On Tue, 2006-12-19 at 06:54 +0100, Ralf Wildenhues wrote:
[quoting Paul Eggert]
Surely the GCC guys care about LIA-1. After all, gcc has an
-ftrapv option to enable reliable signal generation on signed
overflow. But I'd rather not go the -ftrapv route, since that
will
Howard Hinnant wrote:
On Dec 4, 2006, at 6:08 PM, Richard Guenther wrote:
The question
is whether a correctly rounded exact cbrt differs from the pow
replacement by more than 1ulp - it looks like this is not the case.
If that is the question, I'm afraid your answer is not accurate. In
the
Ed S. Peschko wrote:
And in any case, why should it be off-topic? I would think that
the possibility of your project being divided in two would be of
great concern to you guys, and that you'd have every single motivation to
convey any sort of apprehension that you might have about such a split
David Edelsohn wrote:
Steve Kargl writes:
Steve I have not seen this failure, but that may be expected
Steve since SPEC CPU 2000 isn't freely available.
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000.
H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:17:49AM -0800, H. J. Lu wrote:
On Tue, Nov 14, 2006 at 09:43:20AM -0500, David Edelsohn wrote:
No failure should be expected. It is a bug and a regression and
should be fixed, with help of users who have access to SPEC CPU2000.
It was a
Jack Howarth wrote:
Does anyone know how the changes for gcc to require gmp/mpfr will effect the
multilib builds? In the past, gmp/mpfr in gfortran appeared to only be linked
into
the compiler itself so that a 32-bit/64-bit multilib build on Darwin PPC only
required gmp/mpfr for 32-bit to be
Dave Korn wrote:
On 10 November 2006 20:06, Mark Mitchell wrote:
Dave Korn wrote:
It may seem a bit radical, but is there any reason not to modify the
option-parsing machinery so that either '-' or '=' are treated
interchangeably for /all/ options with joined arguments? That is,
whichever is
Dave Korn wrote:
On 10 November 2006 21:18, Brooks Moses wrote:
But that's already not possible -- that's essentially how I got into
this problem in the first place. If one tries to define both of those,
the declaration of the enumeration-type holding the option flags breaks,
so you can't do
The Fortran front end currently has a lang.opt entry of the following form:
ffixed-line-length-
Fortran RejectNegative Joined UInteger
I would like to add to this the following option which differs in the
last character, but should be treated identically:
ffixed-line-length=
Fortran
There's something weird going on with Fortran's -ffixed-line-length
options, and in how the lang.opt files get processed to produce the
--help results from cc1 (and cc1plus, f951, etc.).
Specifically, the fortran/lang.opt file contains the following lines:
Kenneth Zadeck wrote:
The problem with trying to solve this problem on a per pass basis rather
than coming up with an integrate solution is that we are completely
leaving the user out of the thought process.
There are some uses who have big machines or a lot of time on their
hands and want the
I've been setting up a Debian box to do builds on, and make bootstrap on
mainline is failing somewhere in the middle of Stage 1. The problem
appears to be that it's not looking in the right places for libgmp.so.3
when it calls ./gcc/xgcc at the end of the stage.
-
The box, for what it's
Daniel Jacobowitz wrote:
On Sat, Nov 04, 2006 at 10:57:14AM -0800, Brooks Moses wrote:
I've been setting up a Debian box to do builds on, and make bootstrap on
mainline is failing somewhere in the middle of Stage 1. The problem
appears to be that it's not looking in the right places
Rohit Arul Raj wrote:
I am working with a GCC Cross compiler version 4.1.1.
This small bit of code worked fine with all optimization except Os.
unsigned int n = 30;
void x ()
{
unsigned int h;
h = n = 30; // Line 1
if (h)
p = 1;
else
p = 0;
}
[...]
3. What are the
1 - 100 of 107 matches
Mail list logo
