--- Comment #9 from chat95 at mac dot com 2005-12-23 08:07 ---
Hello, Pawel Sikora!
I tried with (2005/12/23)
svn co svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 109008
and this problem has been solved!!
thank you very much!!
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #10 from chat95 at mac dot com 2005-12-23 08:07 ---
.
--
chat95 at mac dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RE
--- Comment #4 from chat95 at mac dot com 2005-12-23 08:10 ---
hi all,
i tried with gmake (GNU Make 3.81beta4) as Arno told,
build and installs file for me.
uname -a
FreeBSD debussy.private.org 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Mon Nov 21
09:36:37 JST 2005 [EMAIL PROTECTED]:/usr/s
--- Comment #5 from chat95 at mac dot com 2005-12-23 08:13 ---
sorry
file for me -> fine for me
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24154
$ uname -a
Linux hertz 2.6.7-gentoo-r14 #8 SMP Mon Sep 6 16:08:44 BST 2004 x86_64 AMD
Opteron(tm) Processor 844 AuthenticAMD GNU/Linux
gcc-4.2.0 svn revision 108950.
$ cd build_hertz
$ rm -rf *
$ ../trunk/gcc/configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=x8
--- Comment #1 from eesrjhc at bath dot ac dot uk 2005-12-23 08:55 ---
Argh -- how embarassing. I'd been looking at it for ages and never seen my
error. I should have used "../trunk/configure " not "../trunk/gcc/configure "
etc.
Sorry for the noise.
--
eesrjhc at bath dot ac dot uk
--- Comment #9 from jakub at gcc dot gnu dot org 2005-12-23 09:43 ---
Subject: Bug 25005
Author: jakub
Date: Fri Dec 23 09:43:36 2005
New Revision: 109013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109013
Log:
PR target/25005
* regrename.c (replace_oldest_val
--- Comment #10 from jakub at gcc dot gnu dot org 2005-12-23 09:44 ---
Subject: Bug 25005
Author: jakub
Date: Fri Dec 23 09:44:41 2005
New Revision: 109014
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109014
Log:
PR target/25005
* regrename.c (replace_oldest_va
--- Comment #11 from jakub at gcc dot gnu dot org 2005-12-23 09:49 ---
Fixed in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIG
$ cat >driver.cxx
template
struct Ref
{
};
namespace Bits
{
template
X&
x ();
}
template
typeof (Bits::x () + Bits::x ())
operator+ (Ref const& x, Ref const& y)
{
return X (0) + Y (0);
}
int
main ()
{
Ref ra;
Ref rb;
int j = ra + rb;
}
$ g++-4.0 --version
g++-4.0 (GCC) 4.0.3
We should probably issue a warning or error here, or
else blank out the rest of the line (g77 and ifort do so).
This is a corner case of an extension, so I don't think this
merits anything more than "enhancement".
$ cat dollar.f
program main
character*20 line
line = '1234567890A
Hi all. g++ 3.4.4 seems to accept calling a destructor ~T() on a char * pointer
if you're inside a template in certain cases. Obviously not very serious in the
grand scheme of things! Apologies if this has been fixed - I couldn't find it
in the bug list, though.
--- START EXAMPLE ---
class Foo {};
I just tried to compile the gcc-4.2 snapshot 20051217 with the Intel C
compiler. It said
1.
../../src/gcc-4.2-20051217/gcc/builtins.c(1155): remark #593: variable
"apply_args_reg_offset" was
set but never used
The source code is
static int apply_args_reg_offset[FIRST_PSEUDO_REGISTER];
I have r
--- Comment #31 from dir at lanl dot gov 2005-12-23 15:14 ---
Hi Jerry,
Would you go ahead and commit this ? A test case something like that in
Comment #9 shows the problem before and the fix after or may be you have a
better one from NIST. The change suggest in comment #14 fixes th
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:19 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:52 ---
*** This bug has been marked as a duplicate of 11078 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #25 from pinskia at gcc dot gnu dot org 2005-12-23 15:52
---
*** Bug 25544 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11078
If you compile by non GCC compiler change:
#define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
to:
#define INTTYPE_MAXIMUM(t) ((t) (~ ((t) 0 - INTTYPE_MINIMUM (t
gcc-4.1-20051008
--
Sent from the gcc - bugs forum at Nabble.com:
http://www.nabble.com/system.h%3A-define-INTTYPE_MA
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-23 15:57 ---
Confirmed, only a 3.4 regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Testcase:
class Foo {};
struct Bing
{
char *GetChar();
};
template struct Bar
{
void Wibble()
{
bing.GetChar()->~T(); // How can this be legal if T isn't char?
}
Bing bing;
};
-
If we change the return type of GetChar() to Foo * (from char*), we get an
error:
t.cc: In member fu
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-23 16:03 ---
I should note that we should reject this earlier, so I filed PR 25548.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25546
After the end of file is read, the file data is corrupted -
[dranta:~/tests/gfortran-D] dir% gfortran -o write17 write17.f
[dranta:~/tests/gfortran-D] dir% write17
538976288
Abort
[dranta:~/tests/gfortran-D] dir% cat write17.f
integer data
data=-1
open(unit=11,status='scratch'
--- Comment #3 from eedelman at gcc dot gnu dot org 2005-12-23 17:58
---
(In reply to comment #2)
> So it seems the problem was introduced within the last 24 hours.
To be a bit more precise: works with revision 108902, ICE:s with revision
108943.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #13 from uweigand at gcc dot gnu dot org 2005-12-23 18:38
---
Subject: Bug 21041
Author: uweigand
Date: Fri Dec 23 18:38:43 2005
New Revision: 109019
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109019
Log:
PR rtl-optimization/21041
* reload.c (fin
--- Comment #14 from uweigand at gcc dot gnu dot org 2005-12-23 18:44
---
Subject: Bug 21041
Author: uweigand
Date: Fri Dec 23 18:44:07 2005
New Revision: 109020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109020
Log:
PR rtl-optimization/21041
* reload.c (fin
--- Comment #15 from uweigand at gcc dot gnu dot org 2005-12-23 18:45
---
Fixed.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
gcov incorrectly shows that a lone return statement inside a block
has executed when in fact it has not
Environment:
System: Linux mercury.acucorp.com 2.4.18-27.8.0smp #1 SMP Fri Mar 14 07:13:13
EST 2003 i686 athlon i386 GNU/Linux
Architecture: i686
host: i686-pc-linux-gnu
build
--- Comment #9 from pcarlini at suse dot de 2005-12-23 20:12 ---
FWIW, on x86-linux at least, we are making progress on the compiler side.
With 4.0.2 I get (-O2):
<_Z1fRKSt6vectorIbSaIbEEj>:
0: 55 push %ebp
1: 89 e5 mov%es
--- Comment #32 from jvdelisle at gcc dot gnu dot org 2005-12-23 20:21
---
Yes, I will work this up with a proper test case and submit for approval.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25139
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-23 20:53 ---
Confirmed, only a 4.0 regression. Works in 4.1.0 and 3.4.0.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2005-12-23 20:54 ---
I'm working on a patch.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #3 from tromey at gcc dot gnu dot org 2005-12-23 20:55 ---
My PR 19132 fix should fix this as well.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #10 from pcarlini at suse dot de 2005-12-23 21:13 ---
Well, I'm not sure that, besides code size, 4_1 is doing better than 4.0.2, but
both are certainly better than 3.4.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16611
The following invalid code snippet is not rejected:
struct A {};
struct B
{
friend A::~B();
};
The problem appeared in gcc 4.0.0.
--
Summary: [4.0/4.1/4.2 regression] Invalid destructor name
accepted in friend declarat
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-
|
--- Comment #3 from mmitchel at gcc dot gnu dot org 2005-12-23 23:16
---
Subject: Bug 24671
Author: mmitchel
Date: Fri Dec 23 23:16:12 2005
New Revision: 109022
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109022
Log:
PR c++/24671
* pt.c (instantiate_template)
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-12-23 23:17
---
Subject: Bug 24671
Author: mmitchel
Date: Fri Dec 23 23:17:12 2005
New Revision: 109023
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109023
Log:
PR c++/24671
* pt.c (instantiate_template)
--- Comment #5 from mmitchel at gcc dot gnu dot org 2005-12-23 23:18
---
Subject: Bug 24671
Author: mmitchel
Date: Fri Dec 23 23:18:06 2005
New Revision: 109024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109024
Log:
PR c++/24671
* pt.c (instantiate_template)
--- Comment #6 from mmitchel at gcc dot gnu dot org 2005-12-23 23:24
---
Fixed in 4.0.3.
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Stat
--- Comment #4 from geoffk at geoffk dot org 2005-12-23 23:33 ---
Subject: Re: New: zero-initialized constants are place in .bss
"drepper at redhat dot com" <[EMAIL PROTECTED]> writes:
> const struct foo f;
>
> The compiler will mark the variable f in .bss instead of, as the const
>
--- Comment #13 from mmitchel at gcc dot gnu dot org 2005-12-23 23:40
---
I've finally figured out a tractable solution to this problem: just treat these
as dynamic initializations. That will be slightly less efficient than what the
C front end does, and result in a different initializ
I don't know what this optimization is called but we miss the removal of the
load of a global variable:
int t;
int g(int);
int f(int tt)
{
if (tt)
t = 2;
else
t = 3;
return g(t);
}
I should note I found this while looking at LAPACK.
--
Summary: Missed removal of load
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-24 01:51 ---
I should mention this shows up semi a lot in fortran code as what happens is
that t is not really a global variable but instead a local variable which is
passed to another function.
--
http://gcc.gnu.org/bugzill
When compiling the supplied test case with `gcc -c -O2 -ftracer test.c` with
gcc-4.0.3 the following error occurs:
test.c: In function mpfr_pow_ui:
test.c:18: error: unrecognizable insn:
(insn 96 44 46 6 (set (reg:CCZ 17 flags)
(compare:CCZ (and:DI (reg/v:DI 66 [ n ])
(co
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-12-24 04:38 ---
Better testcase which shows it also on the 3.4 branch:
unsigned int __gmpfr_flags;
int
f (unsigned long int n)
{
int prephitmp3;
int i;
long unsigned int m;
if (n == 0)
prephitmp3 = -2;
else
{
m = n;
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-24 07:54 ---
ICC does not even do this optimization.
I should note that Fortran code has something like this, except you don't need
to know about the function that is being called, just the variable and if it
has TARGET on it or
46 matches
Mail list logo
