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
Alexandre
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's
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 enough to restore Ada
bootstrap. But of course the
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 below to
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 handling.
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-
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
Alex
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-const.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
Alex (reload_in_progress ||
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 PROTECTED]
PR
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 on the fly
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 enough
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, attaching
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
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 not working;
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 constants
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
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
dir as the source.)
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 tested, not
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 also
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 not
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;
return y + 4;
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;
}
int foo2(int
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
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
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 computing the
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 this one.
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
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
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 library has to
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
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.html
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 and
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
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, and we
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++0x, but not
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_pseudos
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
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
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.
Then I guess the
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.
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
make
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 foo2(int
-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
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 shows
that
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
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 ...
Can you
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;
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(void);
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:
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,
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
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
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
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 (valist,
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[i +
--- Comment #10 from pault at gcc dot gnu dot org 2007-07-05 06:50 ---
Subject: Bug 32613
Author: pault
Date: Thu Jul 5 06:49:54 2007
New Revision: 126354
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126354
Log:
2007-07-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-05 06:50 ---
Subject: Bug 32526
Author: pault
Date: Thu Jul 5 06:49:54 2007
New Revision: 126354
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126354
Log:
2007-07-05 Paul Thomas [EMAIL PROTECTED]
PR
--- Comment #5 from mtrudel at gmx dot ch 2007-07-05 07:03 ---
With -Wl,-Map,/tmp/TheLinkMap.txt you get a list of the objects that have
been included from libgcj.a.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32619
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2007-07-05 08:38
---
FWIW, I haven't been able to bootstrap on ppc64-linux-gnu after this patch
went
in. I'm not sure I'd tried a full bootstrap before (I've only very recently
got easy access to a ppc box), but the failure is
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-07-05 08:41 ---
For 4.1.x I get
kernel:
.LFB2:
subq$8, %rsp
.LCFI0:
movl$1, %edi
callgen_int
movla(%rip), %eax
movl%eax, %edx
andl$3, %edx
addl
Keep a list of ISO C binding related PRs.
--
Summary: [meta-bug] ISO C binding
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority: P3
Component: fortran
--- Comment #22 from jv244 at cam dot ac dot uk 2007-07-05 09:27 ---
It really seems core2 specific, -march=nocona doesn't fail.
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #23 from ubizjak at gmail dot com 2007-07-05 09:29 ---
This is generic sched2 problem and affects all targets. The problem is that the
call to mcount is emitted in final pass, so scheduler can't see it, and is free
to move insns before
(note 26 25 2 NOTE_INSN_PROLOGUE_END)
--- Comment #24 from ubizjak at gmail dot com 2007-07-05 09:41 ---
glibc bug report at:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=4744
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32450
--- Comment #25 from ubizjak at gmail dot com 2007-07-05 09:44 ---
Also fails for 32bit builds on core2 target:
__cp_log_handling_MOD_cp_add_default_logger:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
cmpl$9, __cp_log_handling_MOD_stack_pointer
--- Comment #7 from bonzini at gnu dot org 2007-07-05 10:27 ---
Using s,g,g, or s,^,, or even b as the default sed command doesn't seem
to bad to me.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #15 from paolo dot bonzini at lu dot unisi dot ch 2007-07-05
10:46 ---
Subject: Re: [4.0/4.1/4.2 Regression] address
selection does not work correctly
Yes, we should add a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
--- Comment #26 from jv244 at cam dot ac dot uk 2007-07-05 10:50 ---
adding a c testcase:
int stack_pointer=0;
void mystop()
{
abort();
}
void add()
{
if (stack_pointer+110)
{
mystop();
};
stack_pointer=stack_pointer+1;
}
int main()
{
add();
return stack_pointer-1 ;
}
gcc
--- Comment #8 from pcarlini at suse dot de 2007-07-05 10:54 ---
Thanks David and Paolo. Ok, I'm sanity checking 's,g,g,' on linux...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
--- Comment #13 from bonzini at gnu dot org 2007-07-05 10:36 ---
Can we mark it as WONTFIX for 4.0 to 4.2?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28940
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2007-07-05 10:43
---
Can we mark it as WONTFIX for 4.0 to 4.2?
Seems reasonable to me, but it would be nice to detect a future regression.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from pault at gcc dot gnu dot org 2007-07-05 11:01 ---
fixed on trunk - thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from joerg dot richter at pdv-fs dot de 2007-07-05 11:17
---
Of course, you are right. :)
Just want to confirm, that all s,g,g, and s,^,, and b seem to work fine
with AIX-sed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
--- Comment #11 from pault at gcc dot gnu dot org 2007-07-05 11:00 ---
fixed on trunk - thanks for the report.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from joerg dot richter at pdv-fs dot de 2007-07-05 11:00
---
I think the last g in 's,g,g,g' is the important one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31957
--- Comment #10 from pcarlini at suse dot de 2007-07-05 11:04 ---
It isn't, as explained by Paolo off-line (by the way Paolo maintains GNU sed),
essentially the same string is used in other projects to work around that AIX
problem.
--
--- Comment #11 from bonzini at gnu dot org 2007-07-05 11:13 ---
Actually any no-op command would do, I think even b would be ok unless it
triggers other bugs. In particular, replacing one g with a g, or all g's with
g's, should not matter. :-)
--
--- Comment #1 from pixel at mandriva dot com 2007-07-05 11:20 ---
(bug still valid in trunk)
the fix is plain simple:
--- gcc/ada/gnat_ugn.texi (revision 126361)
+++ gcc/ada/gnat_ugn.texi (working copy)
@@ -101,7 +101,7 @@
@settitle @value{EDITION} User's Guide
--- Comment #15 from pcarlini at suse dot de 2007-07-05 11:46 ---
Fixed for 4.2.1.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|NEW
--- Comment #13 from paolo at gcc dot gnu dot org 2007-07-05 11:45 ---
Subject: Bug 31957
Author: paolo
Date: Thu Jul 5 11:45:24 2007
New Revision: 126362
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126362
Log:
2007-07-05 Joerg Richter [EMAIL PROTECTED]
PR
--- Comment #14 from paolo at gcc dot gnu dot org 2007-07-05 11:46 ---
Subject: Bug 31957
Author: paolo
Date: Thu Jul 5 11:46:00 2007
New Revision: 126363
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126363
Log:
2007-07-05 Joerg Richter [EMAIL PROTECTED]
PR
--- Comment #5 from burnus at gcc dot gnu dot org 2007-07-05 12:52 ---
Subject: Bug 32359
Author: burnus
Date: Thu Jul 5 12:51:51 2007
New Revision: 126366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126366
Log:
gcc/fortran/
2007-07-05 Daniel Franke [EMAIL PROTECTED]
Attached testcase ICEs when compiled with 'g++ -O2':\
messageoutput.cpp: In constructor
âpov_frontend::MessageOutput::MessageOutput(void*)â:
messageoutput.cpp:1090: internal compiler error: in generate_element_copy, at
tree-sra.c:1801
Please submit a full bug report,
with preprocessed source if
--- Comment #1 from ubizjak at gmail dot com 2007-07-05 13:21 ---
Created an attachment (id=13849)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13849action=view)
delta reduced c++ preprocessed source
g++ -O2 1520.cc:
1520.cc: In constructor
--- Comment #2 from falk at debian dot org 2007-07-05 13:01 ---
I tried this patch from Andrew Pinski:
Index: gcc/config/alpha/alpha.c
===
--- gcc/config/alpha/alpha.c(revision 126053)
+++ gcc/config/alpha/alpha.c
bash-3.2$ cat x.c
#include stdio.h
int
main ()
{
printf (Hello\n);
return 0;
}
bash-3.2$ gcc -pie x.c -fpie
bash-3.2$ ./a.out
Hello
bash-3.2$ gcc -shared -pie x.c -fpie
bash-3.2$ ./a.out
bash: ./a.out: /lib/ld64.so.1: bad ELF interpreter: No such file or directory
bash-3.2$
I am
1 - 100 of 186 matches
Mail list logo
