On Mar 23, 2005, Ian Lance Taylor wrote:
> Of course, correctly modeling the effect on the condition codes
> really means putting the information in the RTL so that it is
> exposed to the RTL optimizers.
True, but we want to avoid that because of the loss of optimization
opportunities. Besides,
Hello,
hopefully, you can give me a hint of what's wrong with my Qt compile
issues... (I got no answer in Qt-interest so you are my last
chance):
I ran into a problem installing Qt on my embedded PowerPC platform
(without previous install of Qt). The build was fine, but the
installation breaks when
Hans-Peter Nilsson wrote:
On Sun, 13 Mar 2005, Øyvind Harboe wrote:
Trampolines are strange things... :-)
- AFAICT, the cris target is saving the value of the
static chain register in the trampoline. How can that work
with recursive functions?
What's wrong with that?
Do I miss something fundam
Call the following snippet `bug.cc':
struct a {
static const int size = 0;
};
template
struct p {
int a[T::size]; // Here it says "error: creating array with size zero (`0')"
};
p n;
template
struct q {
int a[0]; // Here it says nothing!
};
q m;
$ g++ -v
Reading specs from /usr/local/
Kazu Hirata wrote:
Hi,
I would like to announce that fold_buildN are now ready.
Great!
When and how do we want to do these conversion?
Currently, I am thinking about doing converting all of
"fold (buildN (...))" and "fold (build (...))" to fold_buildN as soon
as stage 2 starts, which is about one m
Hi Roberto,
> Should I report this as a bug?
> If so, which kind of bug is it?
Isn't this c++/19989?
Paolo.
Paolo Carlini wrote:
>Hi Roberto,
>
>>Should I report this as a bug?
>>If so, which kind of bug is it?
>>
>Isn't this c++/19989?
>
I should add that, on top of pt.c:tsubst (where the first error is issued
unconditionally, irrespective of -pedantic) there is the following comment:
Paolo Carlini wrote:
Should I report this as a bug?
If so, which kind of bug is it?
Isn't this c++/19989?
Hi Paolo,
yes, I think it is that one.
Thanks,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Mar 23, 2005, Ian Lance Taylor wrote:
>
> > Of course, correctly modeling the effect on the condition codes
> > really means putting the information in the RTL so that it is
> > exposed to the RTL optimizers.
>
> True, but we want to avoid that b
Ian Lance Taylor writes:
> Looking at your suggestion makes me realize that my suggestion is too
> complicated. It's not necessary to generate the combinatorial
> explosion at all. We can always keep cc0 setters and cc0 users in
> separate instructions. The key is to keep them from getting
> d
OK, here is a different approach toward eliminating cc0, based on a
combination of my earlier proposal and what Alex described. I'm
looking for comments from anybody.
1) Modify the programs which read the .md file to look for an
attribute named clobbercc. If such an attribute exists, then for
On Thu, Mar 24, 2005 at 11:44:52AM -0500, Ian Lance Taylor wrote:
> OK, here is a different approach toward eliminating cc0, based on a
> combination of my earlier proposal and what Alex described. I'm
> looking for comments from anybody.
One potential problem: once the NOTICE_UPDATE_CC pass is d
Richard Henderson <[EMAIL PROTECTED]> writes:
> Note that there's no longer any insn that *sets* cc_reg. I think
> that's a bit dangerous.
Hmmm, good point.
> One solution to this is to convert the new setter to
>
> [(set (reg 1) (plus (reg 1) (reg 2)))
>(set (reg cc_reg) (unspe
Hi,
only one question please, gcc can compile cobol source? (procobol)
thanks very much!
bye
Ian Lance Taylor writes:
> 3) Write a new CC0 collapse pass. This pass is run immediately
> after RTL expansion. It walks the instruction stream looking for
> instructions which set and use CC_REG. At this point these
> instructions will always be adjacent. The pass combines them into
> the c
Zack Weinberg <[EMAIL PROTECTED]> writes:
> Ian Lance Taylor writes:
>
> > 3) Write a new CC0 collapse pass. This pass is run immediately
> > after RTL expansion. It walks the instruction stream looking for
> > instructions which set and use CC_REG. At this point these
> > instructions will a
[If you're in the explicit CC: list for this mail, I've mentioned you
explicitly below, and I'm hoping that you'll be able to provide me
some feedback.]
I've looked through the 36 critical (i.e., wrong-code, ice-on-valid, or
rejects-valid) regressions open against 4.0. They are categorized
below
On Mar 24, 2005, at 10:32 AM, Galli Andrea wrote:
only one question please, gcc can compile cobol source? (procobol)
You know, there is this thing called google. It is wonderful, you
can type http://www.google.com into your favorite web browser, and
the type GNU cobol and then return, and it w
Hi,
I've been attempting to build the gcc-4.0 20050319 snapshot under
mingw/msys for arm-elf target with a few problems.
the mingw32 gcc is 3.4.2
Configuring seems to work fine.
../../$GCC_SRCDIR/configure \
--enable-languages=c,c++ \
--enable-interwork --enable-multilib\
--with-gcc --wi
> Truly Critical
> --
>
> 19225 Segmentation fault with VLAs, affects GLIBC
>
> This is the TYPE_STUB_DECL that Dan Berlin looked into for a while.
> What is the current status?
I think you mean 19345.
Anyway, the long and short of it is that the real bug here is that
TYPE_NAME
Dale Johannesen wrote:
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call, and when it gets back to the landing pad?
There is no direct r
Stefan Strasser wrote:
movl %ebx, -200(%ebp)
movl %ebx, -196(%ebp)
movl %eax, 4(%esp)
movl -200(%ebp), %edx
movl -196(%ebp), %ecx
It is hard to say without a testcase, but my first guess would be reload
inheritance and/or the post-reload cse pass.
Reload may need to load/store something from
Ian Lance Taylor writes:
> Zack Weinberg <[EMAIL PROTECTED]> writes:
>> I'm not understanding why this is a separate pass, instead of
>> generating the combined instructions directly in the expander. I
>> think generic expander support for compare-and-branch instructions
>> already exists...
>
>
On Mar 24, 2005, at 12:35 PM, James E Wilson wrote:
Dale Johannesen wrote:
I'm interested in fixing this, but could use some help from somebody
knowledgeable about how x86 EH is supposed to work. In particular,
what's the expected relationship between SP at the point of a throwing
call, and when i
On Thu, Mar 24, 2005 at 11:29:09AM -0800, Mark Mitchell wrote:
> 17855 ICE on C code that modifies call return values
>
> RTH and Joseph looked at this; no fix yet.
I'm not sure why this is marked as ice-on-valid; the construct in
question has undefined behaviour.
> 20342 ICE in reload w/ SSE/
On Thu, 24 Mar 2005, Richard Henderson wrote:
> On Thu, Mar 24, 2005 at 11:29:09AM -0800, Mark Mitchell wrote:
> > 17855 ICE on C code that modifies call return values
> >
> > RTH and Joseph looked at this; no fix yet.
>
> I'm not sure why this is marked as ice-on-valid; the construct in
> que
On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote:
> Undefined behavior on execution, not on translation.
It's still a stretch on the word "valid".
r~
Steve Ellcey wrote:
Any optimization experts care to take a look at this test case and help
me understand what is going on and if this change from 3.4 to 4.0 is
intentional or not?
Use the -da -fdump-tree-all options, and start looking at the dumps.
The first thing I notice is that in the RTL .loop
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already suggested
a solution though not a patch (disable deferred argument popping when a
call can throw). It isn't marked critical though, so I d
On Mar 24, 2005, at 3:08 PM, James E Wilson wrote:
Richard Henderson wrote:
19255 EH bug on IA32 when using heavy optimization
Typo in pr number?
I think that is supposed to be 19225, for which I have already
suggested a solution though not a patch (disable deferred argument
popping when a call c
Michael LeBlanc wrote:
Does that option do anything except supply -maltivec implicitly?
As explained in the install docs, it does two things, enables -maltivec
by default, and enables -mabi=altivec by default.
This option has been deprecated and removed in the upcoming gcc-4.0
release. The pref
Richard Henderson wrote:
On Thu, Mar 24, 2005 at 09:27:37PM +, Joseph S. Myers wrote:
Undefined behavior on execution, not on translation.
It's still a stretch on the word "valid".
It's probably reasonable to say that this is not absolutely a
showstopper, as well-written code presumably won't
On Thursday 24 March 2005 23:28, James E Wilson wrote:
> I'd suggest filing a bug report for this problem to make sure it gets
> fixed.
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
> I'd suggest trying -fmove-loop-invariants, and report a bug about
> that instead if it does not move those loop invariants. We really
> should move away from loop.c anyway.
In general, yes, but we will probably always need some RTL loop
optimi
On Mar 24, 2005, at 7:31 PM, James E Wilson wrote:
On Thu, 2005-03-24 at 15:52, Steven Bosscher wrote:
I'd suggest trying -fmove-loop-invariants, and report a bug about
that instead if it does not move those loop invariants. We really
should move away from loop.c anyway.
In general, yes, but we wi
On Thu, 2005-03-24 at 16:39, Andrew Pinski wrote:
> Jim you know that -fmove-loop-invariants enables the "new" RTL BB based
> loop optimizer? This option was added back in 3.4.0.
No, I don't, and I stupidly didn't bother to check. I thought he was
talking about some tree-ssa option.
I tried it,
On Mar 24, 2005, at 8:09 PM, James E Wilson wrote:
I tried it, it doesn't help. It solves neither the loop invariant code
motion problem nor the do-loop optimization problem.
The do-loop optimization which 3.3/3.4 was doing was invalid (see the
bug
referenced below).
I filed it under PR 19210 an
Targets, such as Windows, that don't have getopt() will probably have
get the following error when compiling binutils.
gcc -DHAVE_CONFIG_H -I.
-I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I. -D_GNU_SOURCE
-I. -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I../bfd
-I/aaronwl/cs/co
Daniel Berlin wrote:
Truly Critical
--
19225 Segmentation fault with VLAs, affects GLIBC
This is the TYPE_STUB_DECL that Dan Berlin looked into for a while.
What is the current status?
I think you mean 19345.
Anyway, the long and short of it is that the real bug here is that
TYPE_NAM
Hi
There are occasions, especially when bootstrapping a whole new World where
one needs to build GCC multiple times, that you don't want to be
bootstrapping GCC on every invocation, only the first.
On x86 with GCC-4 and above, `make bootstrap' results in the compiler being
built with `BOOT_CFLAGS
> 20263 SPARC64 ASM bug
>
> Eric has a patch; I've asked about possible other ways to fix it.
I've answered, but probably not very constructively as your remark was not
crystal-clear either. :-) Btw, I think you should "Add CC" you when you
comment on specific PRs in order to speed up the disc
> This means you get a different compiler depending on whether you `make
> bootstrap'ed it or not, which just seems wrong to me. This never used to
> be the case.
Isn't that always the case in general? With a 'make bootstrap' the compiler
is built by itself whereas with a bare 'make' it is built
42 matches
Mail list logo
