--- Comment #12 from rth at gcc dot gnu dot org 2005-11-01 07:35 ---
Frankly, this smells like a plain old-fashioned reload bug to me.
There's no reason this insn couldn't have been rendered as
movl %esi,%eax
movbl %al,%eax
Investigating further to see how nasty it might be...
--
It's true that the arm comment start symbol is '@', but GCC will generate some
assembler code end with a '@' and a comment without a separator so it can't be
parsed by gas.
For example, I compile the libgcc2.c:__gcc_bcmp with xgcc, it failed:
___
--
rth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org
--- Comment #12 from wilson at gcc dot gnu dot org 2005-11-01 07:25 ---
The patch should use false instead of 0. These new fangled boolean types keep
messing me up.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24202
--- Comment #11 from wilson at gcc dot gnu dot org 2005-11-01 07:22 ---
Created an attachment (id=10096)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10096&action=view)
clear buffer_valid when clearing buffer
Untested patch for mainline which makes the testcase work.
--
wilso
--- Comment #10 from wilson at gcc dot gnu dot org 2005-11-01 07:19 ---
On mainline, this appears to be fixable with a one line patch.
We are failing in should_stack_file because we have a _cpp_file struct with
buffer=0 and buffer_valid=1. We call read_file which immediately returns
be
--- Comment #6 from wilson at gcc dot gnu dot org 2005-11-01 06:38 ---
Short story...
Your kernel code is broken. init functions go in .init.text, but init data
goes in .init.data, not .init.text. See the
Documentation/Docbook/kernel-hacking.tmpl file in any recent kernel.
Long story.
--- Comment #1 from ian at airs dot com 2005-11-01 06:02 ---
Created an attachment (id=10095)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10095&action=view)
.s file from gcc -S -O2
For reference, here is the complete .s file I get from gcc -S -O2.
--
http://gcc.gnu.org/bugz
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-01 05:53 ---
Subject: Bug 14994
Author: pault
Date: Tue Nov 1 05:53:29 2005
New Revision: 106317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106317
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2005-11-01 05:53 ---
Subject: Bug 18737
Author: pault
Date: Tue Nov 1 05:53:29 2005
New Revision: 106317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106317
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pault at gcc dot gnu dot org 2005-11-01 05:53 ---
Subject: Bug 21565
Author: pault
Date: Tue Nov 1 05:53:29 2005
New Revision: 106317
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106317
Log:
2005-11-01 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
This test case causes the same value to be consistently stored in two different
registers. This happens when compiling at -O2.
extern int abs (int __x);
extern int bar (short*, short, int);
struct s
{
short int* top;
short int* left;
short int* diag;
};
int
foo (int *a, struct s* p, short
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 05:31 ---
If we used the caret way of doing things it would just work.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
template class A{};
template class B{};
template class C{};
template class D{};
template class E{};
template void f() {
typedef A > > > foo;
}
gets you:
~/ootbc/members/src$ g++ foo.cc
foo.cc: In function `void f()':
foo.cc:7: error: template argument 1 is invalid
foo.cc:7: error: ISO C++ forbid
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-01 04:45 ---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg6.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-01 04:36 ---
Reduced testcase:
struct string;
struct _Deque_iterator {
string &operator*() const;
};
template void for_each(_Function __f) {
_Deque_iterator __first1;
__f(*__first1);
}
struct locale {
loc
--- Comment #84 from geoffk at geoffk dot org 2005-11-01 04:30 ---
Subject: Re: libstdc++ headers should have pop/push of the visibility around
the declarations
On 31/10/2005, at 7:59 PM, bkoz at gcc dot gnu dot org wrote:
> Geoff, it's not as simple as just marking throwable types,
--- Comment #2 from bkoz at gcc dot gnu dot org 2005-11-01 04:05 ---
Oh, ok, whatever. It's still unfortunate for my twisted purposes.
I can see why this is not allowed in practice, since then namespace could be
aliased all over the place, but at least the error message should make sen
--- Comment #83 from bkoz at gcc dot gnu dot org 2005-11-01 03:59 ---
I agree Geoff, we should hold off on this for 4.1, and try to hit 4.2. If
things get solid sooner, maybe this can be reconsidered. Adding this patch to
4.0.x is out of the question, it has the potential to change too
--- Comment #5 from pinskia at gcc dot gnu dot org 2005-11-01 03:09 ---
PR 24606 is the other issue I found.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Testcase:
template
void for_each(_Function __f)
{
__f(1);
}
class locale{};
template
void trim(SequenceT& Input, const locale& Loc=locale());
int main()
{
for_each(trim);
}
---
I don't know if this is valid or not but guess what ICC also ICEs on this
testcase too.
--
Summ
--- Comment #5 from wilson at gcc dot gnu dot org 2005-11-01 02:44 ---
Even at -O0, we notice that main ends with a call to a function that does not
return, so the epilogue gets optimized away, and the last instruction in the
main function is the call to abort.
gdb is naively using retu
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 02:23 ---
Note the backtrace for the orginal issue is:
#28 0x0040bb94 in convert_like_real (convs=Variable "convs" is not
available.
) at /home/pinskia/src/newtest/trunk/gcc/cp/call.c:4379
#29 0x0040c241 in bui
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-01 02:22 ---
With the source here, I was able to find a different issue which I will be
posting soon.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24602
--- Comment #82 from pcarlini at suse dot de 2005-11-01 02:21 ---
To clarify: I have unassigned myself from this bug because I don't consider
myself sufficiently competent in this area to evaluate all the possible trade-
offs of the issue and don't want to block in any way the work of kn
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu
||do
--- Comment #6 from law at redhat dot com 2005-11-01 01:56 ---
Subject: Re: [4.1 Regression] jump threading
causing excessive code duplication
On Mon, 2005-10-31 at 03:43 +, mmitchel at gcc dot gnu dot org
wrote:
>
> --- Comment #5 from mmitchel at gcc dot gnu dot org
--- Comment #4 from hnakamur at good-day dot co dot jp 2005-11-01 01:48
---
You are correct that IANA character-sets file only contains
two "EUC-JP" aliases: csEUCPkdFmtJapanese and EUC-JP.
But actually there are many non-Java programs which use other aliases and
do not accept above al
--- Comment #8 from wilson at gcc dot gnu dot org 2005-11-01 01:16 ---
I see that we are using the priority field now, so let's put the 4.1 target
milestone back and set priority to p4 to indicate this is a regression, but not
a serious one blocking the release.
--
wilson at gcc dot
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 01:10 ---
There is at least a 4.1 regression here as we ICE after an error.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from ron_hylton at hotmail dot com 2005-11-01 01:04 ---
Created an attachment (id=10093)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10093&action=view)
bz2 compressed .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24605
gcc -c -DU_HAVE_INTTYPES_H solveHestonVol.ii gives a segmentation fault.
gcc info from the full source compile:
Reading specs from /gcc-3.4/lib/gcc/i686-pc-cygwin/3.4.5/specs
Configured with: ../gcc/configure --prefix=/gcc-3.4
--enable-languages=c,c++,f77 --verbose --enable-nls --without-included
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-01 00:52 ---
http://gcc.gnu.org/ml/gcc/2005-10/msg01152.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24601
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 00:46 ---
The error message suggest that you are using a pre 4.0 compiler. As the
mainline and 4.0.0 gives only one error message:
earth:~>gcc t.cc
t.cc:6: error: conflicting declaration 'namespace std = std6;'
:0: error: 's
namespace std6
{
int j;
}
namespace std = std6;
%g++ -c test.cc
test.cc:7: error: conflicting declaration 'namespace std = std6;'
:0: error: 'std' has a previous declaration as `namespace std { }'
test.cc:7: error: declaration of `namespace std = std6;'
:0: error: conflicts with previous decla
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 00:36 ---
I think this is a dup of bug 22044.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 00:33 ---
This is a true C++ front-end problem, in that the seg fault is due to a stack
overflow in the C++ front-end. I think this is a regression but I have not
tried to reduce it yet.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #7 from jsm28 at gcc dot gnu dot org 2005-11-01 00:25 ---
diagnostic.c gets #include stack information from input_file_stack. cpplib
gets it from source_locations. With --enable-mapped-location, this regression
could be fixed by diagnostic.c getting it from source_locations
--- Comment #3 from jean-marc dot valin at usherbrooke dot ca 2005-11-01
00:20 ---
Can you send a link to a tarball of the compiler you want me to try?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24601
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-01 00:17 ---
Can you try a newer compiler as I cannot reproduce this with 20051026 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24601
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-01 00:12 ---
This is a target issue. Can you attach regex.i when you add -save-temps to
that command line?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from xeon at gmx dot ch 2005-10-31 23:46 ---
Created an attachment (id=10092)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10092&action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24602
--- Comment #7 from wilson at gcc dot gnu dot org 2005-10-31 23:46 ---
This is partially fixed. The debug info is correct enough to make the gdb
testsuite happy, but we are lacking correct info for the frame_base in the
prologue and epilogue. That used to be computed by code in var-tra
This is the error message I get
../../../im-alias-source/libiberty/regex.c: In function 'byte_regex_compile':
../../../im-alias-source/libiberty/regex.c:4221: error: unrecognizable insn:
(insn 160 159 161 3 ../../../im-alias-source/libiberty/regex.c:284 (set (reg:SI
326 [ ivtmp.838 ])
(cons
--- Comment #6 from wilson at gcc dot gnu dot org 2005-10-31 23:39 ---
Subject: Bug 2
Author: wilson
Date: Mon Oct 31 23:39:29 2005
New Revision: 106299
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106299
Log:
Restore old AT_frame_base code for targets that don't use dwarf
I stumbled over a possible bug in g++ (at least it told me to file a bug
report). I'm not exactly sure if the code I tried to compile is correct.
~/bug > g++ -v -save-temps -I/usr/local/include gpp_bug.cpp
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc
--- Comment #13 from law at redhat dot com 2005-10-31 23:36 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Mon, 2005-10-31 at 23:25 +, hubicka at ucw dot cz wrote:
> See comment #5. The fact that we ended up with more jumps was
--- Comment #81 from geoffk at geoffk dot org 2005-10-31 23:29 ---
Subject: Re: libstdc++ headers should have pop/push of the visibility around
the declarations
On 31/10/2005, at 2:45 PM, mueller at kde dot org wrote:
> --- Comment #80 from mueller at kde dot org 2005-10-31 22:
--- Comment #12 from hubicka at ucw dot cz 2005-10-31 23:25 ---
Subject: Re: [4.1 Regression] Slowdown of the bresenham line drawing by
roughly 20%
>
>
> --- Comment #11 from law at redhat dot com 2005-10-31 23:18 ---
> Subject: Re: [4.1 Regression] Slowdown of the
>
>
>
> --- Comment #11 from law at redhat dot com 2005-10-31 23:18 ---
> Subject: Re: [4.1 Regression] Slowdown of the
> bresenham line drawing by roughly 20%
>
> On Mon, 2005-10-31 at 20:55 +, hubicka at gcc dot gnu dot org wrote:
> >
> > --- Comment #10 from hubicka a
--- Comment #23 from wilson at gcc dot gnu dot org 2005-10-31 23:25 ---
Fixed for gcc-4.1. Won't fix for gcc-4.0.3.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from jean-marc dot valin at usherbrooke dot ca 2005-10-31
23:25 ---
Created an attachment (id=10091)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10091&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24601
--- Comment #22 from wilson at gcc dot gnu dot org 2005-10-31 23:24 ---
Subject: Bug 17356
Author: wilson
Date: Mon Oct 31 23:24:36 2005
New Revision: 106297
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106297
Log:
Rewrite fix for PR 17356, fix for enable checking ada build fa
I'm getting an ICE with gcc-4.1-20051001 on the code in attachment. When
compiling with:
% gcc -O2 -march=pentium3 -ftree-vectorize -c cb_search_pre.c
the result is:
cb_search.c: In function 'split_cb_search_shape_sign':
cb_search.c:268: internal compiler error: Segmentation fault
Please submit a f
--- Comment #11 from law at redhat dot com 2005-10-31 23:18 ---
Subject: Re: [4.1 Regression] Slowdown of the
bresenham line drawing by roughly 20%
On Mon, 2005-10-31 at 20:55 +, hubicka at gcc dot gnu dot org wrote:
>
> --- Comment #10 from hubicka at gcc dot gnu dot
--- Comment #10 from steven at gcc dot gnu dot org 2005-10-31 23:14 ---
I have asked Janis to reghunt this one. The bug also affects ppc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-10-31 23:02 ---
Here is a compile time testcase for easier regression hunting:
typedef int BOOL;
typedef unsigned int UINT;
#pragma pack(1)
typedef struct {
BOOL fFullPathTitle:1;
BOOL fSaveLocalView:1;
BOOL fNotShell:
--- Comment #3 from igodard at pacbell dot net 2005-10-31 22:48 ---
Ys of course; sorry :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24592
--- Comment #80 from mueller at kde dot org 2005-10-31 22:45 ---
- if its not safe for all architectures we'd already run into heaps of problems
because both libsupc++ and libgcc2 already include similiar pragmas.
- not hiding a symbols is better than the resulting issues when hiding a
--- Comment #79 from geoffk at geoffk dot org 2005-10-31 22:14 ---
Subject: Re: libstdc++ headers should have pop/push of the visibility around
the declarations
On 31/10/2005, at 10:37 AM, ismail at uludag dot org dot tr wrote:
> --- Comment #78 from ismail at uludag dot org dot
--- Comment #1 from rguenth at gcc dot gnu dot org 2005-10-31 21:40 ---
Whoops, s390, not s390x.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target
Lots of package failures with
req_track.c:204: error: unrecognizable insn:
(insn 299 61 62 6 (set (reg/f:SI 66)
(plus:SI (reg/f:SI 126 [ server.sv_track ])
--- Comment #12 from hubicka at gcc dot gnu dot org 2005-10-31 21:10
---
Fixed by my patch (at least works on x86 and originally I reproduced same
failure)
Honza
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from hubicka at gcc dot gnu dot org 2005-10-31 21:07
---
Subject: Bug 24093
Author: hubicka
Date: Mon Oct 31 21:07:29 2005
New Revision: 106291
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106291
Log:
PR middle-end/24093
* cgraph.c (cgraph_clo
--- Comment #8 from bothner at gcc dot gnu dot org 2005-10-31 20:56 ---
Created an attachment (id=10090)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10090&action=view)
proposed patch for second testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24101
--- Comment #10 from hubicka at gcc dot gnu dot org 2005-10-31 20:55
---
Jeff, you missed the propagation DOM makes that hurts register allocation
indpeendently on whether code sinking does or does not it's job.
In reality code sinking (that appeared in GCC after I reported the bug)
imp
--- Comment #7 from bothner at gcc dot gnu dot org 2005-10-31 20:53 ---
Created an attachment (id=10088)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10088&action=view)
proposed patch for initial testcase
--
bothner at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from hubicka at ucw dot cz 2005-10-31 20:25 ---
Subject: Re: [4.1 Regression] 4.1 generates sall + addl instead of leal
>
>
> --- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 04:45
> ---
> Jan, what's your analysis on this PR?
Hmm,
I am still no
--- Comment #23 from rguenth at gcc dot gnu dot org 2005-10-31 20:22
---
Created an attachment (id=10087)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10087&action=view)
original source file from xvid (xvidcore-1.1.0-beta2)
"Source" looks like:
MAKE_PASS_16(V_Pass_Avrg_Up_16_Ad
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-31 20:20 ---
I can test the first one since it is an easy one to test.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #22 from pinskia at gcc dot gnu dot org 2005-10-31 20:10
---
(In reply to comment #21)
> Does anyone have the un-preprocessed source for this bug? I'm seeing some
> assignments that should have casts, and I wan't to rule out bogus input.
comment #13 has an un preprocessed
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 20:09 ---
Confirmed, only a 4.0 regression. Back trace:
#0 0x004a1ff2 in find_interesting_uses_cond (data=0x7fc1d340,
stmt=0x2afc0320,
cond_p=0x2afc0358) at
/home/pinskia/src/gcc-4.0/gcc/gcc/tree-ssa
--- Comment #21 from aldyh at gcc dot gnu dot org 2005-10-31 20:08 ---
Does anyone have the un-preprocessed source for this bug? I'm seeing some
assignments that should have casts, and I wan't to rule out bogus input.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24230
--- Comment #2 from tromey at gcc dot gnu dot org 2005-10-31 20:02 ---
See:
http://people.redhat.com/gbenson/SecurityException-throwers-1.4.2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21891
The following testcase crashes when compiled with -O3.
#include
bool v_2 = true;
bool *v_3 = &v_2;
int idv_2 = 0;
int idv_3 = 0;
int
main (int argc, char **argv)
{
if ((bool)((1527719483 + 1477819644))) {
}
for (idv_2 = 0; idv_2 < 15; ++idv_2) {
for (idv_3 = 0; idv_3 < (v_2
--- Comment #14 from rguenth at gcc dot gnu dot org 2005-10-31 19:56
---
Mark, this looks more like a P1 issue. It makes all packages that use
libsigc++ (part of the gtk--) fail to compile. It is related to 24288 but the
patch there doesn't fix this issue.
--
rguenth at gcc dot gn
--- Comment #13 from rguenth at gcc dot gnu dot org 2005-10-31 19:34
---
Seems it's not my call.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2005-10-31 19:31
---
Oh, and this really is a blocker.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-10-31 19:22 ---
Here is a better testcase with only one error:
int f(int c)
{
switch (c)
{
case d: /* { dg-error "'d' was not declared" } */
int optBzip2 = true;
}
}
I am going to fix this one.
--
pinsk
--- Comment #11 from rguenth at gcc dot gnu dot org 2005-10-31 19:17
---
And that patch doesn't fix the testcase which is attached.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24351
--- Comment #29 from hubicka at gcc dot gnu dot org 2005-10-31 19:15
---
Actually I have to reopen this. When playing around on pentiumM or opteron, I
still get roughly 20% regression (6s to 8s), 4.1 and 4.0 scores are about the
same on both machines. For some reason this don't reprodu
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20815
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-10-31 18:58 ---
I will take this for now.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
A
GCC needs support for odcctools and --prefix ablity. The finding of libtool is
the main issue.
I don't know what else is needed right now but when my laptop comes back alive,
I will look more into this.
--
Summary: Need to support odcctools and its ablity to use --prefix
--- Comment #11 from hubicka at gcc dot gnu dot org 2005-10-31 18:47
---
I tested only simplified testcase, but the issue should be resolved pretty
safely.
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from hubicka at gcc dot gnu dot org 2005-10-31 18:45
---
Patch comitted. For some reason don't seem to appear in logs?
--
hubicka at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #78 from ismail at uludag dot org dot tr 2005-10-31 18:37
---
Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? Waiting for 4.2
means that unpatched gcc's will suffer for more.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #28 from hubicka at gcc dot gnu dot org 2005-10-31 18:36
---
I get 0m8.052s on 3.4 and 0m8.127s on mainline on Athlon. This hardly counts
as an regression.
This is actually effect of some cost tweaks we did relatie to gimplifier a
while ago.
Reduced testcase fits in limits
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 18:24 ---
I don't have P4 to test handy. Can you re-test whether fixing 23302 (23303 is
invalid) make any difference?
I doubt these two make actual runtime changes - the sequence would translate to
same uops for P4 and should
--- Comment #2 from echristo at apple dot com 2005-10-31 18:17 ---
Since I don't have access to an irix box anymore I'd really need the
instruction it fails on at the least, some annotated assembly would be a good
start (compile the failing file with -dap and attach the .s output).
--
--- Comment #6 from hubicka at gcc dot gnu dot org 2005-10-31 18:15 ---
Actually the cited 4.0 sequence do not obey the const int x86_read_modify =
~(m_PENT | m_PPRO);
setting -march=athlon or using -Os makes the move go away. Additionally I get
following sequence out of 4.0 in SUSE dis
--- Comment #4 from tromey at gcc dot gnu dot org 2005-10-31 17:51 ---
I'll handle this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #3 from tromey at gcc dot gnu dot org 2005-10-31 17:48 ---
I'll handle this.
I agree, we need this alias.
That particular part of the code is generated by
the script libjava/scripts/encodings.pl.
Looking at the current IANA character-sets file, I see
there is only this:
Al
--- Comment #1 from r dot emrich at de dot tecosim dot com 2005-10-31
17:37 ---
same for gcc-4.1-20051029
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #8 from steven at gcc dot gnu dot org 2005-10-31 17:31 ---
Right, I didn't know this wasn't opened until July of this year, sorry.
I should have looked.
I still am not sure whether this does break a documented ABI. Relevant
texts in C99 are 6.2.6.1 sub 4, and 6.7.2.1 sub 3.
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-10-31 17:18
---
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01691.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #19 from pinskia at gcc dot gnu dot org 2005-10-31 17:16
---
(In reply to comment #18)
> See comment #16 for a patch.
More than that, it has been posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01792.html
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #18 from steven at gcc dot gnu dot org 2005-10-31 17:14 ---
See comment #16 for a patch.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 139 matches
Mail list logo
