--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
01:45 ---
on ppc-darwin with ZCX enabled this passes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19385
--- Additional Comments From hjl at lucon dot org 2005-01-19 01:47 ---
Please take a closer look at the testcase. It is different from
bug 10908. Basically, main executable and DSO see different
function pointer values for the SAME function. From the linker
/* Will references to this sym
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19
02:01 ---
There are two changes that affect this binary incompatibility: one
changes the layout of the class, and the other changes how the bitfield
is accessed. Mark, did this change on purpose and is it covered by
--- Additional Comments From janis187 at us dot ibm dot com 2005-01-19
02:05 ---
Created an attachment (id=7988)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7988&action=view)
test case with script
I get the following output from running the attached script using compilers
I buil
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
02:11 ---
G++ 4.0 is correct. This declaration gives only a signed 9-bit type,
independent of the ABI. Since +128 is not representable in 9 signed bits, it
wraps to -128. The same issue explains the other tests.
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-19 02:35
---
So the bug is the end stab without the start stab? Or do you think that this
bit of code that corresponds not at all to any user code should have full stabs?
If the later, why?
--
http://gcc.gnu.org/bugzill
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
02:40 ---
(In reply to comment #1)
> Also fails on ppc-linux with ZCX.
But passes on ppc-darwin with ZCX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19381
--- Additional Comments From dje at gcc dot gnu dot org 2005-01-19 02:44
---
Steven's experiments seem to demonstrate that the current DSE implementation is
not very effective. GCC 4.0 includes RTL optimizations that will catch most if
not all of these cases, so it is not as if this wil
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
03:11 ---
The difference between non protected and protected functions is the following
in the asm:
movl[EMAIL PROTECTED](%ebx), %eax
leal[EMAIL PROTECTED](%ebx), %eax
but really add -fPIC to
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
03:31 ---
So help out here, which is more correct the GOT or the GOTOFF?(In reply to
comment #7)
> Please take a closer look at the testcase. It is different from
> bug 10908. Basically, main executable and DSO see d
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
03:41 ---
Well I think there is wrong reloc somewhere or a reloc being resolved wrongly
because foo binds locally in x.c otherwise the protect is visibility is really
useless otherwise (except
maybe to make sure tha
--- Additional Comments From giovannibajo at libero dot it 2005-01-19
04:30 ---
Would you please add the testcase to this bug as a file attachment?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19519
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From schlie at comcast dot net 2005-01-19 05:17
---
Actually wonder if a better solutions would be to and (&) the rhs shift count by
Log2(rhs-mode-size) bit mask, thereby the resulting value will always be within
0 >= shift <= (N-1), resulting effectivly a shift m
--- Additional Comments From schlie at comcast dot net 2005-01-19 05:26
---
(In reply to comment #8)
Never mind, as it's likely not worth the bother as the behavor
is undefined anyway, and the existing proposal is simpler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19293
Fix GCC so that a nonlocal label won't appear after local labels.
In other words, the following addition to tree_verify_flow_info should not
introduce regressions.
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01191.html
--
Summary: Fix GCC so that a nonlocal label won't appear after
--- Additional Comments From bje at au1 dot ibm dot com 2005-01-19 06:05
---
Subject: Re: basic_string::_M_rep() can produce an unnaturally aligned pointer
to _Rep
On Tue, Jan 18, 2005 at 09:45:48AM -, pcarlini at suse dot de wrote:
> In other terms, as far as this PR is concerne
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
06:17 ---
Jason, are you looking at this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18604
--- Additional Comments From amodra at bigpond dot net dot au 2005-01-19
06:28 ---
The reason for the bus error is the __exchange_and_add decrement of _M_refcount.
On powerpc, lwarx and stwcx. must have an aligned effective address.
--
What|Removed |
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
06:39 ---
I think the problem is in remove_bb.
This is the only place where we move lables around really.
basically here:
block_stmt_iterator new_bsi = bsi_start (new_bb);
we should just skip over the firs
--- Additional Comments From law at redhat dot com 2005-01-19 06:46 ---
Subject: Re: DSE is not doing its job for
global variables
On Wed, 2005-01-19 at 02:44 +, dje at gcc dot gnu dot org wrote:
> --- Additional Comments From dje at gcc dot gnu dot org 2005-01-19 02:44
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
06:46 ---
Actually I think the verifying patch is wrong, because we can have multiple
computed lables at the
begining of a BB because we moved it from a different BB.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
06:53 ---
Yes that is it. Basically we have two computed GOTO's at the beginging of the
BB which is okay really
since there is no way otherwise since we just remove the other BB (unless you
want to create a new BB
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
06:55 ---
(In reply to comment #3)
... like a waste.
Since we are going to keep the BB's around for longer in 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19522
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
07:21 ---
Java bugs are not showstoppers; removing target milestone.
--
What|Removed |Added
Target
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-19
07:27 ---
Closing as you reported a successful C,C++,Obj-C,Java bootstrap.
--
What|Removed |Added
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-01-19
07:28 ---
Removing target milestone; this is not release-critical.
--
What|Removed |Added
Target Mi
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
07:29 ---
(In reply to comment #4)
> Removing target milestone; this is not release-critical.
Does not matter this has now been fixed, I had forgot to close it, oops.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
07:38 ---
on the mainline I get an stack overflow in the GC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19513
The patch
2004-09-20 Matt Austern <[EMAIL PROTECTED]>
Zack Weinberg <[EMAIL PROTECTED]>
* c-common.c (fix_string_type): Build the unqualified array
type unconditionally, then use c_build_qualified_type to get
the proper const-qualified variant, and set its
--
What|Removed |Added
Keywords||wrong-debug
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--
What|Removed |Added
CC||dpatel at apple dot com,
||zack at codesourcery dot
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-19
07:58 ---
(In reply to comment #3)
> on the mainline I get an stack overflow in the GC.
And I have a work around for that. But that is only a work around, we are
creating too many varients of
FUNCTION_TYPE which se
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/sh
201 - 234 of 234 matches
Mail list logo
