On 6/18/07, Uros Bizjak [EMAIL PROTECTED] wrote:
On 6/18/07, tbp [EMAIL PROTECTED] wrote:
Until now, the contract was: you have to deal with (and contain) NaN
and infinities. Fair enough, even if tricky that remained manageable.
But if i can't expect a mere division by 0, or sqrt of 0 (quite
On 6/18/07, Richard Guenther [EMAIL PROTECTED] wrote:
No, that's not the contract with -ffast-math. Note that -ffast-math
enables -funsafe-math-optimizations which is allowed to change results
(add/remove rounding operations, contract expressions, do transforms
like a/b to a * 1/b, do
On 6/18/2007 1:26 PM, Dorit Nuzman wrote:
these 3 are actually not so simple... the main thing that's blocking 2 of
them right now is that they need support for stores with gaps, which can be
added except the other problem is that the vectorizer thinks it's not
profitable to vectorize them (or
On 6/18/07, Giovanni Bajo [EMAIL PROTECTED] wrote:
I understand your problems, but let me state that your objections are
totally subjective. *You* need a specific behaviour from -ffast-math
(eg: keep NaN/Inf), but that's not what *I* need. So, we have different
goals.
No. My NaN are my problem.
However, as far as I know (also from talking with the
SLP authors) pretty much all the opportunities they had found at the
time
were in loops.
I can hand you more than the testcases i've given so far. There is
tons of code out there that would benefit from straight line
Interesting. I
If it was designed properly in the first place, there simply would *be
no problem at the tree level*, because nothing would have broken.
That's certainly a point of view. The other is that the RTL implementation
predates the Tree one, works fine in GCC 3.x, including for the C compiler.
One
That is not the example case we have given where this breaks.
The case where it breaks is exactly the case i have shown you.
We have a pointer to a structure, and because you have not recorded
the type's alias relationships properly, we claim derferences that are
offsetted from the
Giovanni Bajo [EMAIL PROTECTED] wrote on 18/06/2007 15:06:48:
On 6/18/2007 1:26 PM, Dorit Nuzman wrote:
these 3 are actually not so simple... the main thing that's blocking 2
of
them right now is that they need support for stores with gaps, which
can be
added except the other problem is
I'm writing a tool which reads information (arcs) from the .gcno file
produced by GCC with -ftest-coverage.
It calculates the NPATH complexity (number of execution paths in a function)
By doing this I found out the graph generated by GCC contains more paths
then I expected. For every function
On 6/17/07, michael.a [EMAIL PROTECTED] wrote:
I appreciate the thought, but there is sort of an imperitive with this
effort to shy away from Boost/STL/virtual inheritance completely.
You'd be hard-pressed to find any instance of dynamic polymorphism
anywhere in Boost. Most of Boost is based
If it was designed properly in the first place, there simply would *be
no problem at the tree level*, because nothing would have broken.
It's possible to have bugs anytime and that's all we have here: somebody
is using the wrong alias set someplace. We fix that and all is OK.
So far you guys
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Only debugging symbols for virtual functions are included in
executable output file ?
//cls.cc
#include iostream
using namespace std;
class test
{
On 6/18/07, costin_c [EMAIL PROTECTED] wrote:
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Only debugging symbols for virtual functions are included in
executable output file ?
//cls.cc
#include
On 6/18/07, Eric Botcazou [EMAIL PROTECTED] wrote:
If it was designed properly in the first place, there simply would *be
no problem at the tree level*, because nothing would have broken.
That's certainly a point of view. The other is that the RTL implementation
predates the Tree one, works
On 6/18/07, costin_c [EMAIL PROTECTED] wrote:
On 6/18/07, costin_c [EMAIL PROTECTED] wrote:
In the following code, compiled with
g++ cls.cc -Wall -W -g3 -o cls
why only only virtual functions f1, f2 and constructor is listed by nm.
Because they are needed for the vtable. While f3 is
On 6/18/07, Daniel Berlin [EMAIL PROTECTED] wrote:
On 6/18/07, Eric Botcazou [EMAIL PROTECTED] wrote:
If it was designed properly in the first place, there simply would *be
no problem at the tree level*, because nothing would have broken.
That's certainly a point of view. The other is
michael.a:
A proper C++ style fix would require the introduction of new syntax rather
than tagging unions or such. The dominant ctors would have to be specified,
or unions themselves could simply be allowed ctors that override the member
ctors. Call them constructor overloads or something, no
Uh, except as we've discovered, the RTL uses alias set 0, so whatever
alias set you choose for these doesn't matter anyway to the RTL level.
Only in some cases. That was a kludge put in to fix some obscure bug and
left there. I hope we can remove it at some point, and think we can.
No i mean
Again, the tree level relies on the documented (in the comments of
alias.c) fact that given a structure, the fields contained in a
structure will have alias sets that are strict subsets of the parent.
That is ONLY true for fields that don't have DECL_NONADDRESSABLE_P
and that's been the case
His first patch, which simply makes #1 true, would cause missed optimization.
It doesn't cause missed optimizations: it completely removes all the
functionality of DECL_NONADDRESSABLE_P!
On 6/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
Again, the tree level relies on the documented (in the comments of
alias.c) fact that given a structure, the fields contained in a
structure will have alias sets that are strict subsets of the parent.
That is ONLY true for fields that don't
On 6/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
His first patch, which simply makes #1 true, would cause missed optimization.
It doesn't cause missed optimizations: it completely removes all the
functionality of DECL_NONADDRESSABLE_P!
Hence the reason for the second suggestion.
Robert Dewar writes:
Ross Ridge wrote:
t formal definition.
Most of GCC's long list of extensions to C are also implemented as
extensions to C++, so you've already lost this battle in GNU C++.
And many of them are ill-defined (and some would agree ill-considered).
Mistakes in
On 6/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
But throws away the entire DECL_NONADDRESSABLE_P mechanism!
No, an int* will still not conflict with int:31
a short * will still not conflict with short:31
Using what mechanism? That's what DECL_NONADDRESSABLE_P does!
Please read what
I can hand you more than the testcases i've given so far. There is
tons of code out there that would benefit from straight line
vectorization.
I'm interested in these test cases. Thanks!
In fact, we have some that gets written in loop form
right now just so it gets vectorized!
May be loop
Chris Lattner wrote:
[Richard E., please see below for a question re. RealView's behavior.]
You and Chris are taking the view that the type has a location. But,
a lot of people don't look at it this way. The things that have
locations are variables (including class data) and functions.
On Sun, Jun 17, 2007 at 09:06:36PM +, Joseph S. Myers wrote:
On Sun, 17 Jun 2007, Uros Bizjak wrote:
I was trying to load a full 128 bit constant into __float128 variable, but
with L suffix, I was able to load only XFmode constant. Is there a special
suffix for __float128 available in
H. J. Lu wrote:
I was trying to load a full 128 bit constant into __float128 variable, but
with L suffix, I was able to load only XFmode constant. Is there a special
suffix for __float128 available in gcc?
No; since the x86-64 ABI is what defines the __float128 name, you could
ask the
On 6/18/07, Dorit Nuzman [EMAIL PROTECTED] wrote:
I can hand you more than the testcases i've given so far. There is
tons of code out there that would benefit from straight line
Interesting. I wasn't aware of this potential. Please do send some of this
code. thanks!
I'm thinking about
On 6/18/07, Sebastian Pop [EMAIL PROTECTED] wrote:
On 6/18/07, Dorit Nuzman [EMAIL PROTECTED] wrote:
I can hand you more than the testcases i've given so far. There is
tons of code out there that would benefit from straight line
Interesting. I wasn't aware of this potential. Please do
On Mon, Jun 18, 2007 at 07:25:06PM +0200, Uros Bizjak wrote:
H. J. Lu wrote:
I was trying to load a full 128 bit constant into __float128 variable,
but
with L suffix, I was able to load only XFmode constant. Is there a
special
suffix for __float128 available in gcc?
No; since
Hi guys, I have merged all patches touching lto/ into the new lto branch
I'm almost 100% positive the result will not compile. There are no
interesting conflicts to report (most were just formatting changes).
I have not merged ChangeLog.lto onto the new branch, since it looked
like it only
BTW: IA64 has the same issues with two FP types (long double XFmode and
longer double TFmode). How is this solved for IA64?
Uros.
This is different on IA64 HP-UX and IA64 Linux. On HP-UX, 128 bits is
the standard long double and 80 bits is __float80. We use the 'W'
suffix for a __float80
tbp wrote:
For example, when doing 1/x and sqrt(x) via reciprocal + NR, you first
get an inf from said reciprocal which then turns to a NaN in the NR
stage but if you correct it by, say, doing a comparison to 0 and a
'and'.
That's what ICC used to do in your back. That's what you'll find page
Bernd Schmidt wrote:
I attached a diff file for 14 files of the new structures
and documents. You and other maintainers are welcome to
check it. Thanks a lot!
Note: 14 files are =
genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h
tree.c rtl.def rtl.h rtl.c
Giovanni Bajo wrote:
Both our goals are legitimate. But that's not the point. The point is
what -ffast-math semantically means (the simplistic list of suboptions
activated by it is of couse unsufficiente because it doesn't explain how
to behave in face of new options, like -mrecip). My
On Jun 18, 2007, at 2:14 PM, Uros Bizjak wrote:
tbp wrote:
For example, when doing 1/x and sqrt(x) via reciprocal + NR, you
first
get an inf from said reciprocal which then turns to a NaN in the NR
stage but if you correct it by, say, doing a comparison to 0 and a
'and'.
That's what ICC
On Jun 18, 2007, at 2:27 PM, Bradley Lucier wrote:
But even if sqrt is corrected for 0.0 * inf, there would still be
a lot of problems with the combinations of NR-enhanced rsqrt and
rcp. Consider for example:
1.0/sqrt(a/b) alias rsqrt(a/b)
Having a=0, b != 0, the result is inf.
As
I am glad to see we are converging toward implementation issues now!
I am storing it in a new field under the alias_set_entry:
get_alias_set_entry (TYPE_ALIAS_SET (t))-nonaddr_alias_set.
Where T is which type?
It gives you the alias set of the parent, which, for the reason that
OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer.
Can you give a few sentence explanation of what alias set splay trees
are and why they aren't using the alias set mechanism?
I'm not sure what a TBAA
Richard Kenner writes:
I am glad to see we are converging toward implementation issues now!
I am storing it in a new field under the alias_set_entry:
get_alias_set_entry (TYPE_ALIAS_SET (t))-nonaddr_alias_set.
Where T is which type?
Type of the expression passed to
Type of the expression passed to get_alias_set. And without the
component_uses_parent_alias_set loop.
So you mean the type of the *field*? That can't work. That type can't
be used for *anything*!
Otherwise, if you have
struct foo {int a: 32; int b: 32; };
struct bar {int c:
On 6/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
It gives you the alias set of the parent, which, for the reason that
OTHER THINGS USE THE ALIAS SET SPLAY TREES, gives the wrong answer.
Can you give a few sentence explanation of what alias set splay trees
are and why they aren't using the
H. J. Lu wrote:
Good. I have another question. Intel BID patch itself doesn't change
any sources in DFP nor libdecnummber. The only significant change is
to change Makefile in libgcc to use Intel BID library for DFP
intrinsics when BID encoding is selected. Currently, DFP is only
supported
They are the alias set mechanism, which you don't seem to understand.
They always have been.
I certainly understand the alias set mechanism. It sounded like you were
talking about something else since if the only thing we're using is alias
sets, I'm mystified as to what the issue is.
I'd
Hi Dorit,
loop-context when it helps you do things more efficiently. In any case,
we'll have to have a much better cost model before we start packing
random
sequences of stmts out of loops.
This is off topic from the discussion at hand, but we would be happy to
help with changing the cost model
On 6/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
They are the alias set mechanism, which you don't seem to understand.
They always have been.
I certainly understand the alias set mechanism. It sounded like you were
talking about something else since if the only thing we're using is alias
On 6/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
Type of the expression passed to get_alias_set. And without the
component_uses_parent_alias_set loop.
So you mean the type of the *field*? That can't work. That type can't
be used for *anything*!
Otherwise, if you have
struct
On 6/18/07, Richard Kenner [EMAIL PROTECTED] wrote:
you have the fields A and C conflicting, which is wrong.
Well, that is where structure-field aliasing comes in. The two cannot
even alias for addressable fields:
At tree level I'll take your word for it, but what about RTL level?
Is that
This is the beta release of binutils 2.17.50.0.17 for Linux, which is
based on binutils 2007 0615 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have
struct foo {int a: 32; int b: 32; };
struct bar {int c: 32; int d: 32; };
you have the fields A and C conflicting, which is wrong.
With the current scheme you have fields a and b conflict
and c and d conflicting
Both of which are wrong
But nothing is changing that!
I continue to strongly feel that the field type shouldn't be used
for ANYTHING!
Then you will continue to get worse code generation than you could, in
addition to bugs like we have now.
Explain to me why in the following case:
struct s1 {int a;};
struct s2 {short a;};
On Mon, Jun 18, 2007 at 11:10:43AM -0700, Steve Ellcey wrote:
BTW: IA64 has the same issues with two FP types (long double XFmode and
longer double TFmode). How is this solved for IA64?
Uros.
This is different on IA64 HP-UX and IA64 Linux. On HP-UX, 128 bits is
the standard long
Fu, Chao-Ying wrote:
+ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */
+ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */
+ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */
+ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */
Lots of predefined types and modes in this patch. What about targets
with other requirements (the Blackfin
We need a standard for __float128. Otherwise, a program using
__float128 may generate different results with different
compilers on different platforms.
BTW, I had a __float128 patch for glibc. Because there is no
__float128 standard, it wasn't accepted.
H.J.
The HP compiler has an
If all you need is one memeber that has constructors / destructors, and
all other members are PODs that provide an alternate view of the contents,
then I think that would make a logical extension of the transparent union
extension. A transparent union as passed to functions in the same manner
On Mon, Jun 18, 2007 at 02:33:07PM -0700, Steve Ellcey wrote:
We need a standard for __float128. Otherwise, a program using
__float128 may generate different results with different
compilers on different platforms.
BTW, I had a __float128 patch for glibc. Because there is no
On Jun 18, 2007, at 2:36 PM, michael.a wrote:
This suggestion made some ground. But I just can't get a build to
complete.
The newest checkout / release aren't compatible with my C libraries it
seems, and I'm not sure its safe dependency wise to just replace the C
libraries. So I rewound my
Bernd Schmidt wrote:
+ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */
+ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */
+ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */
+ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */
Lots of predefined types and modes in this patch. What
about targets
with other requirements
Eric Christopher-2 wrote:
Sounds like you're using ./configure. Are you following the directions
at:
http://gcc.gnu.org/install/configure.html
-eric
Thank you, I guess I missed that page somehow.
Only I ran into the same Libc wall again, so I'm temporarily stumped:
Thank you, I guess I missed that page somehow.
Only I ran into the same Libc wall again, so I'm temporarily stumped:
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.so when
searching
for -lc
/usr/bin/ld: skipping incompatible /usr/lib/../lib/libc.a when
searching for
-lc
Snapshot gcc-4.1-20070618 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070618/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 18 June 2007 23:46, michael.a wrote:
Eric Christopher-2 wrote:
You might want to make sure you're passing the same configure options
that the distro did when building. It might cause some incompatibility
somewhere that ld is detecting. From a quick look it seems that ld
believes that
Eric Christopher-2 wrote:
'gcc -v' will give you the information on how the system gcc was
configured.
-eric
Here is the gcc -v output for the binaries installed by the distro:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
michael.a wrote:
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
This belongs on gcc-help not here.
Debian-based distros use a 32/64 bit /usr/lib configuration that is
backwards from what the rest of the world uses and requires a patched
gcc to multilib correctly. You'll probably need to
Brian Dessent wrote:
michael.a wrote:
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
This belongs on gcc-help not here.
Debian-based distros use a 32/64 bit /usr/lib configuration that is
backwards from what the rest of the world uses and requires a patched
gcc to multilib correctly.
On 6/18/07, Uros Bizjak [EMAIL PROTECTED] wrote:
IMO, due to limited range of operands for -mrecip pass (inf, -inf);
where 0.0 is excluded, it should be keept out of -ffast-math. There is
no point to fix reciprocals only for 0.0, we need to fix both
conversions for infinity and 0.0, even in
I would like to get some more information about pr32374.
I do not know what virtual_stack_vars are and there is no documentation
in the doc directory.
1) What are these?
2) Why are they uninitialized?
3) If they really are uninitialized, why is it a problem to assign zero
to them.
4) If they
On Mon, Jun 18, 2007 at 04:57:46PM -0700, michael.a wrote:
Yeah, I know (mailing lists are so particular -- I guess I fail to see the
value beyond a noncentralized discussion)
But since I believe three different people have asked you to move this
problem to a different mailing list now, could
The question was raised a while back on the gcc-patches and gdb-patches
lists of how GCC should tag objects with some ABI information for the use
of GDB, noting that various different methods have been in use
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00395.html.
Mark suggested
Daniel Jacobowitz-2 wrote:
On Mon, Jun 18, 2007 at 04:57:46PM -0700, michael.a wrote:
Yeah, I know (mailing lists are so particular -- I guess I fail to see
the
value beyond a noncentralized discussion)
But since I believe three different people have asked you to move this
problem to
On Tue, Jun 19, 2007 at 01:50:27AM +, Joseph S. Myers wrote:
The question was raised a while back on the gcc-patches and gdb-patches
lists of how GCC should tag objects with some ABI information for the use
of GDB, noting that various different methods have been in use
Bradley Lucier wrote:
If -ffinite-math-only is specified, then producing NaN instead of inf
should be allowed.
Agreed. After all, -finite-math says:
Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs.
Since the compiler
On Sat, 2007-06-16 at 06:17 -0700, H. J. Lu wrote:
BTW, an x86 DFP configure bug was reported 3 months ago. But it still
hasn't benen fixed. I opened a DFP bug report:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351
with a patch. I hope it will be fixed before gcc 4.3 is released :-).
On Sun, 17 Jun 2007, Revital1 Eres wrote:
Hello,
I have one more question regarding the comment in
tree-ssa-ccp.c file -
/* Note that for propagation purposes, we are only interested in
visiting statements that load the exact same memory reference
stored here.
It is a libdecnumber bug, which only affects x86.
The patch is ok.
Paolo
Hi,
On Fri, 15 Jun 2007, Richard Guenther wrote:
so, no PPC testing from us (the old testing machine died and we don't
have a replacement for it).
Actually it's back, and just needs to be partitioned and set up.
Ciao,
Michael.
On 6/17/07, Uros Bizjak [EMAIL PROTECTED] wrote:
Hello!
I was wondering if there are objects to automatically activating Uros'
new -mrecip flag when -ffast-math is specified. It looks like a good
match since -mrecip is exactly about fast non-precise mathematics.
There is a discussion in
Dorit Nuzman wrote:
H. J. Lu wrote:
Why don't we turn on vectorizer at -O3 or even -O2, depending on
ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
-ftree-vectorizer-verbose=1, there are 82 loops vectorized in
gcc source. There are no regressions. There are not
On 6/18/07, Richard Guenther [EMAIL PROTECTED] wrote:
Of course there are cases with every optimization enabled by -ffast-math that
can break existing programs. Just that we know of one case beforehand shouldn't
prevent us from enabling -mrecip at -ffast-math (provided -mno-recip
still works,
Daniel Berlin [EMAIL PROTECTED] wrote on 17/06/2007 18:18:19:
...
The whole purpose of SLP was to enable straight line code
vectorization outside of loops.
I wouldn't say that's the whole purpose of SLP. I think the purpose and
beauty of SLP is that it's a simple algorithm that makes
Tim Prince [EMAIL PROTECTED] wrote on 17/06/2007 19:47:10:
[EMAIL PROTECTED] wrote:
Tim Prince [EMAIL PROTECTED] wrote on 17/06/2007 04:15:56:
[EMAIL PROTECTED] wrote:
On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
There are quite a few known simple cases which
On 6/18/07, tbp [EMAIL PROTECTED] wrote:
On 6/18/07, Richard Guenther [EMAIL PROTECTED] wrote:
Of course there are cases with every optimization enabled by -ffast-math that
can break existing programs. Just that we know of one case beforehand
shouldn't
prevent us from enabling -mrecip at
Hi,
We have come up with two possible solutions to solve the 20 bit data
access problem in m16c targets.
We are very grateful for all the suggestions until now on this issue.
Solution 1 is based on the discussion at the following link -:
http://gcc.gnu.org/ml/gcc/2007-04/msg00402.html
- 2 new
Giovanni Bajo [EMAIL PROTECTED] wrote on 17/06/2007 20:43:15:
Hi Dorit,
some years ago I posted these testcases to Bugzilla's GCC:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439
It looks
On 6/18/07, Eric Botcazou [EMAIL PROTECTED] wrote:
I'm completely unsurprised this is broken at the tree level given how
it is implemented
Nice tautology. :-) You have resisted implementing anything at the tree level
to fix the problem and now you're complaining there is a problem...
On 6/18/07, tbp [EMAIL PROTECTED] wrote:
Until now, the contract was: you have to deal with (and contain) NaN
and infinities. Fair enough, even if tricky that remained manageable.
But if i can't expect a mere division by 0, or sqrt of 0 (quite common
with FTZ/DAZ on) to give me respectively an
--- Comment #12 from pinskia at gcc dot gnu dot org 2007-06-18 06:01
---
This no longer crashes for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19910
--- Comment #22 from pinskia at gcc dot gnu dot org 2007-06-18 06:12
---
This is basically fixed by the pointer_plus except we still have some
combinable code (though this is not PRE's fault); see
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01996.html for how to fix that
issue.
--
--- Comment #11 from pinskia at gcc dot gnu dot org 2007-06-18 06:16
---
*** Bug 30958 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-18 06:16 ---
*** This bug has been marked as a duplicate of 30784 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ubizjak at gmail dot com 2007-06-18 06:41 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-18 06:42 ---
There is a cast which confuses SCEV.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from stephan dot bergmann at sun dot com 2007-06-18 06:54
---
Re #3: http://gcc.gnu.org/onlinedocs/libstdc++/install.html#usage is not
relevant here. That info is about how client code can find libstdc++.so. This
issue is about how libstdc++.so can find the libraries
--- Comment #10 from pinskia at gcc dot gnu dot org 2007-06-18 06:55
---
For -O1, it is even worse. I think we need to mark va_start/va_end as cannot
call clober their inputs at the tree level. This should at least fix the -O1
issue. It might also help code gen in other cases which
--- Comment #2 from redriver at korea dot ac dot kr 2007-06-18 07:40
---
(In reply to comment #1)
What version of GCC are you starting with?
This works for me on an i686-linux-gnu machine (a pentium 4D).
I think I found the problem. Previously, I use the gcc-3.2.2 to bootstrap the
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-18 07:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from patchapp at dberlin dot org 2007-06-18 08:00 ---
Subject: Bug number PR20373
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01216.html
--
--- Comment #3 from uros at gcc dot gnu dot org 2007-06-18 08:31 ---
Subject: Bug 32383
Author: uros
Date: Mon Jun 18 08:30:47 2007
New Revision: 125790
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125790
Log:
PR tree-optimization/32383
* targhooks.c
--- Comment #4 from ubizjak at gmail dot com 2007-06-18 08:33 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
1 - 100 of 190 matches
Mail list logo
