--- Comment #5 from gdr at gcc dot gnu dot org 2006-11-20 01:04 ---
Subject: Bug 8586
Author: gdr
Date: Mon Nov 20 01:03:49 2006
New Revision: 119009
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119009
Log:
2006-11-19 Gabriel Dos Reis <[EMAIL PROTECTED]>
PR c++/8586
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot
|dot org
--- Comment #16 from pinskia at gcc dot gnu dot org 2006-11-20 00:49
---
*** Bug 29903 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28834
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-20 00:49 ---
It is the same failure as mayalias-2.c as I added both, the code is only
slightly different between those two.
*** This bug has been marked as a duplicate of 28834 ***
--
pinskia at gcc dot gnu dot org changed:
Executing on host: /home/dave/gcc-4.3/objdir/gcc/xgcc
-B/home/dave/gcc-4.3/objdi
r/gcc/ /home/dave/gcc-4.3/gcc/gcc/testsuite/gcc.c-torture/execute/mayalias-3.c
-w -O3 -g -fno-show-column -lm -o
/home/dave/gcc-4.3/objdir/gcc/testsuite/g
cc/mayalias-3.x4(timeout = 300)
/home/dave/gcc-4.3/gcc
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29899
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-20 00:27 ---
I think after remove empty loops, we should add a DCE pass which should fix the
above reduced testcase but will not fix this reduced testcase:
int length1();
int g(int);
void f(int capacity_, char*old_storage)
{
tr
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-20 00:23 ---
Reduced testcase:
int length1();
int g(int);
void f(int capacity_, char *old_storage)
{
try {
length1();
int old_capacity = capacity_;
capacity_ *= 2;
g(capacity_);
for (int i = 1; i < old_capac
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-20
00:22 ---
Subject: Re: [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE:
Segmentation fault
> I want to say the gen_insn part which exposed the problem.
I still have the ICE after reverting this part. Try
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--- |4.2
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-19 23:23 ---
Adding Roger as CC because this is a bug in regstack as far as I can tell.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-19 23:16 ---
*** Bug 29896 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 2006-11-19 23:16 ---
This is a dup of bug 27100.
*** This bug has been marked as a duplicate of 27100 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-19 23:14 ---
Reduced testcase:
struct filename_pool
{
struct holder
{
friend void intrusive_ptr_release(holder* p){}
};
friend void intrusive_ptr_release(holder*);
};
--
pinskia at gcc dot gnu dot org changed:
--- Comment #1 from tbm at cyrius dot com 2006-11-19 22:31 ---
Created an attachment (id=12648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12648&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29902
I get the following ICE with 4.2.0 20061116 with -fprefetch-loop-arrays:
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/g++ -c -O3
libjingle0.3-xmppclient.cpp [EMAIL PROTECTED]:~$
/usr/lib/gcc-snapshot/bin/g++ -c -O -fprefetch-loop-arrays
libjingle0.3-xmppclient.cpp
libjingle0
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-19 22:26 ---
I want to say the gen_insn part which exposed the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
--- Comment #1 from andreast at gcc dot gnu dot org 2006-11-19 22:13
---
Last working rev is 118744, the failure appears in 118746. But not clear why.
Andreas
--
andreast at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from dominiq at lps dot ens dot fr 2006-11-19 22:11 ---
Applied to snapshot 4.3-20061118 on OSX 10.3, seems ok for me too, thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-19
21:55 ---
Subject: Re: Shared libstdc++ fails to link
On Mon, Nov 13, 2006 at 02:37:02AM -, pinskia at gcc dot gnu dot org wrote:
> > This problem was introduced by this change:
> That makes less sense really,
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2006-11-19 21:30
---
Commited to mainline.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rakdver at gcc dot gnu dot org 2006-11-19 21:10
---
(In reply to comment #9)
> Created an attachment (id=12643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12643&action=view) [edit]
> New patch, the old one could cause a seg fault also during bootstrap
>
>
--- Comment #10 from tbm at cyrius dot com 2006-11-19 21:09 ---
(In reply to comment #9)
> That would fix it perfectly fine, i'll bootstrap and test it.
ping
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22415
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-19 21:01 ---
regstack is broken.
Before:
(insn:TI 70 69 71 3 (set (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(plus:SF (reg:SF 13 st(5) [orig:80 pretmp.77 ] [80])
(reg:SF 12 st(4) [orig:70 pretmp.92 ] [70])))
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-19 20:50 ---
the only thing fwprop does in this case is props the address.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-19 20:47 ---
This looks like a latent bug in regstack really, the dumps before regstack are
ok in that reg 11 is initialized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29900
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-19 20:46 ---
(In reply to comment #0)
> but:
>
> the same address as an object of a different type, unless the
> types are almost the same. For example, an `unsigned int' can
> alias an `int', but not a `void*'
--- Comment #9 from tkoenig at gcc dot gnu dot org 2006-11-19 20:42 ---
Created an attachment (id=12646)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12646&action=view)
Latest update
Here's the latest update of the patch, for reading, writing and
backspace.
In order to be able t
$ gcc -Wstrict-aliasing -fstrict-aliasing -c test.c
test.c: In function f1:
test.c:2: warning: dereferencing type-punned pointer will break strict-aliasing
rules
$ cat test.c
void f2(char **p);
void f1(unsigned char *bits) { f2((char **)&bits); };
$
but:
the same address as an object of
--- Comment #2 from hjl at lucon dot org 2006-11-19 20:35 ---
Created an attachment (id=12645)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12645&action=view)
RTL stack dump
I am using:
gcc version 4.3.0 20061115 (experimental) [trunk revision 118860]
RTL stack dump still shows
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-19 20:21 ---
I think this was already fixed via:
2006-11-14 Paolo Bonzini <[EMAIL PROTECTED]>
PR rtl-optimization/29798
* fwprop.c (use_killed_between): Check that DEF_INSN dominates
TARGET_INSN before
--- Comment #13 from danglin at gcc dot gnu dot org 2006-11-19 20:11
---
Fixed by patch.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Statu
This patch
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00141.html
triggers uninitialized read of stack register on x86. The testcase is
# cat foo.f90
MODULE foo
CONTAINS
SUBROUTINE SWPARA(IU, JU, IIL, JJL, XI, YJ, XALB, kts,kte)
INTEGER, INTENT(IN ) :: kts,kte
INTEGER, IN
--- Comment #12 from danglin at gcc dot gnu dot org 2006-11-19 19:09
---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 19:09:04 2006
New Revision: 118996
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118996
Log:
PR target/29114
* pa.c (emit_move_sequence)
--- Comment #11 from danglin at gcc dot gnu dot org 2006-11-19 19:06
---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 19:06:09 2006
New Revision: 118995
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118995
Log:
PR target/29114
* pa.c (emit_move_sequence)
--- Comment #10 from danglin at gcc dot gnu dot org 2006-11-19 18:27
---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 18:27:03 2006
New Revision: 118994
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118994
Log:
PR target/29114
* pa.c (emit_move_sequence)
--- Comment #9 from danglin at gcc dot gnu dot org 2006-11-19 18:24 ---
Subject: Bug 29114
Author: danglin
Date: Sun Nov 19 18:24:21 2006
New Revision: 118993
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118993
Log:
PR target/29114
* pa.c (emit_move_sequence):
--- Comment #6 from burnus at gcc dot gnu dot org 2006-11-19 18:19 ---
I though I had replyed to my last comment, but seemingly I forget to "Commit"
the comment.
I tested with de and zh_TW (Zhonghua/Taiwan alias Guoyu) locale and the result
is ok. [Well, in Chinese it least it looks as i
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-11-19 18:01 ---
Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|
Hello,
I work for a long time on a programming language and it is written in C, F77
and F90. I can build this code with all release of gcc/gfortran before the
4.1.x.
I have tried to found a bug in my code without any success, thus, I write this
bug report.
Test program:
schroedinger:[~/test] > gc
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-19 16:18 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-11-19 16:16 ---
Fixed on 4.1 and 4.2 branches.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-11-19 16:16 ---
Subject: Bug 29753
Author: rguenth
Date: Sun Nov 19 16:15:47 2006
New Revision: 118990
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118990
Log:
2006-11-19 Richard Guenther <[EMAIL PROTECTED]>
Ba
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-19 16:15 ---
Subject: Bug 29753
Author: rguenth
Date: Sun Nov 19 16:14:49 2006
New Revision: 118989
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118989
Log:
2006-11-19 Richard Guenther <[EMAIL PROTECTED]>
Ba
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-11-19 16:11 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from steven at gcc dot gnu dot org 2006-11-19 16:10 ---
The best way to reduce this test case is to use
--param ggc-min-expand=0 -- param gcc-min-heapsize=0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-11-19 16:09 ---
Subject: Bug 2
Author: rguenth
Date: Sun Nov 19 16:09:19 2006
New Revision: 118988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118988
Log:
2006-11-19 Richard Guenther <[EMAIL PROTECTED]>
Ba
--- Comment #11 from bonzini at gnu dot org 2006-11-19 15:52 ---
thanks, this patch seems ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29879
--- Comment #2 from pcarlini at suse dot de 2006-11-19 15:12 ---
PS: per the letter of TR1, the new hashing facilities in TR1 also miss
specializations of struct hash for long long and unsigned long long, I'm going
to add those, as a reasonable extension (anyway, long long is already acc
--- Comment #1 from pcarlini at suse dot de 2006-11-19 15:06 ---
Hi Gerald. The libstdc++ project already decided to not work anymore on the
legacy ext/ containers (beyond serious bugs affecting existing facilities,
maybe), because these days there is no reason to not move to the unorder
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-11-19 14:59 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2006-11-19 14:58
---
Working on this
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Assig
The following program fails to compile with every version of GCC 4.x I
tested (including current mainline) with
error: no match for call to '(const __gnu_cxx::hash) (const
long
long int&)'
snip
#include
using namespace __gnu_cxx;
typedef long long T;
void f() {
ha
In gcc/config/sh/symbian.c there is this code:
warning (0, "%s %q+D %s after being referenced with dllimport linkage",
TREE_CODE (decl) == VAR_DECL ? "variable" : "function",
decl, (DECL_INITIAL (decl) || !DECL_EXTERNAL (decl))
? "defined locally"
--- Comment #3 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** Bug 29894 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** This bug has been marked as a duplicate of 29896 ***
--
baraclese at googlemail dot com changed:
What|Removed |Added
---
--- Comment #2 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** Bug 29893 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 14:02
---
*** This bug has been marked as a duplicate of 29896 ***
--
baraclese at googlemail dot com changed:
What|Removed |Added
---
--- Comment #1 from baraclese at googlemail dot com 2006-11-19 13:54
---
since source is too large (~1.7MB) to attach i uploaded it for your
convenience, please download it from here:
http://oscc.sourceforge.net/compiler.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29896
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at lin
--- Comment #10 from belyshev at depni dot sinp dot msu dot ru 2006-11-19
13:41 ---
*** Bug 29895 has been marked as a duplicate of this bug. ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
---
--- Comment #2 from belyshev at depni dot sinp dot msu dot ru 2006-11-19
13:41 ---
*** This bug has been marked as a duplicate of 29879 ***
--
belyshev at depni dot sinp dot msu dot ru changed:
What|Removed |Added
---
--- Comment #1 from dcb314 at hotmail dot com 2006-11-19 13:37 ---
Created an attachment (id=12644)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12644&action=view)
C source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29895
I just tried to compile Linux kernel version 2.6.18.2
with gcc-4.3-20061118 snapshot on a x86_64 box.
The compiler said
/home/dcb/gnu/43-20061118/results/bin/gcc -g -O3 -Wall -march=opteron
-Wp,-MD,arch/x86_64/lib/.csum-partial.o.d -nostdinc -isystem
/home/dcb/gnu/43-20061118/results/lib/gcc/x
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at lin
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-11-19 12:51
---
I need to do the same for array bounds checking, to identify the cases where no
name is provided and see what we can do about it.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
Depending on the compilation flags the same ice will trigger at different
times, but I know which code line causes this, however I have not been
successful at reducing the bug. Possibly with smaller source, the bug won't
show up.
The bug seems to be triggered in class filename_pool which is at lin
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-11-19 12:14
---
The problem is that the division is in no ways special to optimizers. One
possibility I see would be to introduce either a builtin function or a new
tree-code to access the exception flags. Of course the fact tha
see also: http://gcc.gnu.org/ml/fortran/2006-11/msg00511.html
With -fbounds-check, an error message is shown if the character substrings
exceed the size of the variable. This error message contains also the name of
the variable, but this piece of information is not always passed to
gfc_conv_substr
--- Comment #18 from kreckel at ginac dot de 2006-11-19 11:22 ---
An idea: Would it help if feholdexcept, fetestexcept and all those standard
functions accessing the status and control flags were implemented as builtins,
not as extern libcalls?
This probably wouldn't help against elimin
--- Comment #2 from Jean-pierre dot vial at wanadoo dot fr 2006-11-19
08:55 ---
(In reply to comment #1)
> This is a bug in your instation of GMP/MPFR. It is causing gfortran to crash.
>
No, I found the explanation, it has nothing to do with gmp:
it is a parallelism problem in the mak
72 matches
Mail list logo
