--- Additional Comments From steven at gcc dot gnu dot org 2004-12-31
10:38 ---
Testing a patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17544
--- Additional Comments From pcarlini at suse dot de 2004-12-31 11:07
---
In my opinion, this is definitely a (target dependent) code generation bug,
rather serious, if confirmed. As such, we should do our best to reduce it
and recategorize in the right way. Any chance you can try to
--- Additional Comments From pcarlini at suse dot de 2004-12-31 11:10
---
I think we can definitely close this one: the various (configure) issues are
well
known and no fixes are needed anywhere.
--
What|Removed |Added
CVS source dated 2004-12-31, 04:00 MET, doesn't build on sparc-sun-solaris2.9.
Failure is in libfortran, relevant errors are:
xgcc: ../../../../gcc/libgfortran/generated/cshift1_4.c: No such file or
directory
xgcc: no input files
make[5]: *** [cshift1_4.lo] Error 1
make[4]: *** [all] Error 2
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-31
12:02 ---
(From update of attachment 7808)
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02140.html
--
What|Removed |Added
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-31
12:13 ---
I cannot reproduce this (it is monitored??).
I still think something like Andrew's patch is necessary,
but without a test case, well, how can we be sure??
--
What|Removed
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-31
12:45 ---
Why would this cause wrong code? It's just a cast from an enum to an int,
I don't see what's wrong with that except that it's ugly.
You have to actually show that this causes wrong code, not just make
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-31
13:15 ---
Not being able to build X is pretty critical.
--
What|Removed |Added
--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-12-31
13:23 ---
The 'typename' keyword is required because later C++ introduces a lot more
features. Those that interfere with your code are partial specialization
and specialization. For example, you can now have
--- Additional Comments From schwab at suse dot de 2004-12-31 13:32 ---
Test case (see also
http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01109.html):
struct X {
char *a;
/* other members */
int b;
};
void f (struct X *x)
{
x-a[x-b] = 0;
}
--
What
--
What|Removed |Added
CC||schwab at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19204
--
What|Removed |Added
CC||schwab at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19205
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
14:51 ---
(In reply to comment #2)
Why would this cause wrong code? It's just a cast from an enum to an int,
I don't see what's wrong with that except that it's ugly.
You have to actually show that this
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
14:56 ---
What were your configure options?
Could you attach the full build log?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19213
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
14:58 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From reichelt at gcc dot gnu dot org 2004-12-31
16:08 ---
I can still reproduce it with the above testcase:
gcc version 4.0.0 20041230 (experimental) on i686-pc-linux-gnu.
Maybe it is target dependant?
Did you try larger array sizes than 6?
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
16:10 ---
(In reply to comment #5)
I can still reproduce it with the above testcase:
gcc version 4.0.0 20041230 (experimental) on i686-pc-linux-gnu.
Maybe it is target dependant?
It is. You might have to use
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-31
16:24 ---
Subject: Bug 18701
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-31 16:24:48
Modified files:
gcc: ChangeLog combine.c
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-31
16:28 ---
Subject: Bug 18701
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-31 16:28:34
Modified files:
gcc: ChangeLog combine.c
Log message:
--- Additional Comments From hp at gcc dot gnu dot org 2004-12-31 16:33
---
URL:http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02151.html
--
What|Removed |Added
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 17:13
---
At this moment i can't extract simple testcase.
But problem indeed in miscompiletion.
I am use modified testcase (additionl debug output line before assert (and
iostream header include:
std::cout begin==
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 17:15
---
Created an attachment (id=7847)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7847action=view)
.ii file from gcc build object directory
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 17:16
---
Created an attachment (id=7848)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7848action=view)
.s compiled from basic_file.cc with default oprions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 17:17
---
Created an attachment (id=7849)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7849action=view)
.s compiled from basic_file.cc with -O2 (miscompiled version)
--
Compilation of the following short program dies with
Internal compiler error in dwarf2out_finish, at dwarf2out.c:12301
The bug disappears if NUM is replaced by int, even though
NUM is just a typedef for int
/* bug2.c */
/* Last edited on 2004-12-31 14:42:34 by stolfi */
typedef int NUM;
--- Additional Comments From stolfi at ic dot unicamp dot br 2004-12-31
17:40 ---
Created an attachment (id=7850)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7850action=view)
Preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19214
--- Additional Comments From stolfi at ic dot unicamp dot br 2004-12-31
17:41 ---
Created an attachment (id=7851)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7851action=view)
Assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19214
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
17:46 ---
Fixed already in 3.3. Yes I can reproduce it in 3.2.2.
--
What|Removed |Added
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 17:58
---
I extract problematic compiled (with -O2) function:
---8X-
#include bits/basic_file.h
#include fcntl.h
#include limits // For off_t::max() and min() and streamsize::max()
namespace
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 17:58
---
Created an attachment (id=7852)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7852action=view)
.s compiled from basic_file.cc with default oprions
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 17:59
---
Created an attachment (id=7853)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7853action=view)
.s compiled from basic_file.cc with -O2 (miscompiled version)
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
18:20 ---
Hmm, this is the reduced testcase but it was not miscompiled as far as I can
see:
typedef int __attribute__((__mode__(__DI__))) __int64_t;
typedef __int64_t int64_t;
typedef int64_t streamoff;
typedef
--- Additional Comments From pcarlini at suse dot de 2004-12-31 18:29
---
Andrew, this is *definitely* target dependent: it's about such a basic feature
that we would have noticed, otherwise! (btw, thanks for the reduced testcase!)
--
--- Additional Comments From wanderer at rsu dot ru 2004-12-31 18:39
---
This more simplifed version of your last testcase also catch -O2 problem:
#includecassert
typedef int __attribute__((__mode__(__DI__))) off_t;
static long long min() throw() { return -9223372036854775807LL - 1;
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
19:06 ---
Confirmed with your reduced testcase.
t21.dom1 is where the problem comes in.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
19:13 ---
(In reply to comment #19)
Confirmed with your reduced testcase.
t21.dom1 is where the problem comes in.
This also happens on i686-pc-linux. I think this is related to HWI being only
32bit as it works
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
19:15 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-12/msg02156.html.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2004-12-31 19:24
---
Yes, I can reproduce with the last testcase. Still, I can't with the original
one,
that explains why we haven't noticed yet... Thanks to everyone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
--- Additional Comments From pcarlini at suse dot de 2004-12-31 19:27
---
Ah, now I see: the problematic code path is actually used *only* when
_GLIBCXX_USE_LFS is not defined, whereas normally is defined, on linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19060
--- Additional Comments From dje at gcc dot gnu dot org 2004-12-31 19:38
---
Could we use/extend -ffinite-math-only option to cover this case and assert that
the loop will not be infinite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19210
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru
2004-12-31 19:38 ---
// C testcase
void abort (void);
static long long min ()
{
return -9223372036854775807LL - 1;
}
void foo (long long j)
{
if (j 10 || j min ())
abort ();
}
int main ()
{
foo (10);
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
19:40 ---
Note this is only reproducible with HWI being 32bit (x86 is an example but I
cannot think of another
one).
--
What|Removed |Added
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2004-12-31 20:36 ---
Subject: Re: [4.0 Regression] not using do-loop for some loops
Could we use/extend -ffinite-math-only option to cover this case and assert
that
the loop will not be infinite?
I
Gcc 4.0 checked at Fri Dec 31 12:18:14 PST 2004 failed to bootstrap
on x86_64-unknown-linux-gnu:
stage1/xgcc -Bstage1/ -B/usr/gcc-4.0/x86_64-unknown-linux-gnu/bin/ -c -g -
O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-
prototypes -pedantic -Wno-long-long
--- Additional Comments From hjl at lucon dot org 2004-12-31 20:41 ---
It failed to bootstrap on Linux/ia64 also:
/net/gnu/export/gnu/src/gcc/gcc/gcc/gimplify.c: In
function 'gimplify_asm_expr':
/net/gnu/export/gnu/src/gcc/gcc/gcc/gimplify.c:3347: internal compiler error:
Segmentation
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
20:51 ---
Like any real bug report, we need how you configured gcc, and the preprocessed
source.
--
What|Removed |Added
--- Additional Comments From hjl at lucon dot org 2004-12-31 21:52 ---
It is caused by
http://gcc.gnu.org/ml/gcc/2004-12/msg01271.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
22:06 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-31
22:08 ---
Subject: Bug 19211
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-31 22:07:48
Modified files:
gcc: ChangeLog
gcc/config :
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-31
22:25 ---
This is really a duplicate of 17924
*** This bug has been marked as a duplicate of 17924 ***
--
What|Removed |Added
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-31
22:25 ---
*** Bug 19191 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From dberlin at gcc dot gnu dot org 2004-12-31
22:46 ---
Okay.
What really happens here is that the blocks aren't getting marked properly
because we rearrange the block tree and then the used flags aren't set when the
subblocks of a block are used (which is what
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
22:46 ---
The patch which fixed this was reverted.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-31
22:47 ---
Fixed by reverting the patch which caused this.
--
What|Removed |Added
--
What|Removed |Added
Target Milestone|4.0.0 |---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2670
--- Additional Comments From amodra at bigpond dot net dot au 2004-12-31
23:15 ---
This is a problem with the gcc's function call machinery. The underlying
problem is that mem alignment of function args is taken from the type of the
arg, not the alignment given by
--- Additional Comments From rth at gcc dot gnu dot org 2004-12-31 23:30
---
I think that this sort of thing *ought* to work. How, exactly, to teach
cgraph to make it happen is perhaps tricky...
--
What|Removed |Added
--- Additional Comments From dje at gcc dot gnu dot org 2004-12-31 23:55
---
XLC includes the option
strict_induction
Turns off induction variable optimizations
that have the potential to alter the semantics of a
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-01 00:21
---
When references are involved, like this, reduction to MAX_EXPR is wrong to
begin with. The cast is only an additional symptom.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rth at gcc dot gnu dot org
|dot org |
Status|NEW
--- Additional Comments From gschafer at zip dot com dot au 2005-01-01
01:18 ---
I've just hit this while trying to build Glibc with current GCC trunk. It's a
showstopper.
--
What|Removed |Added
--- Additional Comments From max656 at hotmail dot com 2005-01-01 01:37
---
Subject: RE: friend funtion inside a template class seems to have a probl
Hi lerdsuwa
You came up with an interesting topic - class template specializtion.
I didn't know aboou it. I need further research on
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-01
01:43 ---
Subject: Bug 17799
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-01 01:43:13
Modified files:
gcc: ChangeLog c-decl.c dwarf2asm.c
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-01 01:45
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From bdavis at gcc dot gnu dot org 2005-01-01
02:14 ---
re-patch:
http://gcc.gnu.org/ml/fortran/2005-01/msg4.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18778
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-01
02:38 ---
Subject: Bug 19042
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-01 02:38:06
Modified files:
gcc: ChangeLog tree-sra.c
Log message:
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-01 02:42
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From mj1 at cog dot brown dot edu 2005-01-01 02:53
---
Subject: Re: 3.4 default memory allocator much slower
than 3.3 allocator when large amounts of data are turned over
Yes, although you might want to revert to the 3.3 default allocator, as
the 3.4 default
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19042
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-01
03:17 ---
Just to further followup, the change between 3.4 and 4.0 in regard to what the
abstract origin of of the block is set to is because of the inliner for java
code that was made the default in 4.0.
So if it is
This is from FM923.FOR
$ cat b.f
INTEGER J1I(3)
DATA J1I / 3,2,1 /
WRITE(20,'(A)')'/ 10 20 30'
WRITE(20,'(A)')'1 2 3 4'
WRITE(20,'(A)')'5 6 7 8'
REWIND(20)
READ(20,*) (J1I(IVI), IVI=1,3)
PRINT*,(J1I(IVI), IVI=1,3)
READ(20,*) I,J
--
What|Removed |Added
Summary|formatted read with leading |list directed read with
|slash |leading slash
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01
03:42 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From aj at gcc dot gnu dot org 2005-01-01 06:36
---
Raise priority since this hits glibc.
--
What|Removed |Added
Priority|P2
-Wchar-subscripts -version -fmessage-length=0 -fno-strict-aliasing -o
splinesave.s
GNU C version 4.0.0 20041231 (experimental) (SUSE Linux) (i586-suse-linux)
compiled by GNU C version 4.0.0 20041231 (experimental) (SUSE Linux).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min
--- Additional Comments From aj at gcc dot gnu dot org 2005-01-01 06:56
---
Created an attachment (id=7857)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7857action=view)
Preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19217
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From amodra at bigpond dot net dot au 2005-01-01
07:17 ---
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00014.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01
07:28 ---
Confirmed, reduced testcase:
void flexto(int *current,int instance_count)
{
int *end, temp, j;
for ( j=0; jinstance_count; ++j )
end = temp;
*current = *end;
}
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01
07:38 ---
(In reply to comment #2)
Confirmed, reduced testcase:
void flexto(int *current,int instance_count)
{
int *end, temp, j;
for ( j=0; jinstance_count; ++j )
end = temp;
*current = *end;
}
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01
07:53 ---
(In reply to comment #3)
One more note, this does not happen on the tcb but that is because we call dce
after the first ccp and
before the next may_alias.
--
82 matches
Mail list logo
