--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-07
08:48 ---
g77 can do this:
$ cat dosfile.f
write(10,'(2A)') '1',achar(13)
rewind(10)
read (10,*) n
print *,n
end
$ g77 dosfile.f
$ ./a.out
1
$ g77 -v
Reading specs from /usr/lib/gcc
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
09:28 ---
Subject: Bug 19796
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 09:27:48
Modified files:
gcc: ChangeLog
gcc/config/mips: i
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-02-07
09:33 ---
Sigh. Obviously the sys/fpu.h thing isn't as portable as I'd thought.
I wondered why your 4.0 reports had suddendly dropped off...
I have seen this technique mentioned on various web pages,
so I'd be inte
--- Additional Comments From giovannibajo at libero dot it 2005-02-07
10:37 ---
Jakub, it looks like you applied the patch only to 3.4. Can you apply it to
mainline and 3.3 too so that we can close this regression?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18384
--- Additional Comments From giovannibajo at libero dot it 2005-02-07
10:40 ---
Reconfirmed. I see this failure many times in boost logs.
--
What|Removed |Added
Last recon
--- Additional Comments From amodra at bigpond dot net dot au 2005-02-07
11:28 ---
Note that if you declare __builtin_printf and __builtin_puts with
__attribute__((__longcall__)) as well as printf and puts, you will get the
behaviour you expect.
The following patch also works, but I'm u
--- Additional Comments From rmathew at gcc dot gnu dot org 2005-02-07
13:06 ---
The simplest testcase that reproduces this bug with
the current mainline is:
class Foo
{
void bar()
{
int a;
int i;
for(i=a;;);
}
}
If the "int i" is removed and the for loop
is changed t
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
13:24 ---
Subject: Bug 19775
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 13:24:38
Modified files:
gcc: ChangeLog builtins.c
gcc/tes
--- Additional Comments From rguenth at tat dot physik dot uni-tuebingen
dot de 2005-02-07 13:25 ---
Fixed.
--
What|Removed |Added
Status|NEW
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-07
13:33 ---
(Unreviewed) patch here:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00156.html
--
What|Removed |Added
--
gcc version 4.0.0 20050110 (experimental) - from Debian 'gcc-snapshot' package.
[Thread model: posix. I doubt configure flags are important here.]
gcc produces quite poor code when initialising a stack char[] to an empty
string.
This is at any optimisation level, including -Os.
extern void fo
--- Additional Comments From Thomas dot Koenig at online dot de 2005-02-07
14:03 ---
Things are strange on IA-64.
I played around a bit with different optimization levels
for xeigtstd with ded.in as input file. I compiled everything
at -O1 and -O3, and then tried replacing single objec
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-07
14:19 ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00243.html
depends on __builtin_powi (PR19402).
--
What|Removed |Added
--
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-07
14:43 ---
The missed folding of &x.foo[2] - 4B is again due to different representation
of array refs for C and C++. A C testcase is folded, a C++ not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-07 15:10
---
Can you compile those tests with -fdump-tree-original and look at the
.t02.original dump to determine what functions the C frontend calls, and what
functions the Fortran frontend calls?
--
What
--- Additional Comments From tobi at gcc dot gnu dot org 2005-02-07 15:12
---
ps it seems that you'll have to use the -fdump-tree-gimple flag for C and look
at the .t08.gimple dump to get something readable.
On i686-pc-linux the C code calls log10, whereas the Fortran code calls
__buitl
Fails with (most recent) "Mon Feb 7 13:27:26 UTC 2005".
Passes with my latest checkouts on 3.3 (around May 21 2004)
and 3.4 (around Apr 22 2004) branches, hence a regression.
The message in gcc.log is:
Executing on host: /home/hp/cvs_areas/combined/cris-regobj/gcc/xgcc
-B/home/hp/cvs_areas/comb
--- Additional Comments From hp at gcc dot gnu dot org 2005-02-07 15:30
---
(BTW, the regression isn't all that new.)
--
What|Removed |Added
OtherBugsDependingO|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
15:32 ---
Most likely you forgot to copy the decl around for the new rtx symbol.
This is what happened for darwin and cygwin too. Both were fixed by keeping
around the decl.
--
http://gcc.gnu.org/bugzilla/show_
PR19639 is pessimized by (?)
extern void link_error(void);
int main(void)
{
int a[4];
if (&a[2]-1 != &a[1])
link_error();
return 0;
}
where for C++ (!!) we do not fold the addition of ADDR_EXPR (ARRAY_REF (..))
and INTEGER_CST into the ARRAY_REF offset. For C the frontend avoids
passi
--
What|Removed |Added
BugsThisDependsOn||19807
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19639
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-07
17:22 ---
Split that missed &x.foo[2] - 4B folding out to PR19807.
--
What|Removed |Added
BugsThisDep
--
What|Removed |Added
OtherBugsDependingO|19639 |
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19807
--
What|Removed |Added
OtherBugsDependingO||19639
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19807
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-02-07
17:25 ---
It seems the new (and old?) bugzilla doesn't check up-to-date-ness of the bug
wrt changes of just "depends on". Re-added 19807.
--
What|Removed |Added
--
I just ran into bogus code similar to the following.
(The code is bogus, not GCC, but I believe GCC could have helped.)
// main.cc
#include
struct A
{
A(int x) : x(x) {};
int call_me() { return x; }
int x;
};
struct B
{
B(A* a) : i(the_a->call_me()), the_a(a) {}
int i;
A* the_a;
}
This report is based on <[EMAIL PROTECTED]>
given this testcase:
#include
template
struct n{
friend void foo(){
std::cerr << i << std::endl;;
}
};
int main(){
n<1> n1;
n<2> n2;
n<3> n3;
foo();
}
there must be a bug here, though I'm not sure what exactly it is.
a) it could be a
--
What|Removed |Added
Keywords||alias
Last reconfirmed|-00-00 00:00:00 |2005-02-07 18:53:37
date|
--- Additional Comments From giovannibajo at libero dot it 2005-02-07
18:56 ---
Thomas, can you try if -O1 also produces wrong-code? Also can you try to
selectively disable tree optimizations (-fno-tree-this, -fno-tree-that) and see
if you find out which optimizer is triggering the mis
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
19:00 ---
Another testcase this time for loads:
#include
int i;
void bar(void)
{
i = 42;
}
int foo(int * p)
{
int i = *p;
bar ();
return *p + i;/* This load is dead with -fargument-noalias-global. */
}
in
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-02-07
19:04 ---
Daniel Berlin's patch is OK, please apply.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19327
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-02-07
19:06 ---
Eric was the one who posted a patch a
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01081.html
:)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19327
>From this code fragment:
class Confuse {
public static void main (String[] bob)
{
boolean jim;
jim=wtf(true);
System.out.print("Calling wtf(true):");
System.out.println(jim);
jim=wtf(false);
--- Additional Comments From tromey at gcc dot gnu dot org 2005-02-07
19:21 ---
This also affects 3.3.
The code for the wtf() method forgets to call the finally handler:
0: iload_0
1: ifeq 7
4: iconst_1
5: ireturn
6: pop
7: iconst_0
8: ireturn
--
What|Re
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
19:30 ---
Confirmed.
--
What|Removed |Added
CC||pinskia at
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
19:33 ---
It is also a 3.4 regression too:
: Search converges between 2003-06-19-trunk (#269) and 2003-06-20-trunk (#270).
--
What|Removed |Added
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
19:33 ---
Subject: Bug 19327
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 19:32:59
Modified files:
gcc: ChangeLog dbxout.c
Log message:
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-07
19:35 ---
> Eric was the one who posted a patch a
> http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01081.html
> :)
I don't mind being confused with you. :-)
--
What|Removed |Added
--- Additional Comments From giovannibajo at libero dot it 2005-02-07
19:46 ---
My understanding is that this should create one definition *per* instantiation
so there is an ODR conflict if the signatures match. Notice that it is still
useful to do something as:
template
struct A {
g++ crashes on the (invalid) code below:
$ g++ -c x.cc
x.cc: In function 'void foo(void*)':
x.cc:4: error: invalid use of undefined type 'struct C'
x.cc:1: error: forward declaration of 'struct C'
x.cc:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preproces
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
20:15 ---
: Search converges between 2004-07-12-trunk (#484) and 2004-07-13-trunk (#485).
Confirmed.
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
20:17 ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> Really TREE_OVERFLOW/TREE_CONSTANT_OVERFLOW should go away, there has been
> some talk
about
> removing them. on the tre
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
20:20 ---
Subject: Bug 19611
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 20:20:02
Modified files:
libjava: ChangeLog Makefile.am Makefile.in
L
--- Additional Comments From tromey at gcc dot gnu dot org 2005-02-07
20:27 ---
I checked in a patch for this.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
20:34 ---
Subject: Bug 11740
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 20:34:18
Modified files:
libjava: ChangeLog
libjava/gnu/java/n
--- Additional Comments From craig dot powers at gmail dot com 2005-02-07
20:48 ---
The specific problem statement appears to be line 1799/1801 in
gfc_simplify_bound:
return gfc_copy_expr (as->upper[i-1]);
or
return gfc_copy_expr (as->lower[i-1]);
The problematic execution s
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
21:12 ---
Subject: Bug 19803
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 21:11:45
Modified files:
gcc: ChangeLog predict.c
Log message:
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
21:18 ---
Subject: Bug 19803
CVSROOT:/cvs/gcc
Module name:gcc
Branch: gcc-3_4-branch
Changes by: [EMAIL PROTECTED] 2005-02-07 21:18:33
Modified files:
gcc: Change
--- Additional Comments From amodra at bigpond dot net dot au 2005-02-07
21:23 ---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From bangerth at dealii dot org 2005-02-07 21:53
---
Confirmed. We should get a warning for this code, but don't:
--
struct S
{
int i, j;
S() : i(j), j(1) {}
};
S s;
---
W.
--
What|Remo
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
21:56 ---
This is related to PR 2972 and PR 18016.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
G++ 3.4.x ICEs on:
extern double foo (double);
template
struct A
{
T y () const;
};
typedef A B;
template
struct C
{
C ();
B c;
float r;
};
template
C::C ()
{
r = foo (c.y);
}
3.2.x accepted this and CVS HEAD issues
error: not enough type information
--
Summary: ICE
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
22:03 ---
: Search converges between 2003-07-08-trunk (#288) and 2003-07-09-trunk (#289).
This is a duplicate of bug 18445.
*** This bug has been marked as a duplicate of 18445 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
22:03 ---
*** Bug 19812 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
22:05 ---
Confirmed.
--
What|Removed |Added
Severity|minor |enhancemen
--- Additional Comments From david dot billinghurst at comalco dot riotinto
dot com dot au 2005-02-07 22:33 ---
Subject: RE: [4.0 Regression] Bootstrap fails: Unresolved data symbol
"set_fpc_csr"
Thanks Richard. I don't know what is different about my system either.
Happy to follow u
--- Additional Comments From joel at oarcorp dot com 2005-02-07 22:41
---
Subject: Re: gnat tools not buildable cross
laurent at guerby dot net wrote:
> --- Additional Comments From laurent at guerby dot net 2005-02-06 10:02
> ---
> (In reply to comment #19)
>
> Nathanel I c
--- Additional Comments From laurent at guerby dot net 2005-02-07 22:52
---
Nathanael patch is not in CVS, as mentionned on RTEMSAda wiki
http://www.rtems.com/phpwiki/index.php/RTEMSAda
A few things you may have missed:
1. configure for target "powerpc-rtems" and no variation allowed
(
--- Additional Comments From gerald at pfeifer dot com 2005-02-07 23:09
---
I had done extensive benchmarks around New Year, based on Steven's request in
comment #41. Unfortunately I lost most of that data directly before posting
it here and couldn't repeat everything, but coincidently
I'm getting a segfault on what I believe to be valid code using gcc 4.0 but not
when using gcc 3.4 or 3.3. I've reduced this situation down to a relatively
short testcase file, details follow.
testcase.cc:
"""
#include
#include
#include
using namespace std;
struct ltstr
{
bool operator()(co
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-02-07
23:11 ---
Subject: Bug 19489
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-02-07 23:11:05
Modified files:
gcc: libada-mk.in configure.ac configure C
--- Additional Comments From ctsa at u dot washington dot edu 2005-02-07
23:12 ---
(In reply to comment #0)
> I'm getting a segfault on what I believe to be valid code using gcc 4.0 but
> not
> when using gcc 3.4 or 3.3. I've reduced this situation down to a relatively
> short testcase
I'm getting a segfault on what I believe to be valid code using gcc 4.0 but not
when using gcc 3.4 or 3.3. I've reduced this situation down to a relatively
short testcase file, details follow.
testcase.cc:
"""
#include
#include
#include
using namespace std;
struct ltstr
{
bool operator()(co
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-07
23:13 ---
Using var_to_partition does not help. The reason is that the SSA names with
the same root var are not in the same partition, e.g.
int
foo (int x, int a, int b)
{
x = a + b;
x = x * a;
x = x *
--
What|Removed |Added
Component|c++ |regression
Keywords||wrong-code
Summary|gcc 4.0 regression: b
--- Additional Comments From neroden at gcc dot gnu dot org 2005-02-07
23:15 ---
Closing. Laurent, I may ask you to test my alternate solution later (when
it's ready) though, OK?
--
What|Removed |Added
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
23:16 ---
*** This bug has been marked as a duplicate of 19813 ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07
23:16 ---
*** Bug 19814 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19813
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-07
23:16 ---
Note the following:
x_4 not coalesced with x --> New temp: 'x.0'
x_5 not coalesced with x.0 --> New temp: 'x.1'
Not very useful, because x_4 and x_5 have no uses left. So you start with
this:
foo
--- Additional Comments From rth at gcc dot gnu dot org 2005-02-07 23:36
---
Subject: Re: [4.0 Regression] 10% increase in codesize with C code compared to
GCC 3.3
On Mon, Feb 07, 2005 at 11:13:27PM -, steven at gcc dot gnu dot org wrote:
> x = a + b;
> x = x * a;
> x = x
--- Additional Comments From joel at oarcorp dot com 2005-02-08 00:01
---
Subject: Re: gnat tools not buildable cross
neroden at gcc dot gnu dot org wrote:
> --- Additional Comments From neroden at gcc dot gnu dot org 2005-02-07
> 23:15 ---
> Closing. Laurent, I may ask you
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-08
00:15 ---
Might as well make it mine while I'm looking at it.
--
What|Removed |Added
Assigne
--- Additional Comments From rakdver at gcc dot gnu dot org 2005-02-08
00:29 ---
Out of the time spent in ivopts:
-- this patch saves some 25%:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00136.html
-- another 25% are caused by inefficient use of # of iterations analysis;
I am t
--- Additional Comments From david dot billinghurst at comalco dot riotinto
dot com dot au 2005-02-08 00:30 ---
Subject: RE: [4.0 Regression] Bootstrap fails: Unresolved data symbol
"set_fpc_csr"
I can see the problem here once I compile with -v.
get_fpc_csr and set_fpc_csr are in
--- Additional Comments From hjl at lucon dot org 2005-02-08 01:14 ---
The testcase patch is at
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html
To properly support -fvisibility-inlines-hidden, ASM_OUTPUT_EXTERNAL
should be defined. We can collected undefined symbols with non-def
--- Additional Comments From andrewhutchinson at cox dot net 2005-02-08
01:48 ---
I ran testcase with proposed avr_costs patch applied. The result is unchanged.
The initially generated RTL is unfortunately beyond that which can be fixed by
backend. I dont think this problem is avr spec
--- Additional Comments From andrewhutchinson at cox dot net 2005-02-08
02:12 ---
Bad post ignore
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18219
--- Additional Comments From jvdelisle at verizon dot net 2005-02-08 02:34
---
Subject: Re: [g77 & gfortran] Lapack regressions since
g77 2.95.2
giovannibajo at libero dot it wrote:
> --- Additional Comments From giovannibajo at libero dot it 2005-02-07
> 18:56 ---
> Thomas,
--- Additional Comments From echristo at redhat dot com 2005-02-08 03:11
---
cpplib isn't my component and I'd prefer not to implement anything before
knowing that the general idea is ok. reassigning to unassigned.
--
What|Removed |Added
-
--- Additional Comments From echristo at redhat dot com 2005-02-08 03:12
---
It's a legitimate failure, we don't often xfail those - even when there is a
known fix.
--
What|Removed |Added
---
--- Additional Comments From kghazi at verizon dot net 2005-02-08 03:18
---
Subject: Re: [3.3 only] mips-sgi-irix6.5 testsuite failure in
gcc.dg/overflow-1.c with -mabi=64
Huh? It may be a legitimate failure, but you've decided not to fix it. I
thought that's exactly what an XFAIL i
Documentation change - GCC Internals
The definition of MODES_TIEABLE_P is incorrect and has resulted in reduced
optimisation for the avr target (and perhaps others)
The definition is currently:
"A C expression that is nonzero if a value of mode mode1 is accessible in mode
mode2 without copying."
--- Additional Comments From echristo at redhat dot com 2005-02-08 05:02
---
Everytime I try to guess what an XFAIL is for other than a "not implemented yet"
failure I get in trouble. I'm willing to go with this if the 3.3 branch manager
approves though (and I can figure out an easy way
For the following code, the C++ front-end produces a case instead of doing
&v.base which seems
wrong in my mind.
struct base { base(); };
struct vector : public base { };
int f() { vector v; }
This might be the cause of PR 19786 but it might not (I have not looked at the
aliasing sets for tha
The following code should be optimizated out on the tree level but is not
because we have a cast
involved when calling the deconstuctor.
int t;
struct base { int i; ~base(){t = i;}};
struct vector : public base { vector(){ i = 2; }};
int f() { vector v; return t;}
extern "C" void abort ();
int
--- Additional Comments From jvdelisle at verizon dot net 2005-02-08 05:57
---
This seems odd, but I am getting more failures with -O0 then I do -O1, -O2, or
-O3. The fewest failures is with -O1. -O0 and -O3 have regressed since 2-1-05.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com
|dot org |
Status|NEW
--- Additional Comments From ryan dot oliver at pha dot com dot au
2005-02-08 07:22 ---
(In reply to comment #5)
> The patch was approved by the RM here:
>
> http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00850.html
>
> but it is still not applied. It would be great if you could pls co
89 matches
Mail list logo
