--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
06:13 ---
Subject: Bug 23119
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-14 06:13:30
Modified files:
gcc/testsuite : ChangeLog
Take the following code:
struct f
{
int i;
int j;
};
void g(void);
void i(struct f*);
int kk(void)
{
struct f a;
int j;
a.i = 1;
a.j =2 ;
g();
j = a.i;
i(a);
return j;
}
---
j should be changed to 1 as the address of a is not escape until after the call
to i so g should not
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
06:17 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
06:28 ---
Subject: Bug 23320
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-14 06:28:03
Modified files:
gcc: ChangeLog tree-data-ref.c
Log
--- Additional Comments From guillaume dot melquiond at ens-lyon dot fr
2005-08-14 06:45 ---
Looking at it again, I found an even worse regression with respect to g++ 3.4.
Consider this testcase:
struct A { int a[1000]; }
A f();
void g(A);
void h() { g(f()); }
Ideally, h will allocate
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-08-14 07:29 ---
I don't know why you say that MingW claims to have a HAVE_TIMES. It doesn't.
To get process times on mingw we need to use the win32api function
GetProcessTimes. This is available on NT4
--- Additional Comments From edunlop at utvinternet dot ie 2005-08-14
09:41 ---
Subject: RE: [mingw32] cpu_time intrinsic malfunction
Danny
I would consider your suggestion very acceptable - it is obviously not 100%
but would sort the problem for many users, including myself. Thank
Hello,
All versions of gcc I tried (2.95.3, 3.3.6, 3.4.4, 4.0-20050811, and
4.1-20050813) accept this code without any warnings or errors (using -ansi
-pedantic -Wall -W, just in case)
templatetypename T
class A {
struct helper { typedef T type; };
friend class helper::type;
};
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
11:36 ---
GCC tries to unroll and expand this insn:
(insn 28 26 30 2 (set (reg/v:V2SI 65 [ sum ])
(plus:V2SI (reg/v:V2SI 65 [ sum ])
(reg/v:V2SI 68 [ ref1 ]))) 1023 {mmx_addv2si3} (nil)
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
11:40 ---
My uneducated guess is that expand_binop can't find an appropriate obtab.
That means that this problem is target specific (e.g. missing named pattern).
--
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
12:22 ---
From config/i386/mmx.md:
;; Note! Except for the basic move instructions, *all* of these
;; patterns are outside the normal optabs namespace. This is because
;; use of these registers requires the
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
12:26 ---
There is a patch t fix the issue mentioned in that mmx.md comment, see
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01128.html
--
What|Removed |Added
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-14 12:40
---
(In reply to comment #2)
Confirmed.
This is really pr15966, although this latter has been marked as being resolved.
Feng Wang's patch allowed arrays to be used as internal units when there is no
editing
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
12:55 ---
This patch is a bit paradoxical: There is an insn that we want to expand in
the unroller, so we know that have_insn_for *should* return true if the MD is
sane. But the MD can't be sane for an insane ISA
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
13:57 ---
Ouch. This badly needs reducing...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23378
--- Additional Comments From dorit at il dot ibm dot com 2005-08-14 14:00
---
patch: http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00826.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
14:03 ---
Fixed
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
14:06 ---
I think this is related to PR 23302 and PR 23303 since those look like they
were caused by the same
patch.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
14:22 ---
I think this is a dup of bug 21498 but I don't time to double check.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23385
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
14:27 ---
Subject: Bug 23360
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-14 14:26:51
Modified files:
gcc: ChangeLog
gcc/config/i386:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
14:29 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-14
15:16 ---
These days, this bug manifests itself on mainline regularly as:
FAIL: 3.10.2-round-6
in the Jacks testsuite.
--
What|Removed |Added
20050814 (experimental) (hppa-linux)
compiled by GNU C version 4.1.0 20050814 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
options passed: -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -iprefix
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
15:40 ---
This effects all 32bit targets it seems.
See also http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00831.html which is what
I reported about
which patch caused it.
--
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-14
15:48 ---
Smaller test case:
=
typedef struct {
char **visbuf;
char **allbuf;
} TScreen;
void
VTallocbuf(TScreen *screen, unsigned long savelines)
{
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
15:50 ---
Compiling bitmap.c at -O0 make bootstrap past this point.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-08-14
15:50 ---
Updated patch for Part 2 posted in:
http://gcc.gnu.org/ml/java-patches/2005-q3/msg00195.html
--
What|Removed |Added
--
What|Removed |Added
Component|middle-end |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
--- Additional Comments From tobi at gcc dot gnu dot org 2005-08-14 15:53
---
An alternative approach to setting up a temporary in the caller would be to have
pointer-valued functions use a fake result variable, which only immediately
before returning gets assigned to the real result.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
15:53 ---
(In reply to comment #2)
Compiling bitmap.c at -O0 make bootstrap past this point.
On ppc-darwin that is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23386
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
16:15 ---
Subject: Bug 21432
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-14 16:15:46
Modified files:
gcc/fortran: io.c ChangeLog
--- Additional Comments From fn_x at hotmail dot com 2005-08-14 16:48
---
Yeah, this is just slightly different code, but it is covered by that bug's
summary and description. Sorry for the noise.
*** This bug has been marked as a duplicate of 21498 ***
--
What|Removed
--- Additional Comments From fn_x at hotmail dot com 2005-08-14 16:48
---
*** Bug 23385 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From kargl at gcc dot gnu dot org 2005-08-14 16:48
---
(In reply to comment #3)
I don't know why you say that MingW claims to have a HAVE_TIMES.
It doesn't.
Read the code for __cpu_time_1. The only way that cpu_time can return
zero is if HAVE_TIMES is
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:16 ---
Confirmed now, testcase:
typedef unsigned long BITMAP_WORD;
typedef struct bitmap_element_def
{
struct bitmap_element_def *next;
struct bitmap_element_def *prev;
unsigned int indx;
BITMAP_WORD
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:18 ---
We get:
ix_14: [0, 3] EQUIVALENCES: { } (0 elements)
which is wrong as it should be the union of [0,3] and [-1,-1].
so we are folding:
Folding predicate ix_14 != 4294967295 to 1
--
What
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:32 ---
Here is something which is a little more reduced:
int f[100];
int g[100];
unsigned char
f1 (int a, int b)
{
unsigned ix;
if (a == b)
return 1;
for (ix = 4; ix--;)
if (f[ix] != g[ix])
On Sun, 2005-08-14 at 17:32 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
17:32 ---
Here is something which is a little more reduced:
int f[100];
int g[100];
unsigned char
f1 (int a, int b)
{
unsigned ix;
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-14
17:57 ---
Subject: Re: [4.1 Regression] bitmap.c is
being miscompiled (VRP)
On Sun, 2005-08-14 at 17:32 +, pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu
Today seems that I am stupid , but I can not find process difference
between
function raw_to_ull1 and raw_to_ull_11, if you can see the difference
this is not a bug.
/*
Output:
ull.bit_6 = *(raw + len - 2) = #
ull.bit_7 = *(raw + len - 1) = (
---llu=8960
ull.bit_7 = *(raw + len - 1) = (
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
18:02 ---
Here is a testcase which also fail on 64bit targets too:
int f[100];
int g[100];
unsigned char
f1 (int a, int b)
{
__SIZE_TYPE__ ix;
if (a)
return 1;
for (ix = 4; ix--;)
if (f[ix] != g[ix])
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
18:45 ---
Subject: Bug 21432
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-14 18:45:42
Modified files:
gcc/fortran: io.c
--- Additional Comments From buytenh at wantstofly dot org 2005-08-14
18:53 ---
doko's patch triggers PR23256. gcc 3.3.3 on armeb appears to miscompile itself
when SUBTARGET_CPU_DEFAULT is TARGET_CPU_arm6, but with TARGET_CPU_arm7tdmi it
all works fine.
I know the 3.3.x branch is
--- Additional Comments From buytenh at wantstofly dot org 2005-08-14
18:53 ---
Seemingly triggered by http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12527#c21
gcc 3.3.3 on armeb appears to miscompile itself when SUBTARGET_CPU_DEFAULT is
TARGET_CPU_arm6, but with TARGET_CPU_arm7tdmi it all
This PR is a placeholder for known limitations regarding the weak support
of the HP PA_RISC target under HP-UX 11 and later. This support is available
in GCC 3.3 and later.
Weak support on this target is implemented using SOM secondary definition
(sdef) symbols. While sdef symbols have some of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
19:00 ---
It works with 4.0.2 20050802 so this is a 4.1 regression for sure.
--
What|Removed |Added
Compiling the following short test code with '-frepo' switch on triggers a
segfault in Debian Sid's current gcc-4.0.
--test.cpp-
class A
{
};
void foo()
{
do
{
throw new A;
} while (0);
}
--- Additional Comments From roger at eyesopen dot com 2005-08-14 19:17
---
Hi James,
Unfortunately, there are a few mistakes in your proposed patch for PR21137.
Firstly Kazu's proposed transformation is only valid when the results of the
bitwise-AND are being tested for equality or
--- Additional Comments From g dot u dot g dot i at gmx dot de 2005-08-14
19:20 ---
Sorry, forgot gcc -v output:
[EMAIL PROTECTED]:~/tmp/gccbug$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
19:22 ---
*** Bug 23388 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-14
19:22 ---
This has already been fixed in 4.0.2.
This is a dup of bug 22204.
I think Debian should be updating to 4.0.2 soon.
*** This bug has been marked as a duplicate of 22204 ***
*** This bug has been marked as
--- Additional Comments From dirtyepic dot sk at gmail dot com 2005-08-14
19:24 ---
since this is marked critical i want to make sure it doesn't fall between the
cracks. this patch still applies cleanly to the 4.0 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21254
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
19:24 ---
Subject: Bug 22615
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-14 19:23:57
Modified files:
gcc: ChangeLog tree-ssa-structalias.c
--- Additional Comments From pault at gcc dot gnu dot org 2005-08-14 19:30
---
Fixed on mainline and 4.02
There's just the documentation to do, now.
Paul T
--
What|Removed |Added
--- Additional Comments From tg42 at gmx dot de 2005-08-14 19:40 ---
Meanwhile, i compiled the simd tests with gcc 4.0.1. It compiles them
correctly, i. e. the tests run successfully. It, again, uses the
movaps instruction, as does gcc 3.3.6 and unlike 3.4.4.
Since all these tests
In parent generic declare
type Type_T () is tagged private;
and complete it in the private part.
In generic child unit declare
subtype Subtype_T is One.Type_T;
Then try to use the subtype even with initialization
I2a : Twoo.Subtype_T := Twoo.Init;
and the compiler says: three.2.ada:15:37:
--- Additional Comments From dannysmith at users dot sourceforge dot net
2005-08-14 20:56 ---
From my libgfortran/config.h, configured with --host=mingw32 --target=mingw32
and mingw runtime as distributed by mingw.org
/* Define to 1 if you have the `getrusage' function. */
/* #undef
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-14
20:58 ---
Fixed
--
What|Removed |Added
Status|NEW |RESOLVED
Unit one.1.ada should not have compiled. RM 3.9.3(10.
For an abstract type declared in a visible part, an abstract
primitive subprogram shall not be declared in the private part, unless
it is overriding an abstract subprogram implicitly declared in the
visible part.
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-08-14
21:39 ---
If HAVE_MMAP is undefined, then the test case gets to
should not get here, so this is buggy as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23321
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
21:43 ---
Subject: Bug 21432
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-08-14 21:43:14
Modified files:
gcc/fortran: gfortran.texi ChangeLog
Log
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-14
21:46 ---
Subject: Bug 21432
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-4_0-branch
Changes by: [EMAIL PROTECTED] 2005-08-14 21:46:52
Modified files:
gcc/fortran:
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-14
21:56 ---
Actually, doing (a c1) 2**c2 - (a (1c1+c2)) c1 looks worse, but
can be transformed into (a (1c1+c2)) CMP c3 c1. However, I haven't
figure out the details of the second transformation. There is a
--- Additional Comments From Tobias dot Schlueter at physik dot
uni-muenchen dot de 2005-08-14 22:02 ---
Subject: Re: MAXPATHLEN usage in fortran/{scanner,module}.c
Steve Kargl wrote:
The attached patches uses alloca to remove the use of PATH_MAX
from gfortran. It also fixes one
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
Test case:
==
void
foo (int N)
{
int C;
double R;
R = 0.0;
do
{
R += 0.001;
C = (int) (R * N);
if (-R * N = R * N)
{
C++;
}
}
while (C 0);
return;
}
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
00:01 ---
Confirmed, only -O1 is required to reproduce this.
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2005-08-15
00:05 ---
Note that part of the problem is that build_int_cst_type, which scev uses
here, should check that the type given to it is an integral type. That would
have caught the checking failure much earlier. Right
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
00:09 ---
This is related to PR 19899 which was fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23391
--- Additional Comments From sebastian dot pop at cri dot ensmp dot fr
2005-08-15 00:34 ---
Subject: Re: [4.1 regression] Tree checking failure due to scev
This patch should fix the problem. There are some more cases that use
build_int_cst instead of build_real. I'll propose a more
--
What|Removed |Added
CC||mueller at kde dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17700
--- Additional Comments From mueller at kde dot org 2005-08-15 00:46
---
duplicate of #13685 ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15617
This PR is to record the following failures:
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-funroll-loops
-fgnu-runtime
FAIL: objc/execute/exceptions/foward-1.m execution, -O3 -fomit-frame-pointer
-funroll-all-loops
-finline-functions -fgnu-runtime
I have
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
01:56 ---
This fails at -O1 -frename-registers also.
We get a bus error.
In a way this almost be considered a regression as -frename-registers was
enabled at -funroll-loops.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
01:57 ---
PR 15023 is the bug for -frename-registers being broken.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
02:07 ---
Here is the backtrace:
#0 _Unwind_fallback_frame_state_for (context=0xb2cc, fs=0xb530) at
/Users/pinskia/src/
local3/gcc/gcc/config/rs6000/darwin-fallback.c:96
#1 0x000b90d4 in uw_frame_state_for
This PR is to record the following failures on x86_64-linux-gnu:
FAIL: objc/execute/exceptions/catchall-1.m execution, -Os -fgnu-runtime
FAIL: objc/execute/exceptions/finally-1.m execution, -Os -fgnu-runtime
--
Summary: catchall-1.m and finally-1.m fails at -Os
--
What|Removed |Added
Summary|objc/execute/exceptions/fowa|foward-1.m fails with -
|rd-1.m fails with -funroll- |funroll-loops -O3 -fgnu-
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-15
02:15 ---
Seen:
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00850.html
http://gcc.gnu.org/ml/gcc-testresults/2005-08/msg00821.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23393
--- Additional Comments From tausq at debian dot org 2005-08-15 05:31
---
Do I understand correctly that there are two distinct problems:
1) gcc should not be canonicalizing constants casted as function pointers
2) gcc should not generate relational comparisons against function
80 matches
Mail list logo
