> 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:
/*
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
>
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'
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
> 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, 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
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
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
> 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
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
>
>
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
> 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
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
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
> 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
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 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
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
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 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
>>>
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 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
"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
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
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;
> >
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
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
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
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
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
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
> "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
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
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
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
"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
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
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
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
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
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
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
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
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
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:
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
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.
>>
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,
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 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
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
-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 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
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
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 ..."
>
>
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
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
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
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
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
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
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
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
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
"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
"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
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.
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
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
77 matches
Mail list logo
