libstdc++'s bitmap_allocator.cc, because for some reason reload wants
a MODE_PARTIAL_INT mode with 64 bits. There is no such mode, so
get_smallest_mode_for_size aborts. I am attaching the .lreg and .greg
dumps to this message (compressed).
Naively speaking, shouldn't it also look for MODE_IN
On 7/5/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> For me both canonicalizations generate
>
> movl8(%ecx,%edx,4), %eax
> addl4(%ecx,%edx,4), %eax
Hmm, there seem to be other problems in this area as well.
Either add a "p
On 03/07/2007, at 9:18 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
Yes. __attribute__((visibility)) has consistent GNU semantics, and
other features (eg. -fvisibility-ms-compat, __dllspec) match other
compilers.
"Zack Weinberg" <[EMAIL PROTECTED]> writes:
[std_expand_builtin_va_start]
> rtx va_r = expand_normal (valist);
> emit_move_insn (va_r, nextarg);
>
> but this is a part of the compiler I am not at all familiar with...
I think you would want something more like
rtx va_r = expand_expr (val
"Gregory B. Prokopski" <[EMAIL PROTECTED]> writes:
> One of the operations I need to perform is to reorder basic blocks in a
> particular manner. This works fine for example on i386 and other that have
> HAS_LONG_COND_BRANCH, HAS_LONG_UNCOND_BRANCH set. However on platforms like
> PPC, after the
On 7/5/07, Zack Weinberg <[EMAIL PROTECTED]> wrote:
I'll try your patch, but I would still like to know whether we
couldn't stop using make_tree altogether, just expand valist and then
pass it to emit_move_insn (or maybe convert_move would be better).
Patch does not help. Exactly the same fail
Fu, Chao-Ying wrote:
Hi,
I got one test that failed by using the mainline GCC
on the target of mipsisa32r2-elf.
The handling of stack pointer or frame pointer may be broken.
Thanks!
Can you file a bug report so we can track the problem. Also if you know
of a GCC version that does not fai
Hi,
I got one test that failed by using the mainline GCC
on the target of mipsisa32r2-elf.
The handling of stack pointer or frame pointer may be broken.
Thanks!
Ex:
# mipsisa32r2-elf-gcc -o bug126 -Tidt32.ld bug126.c
# mipsisa32r2-elf-run bug126
mips-core: 4 byte read to unmapped address 0x4 at
I'll try your patch, but I would still like to know whether we
couldn't stop using make_tree altogether, just expand valist and then
pass it to emit_move_insn (or maybe convert_move would be better).
zw
On 7/5/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
I posted this to a bug report, specifically about this target too, I
forgot which one. I was hoping someone would test it for me because I
have not got a sim experience to be able to test.
Found the bug, http://gcc.gnu.org/bugzilla/show_bug.c
On 7/5/07, Zack Weinberg <[EMAIL PROTECTED]> wrote:
I'm trying to help DJ with converting m32c to define_constraint, and
I'm running into an unrelated problem. Specifically, the unmodified
compiler targeting m32c-elf, in -mcpu=m32cm mode, crashes on any use
of __builtin_va_start, even this:
Th
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> For me both canonicalizations generate
>
> movl8(%ecx,%edx,4), %eax
> addl4(%ecx,%edx,4), %eax
Hmm, there seem to be other problems in this area as well.
Either add a "p[i + 3]" to it to fool combine or try this:
int g(v
I'm trying to help DJ with converting m32c to define_constraint, and
I'm running into an unrelated problem. Specifically, the unmodified
compiler targeting m32c-elf, in -mcpu=m32cm mode, crashes on any use
of __builtin_va_start, even this:
int foo(int x, ...)
{
__builtin_va_list t;
__builtin_v
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, Richard Guenther wrote:
>
> > > How should this be optimized within the context of your canonicalization?
> >
> > For example by making fold_plusminus_mult_expr do what its comment
> > suggest, "No identical multiplicands; se
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> > How should this be optimized within the context of your canonicalization?
>
> For example by making fold_plusminus_mult_expr do what its comment
> suggest, "No identical multiplicands; see if we can find a common
> power-of-two factor ..."
>
>
Hi,
I am working on adding support for code-copying to GCC that can be used to
safely speed up interpreter-based VMs, as will be presented at GCC Summit:
http://www.gccsummit.org/2007/view_abstract.php?content_key=30
One of the operations I need to perform is to reorder basic blocks in a
particu
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, Richard Guenther wrote:
>
> > Well, that's always the nature of any canonicalization.
>
> Well, I can't say that I agree with your canonicalization, but...
>
> > of course only tested on this particular testcase. It just sh
-Original Message-
A few months ago this did not happen (same building procedure).
___
You posted this several places, and they're still arriving. Apparently,
nothing has changed, except they've added this warning that the maintainers of
this librar
On 7/5/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
Hi,
On Thu, 5 Jul 2007, I wrote:
> Exactly and that's why I think this transformation is done far too early.
> It doesn't make sense that these two examples produce different code:
>
> int foo1(int x)
> {
> return (x * 4) + 4;
> }
> int f
On 7/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, Richard Guenther wrote:
>
> > If there is anything to fix, then all those variants should produce
> > the same code, not just foo3 and foo4. So for these cases we should
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> Well, that's always the nature of any canonicalization.
Well, I can't say that I agree with your canonicalization, but...
> of course only tested on this particular testcase. It just shows
> that it is possible to fix this in a generic way.
le
On Thu, 5 Jul 2007, Alexandre Oliva wrote:
> We might want to take GDB's practice of adding DEPRECATED_ to
> deprecated constructs, such that people who stumble across the code
> are more likely to notice that it needs auditing and updating.
The GDB method (port x86-foo uses deprecated_something,
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> On Jul 5, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>>
>> > The work here is not changing the bits. the work here is the actual
>> > auditing of each place to see if it was the correct place.
>>
Uros Bizjak wrote:
Uros Bizjak wrote:
gcc Revision: 126372, bootstrap from clean directory breaks with:
/home/uros/gcc-build/./prev-gcc/xgcc
-B/home/uros/gcc-build/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing
Gerald Pfeifer writes:
> It is my pleasure to announce that the steering committee has
> appointed Rainer Orth IRIX and Tru64 UNIX maintainer
>
> Congratulations, Rainer!
>
> Please adjust the MAINTAINERS file accordingly, and Happy Hacking,
Done with the following patch (only about a year late
Uros Bizjak wrote:
gcc Revision: 126372, bootstrap from clean directory breaks with:
/home/uros/gcc-build/./prev-gcc/xgcc
-B/home/uros/gcc-build/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-s
Hello!
gcc Revision: 126372, bootstrap from clean directory breaks with:
/home/uros/gcc-build/./prev-gcc/xgcc -B/home/uros/gcc-build/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definiti
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Jul 5, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
>
> > The work here is not changing the bits. the work here is the actual
> > auditing of each place to see if it was the correct place.
>
> Then I guess the best option is to leave no_new_p
Richard Guenther wrote:
Excellent. Let's see if we can have some performance numbers (from Richard ;)
Uh, I know of no thing that uses complex numbers and does not manually
implement them.
Crazy. I understand both in C and in C++, right?
Therefore, we should consider your observation
On Thu, 5 Jul 2007, Paolo Carlini wrote:
> Mark Mitchell wrote:
>
> >To be clear, my preferences, from most preferable to least are:
> >
> >* Method 2 is the default for all C variants, but can be overridden by
> >-ffast-math, or -fcomplex-method.
> >
> >* Method 2 is the default for C99 and C++0
On Thu, Jul 05, 2007 at 10:58:35AM -0700, Ian Lance Taylor wrote:
> "H.J. Lu" <[EMAIL PROTECTED]> writes:
>
> > > I'm also uncertain as to just who approved the commit of
> > > libgcc/config/libbid into mainline. When I look at the code I see
> >
> > http://gcc.gnu.org/ml/gcc/2007-06/msg00457.ht
On Jul 5, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> The work here is not changing the bits. the work here is the actual
> auditing of each place to see if it was the correct place.
Then I guess the best option is to leave no_new_pseudos defined as a
macro, such that we can introduce the
Mark Mitchell wrote:
To be clear, my preferences, from most preferable to least are:
* Method 2 is the default for all C variants, but can be overridden by
-ffast-math, or -fcomplex-method.
* Method 2 is the default for C99 and C++0x, but not for C89 or C++, but
can be overridden by -ffast-mat
Paolo Carlini wrote:
> Ah, one final remark wrt C++0x: note that currently, irrespective of the
> switches, there is *no way* for the user to choose method 2 in C++. I
> think this is very bad in C++0x mode: essentially, as regards this
> feature, it cannot track C99 as it *must*. I really hope we
Uros Bizjak <[EMAIL PROTECTED]> writes:
> IMO the situation here is the same as with current soft-fp
> situation. The library should be considered as imported from upstream,
> and the decisions w.r.t formatting are inherited from the upstream. In
> soft-fp case, functions don't have prototypes, an
Hi Mark,
Paolo Carlini wrote:
Therefore, I'm not sure... I would certainly like to see method 2
becoming the default everywhere, on the other hand, I'm not sure if
method 2 isn't too slow as default for C89 (outside fast-math, I
repeat). Shall we carry out performance tests perhaps, or peak
pe
"H.J. Lu" <[EMAIL PROTECTED]> writes:
> > I'm also uncertain as to just who approved the commit of
> > libgcc/config/libbid into mainline. When I look at the code I see
>
> http://gcc.gnu.org/ml/gcc/2007-06/msg00457.html
> http://gcc.gnu.org/ml/gcc/2007-06/msg00491.html
>
> Both x86 maintainer
> "Uros" == Uros Bizjak <[EMAIL PROTECTED]> writes:
Uros> IMO the situation here is the same as with current soft-fp
Uros> situation. The library should be considered as imported from upstream,
Uros> and the decisions w.r.t formatting are inherited from the
Uros> upstream.
In this case the li
Paolo Carlini wrote:
> Therefore, I'm not sure... I would certainly like to see method 2
> becoming the default everywhere, on the other hand, I'm not sure if
> method 2 isn't too slow as default for C89 (outside fast-math, I
> repeat). Shall we carry out performance tests perhaps, or peak
> perfo
Hello!
I'm also uncertain as to just who approved the commit of
libgcc/config/libbid into mainline. When I look at the code I see
that it is not formatted to the GNU standard, and it includes C++
style comments which we do not normally use in C code.
IMO the situation here is the same as w
I'm also uncertain as to just who approved the commit of
libgcc/config/libbid into mainline. When I look at the code I see
Both x86 maintainer and build/libgcc maintainer reviewed the patch.
Note that build != libgcc maintainer. One may argue whether a libgcc
maintainer's approval is needed
Hi Mark,
I'd prefer not to introduce a situation in which compiling the same code
with "gcc" and with "g++" behaves differently and which performs worse
in one case than the other. Users expect the C subset of C++ to perform
like C.
If we want the C99 rules, let's just turn them on everywhere,
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, Richard Guenther wrote:
>
> > If there is anything to fix, then all those variants should produce
> > the same code, not just foo3 and foo4. So for these cases we should
> > make sure that value-numbering sees them as computi
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> If there is anything to fix, then all those variants should produce
> the same code, not just foo3 and foo4. So for these cases we should
> make sure that value-numbering sees them as computing the same value
> and extend combine to choose the in
On Thu, Jul 05, 2007 at 09:46:27AM -0700, Ian Lance Taylor wrote:
> "H.J. Lu" <[EMAIL PROTECTED]> writes:
>
> > I am checking in this patch to add myself as libbid maintainer.
>
> Normally changes to the list of maintainers are approved by the
> steering committee. I didn't see any notice about
Richard Guenther wrote:
>> I'm having a look to libstdc++/30482, which basically is C++ issue: Jakub
>> basically raises the issue of whether we want to use by default the
>> C99-conforming division in C++ too. Personally, I would be in favor of
>> enabling it unconditionally, modulo maybe a perfo
On Thu, Jul 05, 2007 at 07:36:24PM +0300, Dorit Nuzman wrote:
>> Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
>> 17:46:45:
>>
>>> On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
>> checking whether the GNU Fort
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, I wrote:
>
> > Exactly and that's why I think this transformation is done far too early.
> > It doesn't make sense that these two examples produce different code:
> >
> > int foo1(int x)
> > {
> > return (x * 4) + 4;
> >
Hi,
On Thu, 5 Jul 2007, I wrote:
> Exactly and that's why I think this transformation is done far too early.
> It doesn't make sense that these two examples produce different code:
>
> int foo1(int x)
> {
> return (x * 4) + 4;
> }
> int foo2(int x)
> {
> int y = x * 4;
> retur
"H.J. Lu" <[EMAIL PROTECTED]> writes:
> I am checking in this patch to add myself as libbid maintainer.
Normally changes to the list of maintainers are approved by the
steering committee. I didn't see any notice about this one. I would
just like to confirm that this change was approved.
I'm al
> Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
> 17:46:45:
>
> > On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> > > Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> > >
> > > > > checking whether the GNU Fortran compiler is working... no
> > > > > configure: error: GN
On 05 July 2007 17:06, Joe Buck wrote:
> On Wed, Jul 04, 2007 at 11:00:40AM +0200, Paolo Bonzini wrote:
>> Brian Dessent wrote:
>>> Angelo Graziosi wrote:
>>>
./configure --prefix=${prefix_dir} \
>>>
>>> According to the documentation you should not do this (build in the same
>>>
It's probably a beginner mistake, but I never wrote code to emit
GIMPLE arrays before, and don't know where to look exactly. I'll
continue looking for the reason, but if someone thinks of
something trivial I'd be interested in knowing!
I am pretty sure you should pass the array as a pointer
On Wed, Jul 04, 2007 at 11:00:40AM +0200, Paolo Bonzini wrote:
> Brian Dessent wrote:
> >Angelo Graziosi wrote:
> >
> >>./configure --prefix=${prefix_dir} \
> >
> >According to the documentation you should not do this (build in the same
> >dir as the source.)
>
> This is just less test
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> > What makes "(i + 1) * 4" the canonical form of "(i * 4) + 4" compared to
> > other expressions like "(i * 4) + 8"?
>
> It's an arbitrary decision by fold. For (i + 2) * 4 the canonical form
> is (i * 4) + 8. For (i * j) + j the canonical for
On 7/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> We never insert expressions for FRE, and the replacement we do will
> only replace the entire RHS with an SSA_NAME or a constant.
The problem is precisely that the expression is deemed a constant:
/* Setting value numbers to consta
> We never insert expressions for FRE, and the replacement we do will
> only replace the entire RHS with an SSA_NAME or a constant.
The problem is precisely that the expression is deemed a constant:
/* Setting value numbers to constants will occasionally
screw up phi congru
Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
17:46:45:
> On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> > Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> >
> > > > checking whether the GNU Fortran compiler is working... no
> > > > configure: error: GNU Fortran is no
On Thu, 5 Jul 2007, Paolo Carlini wrote:
> Hi,
>
> I'm having a look to libstdc++/30482, which basically is C++ issue: Jakub
> basically raises the issue of whether we want to use by default the
> C99-conforming division in C++ too. Personally, I would be in favor of
> enabling it unconditionally
Hi,
I'm having a look to libstdc++/30482, which basically is C++ issue:
Jakub basically raises the issue of whether we want to use by default
the C99-conforming division in C++ too. Personally, I would be in favor
of enabling it unconditionally, modulo maybe a performance check
(Richard...).
On 7/5/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> Note that TREE_INVARIANT is not going to be useful in an IPA world
> anyway for these users, if it really means that different calls to the
> function could produce different results.
We could test TREE_CONSTANT instead and this would be enou
On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
>
> > > checking whether the GNU Fortran compiler is working... no
> > > configure: error: GNU Fortran is not working; please report a bug in
> > > http://gcc.gnu.org/bugzilla, att
Hi all,
I'm modifying the Fortran front-end to emit code such as:
static int4 options.2[5] = {102, 127, 1, 1, 1};
_gfortran_set_options (5, options.2);
where _gfortran_set_options is a library function with prototype
"void _gfortran_set_options (int , int [])". This works well (the
pseu
> GNU C has it too:
Yes, but in that case, it's always the same for every reference to the same
type. For GENERIC, that means it can indeed be taken from the type every
time, but the issue is gimplification. The Ada case is harder because
you not only have to deal with gimplification, but that t
> Can you please, again, explain why we even have this wasting space in
> all the component_ref's?
>
> tree.def simply says " Operand 2, if present, is the value of
> DECL_FIELD_OFFSET, measured
>in units of DECL_OFFSET_ALIGN / BITS_PER_UNIT."
>
> It doesn't say why this can't be computed o
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Thu, 5 Jul 2007, Richard Guenther wrote:
>
> > > > The code to fold_binary was added by:
> > > > r107218 | rguenth | 2005-11-19 03:29:10 -0800 (Sat, 19 Nov 2005) | 9
> > > > lines
> > > >
> > > > 2005-11-19 Richard Guenther <[EMAIL PROTECT
Hi,
On Thu, 5 Jul 2007, Richard Guenther wrote:
> > > The code to fold_binary was added by:
> > > r107218 | rguenth | 2005-11-19 03:29:10 -0800 (Sat, 19 Nov 2005) | 9 lines
> > >
> > > 2005-11-19 Richard Guenther <[EMAIL PROTECTED]>
> > >
> > >PR middle-end/23294
> > >* fold-c
David Edelsohn wrote:
>> Alexandre Oliva writes:
>>
>
>
>>> Except that no_new_pseudos was not used consistently.
>>>
>
> Alex> I'm not sure what you mean by "consistently", but regardless, how
> Alex> could any argument possibly make it better to replace it with
>
>
> Alexandre Oliva writes:
>> Except that no_new_pseudos was not used consistently.
Alex> I'm not sure what you mean by "consistently", but regardless, how
Alex> could any argument possibly make it better to replace it with
Alex> (reload_in_progress || reload_completed)
Alex> rather than
Al
Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> > checking whether the GNU Fortran compiler is working... no
> > configure: error: GNU Fortran is not working; please report a bug in
> > http://gcc.gnu.org/bugzilla, attaching
> > /Develop/mainline-dn/build3/powerpc64-unknown-linux-
> gnu/li
On 7/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
The same reason why we have operands 3 and 4 for ARRAY_REFs. Ada (I believe
it's only ada right now) has types that have their offsets computed at
compile-time, so
we put gimplified values of this stuff there if it doesn't match what
we can
> checking whether the GNU Fortran compiler is working... no
> configure: error: GNU Fortran is not working; please report a bug in
> http://gcc.gnu.org/bugzilla, attaching
>
/Develop/mainline-dn/build3/powerpc64-unknown-linux-gnu/libgfortran/config.log
> make[1]: *** [configure-target-libgfortran
On 7/5/07, Daniel Berlin <[EMAIL PROTECTED]> wrote:
On 7/4/07, Richard Kenner <[EMAIL PROTECTED]> wrote:
> > Also, we need to update the GIMPLE grammar so that ARRAY_REF and
> > ARRAY_RANGE_REF take the appropriate values:
>
> A minor comment is that operand 2 of COMPONENT_REF needs the same hand
On Thu, 5 Jul 2007, Roman Zippel wrote:
> Hi,
>
> On Fri, 29 Jun 2007, Andrew Pinski wrote:
>
> > > I'm not sure that's related, what's happening in my example is that the
> > > call to fold_plusminus_mult_expr() defeats the optimization attempted in
> > > pointer_int_sum(). If I use the patch b
Richard Sandiford <[EMAIL PROTECTED]> writes:
> For the record, Alex puts my point of view perfectly here too.
> I gather from the follow-ups that there's resistance to
> s/no_new_pseudos/!BEFORE_RELOAD_P ()/ -- with BEFORE_RELOAD_P
> defined as "reload_in_progress || reload_completed" until Alex'
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Jul 4, 2007, David Edelsohn <[EMAIL PROTECTED]> wrote:
>
>>> Alexandre Oliva writes:
> Alexandre> It's as mechanical as the change you proposed, except that yours
> Alexandre> potentially loses information that would enable someone to recover
>
> Passes ought to distinguish GIMPLE values from GIMPLE invariants
> according to context. As this test case shows, a GIMPLE invariant is
> not always the right value to replace as it cannot be used as a valid
> ARRAY_REF index.
OK, but the replacement is not made by FRE itself, but by fold:
/*
77 matches
Mail list logo
