--- Comment #1 from ismail at pardus dot org dot tr 2007-12-03 08:00
---
Also the check-localplt test fail :
cat build-default-i686-pc-linux-gnu-nptl/elf/check-localplt.out
--- ../scripts/data/localplt-i386-linux-gnu.data2006-01-30
11:29:48.0 +0200
+++ - 2007-12-03
Someone reported a problem with the Windows binaries that is related to how we
deal with CRLF-formatted module files. This issue can be reproduced on non-CRLF
systems by the following:
$ cat a.f90
module foo
end module foo
$ gfortran -c a.f90
$ cat b.f90
use foo
end
$ gfortran
--
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
The price A users storyUK Prime Minister Tony Blair has promised to give every
school university.
Mean most people will instantly recognise this as suspicious said Mr.
--- Comment #27 from bonzini at gnu dot org 2007-12-03 10:17 ---
It seems to me that the old RAW_CXX_FOR_TARGET is unused after the patch.
Can you confirm?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5291
--- Comment #5 from steven at gcc dot gnu dot org 2007-12-03 10:13 ---
Inlining is driven by heuristics. See ipa-inline.c. Heuristics cannot be
perfect for all applications, of course. The current tuning of the heuristics
is based on SPEC2k scores on Opteron, i.e. mostly for programs
--- Comment #1 from jakub at gcc dot gnu dot org 2007-12-03 10:46 ---
Subject: Bug 34317
Author: jakub
Date: Mon Dec 3 10:45:53 2007
New Revision: 130579
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130579
Log:
PR middle-end/34317
* opts.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-03 10:46 ---
Can you provide a testcase please?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ismail at pardus dot org dot tr 2007-12-03 11:01
---
Created an attachment (id=14687)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14687action=view)
glibc double test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34321
--- Comment #5 from ismail at pardus dot org dot tr 2007-12-03 11:02
---
Just run ./build.sh to build and ./test-double to run. Gives the following
error with gcc 4.3 trunk here :
testing double (without inline functions)
Failure: Real part of: csin (-0 + inf i) == -0 + inf i:
--- Comment #2 from jakub at gcc dot gnu dot org 2007-12-03 10:53 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from ismail at pardus dot org dot tr 2007-12-03 10:49
---
I will try to get two tests out of glibc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34321
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-03 11:12 ---
I see the failure with 4.1.2, 4.2.2 and 4.3 but not with 4.0.3. With
optimization
turned on, the test also succeeds.
I think this is related to PR33088.
--
rguenth at gcc dot gnu dot org changed:
--- Comment #4 from antoine64leca at hotmail dot com 2007-12-03 10:39
---
If this works for you, I will check it in.
OK, it works OK here.
Many thanks for your quick and efficient help.
Antoine
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34288
--- Comment #10 from ismail at pardus dot org dot tr 2007-12-03 11:17
---
This breaks glibc 2.7 regression tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33088
--- Comment #2 from ubizjak at gmail dot com 2007-12-03 11:25 ---
Created an attachment (id=14688)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14688action=view)
reduced c testcase
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #3 from ubizjak at gmail dot com 2007-12-03 11:28 ---
Confirmed. Register allocator issue.
--
ubizjak at gmail dot com changed:
What|Removed |Added
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-12-03 11:13 ---
In fact, it looks like the same problem.
*** This bug has been marked as a duplicate of 33088 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-12-03 11:13 ---
*** Bug 34321 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
This is similar to PR 32151
$ gfortran --version
GNU Fortran (GCC) 4.3.0 20071109 (experimental) snip
$cat aa.f90
program aa
implicit none
real(kind=8)::r1=0
if ((3*r1)**2)0) stop
end
$ gfortran -c aa.f90
aa.f90:4.14:
if ((3*r1)**2)0) stop
1
Error: Cannot assign to a named
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-03 12:56 ---
GCC 4.1 (and above) is correct, the overloaded set of resolveName should be
either the direct namespace of which A resides (the global one) or the ones
which are defined before getName.
This is the specific
--- Comment #28 from peb at mppmu dot mpg dot de 2007-12-03 12:57 ---
(In reply to comment #27)
It seems to me that the old RAW_CXX_FOR_TARGET is unused after the patch.
Can you confirm?
I don't think so. The toplevel Makefile.in contains the lines
RAW_CXX_TARGET_EXPORTS = \
--- Comment #6 from dominiq at lps dot ens dot fr 2007-12-03 12:41 ---
Form the gcc manual:
-finline-limit=n
... . The default value of n is 600. ...
This does not seem accurate: ddx and ddy are inlined for n=318, but not for
n=317 (corresponding respectively to 2.7s and 1.6s for the
--- Comment #20 from jakub at gcc dot gnu dot org 2007-12-03 13:09 ---
Andrew, do you have any testcases to back up #c17 claim?
Anyway, some things can be handled already without VCE (and it is undesirable
to generate VCE), like the #c11 testcase.
Here are 2 alternatives I've been
--- Comment #29 from bonzini at gnu dot org 2007-12-03 13:17 ---
It might be me, but I cannot see when they are used. Or better, yes, they are
used in LTCXXCOMPILE but there a few -L... switches shouldn't make any
difference, so you could use CXX_FOR_LIB also in LTCXXCOMPILE (and the
--- Comment #4 from ubizjak at gmail dot com 2007-12-03 13:45 ---
This all comes down to PR 19398. Since JamoClusterSearch() is defined as
static, gcc switches to register passing convention, and this uses %eax, %edx
and %ecx. %ebx is used as a PIC register, so we are out of QImode
--- Comment #11 from bechir dot zalila at gmail dot com 2007-12-03 14:00
---
After a lot of investigation, I succeeded to isolate the problem. The added
-mmacosx-min-version is not done when processing the CC1_SPEC: It is done in
the main function in gcc.c using the
--- Comment #10 from bechir dot zalila at gmail dot com 2007-12-03 13:54
---
Created an attachment (id=14689)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14689action=view)
Patchfile that solves the problem
This patchfile solves the problem by adding a new switch (-gnatea)
--
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 #27 from dominiq at lps dot ens dot fr 2007-12-03 14:32 ---
I have had a look at the failure of gfortran.dg/array_1.f90 with patch #5. The
following reduced code gives the same failure:
! { dg-do run }
! PR 15553 : the array used to be filled with garbage
! this problem
--- Comment #28 from dominiq at lps dot ens dot fr 2007-12-03 14:33 ---
Created an attachment (id=14691)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14691action=view)
result of -fdump-tree-optimized with patch #5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
--- Comment #26 from dominiq at lps dot ens dot fr 2007-12-03 14:08 ---
IMO, SLP should vectorize the sequence.
Uros,
What is the meaning of the above sentence?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
--- Comment #12 from bechir dot zalila at gmail dot com 2007-12-03 14:23
---
Created an attachment (id=14690)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14690action=view)
Patchfile that solves the problem
Fixed a typo in comment
--
bechir dot zalila at gmail dot com
--- Comment #29 from dominiq at lps dot ens dot fr 2007-12-03 14:34 ---
Created an attachment (id=14692)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14692action=view)
result of -fdump-tree-optimized without patch #5
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34265
--- Comment #7 from jakub at gcc dot gnu dot org 2007-12-03 15:00 ---
This isn't one bug, but many unrelated ones.
I have a fix for #c3 testcase, a fix for the p+ issue in the initial testcase
and also a different ICE with missing DECL_GIMPLE_REG_P created by parloop.
But those aren't
--- Comment #21 from jakub at gcc dot gnu dot org 2007-12-03 15:08 ---
Ping.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #5 from pault at gcc dot gnu dot org 2007-12-03 15:05 ---
(In reply to comment #4)
Just for the record, the following, very crude patch works and produces the
same output as NAG. It needs a lot of cleaning up and I should understand why
the inclusion of LEN works fine,
--- Comment #5 from bonzini at gnu dot org 2007-12-03 15:15 ---
As a start, let's limit register passing convention to regparm=2. The risk of
running out QImode registers is quite real, as is the risk of getting extremely
bad code...
--
bonzini at gnu dot org changed:
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |sam at gcc dot gnu dot org
|dot org
--- Comment #22 from hp at gcc dot gnu dot org 2007-12-03 15:23 ---
Ping for me or John David Anglin?
I suppose it's for him, as I don't see the failure on currentish (130398)
trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32636
--- Comment #13 from bechir dot zalila at gmail dot com 2007-12-03 15:26
---
Created an attachment (id=14693)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14693action=view)
Patchfile that solves the problem
Added the support of registring non-(g*m*) switches
--
bechir dot
--- Comment #2 from sam at gcc dot gnu dot org 2007-12-03 16:03 ---
This bug has been fixed in SVN trunk.
--
sam at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from sam at gcc dot gnu dot org 2007-12-03 16:02 ---
Subject: Bug 34287
Author: sam
Date: Mon Dec 3 16:01:57 2007
New Revision: 130582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130582
Log:
2007-12-03 Robert Dewar [EMAIL PROTECTED]
Samuel Tardieu
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-03 15:44 ---
Re-confirmed with SCCVN. Note that while it value numbers the COND_EXPR on
the RHS it does not simplify the condition in the COND_EXPR stmt:
Value numbering tmp_3 stmt = tmp_3 = a_2(D) 2;
Setting value number of
--- Comment #6 from jsjodin at gcc dot gnu dot org 2007-12-03 15:41 ---
Indeed the extra load disappeared when with the patch. The store did not get
deleted as expected. I looked at the differences between the good and bad
case.
After doing some more investigation an attempt to
--- Comment #2 from doko at ubuntu dot com 2007-12-03 15:56 ---
sorry, I was unclear: I changed it from -O3 -fno-strict-aliasing to -O2
-fno-strict-aliasing; didn't try -O2 alone.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34304
--- Comment #23 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-03
15:43 ---
Subject: Re: [4.3 regression] 25_algorithms/search_n/iterator.cc: pch-related
verify_ssa failure
Ping.
Sorry, I don't have an update and haven't had a chance to try the
suggestions in #20. I've been
I was surprised that gcc did not find an error in the following example.
My understanding is that assignment to a void pointer is ok, but arithmetic
is _not_ ok. I have tried this code on my arm cross compiler gcc v. 4.1.1 and
my ubuntu system compiler 4.1.3. Gcc treats the void pointer type as
--- Comment #1 from jmparker at marvell dot com 2007-12-03 16:03 ---
Created an attachment (id=14694)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14694action=view)
simple .c example
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34326
--- Comment #3 from brian at dessent dot net 2007-12-03 16:25 ---
Subject: Re: New: pointer arithmetic on void pointers does not
generate an error
This is a GNU C extension, see
http://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html. I think you can
disable it with -std=c89 or
--- Comment #30 from ubizjak at gmail dot com 2007-12-03 16:30 ---
(In reply to comment #26)
IMO, SLP should vectorize the sequence.
What is the meaning of the above sentence?
Uh, sorry for being terse. If there are no loops, then straight-line
parallelization [SLP] should vectorize
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-12-03 16:24 ---
This is a GCC extension. Use -pedantic to get a warning, -pedantic-errors to
get an error.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-12-03 16:32 ---
Instead, -fPIC should unconditionally decrease the available regparm by 1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34312
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-03 17:34 ---
Created an attachment (id=14695)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14695action=view)
testcase
This testcase fails with revision 130561.
./xgcc -B./ -O2 /tmp/hashtab.c -S -o /dev/null
(gdb) call
--- Comment #7 from rask at gcc dot gnu dot org 2007-12-03 17:52 ---
Note that reload asks for Q_REGS when the constraints allow GENERAL_REGS, so
the root cause is just reload being stupid. I bet it is this optimization from
find_reloads() that causes it:
if (! win !
I compiled the following program with the Windows port of gfortran. When I run
it in a MinGW shell, I do not see the output of the PRINT statement until after
the READ statement has been executed. The problem does not exist if the program
is run in a Cygwin shell, or in a DOS Window.
PROGRAM test
--- Comment #10 from jakub at gcc dot gnu dot org 2007-12-03 18:11 ---
The problem as I see it is that result is uninitialized in the inline routine
and in addition to that is SSA_NAME_OCCURS_IN_ABNORMAL_PHI. After inlining the
empty_stmt SSA_NAME_DEF_STMT is considered to be live from
--- Comment #31 from dominiq at lps dot ens dot fr 2007-12-03 18:58 ---
If there are no loops, then straight-line parallelization [SLP] should
vectorize
your manually unrolled sequence in comment #24.
Yes it should, but if does not after patch #5. The unanswered question so far
--- Comment #1 from burnus at gcc dot gnu dot org 2007-12-03 19:00 ---
Is screen output buffered when gfortran
Generally, gfortran buffers output. (Or more precisely, it lets the C library
do the buffering.) Seemingly, in the MinGW shell there is more buffering.
PRINT *, In the
Summary: After building 4.2.2, `make install` failed due to unrecognized
option `-Wno-overlength-strings`. Removing `-Wno-overlength-strings`
everywhere from BUILDIR/gcc/Makefile fixed it.
These are the source packages used:
gcc-core-4.2.2.tar.bz2
gcc-g++-4.2.2.tar.bz2
This is the exact command
$ cat write_formatted_stream.f90
program main
implicit none
integer :: i
open(2003,form=formatted,access=stream)
do i=1,100
write (2003,'(A)') 'a'
end do
end program main
$ gfortran write_formatted_stream.f90
$ strace -e write,read,_llseek ./a.out
read(3,
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2007-12-03 20:48
---
Instead, -fPIC should unconditionally decrease the available regparm by 1.
Yes, this seems to be the best solution in the short term.
--
ebotcazou at gcc dot gnu dot org changed:
What
--- Comment #5 from tromey at gcc dot gnu dot org 2007-12-03 21:08 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
gcc -O2 -msse -ftree-vectorize -c broken.c -o broken.o
on the code snippet below gives a broken.c:4: internal compiler error:
Segmentation fault.
extern int array[2][7][6];
void test(int type, int *eq, int idx)
{
int i;
int v = type ? 0 : 1;
for (i = 0; i 6; i++)
eq[i] =
--- Comment #3 from janis at gcc dot gnu dot org 2007-12-03 21:57 ---
The failure occurs with -m32 -O3 -maltivec -fno-strict-aliasing, but not
without -fno-strict-aliasing. That option is sometimes necessary because of
invalid code in 176.gcc, as described in
--- Comment #15 from jakub at gcc dot gnu dot org 2007-12-03 22:38 ---
Subject: Bug 29749
Author: jakub
Date: Mon Dec 3 22:38:28 2007
New Revision: 130589
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130589
Log:
PR middle-end/29749
* fold-const.c (fold_binary)
(split_constant_offset): Use POINTER_PLUS_EXPR
for pointer addition.
* tree-parloops.c (canonicalize_loop_ivs): Likewise.
(separate_decls_in_loop_name): Copy DECL_GIMPLE_REG_P from var to
var_copy.
* gcc.c-torture/compile/20071203-1.c: New test.
Added:
trunk
/* { dg-do compile } */
/* { dg-options -O3 -ftree-parallelize-loops=4 } */
struct T
{
int t;
struct { short s1, s2, s3, s4 } *s;
};
void
foo (int *a, int *b, int *c, int *d, struct T *e)
{
int i;
for (i = 0; i e-t; i++)
{
e-s[i].s1 = a[i];
e-s[i].s2 = b[i];
--- Comment #9 from jakub at gcc dot gnu dot org 2007-12-03 22:44 ---
The 2 POINTER_PLUS_EXPR bugs and DECL_GIMPLE_REG_P issue fixed, the unrelated
rest split into PR34330.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from jakub at gcc dot gnu dot org 2007-12-03 22:45 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from burnus at gcc dot gnu dot org 2007-12-03 23:15 ---
For scalar character vs. array, see also PR 32732, which added
gfc_conv_scalar_char_value(). However, I failed to get it working properly :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34246
When applied to a class declaration, __attribute((externally_visible)) should
act as if it were applied to each function or data member in the class -- just
like '__attribute((visibility(protected)))' works in GCC4.2.1. This would
allow using the -fwhole-program -fvisibility=hidden optimizations
--- Comment #3 from lauro dot venancio at gmail dot com 2007-12-03 23:42
---
I think I'm facing a related problem. GCC is emitting unaligned array elements.
struct ccstm {
int32_t val;
const char descr[];
};
static const struct ccstm canon_d30custom[] = {
{ 1, Long
--- Comment #18 from aldyh at gcc dot gnu dot org 2007-12-03 23:21 ---
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01651.html
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-12-04 02:10
---
Here we go again. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-12-04 02:36
---
I am not seeing this here:
$ strace -e write,read,_llseek ./a.out
read(3, \177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0\0\1\0\0\4\1\0\0\0\0\0...,
832) = 832
read(3,
--- Comment #32 from irar at il dot ibm dot com 2007-12-04 06:56 ---
(In reply to comment #30)
Uh, sorry for being terse. If there are no loops, then straight-line
parallelization [SLP] should vectorize your manually unrolled sequence in
comment #24.
Currently only loop-aware SLP
--- Comment #3 from tkoenig at netcologne dot de 2007-12-04 07:03 ---
Subject: Re: access=stream,form=formatted
doesn't buffer
On Tue, 2007-12-04 at 02:36 +, jvdelisle at gcc dot gnu dot org
wrote:
$ strace -e write,read,_llseek ./a.out
read(3,
--- Comment #1 from ubizjak at gmail dot com 2007-12-04 07:04 ---
Confirmed as 4.3 regression; latest mainline is a bit more informative:
gcc -O2 -msse -ftree-vectorize
pr34329.c: In function âtestâ:
pr34329.c:4: error: control flow in the middle of basic block 2
pr34329.c:4: error:
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-12-04 07:30
---
hint: I think bytes_written needs to be calculated slightly differently so that
the CR/LF is added at the end when the file is closed in close.c (close_unit_1)
stream POS specifiers are base 1 and RECL is base
--- Comment #4 from irar at il dot ibm dot com 2007-12-04 07:31 ---
(In reply to comment #3)
The failure occurs with -m32 -O3 -maltivec -fno-strict-aliasing, but not
without -fno-strict-aliasing.
Yes, I succeeded to reproduce the failure with -fno-strict-aliasing.
Thanks,
Ira
--
I was able to generate an internal error with the following code snippet:
snip
#include stdio.h
char s[]=Hello World;
#define xchg(m, in, out) \
asm(xchg%z0 %2,%0 : =g (*(m)), =r (out) : 1 (in))
int main()
{
xchg((char *)s, s[1], s[2]);
printf (%s\n,s);
}
snip
(not
83 matches
Mail list logo
