Let's assume that the recent change is what we want, i.e., that the
answer to (1) is No, these operations should not be part of the vector
extensions because they are not valid scalar extensions. So, that
means we need to answer (2).
We still have the problem that users now can't write
Saral
ITR
The easier way to filing IT returns
Your wait for Income Tax Returns Software is over. Stop. Look no further.
Saral ITR from Relyon will help you file the Income Tax Returns. Saral ITR,
the Software to manage all ITR Forms is just released.
Available online and free to file ITR 1, 2 3
Paolo Bonzini wrote:
2) selection operations on vectors, kind of (v1 = v2 ? v3 : v4). These
can be written for example like this:
cmpleps xmm1, xmm2 ; xmm1 = xmm1 = xmm2 ? all-ones : 0
andnps xmm4, xmm1 ; xmm4 = xmm1 = xmm2 ? 0 : xmm4
andps xmm1, xmm3 ; xmm1 = xmm1 =
Mark Mitchell wrote:
One option is for the user to use intrinsics. It's been claimed that
results in worse code. There doesn't seem any obvious reason for that,
but, if true, we should try to fix it; we don't want to penalize people
who are using the intrinsics. So, let's assume using
Paolo Bonzini wrote:
I'm not sure that it is *so* useful for a user to have access to it,
except for specialized cases:
As there's other means, it may not be that useful but for sure it's
extremely convenient.
2) selection operations on vectors, kind of (v1 = v2 ? v3 : v4). These
can be
Paolo Bonzini [EMAIL PROTECTED] writes:
1) neg, abs and copysign operations on vectors. These we can make
available via builtins (for - of course you don't need it); we already
support them in many back-ends.
Here is my point of view. People using the vector extensions are
already writing
On Friday 24 August 2007, Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
1) neg, abs and copysign operations on vectors. These we can make
available via builtins (for - of course you don't need it); we already
support them in many back-ends.
Here is my point of view.
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour, and it
helps programmers and helps existing code. Who does it hurt to permit
this extension? Who does it help to forbid this extension?
Aren't builtins the designated way to
Chris Lattner [EMAIL PROTECTED] writes:
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour, and it
helps programmers and helps existing code. Who does it hurt to permit
this extension? Who does it help to forbid this
Paul Brook wrote:
On Friday 24 August 2007, Ian Lance Taylor wrote:
Paolo Bonzini [EMAIL PROTECTED] writes:
1) neg, abs and copysign operations on vectors. These we can make
available via builtins (for - of course you don't need it); we already
support them in many back-ends.
Here is my
On Aug 24, 2007, at 8:37 AM, Ian Lance Taylor wrote:
Chris Lattner [EMAIL PROTECTED] writes:
On Aug 24, 2007, at 8:02 AM, Ian Lance Taylor wrote:
Permitting this extension continues the preexisting behaviour,
and it
helps programmers and helps existing code. Who does it hurt to
permit
On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Let a and b be floating-point operands of type F, where F is a
floating-point type. Let N be the number of bytes in F. Then, a | b
is defined as:
Yes that makes sense, not. Since most of the time, you have a mask
and that is what is being
Andrew Pinski wrote:
On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Let a and b be floating-point operands of type F, where F is a
floating-point type. Let N be the number of bytes in F. Then, a | b
is defined as:
Yes that makes sense, not.
I'm not following. Are you agreeing or
On 24 August 2007 17:04, Andrew Pinski wrote:
On 8/24/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Let a and b be floating-point operands of type F, where F is a
floating-point type. Let N be the number of bytes in F. Then, a | b
is defined as:
Yes that makes sense, not. Since most of the
I'm partly worried about cross-platform compatibility, and what this
imples for other SIMD targets.
Yes. Here's a proposed definition:
snip
I agree this is the only sane definition.
I probably wasn't clear: My main concern is that if we do support this
extension the internals should be
Paul Brook wrote:
I probably wasn't clear: My main concern is that if we do support this
extension the internals should be implemented and documented in such a way
that target maintainers (i.e. me) can figure out how to make it work on their
favourite target. We should not just quietly
Brian Sidebotham wrote:
Brian Sidebotham wrote:
../../gcc/gcc/tree.c: In function build_string:
../../gcc/gcc/tree.c:1197: internal compiler error: in
iterative_hash_expr, at tree.c:4189
Please submit a full bug report,
with preprocessed source if appropriate.
I have placed the pre-processed
If there is a reason to put in that obstacle--e.g., because we
are implementing a language standard and the language standard forbids
it--then fine. But citing a PowerPC specific standard to forbid code
appropriate for the x86 does not count as a sufficient reason in my
book.
The code I want
Jie Zhang wrote:
On 8/10/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Are there any folks out there who have projects for Stage 1 or Stage 2
that they are having trouble getting reviewed? Any comments
re. timing for Stage 3?
I have many bfin port patches which have not been merged into
On Fri, Aug 24, 2007 at 02:34:27PM -0400, Ross Ridge wrote:
Mark Mitchell
Let's assume that the recent change is what we want, i.e., that the
answer to (1) is No, these operations should not be part of the vector
extensions because they are not valid scalar extensions.
I don't think we
Mark Mitchell
Let's assume that the recent change is what we want, i.e., that the
answer to (1) is No, these operations should not be part of the vector
extensions because they are not valid scalar extensions.
I don't think we should assume that. If we were to we'd also have
to change vector
Ed S Peschko writes:
Ed which would be fine if the AIX linker works, but I'm getting segmentation
Ed faults when compiling perl out of the box, using the gcc-4.1.0 compiler
Ed provided.. I'm wondering if its the compiler, the linker, or both...
You have not provided information for
Snapshot gcc-4.3-20070824 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070824/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
--- Comment #2 from ubizjak at gmail dot com 2007-08-24 06:04 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01634.html
causes gcc.target/i386/cmov4.c regression.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2007-08-24 06:55 ---
Subject: Bug 32567
Author: jakub
Date: Fri Aug 24 06:54:49 2007
New Revision: 127760
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127760
Log:
PR c++/32567
* typeck.c (build_unary_op) case
--- Comment #3 from steven at gcc dot gnu dot org 2007-08-24 06:36 ---
It's not even supposed to pass on i686:
/* { dg-options -O2 -march=k8 } */
(see
http://gcc.gnu.org/viewcvs/trunk/gcc/testsuite/gcc.target/i386/cmov4.c?revision=127731view=markup)
Note I'm not even going to look at
--- Comment #4 from bonzini at gnu dot org 2007-08-24 06:50 ---
It's supposed to pass on K8 in 32-bit mode. It did, and it does not. However,
I think reverting the patch is not the right thing to do.
Anyway, given Steven's highly constructive remark, I think we can only wait for
it
--- Comment #5 from bonzini at gnu dot org 2007-08-24 06:57 ---
Anyway, it fails on 64-bit mode too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33157
--- Comment #3 from jakub at gcc dot gnu dot org 2007-08-24 07:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from steven at gcc dot gnu dot org 2007-08-24 07:10 ---
Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on
gcc-patches and in this PR when I've made it pretty damn clear that I don't
want to work on gcc anymore...
--
--- Comment #7 from jakub at gcc dot gnu dot org 2007-08-24 07:40 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at gcc dot gnu dot org 2007-08-24 07:42 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2007-08-24 08:48
---
As per comment #6.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-08-24 09:23 ---
MIPS-linux uses elf which has weak support.
So I don't see why you think GTHREAD_USE_WEAK should not be defined.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-08-24 09:02 ---
No, the inline-asm is just wrong, you need to use a different thing for
including non indexed load/stores.
The inline-asm function should be written as:
static inline unsigned long
load_acquire(volatile unsigned
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2007-08-24 10:20
---
Since this one seems to be a documentation issue, I'll take it. I intend to
write a *-*-mingw32 entry to the target-specific installation notes.
--
fxcoudert at gcc dot gnu dot org changed:
What
--- Comment #8 from uros at gcc dot gnu dot org 2007-08-24 10:58 ---
Subject: Bug 33157
Author: uros
Date: Fri Aug 24 10:58:12 2007
New Revision: 127766
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127766
Log:
PR middle-end/33157
* ifcvt.c (noce_find_if_block):
--- Comment #7 from ubizjak at gmail dot com 2007-08-24 10:42 ---
Sometimes it is neccessary to check where you clear a structure.
Attached patch fixes this PR.
Index: ifcvt.c
===
--- ifcvt.c (revision 127761)
+++
--- Comment #9 from ubizjak at gmail dot com 2007-08-24 11:06 ---
(In reply to comment #6)
Re. comment #4 -- as if it is constructive to annoy me by CC-ing me on
gcc-patches and in this PR when I've made it pretty damn clear that I don't
want to work on gcc anymore...
Sorry to hear
Background:
===
In the Linux kernel one often sees the following idiom:
static void foo_func(void)
{
}
static struct foo_type foo_struct = {
.foo_call = foo_func,
};
some_init_func(...)
{
register_foo(foo_struct);
}
some_exit_func(...)
{
I see the following error with trunk from 20070820:
(sid)28233:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/gcc -O -c tor-test.c
tor-test.c: In function 'test_dir_format':
tor-test.c:16: internal compiler error: in set_uids_in_ptset, at
tree-ssa-structalias.c:4704
Please submit a full bug
--- Comment #1 from tbm at cyrius dot com 2007-08-24 12:22 ---
Created an attachment (id=14100)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14100action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
--- Comment #2 from tbm at cyrius dot com 2007-08-24 12:24 ---
Works with 20070811.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33173
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:43
---
ICE still there, not mingw specific.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-24 12:44 ---
It also naturally would fit in the phiopt framework given the structure of
virtual operands:
# SMT.4_26 = VDEF SMT.4_18
*D.2016_7 = D.2019_13;
if (D.2019_13 == 3)
goto bb 4;
else
goto bb 9;
bb 9:
--- Comment #17 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:46
---
Fixed on mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dir at lanl dot gov 2007-08-24 12:46 ---
Created an attachment (id=14101)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14101action=view)
testsuite output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
Some of my programs run Ok with gfortran on the Macintosh and Linux, but fail
on CYGWIN and MSYS - so I ran the testsuite. Several unexpected failures were
found -
=== gcc Summary ===
# of expected passes47388
# of unexpected failures60
# of unexpected
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:53
---
Also works on mainline (4.3).
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:31
---
This is still working fine. mingw development is focusing on 4.3, so this bug
probably stands little chance of being fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
Some of my programs run Ok with gfortran on the Macintosh and Linux, but fail
on CYGWIN and MSYS - so I ran the testsuite. Several unexpected failures were
found -
=== gcc Summary ===
# of expected passes47388
# of unexpected failures60
# of unexpected
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-24 12:56
---
Same kind of thing happens for ld, see PR24382.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pranav dot bhandarkar at gmail dot com 2007-08-24
13:28 ---
Created an attachment (id=14102)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14102action=view)
Another testcase displaying the said behaviour
IMHO, the code generated for the following can benefit
--- Comment #5 from nikolay at totalviewtech dot com 2007-08-24 13:15
---
This is not fixed neither in 4.1.0 nor in any later version. The problem is
that DIE for static foofoo was indeed produced, but produced in wrong place.
2260: Abbrev Number: 7 (DW_TAG_subprogram) --- Constructor
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-24 13:07
---
As indicated in PR29826, this bug was fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-08-24 13:11 ---
Shorter testcase, fails at -O:
static void ConvertAddr (char *saddr, void **addr)
{
*addr = (void *) saddr;
}
void DefineSelf (char *addr)
{
ConvertAddr (addr, (void **) addr);
if (addr[0] == 127 addr[3] ==
The code:
templatetypename T
bool confirm(T t, int i) { return t == i; }
int main() {
int i = 0, j = 1, k = 2;
if (i == j) confirm(j, k) ) { i = 2; }
return 0;
}
gets you:
~/ootbc/sim/src$ g++ foo.cc
foo.cc: In function 'int main()':
foo.cc:5: error: expected `;' before '(' token
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-08-24 13:59 ---
I have a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33166
--- Comment #6 from seppo at totalviewtech dot com 2007-08-24 13:52 ---
Hi Andrew,
Reopened the bug (see comment above). Do also notice that the (due to the
above) static foofoo inside constructor is still not visible to either TV or
gdb.
I have changed the title of the bug to
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-08-24 14:14 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-08-24 14:13 ---
Confirmed. Only after early inlining we know enough to do this, but the
decision
is already made before it seems. Honza?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from paolo dot bonzini at lu dot unisi dot ch 2007-08-24
14:53 ---
Subject: Re: missed store sinking opportunity
Danny said he knows how to fix it (I guess in store sinking though he
didn't say). From knowing him, there might be additional less obvious
cases that
--- Comment #4 from patchapp at dberlin dot org 2007-08-24 14:46 ---
Subject: Bug number PR33139
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-08/msg01651.html
--
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-08-24 14:37 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #6 from burnus at gcc dot gnu dot org 2007-08-24 15:03 ---
FIXED for gfortran 4.3.0.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-24 15:04 ---
I said: FIXED.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from burnus at gcc dot gnu dot org 2007-08-24 15:05 ---
*** This bug has been marked as a duplicate of 33174 ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-24 15:05 ---
*** Bug 33175 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33174
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-08-24 15:09 ---
Subject: Bug 33166
Author: rguenth
Date: Fri Aug 24 15:09:10 2007
New Revision: 127771
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127771
Log:
2007-08-24 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-08-24 15:18 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from burnus at gcc dot gnu dot org 2007-08-24 15:01 ---
Subject: Bug 33139
Author: burnus
Date: Fri Aug 24 15:00:59 2007
New Revision: 127770
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127770
Log:
2007-08-24 Tobias Burnus [EMAIL PROTECTED]
PR
--- Comment #20 from jakub at gcc dot gnu dot org 2007-08-24 15:38 ---
Created an attachment (id=14103)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14103action=view)
gcc43-pr33136.patch
Here is what I have been playing with.
But I'd really like to see some testcases where the
--- Comment #21 from dberlin at gcc dot gnu dot org 2007-08-24 15:42
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 24 Aug 2007 15:38:58 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #20 from jakub at gcc
With the following test case, nint gives wrong result.
svn Revision: 127756
! Program to test the real-integer conversion routines.
program intrinsic_integer
implicit none
real :: val
integer :: i
val = 0.7
i = nint(val)
print *, val, i
val = -0.7
i = nint(val)
print *, val, i
--- Comment #16 from rguenth at gcc dot gnu dot org 2007-08-24 15:57
---
Finished, so unassigning.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from atgraham at gmail dot com 2007-08-24 16:00 ---
Here is a smaller bit of code for reproducing this problem. This doesn't
depend on any C++.
#include pthread.h
static __typeof(pthread_mutex_lock) __gthrw_pthread_mutex_lock __attribute__
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/0019cb490586ed91/
SIGN with INTEGER arguments is allowed for initialization expressions in
Fortran 95; using REAL arguments it is only allowed for Fortran 2003.
gfortran -std=f95 prints the wrong error message for:
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-08-24 16:03 ---
None of the testcases in comment #3 fail on the mainline configured with
--enable-checking=yes,types. So either this bug is fixed or the patches from
Andrew did some slightly different checking. Or both ;)
--
--- Comment #2 from weston at computer dot org 2007-08-24 16:04 ---
Yep, looks like you are right from the standard. That sucks then. I wish it
were the other way because I don't see a way to enter a literal single
character in hex followed a by single character [A-Z0-9] without escape
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-08-24 16:04 ---
Might (or might not) be induced by my changes in this area. I'm currently in no
position to do anything about it, sorry :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33178
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-24 16:06 ---
The testcase is fine with mainline and --enable-checking=yes,types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22474
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-08-24 16:06 ---
So what is happening is that you are using the function directly and also via a
weakref. Can you give the output of GCC (that is the -S file)? This might be
really a binutils bug.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-08-24 16:07 ---
The testcase is fixed with mainline and --enable-checking=yes,types.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22374
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-08-24 16:14 ---
This all comes down to cloning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
--- Comment #4 from dberlin at gcc dot gnu dot org 2007-08-24 16:14 ---
Subject: Re: [4.3 Regression] ICE in set_uids_in_ptset, at
tree-ssa-structalias.c:4704
Accidently reversed test in tree-ssa-alias.c: find_used_portions
Testing fix now.
--
--- Comment #22 from jakub at gcc dot gnu dot org 2007-08-24 16:16 ---
Not sure how, could I pass the buck to you then?
My thought was just that may_alias_p could for STRUCT_FIELD_TAG call
ipa_type_escape_field_does_not_clobber (TREE_TYPE (SFT_PARENT_VAR (var)),
TREE_TYPE (var)) (i.e.
--- Comment #5 from tkoenig at gcc dot gnu dot org 2007-08-24 16:16 ---
Subject: Bug 32972
Author: tkoenig
Date: Fri Aug 24 16:16:16 2007
New Revision: 127774
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=127774
Log:
2007-08-24 Thomas Koenig [EMAIL PROTECTED]
PR
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-08-24 16:16 ---
So one goes the GOT (the weakref) while the other does not (straight call).
I am guess this is really a bug in binutils if a bug at all. Though two
different relocs for the same symbol should be ok.
and thusly
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-08-24 16:17
---
This is a cygwin bug:
$ cat a.c
#include math.h
#include stdio.h
int main (void) {
float x = 0.7;
int i = (int) lroundf (x);
printf (%d\n, i);
}
$ gcc a.c ./a.exe
0
I you replace lroundf() with
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-24 16:24
---
cygwin or msys? What is the host, what is the target?
As far as I see, there is only one gfortran failure:
FAIL: gfortran.fortran-torture/compile/pr32417.f90, -O (internal compiler
error)
I don't see it on
--- Comment #5 from atgraham at gmail dot com 2007-08-24 16:12 ---
Created an attachment (id=14104)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14104action=view)
Output of mipsel-linux-gcc -Os -s tworelocs.c
gcc output attached.
--
--- Comment #23 from dberlin at gcc dot gnu dot org 2007-08-24 16:21
---
Subject: Re: [4.1/4.2/4.3 Regression] wrong code due to alias with allocation
in loop
On 24 Aug 2007 16:16:44 -, jakub at gcc dot gnu dot org
[EMAIL PROTECTED] wrote:
--- Comment #22 from jakub at gcc
--- Comment #8 from dpgrote at lbl dot gov 2007-08-24 16:29 ---
Subject: Re: array pointer assignment gives incorrect
dimensions
Great! Thanks for fixing this!
Dave
burnus at gcc dot gnu dot org wrote:
--- Comment #7 from burnus at gcc dot gnu dot org 2007-08-24 15:04
--- Comment #17 from jakub at gcc dot gnu dot org 2007-08-24 16:33 ---
Does this make sense to do this for POINTER_TYPE_P in 4.1/4.2, which
reassociate
in many other places?
I belive in 4.3 that changed with POINTER_PLUS_EXPR stuff.
struct A { int i; int v[1]; };
int *foo (struct A
--- Comment #7 from atgraham at gmail dot com 2007-08-24 16:34 ---
binutils bug created:
http://sourceware.org/bugzilla/show_bug.cgi?id=4959
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33169
--- Comment #18 from rguenth at gcc dot gnu dot org 2007-08-24 16:40
---
Maybe - I was just conservative here to not possibly introduce new overflow
with the re-association as elsewhere we may rely on the undefinedness of
overflow.
Another way to fix this particular regression is to
--- Comment #8 from nikolay at totalviewtech dot com 2007-08-24 16:45
---
(In reply to comment #7)
This all comes down to cloning.
What do you mean?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33044
On 24 Aug 2007 16:45:41 -, nikolay at totalviewtech dot com
[EMAIL PROTECTED] wrote:
What do you mean?
The IA64 C++ ABI requires two (or three) versions of constructor. So
GCC clones functions to deal with that. And we emit the context of
the local static variable part of the original
--- Comment #9 from pinskia at gmail dot com 2007-08-24 16:51 ---
Subject: Re: Local static variable in C++ constructor not visible for
debugging
On 24 Aug 2007 16:45:41 -, nikolay at totalviewtech dot com
[EMAIL PROTECTED] wrote:
What do you mean?
The IA64 C++ ABI requires two
--- Comment #24 from jakub at gcc dot gnu dot org 2007-08-24 16:36 ---
Removing that call in 4.1/4.2 would indeed cure c#8 testcase.
c#22 would be still broken (ipa_type_escape_field_does_not_clobber_p isn't
called at all on that testcase, neither in 4.1, nor 4.2, nor 4.3.
Guess c#22
1 - 100 of 142 matches
Mail list logo
