I tried to install gcc-4.2-20061121 and gcc-4.3-20061118. Both failed at
exactly the same point. The steps I used to install them were:
# cd /common/src
# tar xjf gcc-4.2-20061121.tar.bz2
# cd /common/compilers/linux/gcc-4.2
# /common/src/gcc-4.2-20061121/configure
--prefix=/common/compilers/linu
Hello,
I have a proc file which I compile with the proc compiler and link it with
gcc.
The .pc file as well as makefile is same in two m/c's.
In one m/c with gcc3.3.3 installed, I have no problem in compiling and
linking.
In another m/c with gcc4.0.0 installed, I was getting the following error
Hi.
I've a reduced test case showing that a function like:
struct x {
uint8_t a;
uint16_t b;
};
f(struct x *y)
...
will expect that 'y' is correctly aligned: it uses 'ldrh' to access y->b and
ldrh documentation says "if the memory is not halfworld-aligned and no data
abort occurs, the value w
--- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-22 10:50
---
The compiler expects 'y' to be correctly aligned because the ABI says that it
can expect this to be so. If you write a program that then provides an
unaligned value, then the behaviour is undefined and you can get
--- Comment #27 from irar at il dot ibm dot com 2006-11-22 11:15 ---
I committed the patch that enables vectorization of strided accesses
(http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01679.html), and now bootstrap
with vectorization fails also on x86 with the same error as in comment #3
--- Comment #2 from bernard dot fouche at kuantic dot com 2006-11-22 11:32
---
Subject: Re: [3.4.4/3.4.6/4.1.1] ARM structure pointer alignment
problem with optimization
rearnsha at gcc dot gnu dot org wrote:
> --- Comment #1 from rearnsha at gcc dot gnu dot org 2006-11-22 10:50
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-11-22 12:39
---
Created an attachment (id=12666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12666&action=view)
testcase run through uninclude
unincluded so it's 64bit clean also.
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-22 13:42 ---
I have just submitted a patch to the gfortran list.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #8 from patchapp at dberlin dot org 2006-11-22 13:45 ---
Subject: Bug number PR29912
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01561.html
--
http://gcc.gnu.org/bugzilla/sh
Rvalue references as described in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2118.html were voted
into the C++0x working draft at the 2006 Portland meeting, and I'd like to use
them.
--
Summary: Please implement rvalue references
Product: gcc
Versio
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-11-22 14:20 ---
Sorry for my slow reply. I have no easy way to look this
issue quickly. I'd like to revert the reorg part of 118746
to fix the build failure on hppa.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
--- Comment #4 from tobi at gcc dot gnu dot org 2006-11-22 14:48 ---
A possible solution is to add entries for the symbolic forms (e.g. '==') of the
intrinsic operators to the enum gfc_intrinsic_op, and then use them
interchangeably, except when matching the operators, and when printing
--- Comment #5 from hjl at lucon dot org 2006-11-22 14:50 ---
Another testcase:
[EMAIL PROTECTED] build_base_o2.]$ cat bar.f90
SUBROUTINE foo(DPRS,LBOT,LTOP,KTS,KTE)
IMPLICIT NONE
INTEGER,INTENT(IN) :: KTS,KTE
INTEGER,INTENT(OUT) :: LBOT,LTOP
REAL,DIMEN
--- Comment #3 from s__nakayama at infoseek dot jp 2006-11-22 14:57 ---
(In reply to comment #2)
(In reply to comment #2)
> What exactly do you expect the code to do?
> foo();
> leads to an instantiation of foo with
> T= int()()
> i.e. reference to "no-arg function returning int".
--- Comment #3 from tobi at gcc dot gnu dot org 2006-11-22 15:01 ---
I have a one-line patch for this.
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
This program compiles:
#include
int main()
{
std::cout << _S << std::endl;
return 0;
}
If started, it outputs : 8
output of my g++ -v:
Reading specs from /opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/specs
Target: i386-pc-solaris2.8
Configured with: ../sources/gcc-4.0.2/configure -
--- Comment #1 from boris dot breidenbach at physik dot uni-erlangen dot de
2006-11-22 15:05 ---
Created an attachment (id=12667)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12667&action=view)
output of g++ -E
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29940
--- Comment #1 from fang at csl dot cornell dot edu 2006-11-22 15:07
---
There was some (suspended) discussion about support for rvalue references in PR
24803. Is there a plan for them somewhere in the pipeline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29939
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-11-22
15:11 ---
Subject: Re: [4.3 Regression] libgcc2.c: In function '__gcc_bcmp': ICE:
Segmentation fault
> Sorry for my slow reply. I have no easy way to look this
> issue quickly. I'd like to revert the reorg part of
With this subroutine:
subroutine whatever(str)
character(len=*), dimension(*) :: str
integer :: i
i = len(str)
end subroutine whatever
gfortran reports:
i = len(str)
1
Error: The upper bound in the last dimension must appear in the reference to
the assumed size array 'str' at (1)
The sub
The following code produce a compilation error at the unique line of the
function named "visit" below (it is a basic implementation of a visitor
pattern) :
# 1 "test.cpp"
# 1 ""
# 1 ""
# 1 "test.cpp"
template
struct Toto
{
template
void visit(T2 * o)
{
o->eval();
}
};
te
--- Comment #4 from bangerth at dealii dot org 2006-11-22 15:31 ---
(In reply to comment #3)
> I expected that the compiler reject it.
> But Comeau compiler also accepted this code.
As does icc.
I can't see why the code would be invalid if one accepts that
T bar;
is the declaration
--- Comment #7 from kkojima at gcc dot gnu dot org 2006-11-22 15:40 ---
Indeed. I've reverted it now. Sorry again for the breakage.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29891
--- Comment #4 from jakub at gcc dot gnu dot org 2006-11-22 15:58 ---
Too old glibc or configured without TLS support? Try building gcc with
--disable-tls. Works just fine here.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from hhinnant at apple dot com 2006-11-22 16:21 ---
If there is a plan, I don't know about it.
Russell Yanofsky has a prototype implementation here:
http://russ.yanofsky.org/rref/
I haven't looked at it enough to know how complete it is. It was done a couple
of years a
--- Comment #1 from hjl at lucon dot org 2006-11-22 16:32 ---
Please try
# make -j5 bootstrap-lean
--
hjl at lucon dot org changed:
What|Removed |Added
C
The following example(reduced from glibc) compiles differently for ppc target
when using gcc 4.2 as compared to gcc 4.1
It generates the alias symbol as a real symbol instead of creating it as alias.
I get this correct using gcc 4.2 for arm so the problem seems to be affecting
only ppc. This also w
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:42 ---
/common/compilers/linux/gcc-4.2//x86_64-unknown-linux-gnu/sys-include -m32
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled p
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Prio
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:45 ---
_S is in the reserved identifiers for implemenation so ...
Closing as invalid.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 16:47 ---
Instead of:
o->eval();
You want:
o->template eval();
Which is required by the C++ standard.
read:
http://gcc.gnu.org/gcc-3.4/changes.html
--
pinskia at gcc dot gnu dot org changed:
W
--- Comment #6 from hjl at lucon dot org 2006-11-22 16:56 ---
A simpler testcase:
[EMAIL PROTECTED] 29921]$ cat bar.f90
SUBROUTINE foo(DPRS,FPK,LBOT,LTOP,KTS,KTE)
IMPLICIT NONE
INTEGER,INTENT(IN) :: KTS,KTE
INTEGER,INTENT(OUT) :: LBOT,LTOP
REAL,DIMENSION(K
At the moment, we only do biv (basic induction variable) widening when we
can argue that overflow cuases undefined behaviour, as in:
int
f (int start, int end, int x, int y)
{
short i;
for (i = start; i < end; i++)
x <<= y;
return x;
}
However, for -ftrapv, we get the wrong result (it
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-11-22 19:23 ---
Created an attachment (id=12668)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12668&action=view)
3.4.3 patch
For illustration, this patch implements this optimization in a 3.4.3 based
compiler.
Because the 4
The code from libgfortran ICEs:
extern const char *__ctype_ptr;
parse_real (unsigned char c)
{
if ((__ctype_ptr[c]&04) &&c != '.')
unget_char ( c);
}
-
t.c: In function 'parse_real':
t.c:6: internal compiler error: in simplify_subreg, at simplify-rtx.c:4470
Plea
--- Comment #7 from hjl at lucon dot org 2006-11-22 19:34 ---
Reduced:
[EMAIL PROTECTED] 29921]$ cat bar.f90
SUBROUTINE foo(DPRS,DEN,LBOT,LTOP,KTS,KTE)
IMPLICIT NONE
INTEGER,INTENT(IN) :: KTS,KTE
INTEGER,INTENT(OUT) :: LBOT,LTOP
REAL,DIMENSION(KTS:KTE),INT
When profile based feedback indicates that a loop has a low iteration
count, it will often refuse to unroll even though unrolling is still
useful. Moreover, while it knows about the average loop iteration
count, it lacks the concept of a prevalent iteration count.
In particular, the header checks
--
tobi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org
|dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 19:49 ---
> With the introduction of the new loop unroller in 4.0,
I think you mean 3.4.0 because the new unroller was in 3.4.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29946
--- Comment #8 from hjl at lucon dot org 2006-11-22 20:02 ---
A testcase in C:
int
foo (float *array, int end)
{
int i;
float sum1, sum2;
sum2=0;
for (i=0; i < end; i++)
sum2=sum2+array[i];
sum2=1./sum2;
sum1 =0.;
for (i=0; i < end; i++)
sum1=sum1+array[i];
sum1
--- Comment #3 from dkouroun at cc dot uoi dot gr 2006-11-22 20:07 ---
Subject: Re: bootstrap failure on Linux AMD64
Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>:
>
>
> --- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-22 16:42
> ---
> /common/compilers
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-22 20:10 ---
(In reply to comment #1)
> > With the introduction of the new loop unroller in 4.0,
> I think you mean 3.4.0 because the new unroller was in 3.4.0.
>
You're right, it was introduced then. Although the old loop unr
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-22 20:14 ---
(In reply to comment #3)
> what else can I do to check manually the glibc libraries?
> I never learned how can somebody check the version of glibc installed
> on his system. How can I do that?
for one where does gen
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 20:16 ---
I have a fix.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #5 from dkouroun at cc dot uoi dot gr 2006-11-22 20:18 ---
Subject: Re: bootstrap failure on Linux AMD64
# ls /usr/ -l
total 72
lrwxrwxrwx 1 root root 6 Nov 21 12:59 X11R6 -> ../usr
drwxr-xr-x 2 root root 16384 Nov 22 17:21 bin
drwxr-xr-x 61 root root 8192 Nov 22
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-11-22 20:48 ---
(In reply to comment #0)
> The following example should give an EOR error.
This is one of the things that the programmer has to
get right, a processor may do anything (including
silently ignoring the error, as gfort
--- Comment #1 from burnus at gcc dot gnu dot org 2006-11-22 21:04 ---
Confirmed.
Accepted without warning by NAG f95, g95,sunf95 and ifort.
In order to determine the length of a character array, the size or shape of the
array does not matter.
--
burnus at gcc dot gnu dot org change
--- Comment #6 from dkouroun at cc dot uoi dot gr 2006-11-22 21:23 ---
Subject: Re: bootstrap failure on Linux AMD64
> --- Comment #1 from hjl at lucon dot org 2006-11-22 16:32 ---
> Please try
>
> # make -j5 bootstrap-lean
>
again it stops at the same point as it did initia
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-22 21:27 ---
(In reply to comment #5)
> Subject: Re: bootstrap failure on Linux AMD64
> hope this helps
Yes gentoo is installing libc in the wrong directory. lib should be a symbol
link (or really what is currently lib32) to li
--- Comment #8 from dkouroun at cc dot uoi dot gr 2006-11-22 21:39 ---
Subject: Re: bootstrap failure on Linux AMD64
Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>:
>
>
> --- Comment #7 from pinskia at gcc dot gnu dot org 2006-11-22 21:27
> ---
> (In reply to comm
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-22 21:44 ---
(In reply to comment #8)
> I do not think that the directory is wrong. I think you mean that it
> install's in a directory which is not the one gcc expects it to be.
> So I guess that gcc expects the 32bit libraries
--- Comment #10 from dkouroun at cc dot uoi dot gr 2006-11-22 21:47 ---
Subject: Re: bootstrap failure on Linux AMD64
Quoting pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>:
>
>
> --- Comment #9 from pinskia at gcc dot gnu dot org 2006-11-22 21:44
> ---
> (In reply to com
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-11-22 21:58
---
Again this is a bug in the distro and not a bug in GCC, if gentoo wants that
directory layout, they are not going to be compatible with any other distros or
even most newer closed source software.
--
http://gc
The following test program works as expected when compiled without -fopenmp.
In some cases, such as shown below, it fails when the loop termination
condition is already satisfied on entry:
[EMAIL PROTECTED] tmp]$ uname -a
Linux carmenere.cfa.harvard.edu 2.6.18-1.2200.fc5 #1 SMP Sat Oct 14 16:59:5
--- Comment #4 from tobi at gcc dot gnu dot org 2006-11-22 22:09 ---
Subject: Bug 29441
Author: tobi
Date: Wed Nov 22 22:09:14 2006
New Revision: 119101
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119101
Log:
fortran/
PR fortran/29441
* intrinsic.c (gfc_intrin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 22:11 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
When compiling kmail with Debian's dpkg-buildpackage, cc1plus is killed by the
kernel due to memory shortage. This shows when using either g++ 4.0 or 4.1.
Files (including .ii files) are on the following URL:
http://errors.linuxonly.nl/gcc/
G++ version:
g++-4.0 (GCC) 4.0.4 20060904 (prerelease)
--- Comment #1 from amodra at bigpond dot net dot au 2006-11-22 22:21
---
relevant -O2 assembly is
.globl _dl_argv
.globl _dl_argv_internal
.hidden _dl_argv_internal
.set_dl_argv_internal,_dl_argv
.section.data.rel.ro,"aw",@progbits
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-22 22:24 ---
Can you report what options you are using to compile?
Actually just copy and paste the exact command that is running out of memory.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29948
--- Comment #9 from hjl at lucon dot org 2006-11-22 22:26 ---
Is HONOR_NANS missing somwhere?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29921
--- Comment #2 from amodra at bigpond dot net dot au 2006-11-22 22:27
---
Removing __attribute__ ((section (".data.rel.ro"))) from _dl_argv_internal also
generates good code.
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
---
--- Comment #2 from sjoerd-gcc at linuxonly dot nl 2006-11-22 22:27 ---
Command line:
g++ -save-temps -DHAVE_CONFIG_H -I.
-I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./kmail -I..
-I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.dfsg.1/./libkmime
-I/home/sjoerd0/dev/dist/bla/kdepim-3.5.5.df
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-22 22:30 ---
.data.rel.ro, isn't that a special section?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
--- Comment #4 from amodra at bigpond dot net dot au 2006-11-22 22:41
---
Not particularly. s/.data.rel.ro/.mysect/ does the same thing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29943
Arguments for omp_set_num_threads/OMP_NUM_THREADS are used without checking for
validity, i.e.
$> cat omp_set_num_threads.f90
PROGRAM main
USE OMP_LIB
CALL omp_set_num_threads(-3)
!$OMP PARALLEL
WRITE(*,*) "thread:", omp_get_thread_num()
!$OMP END PARALLEL
END PROGRAM
$> gfortran-4.3 -g
I noticed that sizes of functions in generated code change when I do simple
unrelated changes. Example:
# diff -u vi_small.c vi_big.c
--- vi_small.c 2006-11-22 23:35:39.0 +0100
+++ vi_big.c2006-11-22 23:35:42.0 +0100
@@ -3414,6 +3414,8 @@
} sockaddr_inet;
extern int dotted2s
--- Comment #1 from vda dot linux at googlemail dot com 2006-11-22 22:57
---
Created an attachment (id=12669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12669&action=view)
Visual comparison of assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #2 from vda dot linux at googlemail dot com 2006-11-22 22:58
---
Created an attachment (id=12670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12670&action=view)
Complete testcase with .c, .o and .s files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #10 from rakdver at gcc dot gnu dot org 2006-11-22 23:11
---
Subject: Bug 29921
Author: rakdver
Date: Wed Nov 22 23:11:15 2006
New Revision: 119102
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119102
Log:
PR tree-optimization/29921
* fold-const.c (
--- Comment #1 from franke dot daniel at gmail dot com 2006-11-22 23:12
---
Correction: checks are already implemented for environment variables.
In above report OMP_NUM_THREADS is not affected, but omp_set_num_threads still
is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
--- Comment #11 from rakdver at gcc dot gnu dot org 2006-11-22 23:43
---
(In reply to comment #9)
> Is HONOR_NANS missing somwhere?
Not really, it is basically the same problem as the one with -0 -- for some
time, ccp may believe that there might be a NaN (due to division by zero in
ca
--- Comment #6 from jsm28 at gcc dot gnu dot org 2006-11-23 00:16 ---
Patch was discussed at
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00451.html
and had some objections from Geoff Keating.
I've come across another problem case and am testing another possible patch to
address both ca
--- Comment #2 from danglin at gcc dot gnu dot org 2006-11-23 00:25 ---
Introduced by r118475. However, it wasn't fixed by Andrew's fwprop.c
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29840
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summary|build/genconditions |[4.3 Regression]
|../../gcc/gcc/config/pa/pa.m|buil
--- Comment #5 from patchapp at dberlin dot org 2006-11-23 00:35 ---
Subject: Bug number PR17711
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01590.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-11-23 02:10
---
Actually the problem was that gfortran was failing to set the record length to
the value requested in the OPEN statement. Now as far as emitting an error or
warning I have a concern.
If the user specifies a RECL
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |amodra at bigpond dot net
|dot org
--- Comment #5 from dje at gcc dot gnu dot org 2006-11-23 02:31 ---
If GCC is not creating the alias correctly, that is a bug. However, we
previously agreed in PR 28598 that changing sections behind GCC's back is not
guaranteed to work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-23 03:12 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-23 03:13 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from richard at codesourcery dot com 2006-11-23 05:04
---
Subject: Re: [4.2/4.3 Regression] gcc generate incorrect alias symbols for PPC
"amodra at bigpond dot net dot au" <[EMAIL PROTECTED]> writes:
> AssignedTo|unassigned at gcc dot gnu |amodra at bigpond d
81 matches
Mail list logo
