"John David Anglin" <[EMAIL PROTECTED]> writes:
> I have a question about storage for uninitialized objects.
>
> I made the mistake of looking at the code being generated for
> testcase #2 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626.
> I noticed that reload used the same register r3 for
I have a question about storage for uninitialized objects.
I made the mistake of looking at the code being generated for
testcase #2 in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626.
I noticed that reload used the same register r3 for the variables
"call_result" and "node" after the call to af
On Fri, 13 Jan 2006, Eric Christopher wrote:
|
| > | OK?
| >
| > yes.
| >
| > | Did you want me to add this as a testcase?
| >
| > yes -- so that we don't regress.
|
| Ok. apparently I tested in the wrong directory and we already have a
| few testcases that test whether we're emitting warnings. I
> Perry Smith writes:
Perry> Now that I have (or think I have) my compiler and library problems
Perry> solved, I'm toying with the idea of creating a cross compile
Perry> environment on my Mac laptop for AIX (RS/6000). Does anyone see any
Perry> obstacles with this? I've never done a c
Now that I have (or think I have) my compiler and library problems
solved, I'm toying with the idea of creating a cross compile
environment on my Mac laptop for AIX (RS/6000). Does anyone see any
obstacles with this? I've never done a cross compile before.
Thank you,
Perry Smith
Marcin Dalecki <[EMAIL PROTECTED]> writes:
| Testing the resulting compiler has already a name:
|
| make test
That does not test the compiler on building the runtime.
There are a number of times where people reported runtime buik
failures after front-end changes. So, I don't think your statem
On Jan 8, 2006, at 7:19 PM, Daniel Berlin wrote:
On Sun, 2006-01-08 at 18:05 -0600, Bradley Lucier wrote:
OK, here are some details. Our server is a dual UltraSparc running
Solaris 10 attached to the SAN.
Working client situation: subversion 1.3.0 on Sparc Solaris 9, not
using Berkeley DB
On Sat, 14 Jan 2006, Jack Howarth wrote:
> FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)
This probably means your timestamps are out of order. Run
contrib/gcc_update --touch
to fix them.
--
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (pe
DJ Delorie wrote:
Seems rather marginal to worry about this. Surely this is letting
best be the enemy of good.
I agree. I was only noting the objections last time I suggested
something like this.
And as for it being a bug, that's just a matter of clear
documentation.
The prob
I have a number of things that I would like to see added to
collect2. If there is interest in them, I'll volunteer to do the
work. I am not sure of the process of making suggestions like this
so if there is another format, please let me know.
Changes to collect2:
1) Added the ability for
> Seems rather marginal to worry about this. Surely this is letting
> best be the enemy of good.
I agree. I was only noting the objections last time I suggested
something like this.
> And as for it being a bug, that's just a matter of clear
> documentation.
The problem was that you *can't* hav
I am seeing a new failure in the gcc testsuite for the gcc 4.1
branch built on MacOS X 10.4.4...
Running
/sw/src/fink.build/gcc4-4.1.0-20060114/gcc-4.1-20060114/gcc/testsuite/gcc.dg/cpp/cpp.exp
...
FAIL: gcc.dg/cpp/_Pragma3.c (test for excess errors)
Is this expected? None of the other
> Perry Smith writes:
Perry> I have a tool that I use to look at AIX dumps. It understands stab
Perry> strings that xlc (the IBM compiler) produces. I feed it a file
Perry> produced by gcc/g++ and it complains. The same thing happens with
Perry> dbx (IBM's debugger). Of course, gdb u
> Couldn't (and shouldn't) the start sequence in crt0 align the stack?
> It seems someone somewhere has to do that eventually anyway. I would
> not assume the OS is going to cooperate.
Yes, but that's not sufficient. The compiler must align local objects too.
--
Eric Botcazou
I have a tool that I use to look at AIX dumps. It understands stab
strings that xlc (the IBM compiler) produces. I feed it a file
produced by gcc/g++ and it complains. The same thing happens with
dbx (IBM's debugger). Of course, gdb understands it fine.
Has gcc/g++ extended the stab str
Snapshot gcc-4.2-20060114 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060114/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Jan 14, 2006, at 10:19 AM, Robert Dewar wrote:
Perry Smith wrote:
The conflict is actually 32bit, AIX, Altivec, and Ada
(together). So, how about for now, just say that Ada can't
support Altivec on 32bit AIX.
My point is that I'd like to keep Altivec support on 32bit AIX
for othe
Andrew Pinski wrote:
Huh? Where is this requirement documented because I don't see it at all
in tm.texi? Also what is Ada using BIGGEST_ALIGNMENT for, that just seems
wrong.
Ada uses BIGGEST_ALIGNMENT as the largest value that can be specified
for alignment
of a type (which seems a reaso
> Huh? Where is this requirement documented because I don't see it at all
> in tm.texi?
It's a logical consequence of the code in assign_stack_local_1.
> Also what is Ada using BIGGEST_ALIGNMENT for, that just seems
> wrong.
Well, the manual reads:
-- Macro: BIGGEST_ALIGNMENT
Biggest al
>
> > Why isn't this bug an incorrect use of BIGGEST_ALIGNMENT somewhere
> > in the compiler?
>
> Because you must have BIGGEST_ALIGNMENT <= STACK_BOUNDARY (or
> PREFERRED_STACK_BOUNDARY) in order to be able to allocate objects with
> BIGGEST_ALIGNMENT on the stack. Otherwise the offsets a
> The conflict is actually 32bit, AIX, Altivec, and Ada (together).
Not quite.
> My point is that I'd like to keep Altivec support on 32bit AIX for
> other languages.
Well, GCC has *no* Altivec support on AIX.
--
Eric Botcazou
> Why isn't this bug an incorrect use of BIGGEST_ALIGNMENT somewhere
> in the compiler?
Because you must have BIGGEST_ALIGNMENT <= STACK_BOUNDARY (or
PREFERRED_STACK_BOUNDARY) in order to be able to allocate objects with
BIGGEST_ALIGNMENT on the stack. Otherwise the offsets are not suffic
DJ Delorie wrote:
For example, if you have two warnings in one statement, you can't
control one but not the other if they use the same -W option. A minor
point, but if we used line numbers we'd be really close to "this
should work" that people would claim it's a bug when it doesn't.
Seems r
Perry Smith wrote:
The conflict is actually 32bit, AIX, Altivec, and Ada (together).
So, how about for now, just say that Ada can't support Altivec on
32bit AIX.
My point is that I'd like to keep Altivec support on 32bit AIX for
other languages.
I am confused, how can Altivec be prope
The conflict is actually 32bit, AIX, Altivec, and Ada (together).
So, how about for now, just say that Ada can't support Altivec on
32bit AIX.
My point is that I'd like to keep Altivec support on 32bit AIX for
other languages.
On Jan 14, 2006, at 9:03 AM, Eric Botcazou wrote:
A
Why isn't this bug an incorrect use of BIGGEST_ALIGNMENT somewhere
in the compiler?
David
Except that host tools (fastjar mostly) are made with the *new* GCC
rather than the old one.
And the reason is what? I don't see even any theoretical merit in the
whole staging thing:
1. Bugs can theoretically cancel them self out.
2. The compiler isn't stressing himself more then the targ
> And how does that solve the problem when Altivec is "supported"?
Let's first fix existing problems. :-) But a partial solution could be to
make BIGGEST_ALIGNMENT depend on TARGET_ALTIVEC_ABI and later set
TARGET_ALTIVEC_ABI unconditionally to 1 when Altivec support is added:
#define BI
> Eric Botcazou writes:
Eric> So why not revert to the original BIGGEST_ALIGNMENT setting until Altivec
is
Eric> supported? That would be more in keeping with all the other settings on
AIX.
And how does that solve the problem when Altivec is "supported"?
This just covers up proble
> AIX does support Altivec.
Great, but not GCC as far as I can see:
[EMAIL PROTECTED]:~/build/gcc/powerpc-ibm-aix5.3> gcc/xgcc -Bgcc -E -dM t.h
-maltivec
| grep __ALTIVEC__
[EMAIL PROTECTED]:~/build/gcc/powerpc-ibm-aix5.3>
So why not revert to the original BIGGEST_ALIGNMENT setting until
> > So the previous system was easy? IMO it's just that it's been tested for
> > 15 years. Personally it took me a lot of time to understand the working of
> > bubblestrap, stage*_copy, stage*_build, and so on
>
> The previous "make" was easy. Now even "make" is too much intricate for
> common
> So the previous system was easy? IMO it's just that it's been tested for
> 15 years. Personally it took me a lot of time to understand the working of
> bubblestrap, stage*_copy, stage*_build, and so on
The previous "make" was easy. Now even "make" is too much intricate for
common mortals.
>
> Eric Botcazou writes:
Eric> That's problematic (in particular for Ada) because nothing is 128-bit
aligned
Eric> on AIX 32-bit.
AIX does support Altivec.
David
Hi,
Its current setting is 128. It originally had been 64 and was bumped to 128
in 2001 when Altivec support was added; yet:
aix.h:
/* AIX does not support Altivec. */
#undef TARGET_ALTIVEC
#define TARGET_ALTIVEC 0
#undef TARGET_ALTIVEC_ABI
#define TARGET_ALTIVEC_ABI 0
That's problematic (i
Alfred M. Szmidt <[EMAIL PROTECTED]> wrote:
>Please read the web page:
>http://gcc.gnu.org/contribute.html
>
> This assumes a stable access to the 'net so that such information can
> be extracted when one is reading the documentation. Which isn't
> always the case for everyone. URL's sh
> make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java
> Wow, that's awkward.
I understand, but I have a patch to make it easier.
Patches for the toplevel take a long time to review, and I cannot handle
posting too many patches and tracking them. Not even two patches. Currently I
Please read the web page:
http://gcc.gnu.org/contribute.html
This assumes a stable access to the 'net so that such information can
be extracted when one is reading the documentation. Which isn't
always the case for everyone. URL's shouldn't point to important
information of this type in a
On Saturday 14 January 2006 02:18, Alfred M. Szmidt wrote:
> But this seems very awkward for people who only send a patch ones in a
> blue moon;
Why? There are lots of people who only send a few patches per year
and they all know how to contribute them.
> and not much good info on that either, t
38 matches
Mail list logo
