On 2005-04-18, at 04:22, Dan Kegel wrote:
Once the gcc C++ ABI stabilizes,
i.e. once all the remaining C++ ABI compliance bugs have
been flushed out of gcc, this requirement can be relaxed."
"Thus in esp. on Judgment Day we will relax this requirement".
The changes in CPU instrution sets surpasses
On 2005-04-18, at 04:37, Gareth Pearce wrote:
So I just started trying out gcc 4.1 - with a program which compiles
and
runs fine on gcc 3.3.
Attached is a reduced testcase which shows runtime segfault due to
stack
overflow if compiled with 4.1 but does not with 3.3. Trivial work
around is
to m
On Apr 18, 2005 07:41 AM, Roger Sayle <[EMAIL PROTECTED]> wrote:
>
> On Sat, 16 Apr 2005, Richard Kenner wrote:
> > Although, RTL expansion may introduce new loops, these tend to be
> > rare, and the expanders have all the information they need to
> > hoist/sink invariant expressions
Geoffrey Keating writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > Ranjit Mathew writes:
> > > Geoffrey Keating wrote:
> > > [...]
> > > > which I see you've already committed a patch for, and a large number
> > > > of Java failures.
> > > >
> > > > You can see full test res
On Sun, 17 Apr 2005, Geoffrey Keating wrote:
> > I thought we acted like it is "off", allowing CSE and constant folding
> > which might be affected by changes in rounding mode. Certainly some of
> > Stephen Moshier's testcases (attached to bug 20785) fail.
>
> The flag that controls this is -f
I take it from your comments, that you are in the camp that believes
that "the sun has not yet set" on the need for RTL optimizers. :-)
I'm actually in the camp that "the sun will never set" on the need for
some RTL optimizers. We'll be able to remove some of the most costly
of them and t
How does the i386 backend optimise the stack slot assignment to minimize
the displacement offset?
What code should I look at?
Or is there some other optimisation at work here...?
I.e.:
; -O0 => large offset
leal8268(%esp), %eax
incl(%eax)
; -O3 => small offset
i
Unfortunately you appear to have little clue what you are really
talking about. So let me provide you with some loud feedback as well.
Please try to keep this discussion on a civil level!
> I had greatly underestimated the importance of RTL alias analysis,
> especially with res
After encountering problems with 3.4.3 of gcc (it did not compile a
package I really needed to have - yes yes I am sure it is right and
better, BUT ...), I went back to 3.3.3 for a while. I just noticed that
there are two copies of libraries installed the install script on my
machine (one in /opt/l
> What is the purpose of having two such identically names libraries?
To support 2 architectures, 32-bit (sparcv7) and 64-bit (sparcv9).
> Or alternatively - which is the real one that I should be using?
Both, but the compiler automatically picks up the right one, depending on
whether you co
On Sun, 2005-04-17 at 19:22 -0700, Dan Kegel wrote:
> But I can't shake the feeling that it's crazy that libaspell
> got linked against two different C++ libraries. Can you
> try creating a minimal test case demonstrating this
> without involving inkscape? If so, maybe it's a glibc
> shared libra
For the PL/I front-end project (pl1gcc.sourceforge.net), I am just about to
begin to add a preprocessor expansion step, and was wondering what other
front-end do.
My initial thoughts were to create a completely separate program that just do
the preprocessing and passes the output to the compil
On Apr 18, 2005 02:51 PM, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Unfortunately you appear to have little clue what you are really
> > talking about. So let me provide you with some loud feedback as well.
>
> Please try to keep this discussion on a civil level!
I am (for a change,
Hi folks.
All mail addressed to me from Apr-3 to Apr-10 was not delivered. I was
having problems with my mail setup. Please resend.
My apologies for reporting this so late; I've been sequestered at
customer sites with no internet for the past week after my vacation :-(.
Cheers.
Aldy
I think Roger simply mis-spoke because in his original message, he
said what you said: the important issue is having the alias
information available in RTL. Much (but not all: eg., SUBREG info) of
that information is best imported down from the tree level.
Well, paradoxical subregs are just a mess
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results with the
contrib/test_summary script, and send me a message saying whether or
not there are a
> Please try to keep this discussion on a civil level!
I am (for a change, maybe) not the one who started making the
discussion uncivil.
I'm sorry, but in my opinion that doesn't matter. I don't call people
names or make personal attacks no matter what I'm responding to.
> Thi
Well, paradoxical subregs are just a mess:
Agreed, but I wasn't talking about the paradoxical case.
optimizations on paradoxical subregs are better served at the tree
level, because it is just obfuscation of e.g. QImode arithmetic.
Not clear: I think this is a more complex issue.
Hi Caroline,
You've made this change to assemble_start_function (unidiff format):
+ last_text_section = no_section;
+ in_section = no_section;
resolve_unique_section (decl, 0, flag_function_sections);
+
+ /* Switch to the correct text section for the start of the function. */
+
function
On 2005-04-17 19:34:40 -0700, Brooks Moses wrote:
> Yes, the standard refers to changing the rounding mode "if the processor
> supports [it]" -- but consider what the standard means by "processor":
> "The combination of a computing system and the means by which programs
> are transformed for use on
On Mon, 18 Apr 2005, Paolo Bonzini wrote:
> Roger proposed lowering 64-bit arithmetic to 32-bit in tree-ssa! How
> would you do it? Take
>
> long long a, b, c;
> c = a + b;
>
> Would it be
>
> c = ((int)a + (int)b)
> + ((int) (a >> 32) + (int) (b >> 32)
> + ((
But it turned out that CSE around basic blocks (-fcse-skip-blocks) was
still a very useful thing to do (and it still was, when I looked at it
again a couple of weeks ago).
And I would *very much* like to know why! My view was always that any
global CSE at all should render it unnecessary
On Apr 18, 2005, at 8:35 AM, Daniel Jacobowitz wrote:
Hi Caroline,
You've made this change to assemble_start_function (unidiff format):
+ last_text_section = no_section;
+ in_section = no_section;
resolve_unique_section (decl, 0, flag_function_sections);
+
+ /* Switch to the correct text sect
From line_map comment at (libcpp/include/line-map.h)
/* Physical source file TO_FILE at line TO_LINE at column 0 is
represented
by the logical START_LOCATION. TO_LINE+L at column C is
represented by
START_LOCATION+(L*(1<
What happens when column number is >= 128 ? This is PR 20907.
a
On Mon, Apr 18, 2005 at 09:47:55AM -0700, Caroline Tice wrote:
> Just out of curiousity, could you be more explicit about exactly how
> having
> an extra .text breaks the mechanism? That worries me...
asm(".section .init");
void _init() {
asm("@@@ MARKER @@@);
}
Then sed is used to separate
Hi,
thanks for your responses.
I've debugged a little further and found out that
the testcase breakage was caused by (the elfos.h part):
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00913.html
The elfos.h part of the patch was reverted on 04/14/2005:
http://gcc.gnu.org/ml/gcc-patches/2005-04/ms
You seem to be confused. We've known *why* CSE does stuff that GCSE
doesn't catch for almost as long as we've had GCSE.
It's because CSE *doesn't just do CSE*! It does value numbering, and
a bunch of other things, which are not really implemented at the RTL
level as seperate
I am trying to comment out
static GTY (()) int foo = 0;
with
#if 0
static GTY (()) int foo = 0;
#endif
But I got an error saying something like
./gth:44: error: foo undeclared here (not in a function)
Is that expected? How can I comment it out?
H.J.
On Apr 18, 2005, at 2:11 PM, H. J. Lu wrote:
I am trying to comment out
static GTY (()) int foo = 0;
with
#if 0
static GTY (()) int foo = 0;
#endif
But I got an error saying something like
./gth:44: error: foo undeclared here (not in a function)
Is that expected? How can I comment it out?
Yes,
Answer: FRAME_GROWS_DOWNWARD.
The stack slots for the registers spilled on the
stack are allocated last. When the frame grows downward,
the displacement is smaller than if the frame grows upward.
Thanks.
--
Øyvind Harboe
http://www.zylin.com
Hi,
I've been looking at GCC's use of sign-extensions when dealing with
integers smaller than a machine word size. It looks like there is room
for improvement.
Consider this C function:
short g(short x)
{
short i;
for (i = 0; i < 10; i++) {
x += i;
}
On Apr 18, 2005, at 9:55 AM, Devang Patel wrote:
From line_map comment at (libcpp/include/line-map.h)
/* Physical source file TO_FILE at line TO_LINE at column 0 is
represented
by the logical START_LOCATION. TO_LINE+L at column C is
represented by
START_LOCATION+(L*(1<
What happens when
On Monday 18 April 2005 18:28, Daniel Berlin wrote:
> The correct viewpoint is "we shouldn't remove CSE until every *profitable*
> transformation it makes is subsumed by something else".
>
> Otherwise, you've started with the unproven assumption that every
> transformation CSE makes is profitable.
On Monday 18 April 2005 20:53, Nicholas Nethercote wrote:
> Hi,
>
> I've been looking at GCC's use of sign-extensions when dealing with
> integers smaller than a machine word size. It looks like there is room
> for improvement.
Is your problem the same as the one described on one of the Wiki page
On Mon, 18 Apr 2005, Steven Bosscher wrote:
I've been looking at GCC's use of sign-extensions when dealing with
integers smaller than a machine word size. It looks like there is room
for improvement.
Is your problem the same as the one described on one of the Wiki pages,
"http://gcc.gnu.org/wiki/E
On Apr 18, 2005, at 11:54 AM, Mike Stump wrote:
On Apr 18, 2005, at 9:55 AM, Devang Patel wrote:
From line_map comment at (libcpp/include/line-map.h)
/* Physical source file TO_FILE at line TO_LINE at column 0 is
represented
by the logical START_LOCATION. TO_LINE+L at column C is
represente
On MIPS, libgcc is built with -G 0, which is used to ensure the contents
don't assume they will be placed in the small data/bss section. Setting -G
0 is used to allow for the possibility of large applications, or those
where even small data may be located more than 64k away from the gp pointer.
[EMAIL PROTECTED] (Richard Kenner) writes:
> The correct viewpoint is "we shouldn't remove CSE until every
> *profitable* transformation it makes is subsumed by something else".
>
> And, as I understand it, the claim is that this is not yet true for the
> following of jumps and m
The minor "problem" is still there in RC2, I opened PR21094 about it:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21094
Laurent
> A minor thing:
>
> I configured with c,ada only (no C++) on x86 and x86_64-linux and got
> http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00791.html
> http://gcc.
On Mon, Apr 18, 2005 at 07:44:03AM -0700, Mark Mitchell wrote:
>
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contr
c,ada are clean on x86 and x86_64 linux.
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01311.html
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01313.html
Laurent
was: Re: *SPAM* Re: My opinions on tree-level and RTL-level
optimization
On Monday 18 April 2005 19:43, Richard Kenner wrote:
an email.
Which the Novell spam filter thinks is spam.
Sorry if I miss an email from you, the reason is obvious: I throw
all messages marked "SPAM" straight to
On Mon, 2005-04-18 at 13:34 -0700, Dan Nicolaescu wrote:
> [EMAIL PROTECTED] (Richard Kenner) writes:
>
> > The correct viewpoint is "we shouldn't remove CSE until every
> > *profitable* transformation it makes is subsumed by something else".
> >
> > And, as I understand it, the cl
Hi Richard,
The documentation for the atomic operation patterns says things like:
This pattern must issue any memory barrier instructions such that the
pattern as a whole acts as a full barrier.
Should the barrier happen before the operation, after the operation,
are there two barriers, or is it u
Steven Bosscher <[EMAIL PROTECTED]> writes:
> was: Re: *SPAM* Re: My opinions on tree-level and RTL-level
> optimization
>
> On Monday 18 April 2005 19:43, Richard Kenner wrote:
>
> an email.
>
> Which the Novell spam filter thinks is spam.
This is because he is using an obsolete mailer
On Apr 16, 2005, at 15:45, Nathan Sidwell wrote:
It's not clear to me which is the best approach. (b) allows threads to
be supported via copious uses of volatile (but probably introduces
pessimizations), whereas (a) forces the thread interactions to be
compiler
visible (but shows more promise for
Ken Raeburn wrote:
On Apr 16, 2005, at 15:45, Nathan Sidwell wrote:
It's not clear to me which is the best approach. (b) allows threads to
be supported via copious uses of volatile (but probably introduces
pessimizations), whereas (a) forces the thread interactions to be
compiler
visible (but sho
On 2005-04-18, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contrib/test_su
Björn Haase wrote:
In case that one should not use machine specific atttributes, *is* there a
standard way for GCC how to implement different address spaces?
Use section attributes to force functions/variables into different
sections, and then use linker scripts to place different sections into
On Apr 18, 2005, at 3:08 PM, Ken Raeburn wrote:
Is there anything in the language specifications (mainly C++ in
this context, but is this an area where C and C++ are going to
diverge, or is C likely to follow suit?) that prohibits spurious
writes to a location?
No, in both languages. The rea
"H. J. Lu" <[EMAIL PROTECTED]> writes:
> I am trying to comment out
>
> static GTY (()) int foo = 0;
>
> with
>
> #if 0
> static GTY (()) int foo = 0;
> #endif
>
> But I got an error saying something like
>
> ./gth:44: error: foo undeclared here (not in a function)
>
> Is that expected?
> Joe> For sparc-sun-solaris2.8, I get a failure when building the Java
> compiler,
> Joe> but I may be doing something wrong, as I usually avoid the Java build
> Joe> on Solaris (since it takes most of a day to build and test). The message
> Joe> is
>
> Joe> java/parse.o(.text+0x16cc): In func
James Tabor wrote:
fp-bit.c:744: error: unrecognizable insn:
(call_insn:HI 53 49 59 0 fp-bit.c:743 (parallel [
(set (reg:SF 33 1)
(call (mem:SI (symbol_ref:SI ("__pack_f") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0])))
(use (const_int 0
On Monday 18 April 2005 20:53, Nicholas Nethercote wrote:
> Hi,
>
> I've been looking at GCC's use of sign-extensions when dealing with
> integers smaller than a machine word size. It looks like there is room
> for improvement.
>
> Consider this C function:
>
> short g(short x)
> {
>
Clemens Koller wrote:
/usr/local/lib/nof/libstdc++.so.6: undefined reference to
[EMAIL PROTECTED]'
/usr/local/lib/nof/libstdc++.so.6: undefined reference to
[EMAIL PROTECTED]'
These functions should come from libgcc_s.so or libgcc_eh.a, depending
on whether this is a shared or static link.
Try
On Mon, Apr 18, 2005 at 05:13:33PM -0700, Joe Buck wrote:
> [ solaris failure building Java compiler ]
> It appears the bug is because there's a libiconv.so in /usr/local/lib on
> that machine, with headers in /usr/local/include, but /usr/local/lib isn't
> in my LD_LIBRARY_PATH. configure finds th
Petar Penchev wrote:
I tried to use force_reg or PUT_MODE
but it does nothing and PUSH AL, inc S remain.
If nothing is happening, then that means the peephole isn't matching.
The matching happens in peephole2_insns. You could try putting a
breakpoint there and stepping through the code to see wh
Guochun Shi wrote:
make[1]: Entering directory
`/home/gshi/gcc/gcc-4.0.0-20050410/build-i686-pc-linux-gnu/libiberty'
make[1]: *** No rule to make target `../include/ansidecl.h', needed by
`regex.o'. Stop.
make[1]: Leaving directory
`/home/gshi/gcc/gcc-4.0.0-20050410/build-i686-pc-linux-gnu/libi
Mark Mitchell <[EMAIL PROTECTED]> writes:
> RC2 is available here:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
>
> As before, I'd very much appreciate it if people would test these bits
> on primary and secondary platforms, post test results with the
> contrib/test_summary script,
Ling-hua Tseng wrote:
> It's obvious that `movil' and `movim' are only access the partial
> 16-bit of the 32-bit register. How can I use RTL expression to
> represent the operations?
As you noticed, within a register, subreg can only be used for low
parts. You can't ask for the high part of a s
On Apr 18, 2005, at 9:07 PM, Geoffrey Keating wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
RC2 is available here:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.0-20050417/
As before, I'd very much appreciate it if people would test these bits
on primary and secondary platforms, post test results w
> Geoffrey Keating writes:
Geoff> The documentation for the atomic operation patterns says things like:
>> This pattern must issue any memory barrier instructions such that the
>> pattern as a whole acts as a full barrier.
Geoff> Should the barrier happen before the operation, after the oper
Devang Patel wrote:
warning: initialization discards qualifiers from pointer target type
This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
It looks like we have been doing it this way since at least gcc-1.42.
The same code is there, with n
> > 2005-04-12 Paolo Bonzini <[EMAIL PROTECTED]>
> >
> > * acx.m4 (ACX_PROG_GNAT): Remove stray break.
>
> OK for 4.0.0.
Mark,
When this patch went into 4.0, Paolo didn't regenerate the top level
configure, although the ChangeLog claims he did:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg
On Apr 18, 2005, at 6:29 PM, James E Wilson wrote:
This seems rather unlikely to be an accident.
I agree, I'm sure it was due to bad system header files, only some of
which had const and others didn't. By ignoring the issue in the
compiler, the compiler works on such (broken) systems. The usu
On 18/04/2005, at 6:13 PM, David Edelsohn wrote:
Geoffrey Keating writes:
Geoff> The documentation for the atomic operation patterns says things
like:
This pattern must issue any memory barrier instructions such that the
pattern as a whole acts as a full barrier.
Geoff> Should the barrier happen
On Apr 18, 2005, at 6:29 PM, James E Wilson wrote:
Devang Patel wrote:
warning: initialization discards qualifiers from pointer
target type
This warning can not be disabled using -Wno-cast-qual
(or any other warning flags). Is it intentional ?
It looks like we have been doing it this way sin
. I had a similar problem with 'do_waitid' and I have attached
the patch just for the sake of discussion. Does anyone have some
insight on this? I am using binutils-2.15, glibc-2.3.4, 2.6.12-rc2
kernel headers and gcc-4.1.0-20050418. Thanks.
-Steve
mips-unknown-linux-gnu-gcc -mabi=32
../sy
Martin Koegler wrote:
I added to the i386 version the following code (using a unmodified gcc for the rest):
With this change, I can reproduce the problem.
I noticed that I get a failure for all types, not just array types.
This is different than what you described earlier, but perhaps the
differe
> the patch just for the sake of discussion. Does anyone have some
> insight on this? I am using binutils-2.15, glibc-2.3.4, 2.6.12-rc2
> kernel headers and gcc-4.1.0-20050418. Thanks.
>
I'd use 2.16 binutils, especially if using mainline gcc, but that's not
as relevant h
> >
> > Though of course, this doesn't mean that we can't have an option to
> > control it. -Wno-cast-qual doesn't seem like the right choice, as
> > there is no user cast here. Maybe something like -Wno-discard-
> > qual, where -Wdiscard-qual is the default.
> >
> > I notice that these are
On Mon, Apr 18, 2005 at 02:48:27PM -0700, Geoffrey Keating wrote:
> The documentation for the atomic operation patterns says things like:
>
> >This pattern must issue any memory barrier instructions such that the
> >pattern as a whole acts as a full barrier.
>
> Should the barrier happen before t
nothing
worked. I had a similar problem with 'do_waitid' and I have attached
the patch just for the sake of discussion. Does anyone have some
insight on this? I am using binutils-2.15, glibc-2.3.4, 2.6.12-rc2
kernel headers and gcc-4.1.0-20050418. Thanks.
../sysdeps/unix/sysv/linux/waitid.c: I
So the combination of the TCB merge plus the pending jump threading
changes apparently has ticked a reload bug which manifests itself with
the stage1 compiler mis-compiling the stage2 compiler.
Upon entry into local-alloc we have the following key insns:
(insn:HI 88 85 89 10 (set (reg:QI 66 [ D.
> For sparc-sun-solaris2.8, I get a failure when building the Java compiler,
> but I may be doing something wrong, as I usually avoid the Java build
> on Solaris (since it takes most of a day to build and test).
Known glitch. You have to find out why configure thinks you have libiconv
installed
> So the combination of the TCB merge plus the pending jump threading
> changes apparently has ticked a reload bug which manifests itself with
> the stage1 compiler mis-compiling the stage2 compiler.
>
> [...]
>
> Which faults because the memory location is actually read-only memory.
PR rtl-optim
Kaveh R. Ghazi wrote:
When this patch went into 4.0, Paolo didn't regenerate the top level
configure, although the ChangeLog claims he did:
http://gcc.gnu.org/ml/gcc-cvs/2005-04/msg00842.html
You're right. I was being conservative and typed the "cvs ci" filenames
manually, but in this case the
77 matches
Mail list logo
