--- Comment #6 from uros at gcc dot gnu dot org 2005-11-08 07:59 ---
Subject: Bug 19340
Author: uros
Date: Tue Nov 8 07:58:51 2005
New Revision: 106633
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106633
Log:
PR target/19340
* reg-stack.c (reg_to_stack): Updat
--- Comment #14 from uros at gcc dot gnu dot org 2005-11-08 07:59 ---
Subject: Bug 24315
Author: uros
Date: Tue Nov 8 07:58:51 2005
New Revision: 106633
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106633
Log:
PR target/19340
* reg-stack.c (reg_to_stack): Upda
--- Comment #5 from bonzini at gcc dot gnu dot org 2005-11-08 07:53 ---
The approved patch is the one at
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00212.html
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from r dot emrich at de dot tecosim dot com 2005-11-08
07:47 ---
Bootstrap of gcc-4.1-20051105 succeeded for c,c++,objc,obj-c++.
Testsuite still in progress.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24514
--- Comment #5 from steven at gcc dot gnu dot org 2005-11-08 07:44 ---
Created an attachment (id=10170)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10170&action=view)
merge patch from the killloop-branch
With this patch applied and -fmove-loop-invariants enabled by default at -O
--- Comment #5 from sven dot buijssen at math dot uni-dortmund dot de
2005-11-08 07:04 ---
> Sven,
> Thanks for reporting this and narrowing it down.
You're welcome, Jerry. I reckoned this to be the most promising way to get rid
of this regression as soon as possible. :-)
> This is a
--- Comment #28 from phython at gcc dot gnu dot org 2005-11-08 06:48
---
Steven: How long does 4.0 take to compile this function on your box?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19097
--
phython at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|phython at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #4 from jvdelisle at verizon dot net 2005-11-08 06:37 ---
Subject: Re: [4.1 Regression] Nonadvancing read does not
read more than 1 line
> For sake of compliance with the bug report policy:
> * gfortran from cvs via
> TZ=GMT cvs -q update -D'2005.10.24.03.00.00'
> w
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2005-11-08 06:22
---
I believe I have a fix for this one that works with the previous patch to
pr24489. I am testing along with work on pr24699 to make sure we have no
conflicts or regressions. pr24719, pr24699, pr24700, and pr24489
--- Comment #5 from uros at gcc dot gnu dot org 2005-11-08 06:21 ---
Subject: Bug 19340
Author: uros
Date: Tue Nov 8 06:21:51 2005
New Revision: 106632
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106632
Log:
PR target/19340
* reg-stack.c (reg_to_stack): Updat
--- Comment #13 from amodra at bigpond dot net dot au 2005-11-08 05:24
---
Looking at fixing REG_FRAME_RELATED_EXPR in regrename.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23392
--- Comment #25 from bangerth at dealii dot org 2005-11-08 05:23 ---
*** Bug 24657 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--
--- Comment #6 from bangerth at dealii dot org 2005-11-08 05:23 ---
This is PR 13967. See in particular comment #11 in the audit trail there.
Not that that PR would be particularly enlightening, but the situation is
at least discussed at length there.
W.
*** This bug has been marked a
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #5 from bangerth at dealii dot org 2005-11-08 05:14 ---
This can of course be made even simpler:
struct A {
template A(int (*)[i]) : j(i) {}
int * i;
int j;
};
int i[3];
A a(&i);
g/x> /home/bangerth/bin/gcc-3.4.5-pre/bin/c++ -
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 04:34 ---
No, in C, these are two different function types.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from ghazi at gcc dot gnu dot org 2005-11-08 04:28 ---
I'm not convinced it's the same issue. With regard to 17402, comment #6 by
Joseph there refers specifically to static inlines in that builtins shouldn't
generate calls to "file-scope statics". However in my case glib
--- Comment #2 from joshudson at gmail dot com 2005-11-08 04:25 ---
Aren't function arguments contravariant rather than covariant?
--
joshudson at gmail dot com changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 03:52 ---
I want to say this is dup of bug 17402 which was marked as will not fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24729
When doing transformations on builtins, if the builtin results in a function
call that has an inline expansion, GCC emits a library call not the inline
function body. E.g. glibc defines an inline for fputc_unlocked. Given this
code:
#define _GNU_SOURCE
#include
#define MAX 1
int main (
--- Comment #6 from amodra at bigpond dot net dot au 2005-11-08 03:17
---
I meant, fixed on 3.4 and 4.0 by patch for pr20277
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23704
--- Comment #5 from amodra at bigpond dot net dot au 2005-11-08 03:15
---
Fixed mainline. Bug fixed on 3.4 and 4.0 branch by patch for pr20227
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
--
--- Comment #2 from bugzilla-gcc at thewrittenword dot com 2005-11-08
03:15 ---
(In reply to comment #1)
> See the thread on the gcc list discussing this bug.
> http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html
>
> I suspect this is a bug in patches applied to the gcc-3.4.x sources a
--- Comment #4 from amodra at gcc dot gnu dot org 2005-11-08 03:09 ---
Subject: Bug 23704
Author: amodra
Date: Tue Nov 8 03:08:43 2005
New Revision: 106631
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106631
Log:
PR target/23704
* config/rs6000/rs6000.c (rs600
--- Comment #16 from pinskia at gcc dot gnu dot org 2005-11-08 02:41
---
*** Bug 24728 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 02:41 ---
First this is only undefined code which means that we have to accept the code.
Second this is a dup of bug 8268.
*** This bug has been marked as a duplicate of 8268 ***
--
pinskia at gcc dot gnu dot org changed:
A constant reference to an array element past the end of the array does not
generate an error. Included are the output from gcc -v and a test program that
mimics the real-world case where the coding error corrupted the stack:
Using built-in specs.
Target: i586-suse-linux
Configured with: ../confi
--- Comment #8 from dpatel at apple dot com 2005-11-08 02:22 ---
tree if-conversion was expecting perfect dimond, but it is not always true
after tree-cleanup-branch work. I've started overnight patch test run.
Hopefully, I'll send patch tomorrow for review.
--
http://gcc.gnu.org/b
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2005-11-08 02:18
---
I have confirmed that when I revert the patch to pr24489 that this bug goes
away. Isn't life wonderful!
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2005-11-08 01:46
---
This is precisly when I committed the patch to pr24489. I am also seeing some
possible connections with pr24699. I will investigate further.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24719
--- Comment #1 from wilson at gcc dot gnu dot org 2005-11-08 01:41 ---
See the thread on the gcc list discussing this bug.
http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html
I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do not
see this problem in the FSF sour
--- Comment #60 from pinskia at gcc dot gnu dot org 2005-11-08 01:40
---
Fixed on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-08 01:34 ---
Actually I don't think my patch is the right one.
Here is the patch:
svn diff
Index: tree.c
===
--- tree.c (revision 106572)
+++ tree.c (worki
--- Comment #12 from arun dot sharma at google dot com 2005-11-08 01:30
---
(In reply to comment #10)
> (In reply to comment #9)
> > Yes and the ones against gcc are only about eplogue or prologue so it should
> > not matter for what you are doing.
>
> PR 18748 and PR 18749 both are ab
--- Comment #11 from pinskia at gcc dot gnu dot org 2005-11-08 01:23
---
(In reply to comment #7)
> The particular malloc in question is coming from start_fde_sort() in
> unwind-dw2-fde.c. Perhaps the sorting can be done earlier i.e. before
> _Unwind_Backtrace() is called?
If you do th
--- Comment #10 from pinskia at gcc dot gnu dot org 2005-11-08 01:12
---
(In reply to comment #9)
> Yes and the ones against gcc are only about eplogue or prologue so it should
> not matter for what you are doing.
PR 18748 and PR 18749 both are about prologue and eplogue code which sho
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-08 01:10 ---
(In reply to comment #8)
> libunwind doesn't pass unit tests on amd64. davidm thinks that the problems
> are
> outside of libunwind. I think he has a couple of bugs open against gcc/glibc.
Yes and the ones against
--- Comment #8 from arun dot sharma at google dot com 2005-11-08 01:09
---
(In reply to comment #6)
> Hmm, You could try libunwind instead, it should work on x86_64:
> http://www.hpl.hp.com/research/linux/libunwind/
>
> They show you how to use libunwind to generate a normal backtrace:
--- Comment #7 from arun dot sharma at google dot com 2005-11-08 01:07
---
(In reply to comment #4)
> I really doubt we can remove it because this is also used in the undwinding
> for
> exceptions.
>
It must be possible to do stack unwinding without any mallocs. If the exception
thro
--- Comment #6 from pinskia at gcc dot gnu dot org 2005-11-08 01:02 ---
Hmm, You could try libunwind instead, it should work on x86_64:
http://www.hpl.hp.com/research/linux/libunwind/
They show you how to use libunwind to generate a normal backtrace:
http://www.hpl.hp.com/research/linux
--- Comment #5 from arun dot sharma at google dot com 2005-11-08 00:55
---
(In reply to comment #3)
> You know that glibc has an backtrace function which might be more friendly for
> your purpose?
>
glibc backtrace dlopens libgcc and uses _Unwind_Backtrace() on amd64. glibc
backtrace
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-08 00:53 ---
I really doubt we can remove it because this is also used in the undwinding for
exceptions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-08 00:51 ---
You know that glibc has an backtrace function which might be more friendly for
your purpose?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
--- Comment #2 from arun dot sharma at google dot com 2005-11-08 00:48
---
It deadlocks because malloc is holding a lock and then calls the unwinder.
No, we're not throwing exceptions. One reason why malloc might want to use the
unwinder is to do heap profiling.
http://goog-perftools.
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-08 00:30 ---
Seen at test-case reduction also for code of the form:
int i; for (i = 1; i <= shift_size; i++) { }
not producing the same ICE as for:
int i; i = 1 <= shift_size ? shift_size : 1;
(I'll put a pointer here to the complete
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 00:23 ---
What is your malloc doing special and why would it dead lock? (if you are
throwing from inside malloc I think that is an invalid thing to do).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24724
--- Comment #27 from steven at gcc dot gnu dot org 2005-11-08 00:18 ---
On AMD64, revision 106596M (the M is for a local loop-invariant.c
patch, nothing special), compiler built with --enable-checking=release:
at -O1:
tree operand scan : 1.50 (10%) usr 0.09 (17%) sys 1.62 (10
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 00:09 ---
*** Bug 24725 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24726
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-08 00:09 ---
*** This bug has been marked as a duplicate of 24726 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from schwab at suse dot de 2005-11-08 00:07 ---
The warning is correct. The type of x_write is incompatible with x_io, because
"const void *" is incompatible with "void *". Argument promotion does not come
into play here.
--
schwab at suse dot de changed:
--- Comment #3 from tobi at gcc dot gnu dot org 2005-11-07 23:56 ---
I'm adding FX to the CC list, because this looks like it's related to his patch
for FPU exceptions.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #9 from Tobias dot Schlueter at physik dot uni-muenchen dot de
2005-11-07 23:43 ---
Subject: Re: Unclassifiable statement on implicitly typed
character substring
steven at gcc dot gnu dot org wrote:
> --- Comment #8 from steven at gcc dot gnu dot org 2005-11-07 23:29
Tried this on two machines:
SunOS hornet 5.10 Generic sun4u sparc SUNW,Ultra-4
with GCC 4.0.1
Linux numenor 2.6.13 #9 Mon Sep 19 19:03:35 PDT 2005 i686 unknown unknown
GNU/Linux
with GCC 3.3.6
The following code produces spurios warning:
/* Cut here */
int x_read(int h, void *buf, unsigne
--- Comment #8 from steven at gcc dot gnu dot org 2005-11-07 23:29 ---
We get to "check_substring:" in match_varspec:
PROGRAM P
IMPLICIT CHARACTER*8 (Y)
YLOCAL='A'
YBTABLE=YLOCAL(1:2)
END
check_substring:
if (primary->ts.type == BT_CHARACTER)
Ture-Andersens-dator:~/Documents/Privat/programutveckling/ada/sudoku ture$
gnatmake sudoku
gcc -c elements-sets.adb
+===GNAT BUG DETECTED==+
| 3.3 20040913 (GNAT for Mac OS X build 1650) (powerpc-unknown-darwin) |
| Gigi abort, Code=508
--
Summary: Gigi abort, Code=508
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ture dot andersen a
As this stacktrace shows:
#3 0x004044e2 in malloc (size=36024) at tcmalloc.cc:1314
#4 0x0047a938 in search_object ()
#5 0x0047b189 in _Unwind_Find_FDE ()
#6 0x00478049 in uw_frame_state_for ()
#7 0x00478eca in uw_init_context_1 ()
#8 0x004790b0
--- Comment #2 from hp at gcc dot gnu dot org 2005-11-07 23:24 ---
In reply to comment #1, yes. The message in the log for -O3 and -Os is now:
Executing on host: /home/hp/combined/crislinux-sim/gcc/testsuite/../gfortran
-B/home/hp/combined/crislinux-sim/gcc/testsuite/../ \
/home/hp/com
--- Comment #15 from mmitchel at gcc dot gnu dot org 2005-11-07 23:10
---
*** Bug 23457 has been marked as a duplicate of this bug. ***
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-11-07 23:10
---
*** This bug has been marked as a duplicate of 21308 ***
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
---
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de
|dot org |
--- Comment #2 from pcarlini at suse dot de 2005-11-07 21:54 ---
(In reply to comment #1)
> Note _TREE_H is reserved by the standard for implementations so this is a
> correct use really. Anyone using _TREE_H in their headers are asking for
> troubles as they are using a reserved identi
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 21:51 ---
Note _TREE_H is reserved by the standard for implementations so this is a
correct use really. Anyone using _TREE_H in their headers are asking for
troubles as they are using a reserved identifier.
--
pinskia at
Due to the global nature of macros, the include guard at the top of stl_tree.h:
#ifndef _TREE_H
...
should be renamed to something more specific such as _STL_TREE_H. _TREE_H
shouldn't really be defined by anyone, especially the STL library. I noticed
this header from someone else who wrote code
Revision 1.64 of libgfortran/io/transfer.c causes a regression for the
following testcase:
% cat < regression.f90
program demonstration
implicit none
character(len=1) :: saux
open(unit = 1, FILE = "foo.conf", STATUS = 'OLD', ACTION = 'READ')
do
10read(unit = 1, fmt = '(a)', adv
--- Comment #9 from pinskia at gcc dot gnu dot org 2005-11-07 21:16 ---
(In reply to comment #8)
> If -
>
> cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc
>
> is now wrong, what is the correct CVS command to use ?
GCC does not use cvs any more.
Read http://gcc.gnu.org/svn.html
W
--- Comment #8 from dir at lanl dot gov 2005-11-07 21:14 ---
If -
cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc
is now wrong, what is the correct CVS command to use ?
Changing the directory make no difference, I have done exactly the same thing
for the last year or so and I had t
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-07 21:00 ---
Fixed in 4.0.0 and above.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from pinskia at gcc dot gnu dot org 2005-11-07 20:56
---
Fixed at least on the mainline.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-07 20:43 ---
-O1 -fno-tree-ccp -fno-tree-store-ccp -fno-tree-dominator-opts works (maybe
this will give a hint on how to reduce the issue).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #3 from pinskia at gcc dot gnu dot org 2005-11-07 20:39 ---
A little more info, umf_analyze.i is being miscompiled. I don't know which one
yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #5 from pault at gcc dot gnu dot org 2005-11-07 20:14 ---
> Did this patch ever get posted?
Tobi, that's a coincidence; I just found it whilst working on dot_product!
I'll submit in the next 24 hours. I've found another patch that I just forgot
about too
--
http:/
--- Comment #13 from thebohemian at gmx dot net 2005-11-07 20:03 ---
anthony you're right. It should work without ffi_call invocation.
Thanks for the review. I try to find out whether this fixes my segfault too,
tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24616
--- Comment #7 from pinskia at gcc dot gnu dot org 2005-11-07 20:03 ---
Can you try first by not building in the source directory?
Second that CVS repro is no longer being updated.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #7 from matz at suse dot de 2005-11-07 19:59 ---
Of course not. But unaware people trying trunk currently on distros which
provided 3.4 or 4.0 will get non-obvious problems, and I'm not sure if that's
a good idea (ignoring this problem 4.0 and trunk are nearly compatible, an
--- Comment #19 from wilson at gcc dot gnu dot org 2005-11-07 19:52 ---
Fixed on gcc-3.4.x branch, gcc-4.0.x branch, and mainline.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #18 from wilson at gcc dot gnu dot org 2005-11-07 19:51 ---
Mine.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #17 from wilson at gcc dot gnu dot org 2005-11-07 19:49 ---
Subject: Bug 15220
Author: wilson
Date: Mon Nov 7 19:49:04 2005
New Revision: 106608
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106608
Log:
Fix problem with -MM -MG and missing system header files.
PR p
--- Comment #24 from jason at gcc dot gnu dot org 2005-11-07 19:35 ---
This is a bug in the generic thunk support; it doesn't show up on x86 because
it uses asm thunks. Continuing to investigate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
I've built gcc-3.4.3 for HP-UX 11.23/IA-64 and used the pre-compiled
gcc-3.4.4 binary from the http://www.hp.com/go/gcc site. Both exhibit
the same problem. While trying to build Perl 5.8.6:
$ gmake
...
gcc -v -o libperl.so -shared -fPIC perl.o gv.o toke.o perly.o op.o
pad.o regcomp.o dump
--- Comment #6 from dir at lanl dot gov 2005-11-07 19:19 ---
I have a dual 2.5 GHZ PowerPC G5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24710
--- Comment #5 from dir at lanl dot gov 2005-11-07 19:17 ---
I do the get with -
[dranta:~/utlib] dir% cat gfortranGet
cvs -d :ext:[EMAIL PROTECTED]:/cvsroot/gcc co gcc
I do the configure with -
[dranta:~/utlib] dir% cat gfortranConfig
configure --prefix=/Users/dir/gfortran --enable-l
--- Comment #2 from dnovillo at gcc dot gnu dot org 2005-11-07 19:06
---
Fixed. http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00458.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
-
enum A{a,b,c};
template void f(const U&, int) {}
template void f(const U&, int) {}
template void f(const U&, int) {}
template void f(const U&, int, int) {}
template void f(const U&, int, int) {}
template void f(const U&, int, int) {}
int main() {
bool b;
f(b, 5);
f(b, 5);
f<>(b, 5)
--- Comment #24 from ian at airs dot com 2005-11-07 18:58 ---
Fixed on 4.0 branch and on mainline.
The 3.4 branch breaks in a slightly different way. I'm not going to worry
about it since you can only create this problem by building implausible
addresses that include offsets of more th
--- Comment #23 from ian at gcc dot gnu dot org 2005-11-07 18:55 ---
Subject: Bug 24683
Author: ian
Date: Mon Nov 7 18:55:03 2005
New Revision: 106602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106602
Log:
./:
PR rtl-optimization/24683
* config/i386/i386.c (
--- Comment #22 from ian at gcc dot gnu dot org 2005-11-07 18:52 ---
Subject: Bug 24683
Author: ian
Date: Mon Nov 7 18:52:24 2005
New Revision: 106601
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106601
Log:
./:
PR rtl-optimization/24683
* config/i386/i386.c (
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-11-07 18:49 ---
(In reply to comment #0)
> The error seems to be specific to powerpc; it does not happen on i386.
It does fail for me on i686 with 4.1.0 20051026.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--- Comment #21 from mueller at kde dot org 2005-11-07 18:45 ---
its an error in the testcase, the original code initializes i:
if((j + len) > 63) {
562 memcpy(&context->buffer[j], data, (i = 64-j));
563 transform(context->state
--- Comment #1 from schnetter at aei dot mpg dot de 2005-11-07 18:42
---
Created an attachment (id=10165)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10165&action=view)
Tarball with source code demonstrating the problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24716
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|Wrong code generated when |[4.1 Regre
--- Comment #20 from ian at airs dot com 2005-11-07 18:41 ---
By the way, Richard, I just want to note that while this is obviously a
compiler bug, it is only being triggered for the original test case because of
the uninitialized variable i in sha1_update:
void sha1_update(SHA1_C
--- Comment #4 from sje at cup dot hp dot com 2005-11-07 18:40 ---
Original patch submittal is at
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00985.html
I will apply this to the 3.4 branch and test it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24688
In a large application, a certain routine from the UMFPACK library is
miscompiled when -O is specified. Without optimisation, the routine works
fine. This triggers an assertion failure in the code.
I use gcc (GCC) 4.1.0 20051030 (experimental). The problem can be reproduced
with the attached so
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|sco_math fixincl breaks |[3.4 Regression] sco_math
|math.h
--- Comment #3 from sje at cup dot hp dot com 2005-11-07 18:26 ---
It looks like this is fixed on the mainline and on the 4.0 branch by the
addition of
bypass = "__GNUG__";
This patch was done in revision 90550 by jsm28. We should do this for the 3.4
branch as well.
--
sje at cu
--- Comment #21 from bonzini at gcc dot gnu dot org 2005-11-07 18:22
---
Is this a 4.0 regression too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22509
--- Comment #3 from bonzini at gcc dot gnu dot org 2005-11-07 18:19 ---
it works now
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #9 from bonzini at gcc dot gnu dot org 2005-11-07 18:18 ---
fixed on 4.0 branch too
--
bonzini at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 171 matches
Mail list logo
