--- Comment #7 from amodra at bigpond dot net dot au 2006-11-23 08:01
---
This is the simple patch I've bootstrapped and am currently regression testing.
Index: varasm.c
===
--- varasm.c(revision 119100)
+++ varasm.c
--- Comment #12 from dkouroun at cc dot uoi dot gr 2006-11-23 08:34 ---
Subject: Re: bootstrap failure on Linux AMD64
I submitted a bug report in the Gentoo Bugzilla. I hope they will fix it.
I still believe that the best way through would be to add an option to the
configure script of
--- Comment #10 from martin at mpa-garching dot mpg dot de 2006-11-23
09:22 ---
I can still reproduce the compilation problem with today's mainline.
I'll try with the 4.2 branch as soon as possible.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
Dear people,
The sample code below converts 4 characters to an integer using the transfer
function. If the characters are stored in an array of characters this works
fine. If the characters are stored in a string the transfer fails.
The following commands were used to compile with both gfortran a
--- Comment #1 from kloedej at knmi dot nl 2006-11-23 09:27 ---
Hi,
a little correction on the just submitted report.
I seem to have mixed up the two cases. The string case fails so it clearly has
nothing to do with the rank of the first parameter to transfer().
Jos de Kloe
--
ht
Intel has a nice feature to find bad array definitions.
Somehow thinking of C I wrote:
real :: coord(N,3)
rather than coord(3,N). Using "ifort -check arg_temp_created" this gave then
such information at run time (in my example below 20 times):
"forrtl: warning (402): fort: (1): In call to DISTAN
GCC 4.1.1 (probably all 4.* versions, tested 4.3.0-svn also), uses cmp/eq
instead of "dt" in loops. This leads to ~20% perfomance decrease.
Technically, loop processing algorithm is completely different between
versions.
Example (sources in attach):
CFLAGS="-m4 -O3 -fomit-frame-pointer"
gcc 3.
--- Comment #1 from nbkolchin at gmail dot com 2006-11-23 10:15 ---
Created an attachment (id=12671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12671&action=view)
test.cpp
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29953
Hi
I am compiling gcc for SUN solaris10.0 with the following parameters:
--enable-languages=c,c++ --enable-shared
here is the following errors I found:
ld: fatal: relocation error: R_SPARC_DISP32: file
.libs/libstdc++.lax/libsupc++convenience.a/new_op.o: symbol : offset
0xfccd14b5 is non-al
extern void bar (int);
void
foo (int n)
{
int i;
#pragma omp parallel for schedule(dynamic)
for (i = 0; i < n; i++)
bar (0);
}
ICEs on ia64-linux with -xc -O2 -fopenmp -fexceptions, as
eh_personality_libfunc
isn't set, yet foo.omp_fn.0 has cfun->uses_eh_lsda.
--
Summary: ICE
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-23 11:17 ---
Confirmed.
For "transfer(string, integer)", gfortran's transfer only uses the first
character (byte).
It should use all characters.
-fdump-tree-original:
value = VIEW_CONVERT_EXPR(byte_string[1]{lb: 1 sz: 1});
In
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2006-11-23 11:18
---
Please specify the exact configure line and build command. Also make sure
to read the documentation: http://gcc.gnu.org/install
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from burnus at gcc dot gnu dot org 2006-11-23 11:39 ---
> In iresolve.c gfortran only checks whether the source is scalar or an array,
This is none sense it actually checks the mold-rank.
The function to modify is gfc_conv_intrinsic_transfer (trans-intrinsic.c);
we somewh
--
sos at cal dot interrasystems dot com changed:
What|Removed |Added
CC||sos at cal dot
|
--- Comment #2 from sos at cal dot interrasystems dot com 2006-11-23 12:29
---
Hi Ebotcazou,
Thanks for your reply.
Here is the command, that I am using:
I am at
gcc-4.0.2_obj directory.
"../gcc-4.0.2_src/configure --prefix=/software/gcc/v4.0.2/sparc-sun-solaris2.10
--enable-languages
--- Comment #8 from patchapp at dberlin dot org 2006-11-23 12:45 ---
Subject: Bug number PR29943
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/msg01613.html
--
http://gcc.gnu.org/bugzilla/sh
g++ -v:
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.2/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --disable-nls--disable-libgcj --enable-languages=c,c+
: (reconfigured) ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --
--- Comment #1 from sgaltsev at cbossgroup dot com 2006-11-23 14:09 ---
Created an attachment (id=12672)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12672&action=view)
1.ii
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29956
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-11-23 14:13 ---
No, subtraction of pointer types "const int *const *" and "int *const *" is
nonstandard.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-11-23 14:20
---
> Thanks for your reply.
You're welcome, but please do not undo the changes to the fields.
> Can you please help me in this issue and give the comman for build gcc4.x on
> Solaris 10.
You didn't post the build
--- Comment #5 from s__nakayama at infoseek dot jp 2006-11-23 14:34 ---
(In reply to comment #4)
> In any case, can you clarify why exactly you think the code should be
> rejected?
ISO 14882:2003 14.3.1 p3
> If a declaration acquires a function type through a type dependent on a
> t
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-23 17:45
---
(In reply to comment #12)
>
> On the other hand gcc-4.3 breaks both with or without -j5 at libgfortran
> spitting a lot of messages like:
That is an issue with the glibc headers not being C99 complaint. Anyways
--- Comment #2 from pault at gcc dot gnu dot org 2006-11-23 17:55 ---
Tobias,
This one liner does the right thing but I have no time right now to do anything
with it:
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolv
--- Comment #1 from pault at gcc dot gnu dot org 2006-11-23 18:31 ---
Confirmed sort of.
>
> While one can sometimes not prevent the need for a array temporary, one often
> can and should do so to speed up the program.
{
void * D.1019;
struct
--- Comment #17 from manu at gcc dot gnu dot org 2006-11-23 18:39 ---
Subject: Bug 9072
Author: manu
Date: Thu Nov 23 18:39:32 2006
New Revision: 119129
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119129
Log:
2006-11-23 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/
$ uname -a
Linux athena 2.6.17-2-486 #1 Wed Sep 13 15:56:30 UTC 2006 i686 GNU/Linux
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/l
--- Comment #18 from lopezibanez at gmail dot com 2006-11-23 18:55 ---
I have insufficient privileges to close this bug. Please, someone, close it as
FIXED. Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072
--- Comment #1 from chevallier_sylvain at yahoo dot fr 2006-11-23 19:00
---
Created an attachment (id=12673)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12673&action=view)
cat of all the source files required by the bug box
This is the cat of the source files named by the bug b
--- Comment #10 from pault at gcc dot gnu dot org 2006-11-23 19:14 ---
Subject: Bug 29820
Author: pault
Date: Thu Nov 23 19:14:05 2006
New Revision: 119132
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119132
Log:
2006-11-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #7 from pault at gcc dot gnu dot org 2006-11-23 19:14 ---
Subject: Bug 25087
Author: pault
Date: Thu Nov 23 19:14:05 2006
New Revision: 119132
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119132
Log:
2006-11-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #4 from pault at gcc dot gnu dot org 2006-11-23 19:14 ---
Subject: Bug 29652
Author: pault
Date: Thu Nov 23 19:14:05 2006
New Revision: 119132
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119132
Log:
2006-11-23 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/2
--- Comment #8 from pault at gcc dot gnu dot org 2006-11-23 19:17 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pault at gcc dot gnu dot org 2006-11-23 19:18 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pault at gcc dot gnu dot org 2006-11-23 19:19 ---
Fixed on trunk and 4.2
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-11-23 19:59 ---
For the -mrelax breakage, also see:
http://sourceware.org/bugzilla/show_bug.cgi?id=3298
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842
The SH port internally uses fixed register numbers for MACH/MACL and the
floating point registers, which are only appropriate for big endian.
This prevents using SImode subregs of DFmode registers, and referring to
a 64 bit multiplication result in MACH/MACL as DImode.
The register numbering shoul
--
amodra at bigpond dot net dot au changed:
What|Removed |Added
AssignedTo|amodra at bigpond dot net |unassigned at gcc dot gnu
|dot au
--- Comment #2 from patchapp at dberlin dot org 2006-11-23 20:30 ---
Subject: Bug number PR29949
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/msg01644.html
--
http://gcc.gnu.org/bugzilla/sh
We should only allow
a) elemental functions
b) we currently check gfc_init_expr_extensions():
/* FIXME: This should be moved into the intrinsic definitions. */
static const char * const init_expr_extensions[] = {
"digits", "epsilon", "huge", "kind", "maxexponent", "minexponent",
"preci
Currently, variables are generally placed in the data or bss segment;
they cannot be addressed directly, hence their address needs to be
loaded into a register first. Moreover, this address load is
done with a pc-relative load, which incurs extra latency.
If the variable was in the text segment w
--
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 burnus at gcc dot gnu dot org 2006-11-23 21:10 ---
I just realized I was too brief:
There are three types of initialization expressions (IE):
- Valid in F95
- Added as valid F2003
- Only valid as GNU extensions
We need to check:
- Is there a non-elemental function
--- Comment #5 from amylaar at gcc dot gnu dot org 2006-11-23 21:22 ---
Subject: Bug 29920
Author: amylaar
Date: Thu Nov 23 21:22:23 2006
New Revision: 119134
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119134
Log:
2006-11-22 Antony King <[EMAIL PROTECTED]>
J"orn
--- Comment #6 from amylaar at gcc dot gnu dot org 2006-11-23 21:25 ---
Fixed in Revision 119091 (mainline) / 119134 (gcc-4_2-branch)
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
---
Using -Os and volatile results in functions, sometimes the optimizer 'forgets'
the volatile property of the function and makes it pure. This has a major
impact in some cases. Test case 1 gives buggy code where test case 2 & 3 works.
The command line to compile this was arm-elf-gcc -c test.c -Os
/*
--
sb at anoto dot com changed:
What|Removed |Added
CC||sb at anoto dot com
Severity|normal |major
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-23 21:40 ---
Confirmed. IPA pure-const pass is founds func_a as pure which is incorrect:
Function found to be pure: func_a
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from burnus at gcc dot gnu dot org 2006-11-23 21:58 ---
One other thing we need to change:
real, parameter :: d = 2.0**0.5
1
Error: Exponent at (1) must be INTEGER for an initialization expression
This is now also allowed in F2003.
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-23 22:08 ---
And I have a fix which I am testing right now. It moves some code around so we
get the correct result.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-23 22:49 ---
By the way this is the patch which I am testing:
Index: ipa-pure-const.c
===
--- ipa-pure-const.c(revision 119134)
+++ ipa-pure-const.c(working
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-11-23 22:51
---
(In reply to comment #18)
> I have insufficient privileges to close this bug. Please, someone, close it as
> FIXED. Thanks.
You should be able to use your @gcc.gnu.org account to close the bug report.
--
pinsk
The following program causes an ICE with -fopenmp -fexceptions:
extern void bar (int);
void
foo (int n)
{
int i;
#pragma omp parallel for schedule(dynamic)
for (i = 0; i < n; i++)
{
bar (0);
@throw 0;
}
}
--
Summary: Objective-C exceptions vs OpenMP
P
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-23 23:04 ---
Actually you can reproduce the same ICE (with the same backtrace) with C++
code:
extern void bar (int);
void
foo (int n)
{
int i;
#pragma omp parallel for schedule(dynamic)
for (i = 0; i < n; i++)
{
th
--- Comment #3 from burnus at gcc dot gnu dot org 2006-11-23 23:51 ---
Non-elemental intrinsic functions in Section 13.7 of Fortran 2003:
ALL(T), ALLOCATED(I), ANY(T), ASSOCIATED(I), BIT_SIZE(I),
COMMAND_ARGUMENT_COUNT(I), COUNT(T), CSHIFT(T), DIGITS(I), DOT_PRODUCT(T),
EOSHIFT(T), EPSI
Both gcc and g++ crash on this. (I'll attach the code later, as it's still
kind of large.) Seemingly innocent changes will affect the crash behavior.
Normally I compile with "-std=gnu99 -O2"; this is intended to be C code.
These very similar programs give different errors at times, especially when
--- Comment #1 from acahalan at gmail dot com 2006-11-23 23:59 ---
Created an attachment (id=12676)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12676&action=view)
crash1.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #2 from acahalan at gmail dot com 2006-11-24 00:00 ---
Created an attachment (id=12677)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12677&action=view)
crash2.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #3 from acahalan at gmail dot com 2006-11-24 00:01 ---
Created an attachment (id=12678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12678&action=view)
crash3.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #4 from acahalan at gmail dot com 2006-11-24 00:01 ---
Created an attachment (id=12679)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12679&action=view)
crash4.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #5 from acahalan at gmail dot com 2006-11-24 00:02 ---
Created an attachment (id=12680)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12680&action=view)
crash5.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29966
--- Comment #17 from acahalan at gmail dot com 2006-11-24 00:11 ---
(In reply to comment #13)
> The question I asked is "why doesn't this happen for 'const'"? That
> turned out to be a good question, because it leads to the better
> question of "what debugging output did you expect
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-11-24 00:17 ---
valgrind on the mainline shows begining with:
==11886== Invalid write of size 1
==11886==at 0x8592FE0: _cpp_lex_direct (lex.c:881)
==11886== Address 0x48DD485 is 5 bytes after a block of size 4,000 alloc'd
==118
--- Comment #7 from manu at gcc dot gnu dot org 2006-11-24 01:50 ---
Subject: Bug 2707
Author: manu
Date: Fri Nov 24 01:50:33 2006
New Revision: 119143
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119143
Log:
2006-11-24 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/27
--- Comment #15 from manu at gcc dot gnu dot org 2006-11-24 01:50 ---
Subject: Bug 26167
Author: manu
Date: Fri Nov 24 01:50:33 2006
New Revision: 119143
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119143
Log:
2006-11-24 Manuel Lopez-Ibanez <[EMAIL PROTECTED]>
PR c/
--- Comment #16 from manu at gcc dot gnu dot org 2006-11-24 01:56 ---
Fixed in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NE
--- Comment #8 from manu at gcc dot gnu dot org 2006-11-24 01:59 ---
Fixed in mainline.
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-24 02:00 ---
No feedback in over 3 months so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-24 02:10 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-24 02:17 ---
This works for me in 4.0.4 on i686-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29883
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords||wrong-code
Summary|out of SSA (TER) extends|[4.0/4.1/4
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-24 02:23 ---
Fixed on the trunk.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Summ
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-24 02:34 ---
(In reply to comment #3)
> The C standard permits structures to have common layout for *initial* elements
> and casting between these *is* permitted. But your code is taking the
> address
> of an element in the *m
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-24 02:36 ---
As explained already this is not a bug.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-24 02:51 ---
Most likely something is being hashed by addresses and then transversing the
hashtable or an unstable sort due to using addresses as the last compare. A
lot of these issues were fixed in 4.2.0 so this might be fixed
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-11-24 03:00 ---
(In reply to comment #2)
> Confirmed.
> For "transfer(string, integer)", gfortran's transfer only uses the first
> character (byte).
> It should use all characters.
>
> -fdump-tree-original:
> value = VIEW_CONVERT
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-11-24 03:06 ---
Still fails as of today.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29958
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-11-24 03:43 ---
Reduced Testcase:
unsigned char dwarf_reg_size_table[63 +1];
init_dwarf_reg_size_table (void)
{
__builtin_init_dwarf_reg_size_table (dwarf_reg_size_table);
}
--
pinskia at gcc dot gnu dot org changed:
gcc 4.1.1 generates wrong code for following source with -O2
on sh4-linux.
'-fno-schedule-insns' fixes this problem.
int *p = 0;
void *bar()
{
return (void *)&p;
}
void foo (int code)
{
void **pp;
pp = bar();
*pp = malloc (sizeof (int));
**(int **)pp = code; /* segmentation fault here
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-11-24 06:00 ---
*pp = malloc (sizeof (int));
**(int **)pp = code; /* segmentation fault here */
You are violating aliasing rules in that "void*" does not alias "int*" so the
optimizers are swapping around the store to *pp and
--- Comment #2 from sugioka at itonet dot co dot jp 2006-11-24 06:20
---
This code is reduced from gcc/java/expr.c(add_type_assertion).
jc1 is really miscompiled on sh4-linux, so bootstrapping
libgcj fails with segmentation fault in jc1.
Should gcc/java/expr.c be fixed ?
It would be b
On Fri, 2006-11-24 at 06:20 +, sugioka at itonet dot co dot jp
wrote:
>
> --- Comment #2 from sugioka at itonet dot co dot jp 2006-11-24 06:20
> ---
> This code is reduced from gcc/java/expr.c(add_type_assertion).
> jc1 is really miscompiled on sh4-linux, so bootstrapping
> libgcj fa
--- Comment #3 from pinskia at gmail dot com 2006-11-24 06:32 ---
Subject: Re: wrong code generated with -O2 on sh4-linux
On Fri, 2006-11-24 at 06:20 +, sugioka at itonet dot co dot jp
wrote:
>
> --- Comment #2 from sugioka at itonet dot co dot jp 2006-11-24 06:20
> ---
--- Comment #4 from burnus at gcc dot gnu dot org 2006-11-24 07:19 ---
Some more points (thanks to Richard Main for pointing out):
Not all inquiry functions are allowed but only "specification inquiry" listed
in 7.1.6:
- Array inquiry (14.5.7; lbound, ubound, shape, size)
- bit_size
- l
--- Comment #4 from dannysmith at users dot sourceforge dot net 2006-11-24
07:43 ---
This works for me too, using same cygwin distro of gcc-3.4.4, same command line
(g++ -Wall -o Employee.h Employee.h -mno-cygwin), cygwin version 1.5.22.
Could it be a mmap vs .pch problem that is now
85 matches
Mail list logo
