[Bug bootstrap/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2007-10-07 03:20 ---
Sources that are obtained via

  svn merge -r HEAD:'{2007-10-01}' .

bootstrap without a problem.  I'll slide forward to 10-03.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676

[Bug rtl-optimization/33669] [4.3 Regression] Revision 128957 miscompiles 481.wrf

[zadeck at naturalbridge dot com]

--- Comment #9 from zadeck at naturalbridge dot com  2007-10-07 03:18 
---
Subject: Re:  [4.3 Regression]  Revision 128957
 miscompiles 481.wrf

hj,

here is a fix.  I will most likely post the patch on monday after i get
it really tested on a bunch of platforms.  The fix is in the third
stanza, the rest is better logging.

The failure only happens if you have a block with 2 or more uses of a
multiword pseudo register that is local to this block and has been
allocated by local_alloc.  The uses must be in a particular form: the
last use was a subreg use that only used some of the hard registers and
a previous non subreg use of the multiword register.

When all of this happens, the code did not properly expand this to a
whole multiregister when the second to last use is encounterd in the
backwards scan.

I.e. a lot of things have to happen to get this to fail.

Thanks for the small test case, that really helped.

Kenny



Index: ra-conflict.c
===
--- ra-conflict.c(revision 129036)
+++ ra-conflict.c(working copy)
@@ -76,7 +76,7 @@ record_one_conflict_between_regnos (enum
 enum machine_mode mode2, int r2)
 {
   if (dump_file)
-fprintf (dump_file, "  rocbr adding %d<=>%d\n", r1, r2);
+fprintf (dump_file, "rocbr adding %d<=>%d\n", r1, r2);
   if (reg_allocno[r1] >= 0 && reg_allocno[r2] >= 0)
 {
   int tr1 = reg_allocno[r1];
@@ -293,9 +293,6 @@ set_conflicts_for_earlyclobber (rtx insn
 recog_data.operand[use + 1]);
 }
 }
-
-  if (dump_file)
-fprintf (dump_file, "  finished early clobber conflicts.\n");
 }


@@ -876,7 +873,7 @@ global_conflicts (void)
 allocnum, renumber);
 }

-  else if (GET_ALLOCNO_LIVE (allocnos_live, allocnum) == 0)
+  else
 {
   if (dump_file)
 fprintf (dump_file, "dying pseudo\n");
@@ -963,6 +960,8 @@ global_conflicts (void)
  FIXME: We should consider either adding a new kind of
  clobber, or adding a flag to the clobber distinguish
  these two cases.  */
+  if (dump_file && VEC_length (df_ref_t, clobbers))
+fprintf (dump_file, "  clobber conflicts\n");
   for (k = VEC_length (df_ref_t, clobbers) - 1; k >= 0; k--)
 {
   struct df_ref *def = VEC_index (df_ref_t, clobbers, k);
@@ -1024,6 +1023,8 @@ global_conflicts (void)
   if (GET_CODE (PATTERN (insn)) == PARALLEL && multiple_sets
(insn))
 {
   int j;
+  if (dump_file)
+fprintf (dump_file, "  multiple sets\n");
   for (j = VEC_length (df_ref_t, dying_regs) - 1; j >= 0; j--)
 {
   int used_in_output = 0;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33669

[Bug fortran/33609] ICE on arithmetic overflow

[jvdelisle at gcc dot gnu dot org]

--- Comment #11 from jvdelisle at gcc dot gnu dot org  2007-10-06 23:49 
---
Closing, Thanks Dominique for report and testing.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609

[Bug libstdc++/33678] [4.2.0 regression] __do_catch, __do_upcast ABI change

[bkoz at gcc dot gnu dot org]

--- Comment #3 from bkoz at gcc dot gnu dot org  2007-10-06 23:48 ---
Subject: Bug 33678

Author: bkoz
Date: Sat Oct  6 23:48:31 2007
New Revision: 129061

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129061
Log:
2007-10-06  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/33678  
* libsupc++/typeinfo (typeinfo): Revert ordering of virtual components.


Modified:
branches/gcc-4_2-branch/libstdc++-v3/ChangeLog
branches/gcc-4_2-branch/libstdc++-v3/libsupc++/typeinfo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678

[Bug fortran/33609] ICE on arithmetic overflow

[jvdelisle at gcc dot gnu dot org]

--- Comment #10 from jvdelisle at gcc dot gnu dot org  2007-10-06 23:45 
---
Subject: Bug 33609

Author: jvdelisle
Date: Sat Oct  6 23:44:48 2007
New Revision: 129059

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129059
Log:
2007-10-06  Jerry DeLisle  <[EMAIL PROTECTED]>

PR fortran/33609
* simplify.c (range_check): Return gfc_bad_expr if incoming expression 
is NULL.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/simplify.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609

[Bug libstdc++/33678] [4.2.0 regression] __do_catch, __do_upcast ABI change

[bkoz at gcc dot gnu dot org]

--- Comment #2 from bkoz at gcc dot gnu dot org  2007-10-06 23:40 ---
Subject: Bug 33678

Author: bkoz
Date: Sat Oct  6 23:40:32 2007
New Revision: 129058

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129058
Log:
2007-10-06  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/33678  
* libsupc++/typeinfo (typeinfo): Revert ordering of virtual components.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/libsupc++/typeinfo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678

[Bug libfortran/33683] calculating lgamma instead of gamma

[fxcoudert at gcc dot gnu dot org]

--- Comment #2 from fxcoudert at gcc dot gnu dot org  2007-10-06 23:04 
---
I checked and the simplification routines work correctly, which means there is
no real testsuite coverage for these functions. We should always include
testcases comparing values calculated at runtime with constants coming from our
simplification routines.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33683

[Bug libfortran/33683] calculating lgamma instead of gamma

[dominiq at lps dot ens dot fr]

--- Comment #1 from dominiq at lps dot ens dot fr  2007-10-06 22:28 ---
On Darwin I get:

/usr/bin/ld: Undefined symbols:
_gammaf
collect2: ld returned 1 exit status

Target: powerpc-apple-darwin8
Configured with: ../gcc-4.3-work/configure --prefix=/opt/gcc/gcc4.3w
--mandir=/opt/gcc/gcc4.3w/share/man --infodir=/opt/gcc/gcc4.3w/share/info
--build=powerpc-apple-darwin8 --enable-languages=c,fortran --with-gmp=/sw
--with-libiconv-prefix=/sw --with-system-zlib --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.3.0 20071006 (experimental) (GCC) 

revision 129055.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33683

[Bug libfortran/33683] New: calculating lgamma instead of gamma

[tkoenig at gcc dot gnu dot org]

$ cat g.f90 
program main
  real :: x
  x = 10.
  print *,gamma(x)
end program main
$ gfortran g.f90 
$ ./a.out
   12.801827
$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../../gcc/trunk/configure --prefix=/home/ig25
--enable-languages=c,fortran --enable-mainainer-mode
Thread model: posix
gcc version 4.3.0 20071006 (experimental) (GCC)


-- 
   Summary: calculating lgamma instead of gamma
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: critical
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tkoenig at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33683

[Bug libstdc++/33682] libstdc++ broken for !__GTHREAD_HAS_COND hosts

[dannysmith at users dot sourceforge dot net]

--- Comment #1 from dannysmith at users dot sourceforge dot net  2007-10-06 
21:53 ---
The 'obvious' patch  is here:
http://gcc.gnu.org/ml/libstdc++/2007-10/msg00043.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33682

[Bug libstdc++/33682] New: libstdc++ broken for !__GTHREAD_HAS_COND hosts

[dannysmith at users dot sourceforge dot net]

../../../../gcc/libstdc++-v3/libsupc++/guard.cc:68: error: expected
initializer before '*' token
../../../../gcc/libstdc++-v3/libsupc++/guard.cc:71: error: '__cond' is
not a member of '__gnu_cxx'
../../../../gcc/libstdc++-v3/libsupc++/guard.cc:72: error: '__cond' is
not a member of '__gnu_cxx'
../../../../gcc/libstdc++-v3/libsupc++/guard.cc:73: error:
'fake_cond_t' does not name a type
../../../../gcc/libstdc++-v3/libsupc++/guard.cc: In function
'void::init_static_cond()':
../../../../gcc/libstdc++-v3/libsupc++/guard.cc:76: error:
'static_cond' was not declared in this scope


-- 
   Summary: libstdc++ broken for  !__GTHREAD_HAS_COND hosts
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
 GCC build triplet: i686-pc-mingw32
  GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33682

[Bug fortran/31608] wrong types in character array/scalar binop

[dominiq at lps dot ens dot fr]

--- Comment #24 from dominiq at lps dot ens dot fr  2007-10-06 21:47 ---
The patch in comment #22 fixes the 3 PR's, but cause a quite massive regression
on my tests, for instance:

INTEGER :: I
CHARACTER(LEN=100) :: data="1.0 3.0"
REAL :: C,D
READ(data,*) C,D
I=TRANSFER(C/D,I)
SELECT CASE(I)
CASE (TRANSFER(1.0/3.0,1))
CASE DEFAULT
 CALL ABORT()
END SELECT
END

now gives

pr31216.f90:5: internal compiler error: Segmentation Fault

and so on. I did not have the time to comb the regressions, but for 3 ICE's
fixed I have15 new ones.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608

[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-10-06 21:40 
---
Well from comment on comp.lang.fortran, I lost my argument.  :)  We move on to
fixing this.  I am not going to assign myself yet.  I need to study the how to
do it a bit more.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268

[Bug fortran/31588] gfortran should be able to output Makefile dependencies with -M* options

[tkoenig at gcc dot gnu dot org]

--- Comment #7 from tkoenig at gcc dot gnu dot org  2007-10-06 21:36 ---
For once, the segfault is in the
gfortran driver, not the f951 binary.

Backtrace, plus some more debug info:

$ gdb ~/bin/gfortran 
GNU gdb 6.6.90.20070912-debian
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1".
(gdb)  r foo.f90 -v -M
Starting program: /home/ig25/bin/gfortran foo.f90 -v -M

Program received signal SIGSEGV, Segmentation fault.
0xb7e23513 in strlen () from /lib/i686/cmov/libc.so.6
(gdb) bt
#0  0xb7e23513 in strlen () from /lib/i686/cmov/libc.so.6
#1  0x08056b56 in lang_specific_driver (in_argc=0xbfde2b08, in_argv=0xbfde2b04,
in_added_libraries=0x8079b94)
at ../../../gcc/trunk/gcc/fortran/gfortranspec.c:431
#2  0x0804f910 in process_command (argc=4, argv=0x807e938) at
../../../gcc/trunk/gcc/gcc.c:3581
#3  0x0805364e in main (argc=4, argv=0xbfde2c54) at
../../../gcc/trunk/gcc/gcc.c:6244
(gdb) up
#1  0x08056b56 in lang_specific_driver (in_argc=0xbfde2b08, in_argv=0xbfde2b04,
in_added_libraries=0x8079b94)
at ../../../gcc/trunk/gcc/fortran/gfortranspec.c:431
431   p = XNEWVEC (char, strlen (argv[i + 1]) + 2);
(gdb) p i   
$1 = 4
(gdb) p argv[0]
$2 = 0xbfde47c5 "/home/ig25/bin/gfortran"
(gdb) p argv[1]
$3 = 0xbfde47dd "foo.f90"
(gdb) p argv[2]
$4 = 0xbfde47e5 "-v"
(gdb) p argv[3]
$5 = 0xbfde47e8 "-M"
(gdb) p argv[4]
$6 = 0x0


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31588

[Bug tree-optimization/33092] [4.3 Regrsssion] Using -O1 -fno-tree-salias results in ICE

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-10-06 21:22 ---
*** Bug 33681 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||patrik dot hagglund at
   ||bredband dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33092

[Bug c/33681] ICE with -O1 -fno-tree-salias

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-06 21:22 ---


*** This bug has been marked as a duplicate of 33092 ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33681

[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-10-06 20:22 
---
Reply to comment #2:  After studying this some more.

Note that the first form of the READ has a non optional left paren.  This means
that as soon as one sees a left paren right after READ that we must be in
io-control-spec-list form.

The PRINT statement is valid because the first entity after the PRINT, must
always be a format expression, parens do not matter in the same way.

I am going to vote that this bug is invalid.  IFORT and Sun F95 also reject
this.

I will post to comp.lang.fortran for an interpretation.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268

[Bug rtl-optimization/33638] [4.3 regression]: wrong code with -fforce-addr

[zadeck at naturalbridge dot com]

--- Comment #20 from zadeck at naturalbridge dot com  2007-10-06 21:20 
---
Subject: Re:  [4.3 regression]: wrong code with
 -fforce-addr

ubizjak at gmail dot com wrote:
> --- Comment #19 from ubizjak at gmail dot com  2007-10-06 19:58 ---
> In dse.c, scan_insn(), we have:
>
>   if ((GET_CODE (PATTERN (insn)) == CLOBBER)
>   || volatile_refs_p (PATTERN (insn))
>   || (flag_non_call_exceptions && may_trap_p (PATTERN (insn)))
>   || (RTX_FRAME_RELATED_P (insn))
>   || find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX))
> insn_info->cannot_delete = true;
>
> And since the docs say that:
>
> `RTX_FRAME_RELATED_P (X)'
>  Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or
>  `set' which is part of a function prologue and sets the stack
>  pointer, sets the frame pointer, or saves a register.  This flag
>  should also be set on an instruction that sets up a temporary
>  register to use in place of the frame pointer.  Stored in the
>  `frame_related' field and printed as `/f'.
>
> I wonder if the insn that stores to (or uses(?)) this temporary register (in
> place of the frame pointer) should also be marked as frame related insn?
>
> So, all the insns in the sequence of
>
> set tmpreg, FP + const
> ...
> store (tmpreg)
>
> should be marked as frame related insns.
>
>
>   
i was not referring to the frame_related flag, though i guess it could
be taken over for this purpose.  Note that the frame_related flag is for
use by the prologue and this is not.  This is just a register that
happens to point into the frame, which i think is only ever created if
you say -fforce-addr.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638

[Bug c/33681] New: ICE with -O1 -fno-tree-salias

[patrik dot hagglund at bredband dot net]

cat > foo.c << EOF
void foo() {}
EOF
gcc -c -O1 -fno-tree-salias foo.c

foo.c: In function 'foo':
foo.c:1: internal compiler error: in verify_curr_properties, at passes.c:1044

gcc (GCC) 4.3.0 20071005 (experimental)


-- 
   Summary: ICE with -O1 -fno-tree-salias
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: patrik dot hagglund at bredband dot net


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33681

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2007-10-06 20:37 ---
Reduced testcase:
int f(int dim, int *b) {
  int newcentroid[3][dim];
  int *a = newcentroid[2];
  int i, dist=0;
  for (i=0;ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2007-10-06 20:11 ---
We do catch this earlier with checking turned on.
Reducing all the way now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680

[Bug rtl-optimization/33638] [4.3 regression]: wrong code with -fforce-addr

[ubizjak at gmail dot com]

--- Comment #19 from ubizjak at gmail dot com  2007-10-06 19:58 ---
In dse.c, scan_insn(), we have:

  if ((GET_CODE (PATTERN (insn)) == CLOBBER)
  || volatile_refs_p (PATTERN (insn))
  || (flag_non_call_exceptions && may_trap_p (PATTERN (insn)))
  || (RTX_FRAME_RELATED_P (insn))
  || find_reg_note (insn, REG_FRAME_RELATED_EXPR, NULL_RTX))
insn_info->cannot_delete = true;

And since the docs say that:

`RTX_FRAME_RELATED_P (X)'
 Nonzero in an `insn', `call_insn', `jump_insn', `barrier', or
 `set' which is part of a function prologue and sets the stack
 pointer, sets the frame pointer, or saves a register.  This flag
 should also be set on an instruction that sets up a temporary
 register to use in place of the frame pointer.  Stored in the
 `frame_related' field and printed as `/f'.

I wonder if the insn that stores to (or uses(?)) this temporary register (in
place of the frame pointer) should also be marked as frame related insn?

So, all the insns in the sequence of

set tmpreg, FP + const
...
store (tmpreg)

should be marked as frame related insns.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg (vectorizer)

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2007-10-06 19:37 ---
Vectorizer produces invalid Gimple SSA code:

  D.1769_169 = D.1599 /[ex] 4;

D.1599 should be renamed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||dorit at gcc dot gnu dot org
Summary|[4.3 Regression] ICE when   |[4.3 Regression] ICE when
   |compilling elbg.c from  |compilling elbg.c from
   |ffmpeg  |ffmpeg (vectorizer)


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680

[Bug tree-optimization/33680] [4.3 Regression] ICE when compilling elbg.c from ffmpeg

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2007-10-06 19:09 ---
Reducing.

Inside tree dce we have a statment as a DECL which seems wrong.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|middle-end  |tree-optimization
   Keywords||ice-on-valid-code
Summary|ICE when compilling elbg.c  |[4.3 Regression] ICE when
   |from ffmpeg |compilling elbg.c from
   ||ffmpeg
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680

[Bug bootstrap/33676] libgfortran bootstrap failure: selected_int_kind.f90:22: Segmentation fault

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2007-10-06 18:59 ---
Sigh.  GCC appears to be miscompiling itself on i386-*-freebsd.

configure --disable-bootstrap
make

Builds a working compiler

configure
make bootstrap
dies.


-- 

kargl at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-06 18:59:19
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676

[Bug fortran/33609] ICE on arithmetic overflow

[jvdelisle at gcc dot gnu dot org]

--- Comment #9 from jvdelisle at gcc dot gnu dot org  2007-10-06 18:49 
---
Might as well assign myself


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jvdelisle at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-06 17:36:18 |2007-10-06 18:49:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609

[Bug middle-end/33680] ICE when compilling elbg.c from ffmpeg

[ismail at pardus dot org dot tr]

--- Comment #1 from ismail at pardus dot org dot tr  2007-10-06 18:18 
---
Created an attachment (id=14312)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14312&action=view)
elbg.i produced with -save-temps


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680

[Bug middle-end/33680] New: ICE when compilling elbg.c from ffmpeg

[ismail at pardus dot org dot tr]

Looks like ffmpeg should be added to gcc testsuite. Just another ICE :

[/packages/mplayer/libavcodec]> cc -I../libswscale -I../libavcodec 
-DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE
-I.. -I.. -I../libavutil -Wdisabled-optimization -Wno-pointer-sign
-Wdeclaration-after-statement -I. -I.. -I../libavutil -Wall -Wno-switch
-Wpointer-arith -Wredundant-decls -O4 -march=native -mtune=native -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DHAVE_CONFIG_H -I/usr/include/ 
-I/usr/include/SDL  -D_REENTRANT  -I/usr/include/freetype2 -I/usr/include  -c
-o elbg.o elbg.c
elbg.c: In function 'try_shift_candidate':
elbg.c:245: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr/lib/gcc-snapshot --disable-libgcj
--disable-libssp --disable-nls --disable-werror --disable-checking
--enable-clocale=gnu --enable-__cxa_atexit
--enable-languages=c,c++,fortran,objc --enable-libstdcxx-allocator=new
--enable-shared --enable-ssp --enable-threads=posix
--enable-version-specific-runtime-libs --without-included-gettext
--without-system-libunwind --with-system-zlib
Thread model: posix
gcc version 4.3.0 20071005 (experimental) (GCC)


-- 
   Summary: ICE when compilling elbg.c from ffmpeg
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ismail at pardus dot org dot tr


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33680

[Bug fortran/33609] ICE on arithmetic overflow

[jvdelisle at gcc dot gnu dot org]

--- Comment #8 from jvdelisle at gcc dot gnu dot org  2007-10-06 18:04 
---
The following fixes this:

Index: simplify.c
===
--- simplify.c  (revision 129029)
+++ simplify.c  (working copy)
@@ -70,6 +70,9 @@ gfc_expr gfc_bad_expr;
 static gfc_expr *
 range_check (gfc_expr *result, const char *name)
 {
+  if (result == NULL)
+return &gfc_bad_expr;
+
   switch (gfc_range_check (result))
 {
   case ARITH_OK:


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609

[Bug fortran/33609] ICE on arithmetic overflow

[jvdelisle at gcc dot gnu dot org]

--- Comment #7 from jvdelisle at gcc dot gnu dot org  2007-10-06 17:36 
---
Nevermind above comment, I can reproduce the problem with:

print *, real(huge(1.0_8),4)
end

(gdb) bt
#0  gfc_range_check (e=0x0) at ../../gcc43/gcc/fortran/arith.c:524
#1  0x00464f29 in range_check (result=0x0, name=0xb5e935 "REAL")
at ../../gcc43/gcc/fortran/simplify.c:73
#2  0x00427ceb in do_simplify (specific=0xfd6108, e=0x1059df0)
at ../../gcc43/gcc/fortran/intrinsic.c:3179
#3  0x00428b1a in gfc_intrinsic_func_interface (expr=0x1059df0, 
error_flag=1) at ../../gcc43/gcc/fortran/intrinsic.c:3437
#4  0x0045b3ad in gfc_resolve_expr (e=0x1059df0)
at ../../gcc43/gcc/fortran/resolve.c:1568
#5  0x0045e63a in resolve_code (code=0xfc2e80, ns=0x10592b0)
at ../../gcc43/gcc/fortran/resolve.c:5988


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2007-10-01 20:11:40 |2007-10-06 17:36:18
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609

[Bug fortran/33636] Rejects valid use of vector subscript in derived type parameter

[pault at gcc dot gnu dot org]

--- Comment #2 from pault at gcc dot gnu dot org  2007-10-06 17:17 ---
(In reply to comment #1)

Needless to say, it was developed on a 64bit machine.

Thanks, Dominique

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33636

[Bug target/33594] [4.0/4.1/4.2/4.3 regression] stack arrays not aligned on word boundaries

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2007-10-06 16:47 ---
most of the PowerPC don't enforce alignment requirements for integer
instructions (except for cache inhibited memory) so please don't use that as an
example.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug rtl-optimization/33669] [4.3 Regression] Revision 128957 miscompiles 481.wrf

[hjl at lucon dot org]

--- Comment #8 from hjl at lucon dot org  2007-10-06 16:16 ---
(In reply to comment #7)
> Subject: Re:  [4.3 Regression]  Revision 128957
>  miscompiles 481.wrf
> 
> hjl at lucon dot org wrote:
> > --- Comment #5 from hjl at lucon dot org  2007-10-06 02:07 ---
> > Kenny, does your patch
> >
> > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00124.html
> >
> > handle cases where number of consecutive hard regs needed to hold some mode 
> > > 1
> > correctly? IA32 needs 2 hard registers to hold long long and your patch
> > miscompiles the testcase in comment #4.
> >
> >
> >   
> I will look into it.  It should do this correctly.
> 

Can you take a look at

  while (regno < last)
{
  if ((!TEST_HARD_REG_BIT (hard_regs_live, regno))
  && (!TEST_HARD_REG_BIT (renumbers_live, regno))
  && ! fixed_regs[regno])
{
  if (dump_file)
fprintf (dump_file, "dying hard reg %d\n",
regno);
  if (renumbering)
SET_HARD_REG_BIT (renumbers_live, regno);
  else
SET_HARD_REG_BIT (hard_regs_live, regno);

  added = true;
}
  regno++;
}

in global_conflicts? Should it also check live_subregs before marking
a hard register is dying?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33669

[Bug libstdc++/33678] [4.2.0 regression] __do_catch, __do_upcast ABI change

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2007-10-06 16:04 ---
Created an attachment (id=14311)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14311&action=view)
fix


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678

[Bug middle-end/33679] New: Fortran front-end miscompiled?

[fxcoudert at gcc dot gnu dot org]

This one has me quite puzzled. Starting between 2007-10-02 and 2007-10-03, I
haven't been able to bootstrap with Fortran enabled due to an ICE in the
Fortran compiler for very simple testcases:

$ cat foo.f90 
integer function foo ()
end function
$ ./f951 foo.f90
foo.f90:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ ./gfortran -v
Using built-in specs.
Target: i386-pc-linux-gnu
Configured with: ../gfortran_nightbuild/trunk/configure --prefix=/tmp
--with-gmp=/home/fx/gfortran_nightbuild/software --enable-languages=c,fortran
--build=i386-pc-linux-gnu --enable-checking=release
Thread model: posix
gcc version 4.3.0 20071005 (experimental) [trunk revision 129029] (GCC)

This ICE happens all over libgfortran, which is why it breaks bootstrap. All
functions are broken, while subroutines (which return void) work fine. I doubt
that we've broken the Fortran front-end so thouroughly that it can't compile
any function on i386, yet works fine on all other targets (including i686), so
I suppose it is miscompiled. I can get a backtrace:

Program received signal SIGSEGV, Segmentation fault.
build_function_type (value_type=0x0, arg_types=0x0)
at ../../gfortran_nightbuild/trunk/gcc/tree.c:5787
5787  if (TREE_CODE (value_type) == FUNCTION_TYPE)
(gdb) bt
#0  build_function_type (value_type=0x0, arg_types=0x0)
at ../../gfortran_nightbuild/trunk/gcc/tree.c:5787
#1  0x080d9564 in gfc_get_function_type (sym=0x86b7860)
at ../../gfortran_nightbuild/trunk/gcc/fortran/trans-types.c:2039
#2  0x080bd975 in build_function_decl (sym=0x86b7860)
at ../../gfortran_nightbuild/trunk/gcc/fortran/trans-decl.c:1237
#3  0x080bea12 in gfc_create_function_decl (ns=0x873a4c8)
at ../../gfortran_nightbuild/trunk/gcc/fortran/trans-decl.c:1793
#4  0x080bfbf8 in gfc_generate_function_code (ns=0x873a4c8)
at ../../gfortran_nightbuild/trunk/gcc/fortran/trans-decl.c:3139
#5  0x08089b02 in gfc_parse_file ()
at ../../gfortran_nightbuild/trunk/gcc/fortran/parse.c:3384

but I can't get any further, because gdb becomes crazy:

(gdb) b gfc_sym_type
Breakpoint 1 at 0x80d9288: file
../../gfortran_nightbuild/trunk/gcc/fortran/trans-types.c, line 1539.
(gdb) r
Starting program: /home/fx/ibin/gcc/f951 a.f90
Warning:
Cannot insert breakpoint 1.
Error accessing memory address 0x80d9288: Input/output error.
Cannot insert breakpoint -3.
Temporarily disabling shared library breakpoints:
breakpoint #-3

The symbol looks OK, but gfc_sym_type() apparently returns a NULL_TREE, which
is not OK. I've followed that code path and function called from there, all the
way down to gfc_get_int_type(), and it looks fine.


-- 
   Summary: Fortran front-end miscompiled?
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Keywords: wrong-code, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fxcoudert at gcc dot gnu dot org
 GCC build triplet: i386-pc-linux-gnu
  GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33679

[Bug libstdc++/33678] [4.2.0 regression] __do_catch, __do_upcast ABI change

[bkoz at gcc dot gnu dot org]

-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||mark at codesourcery dot com
   Severity|normal  |blocker
   Priority|P3  |P1
   Target Milestone|--- |4.2.2


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678

[Bug libstdc++/33678] New: [4.2.0 regression] __do_catch, __do_upcast ABI change

[bkoz at gcc dot gnu dot org]

First reported by Daniel Jacobowitz here:
http://gcc.gnu.org/ml/libstdc++/2007-10/msg00036.html

The patch is as attached.


-- 
   Summary: [4.2.0 regression] __do_catch, __do_upcast ABI change
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678

[Bug target/33594] [4.0/4.1/4.2/4.3 regression] stack arrays not aligned on word boundaries

[ebotcazou at gcc dot gnu dot org]

--- Comment #7 from ebotcazou at gcc dot gnu dot org  2007-10-06 15:44 
---
Taking care of it.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |ebotcazou at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
  GCC build triplet|sparc-sun-solaris2.10   |sparc-sun-solaris2.*
   GCC host triplet|sparc-sun-solaris2.10   |sparc-sun-solaris2.*
 GCC target triplet|sparc-sun-solaris2.10   |sparc-sun-solaris2.*
   Last reconfirmed|2007-10-06 15:42:42 |2007-10-06 15:44:34
   date||
Summary|Local (stack) arrays not|[4.0/4.1/4.2/4.3 regression]
   |aligned on word boundaries  |stack arrays not aligned on
   ||word boundaries


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug target/33594] Local (stack) arrays not aligned on word boundaries

[ebotcazou at gcc dot gnu dot org]

-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
  Component|c   |target
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-10-06 15:42:42
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug fortran/33609] ICE on arithmetic overflow

[jvdelisle at gcc dot gnu dot org]

--- Comment #6 from jvdelisle at gcc dot gnu dot org  2007-10-06 15:40 
---
I do not get this error on x86-64-Gnu-linux.  So I think it is target specific.
 I am at rev 129029.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33609

[Bug c/33594] Local (stack) arrays not aligned on word boundaries

[amruth dot laxman at nsn dot com]

--- Comment #6 from amruth dot laxman at nsn dot com  2007-10-06 15:37 
---
Based on the feedback below, I'd like to reopen this as an enhancement request.
Rationale for requesting this as an enhancment is as follows:
-> restoring gcc 3.x behavior will ease migration to gcc 4.x on alignment
enforcing platforms (ARM, SPARC, PPC etc.). Without this, the migration will be
painful & slow. I don't think it is in anyone's interest to stay on older
releases.
-> comments in sparc.h clearly indicate a desire to align character arrays:
/* Make strings word-aligned so strcpy from constants will be faster.  */
#define CONSTANT_ALIGNMENT(EXP, ALIGN)  \
...
/* Make arrays of chars word-aligned for the same reasons.  */
#define DATA_ALIGNMENT(TYPE, ALIGN) \
...

I have attached a patch for the SPARC platform below. This was tested on
Solaris 10, with gcc 4.1.2 and 4.2.1.
diff -cr gcc-4.2.1/gcc/config/sparc/sparc.h
gcc-4.2.1-new/gcc/config/sparc/sparc.h
*** gcc-4.2.1/gcc/config/sparc/sparc.h  Tue Oct  3 16:25:00 2006
--- gcc-4.2.1-new/gcc/config/sparc/sparc.h  Mon Oct  1 20:05:16 2007
***
*** 690,695 
--- 690,702 
 && TYPE_MODE (TREE_TYPE (TYPE)) == QImode  \
 && (ALIGN) < FASTEST_ALIGNMENT ? FASTEST_ALIGNMENT : (ALIGN))

+ /* Make stack local arrays of chars word-aligned for the same reasons.  */
+ #define LOCAL_ALIGNMENT(TYPE, ALIGN)\
+   (TREE_CODE (TYPE) == ARRAY_TYPE \
+&& TYPE_MODE (TREE_TYPE (TYPE)) == QImode  \
+&& (ALIGN) < FASTEST_ALIGNMENT ? FASTEST_ALIGNMENT : (ALIGN))
+ 
+ 
  /* Set this nonzero if move instructions will actually fail to work
 when given unaligned data.  */
  #define STRICT_ALIGNMENT 1


-- 

amruth dot laxman at nsn dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33594

[Bug libstdc++/33489] parallel v3: not default constructable issues

[bkoz at gcc dot gnu dot org]

--- Comment #5 from bkoz at gcc dot gnu dot org  2007-10-06 15:31 ---
Created an attachment (id=14310)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14310&action=view)
partial fix


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33489

[Bug target/28074] -mstackrealign generates inefficient code

[hjl at lucon dot org]

--- Comment #5 from hjl at lucon dot org  2007-10-06 15:21 ---
(In reply to comment #3)
> The testcase is slightly uninformative.
> 
> Note, that %esp is aligned here and %ebp is potentially not (thus locals are
> accessed via %esp).
> 
> What if:
> 
> 1. We have dinamic size alloca() call
> 2. We have incoming arguments. How are they referenced? Via %ebp?

%ebp isn't really required since -fomit-frame-pointer works for x86. We
have the original stack pointer in %ebp, which can be used to access
arguments. The aligned stack pointer in %esp can be used for local.

[EMAIL PROTECTED] align-4]$ cat x.c
#include 

extern void bar (char *);

char *
e1 (float x, char *p)
{
  volatile __m128 dummy = _mm_set_ps1(x);
  char foo [0];
  bar (foo);
  return p;
}
[EMAIL PROTECTED] align-4]$ /opt/intel/cc/10.0/bin/icc -S -O x.c
[EMAIL PROTECTED] align-4]$ cat icc.s
e1:
pushl %ebp
movl  %esp, %ebp
andl  $-16, %esp
subl  $32, %esp
movss 8(%ebp), %xmm0
lea   16(%esp), %eax
unpcklps  %xmm0, %xmm0
unpcklps  %xmm0, %xmm0
movaps%xmm0, (%esp)
pushl %eax
call  bar
popl  %ecx
movl  12(%ebp), %eax
movl  %ebp, %esp
popl  %ebp
ret
[EMAIL PROTECTED] align-4]$ /usr/gcc-4.3/bin/gcc -m32 -O -msse2 -S 
-mstackrealign x.c
[EMAIL PROTECTED] align-4]$ cat gcc.s
e1:
leal4(%esp), %ecx
andl$-16, %esp
pushl   -4(%ecx)
pushl   %ebp
movl%esp, %ebp
subl$40, %esp
movl%ecx, -8(%ebp)
movl%ebx, -4(%ebp)
movss   (%ecx), %xmm0
movl4(%ecx), %ebx
shufps  $0, %xmm0, %xmm0
movaps  %xmm0, -24(%ebp)
leal-24(%ebp), %eax
movl%eax, (%esp)
callbar
movl%ebx, %eax
movl-8(%ebp), %ecx
movl-4(%ebp), %ebx
movl%ebp, %esp
popl%ebp
leal-4(%ecx), %esp
ret
[EMAIL PROTECTED] align-4]$

As you can see, icc generate much cleaner codes than gcc.


-- 

hjl at lucon dot org changed:

   What|Removed |Added

 CC||xuepeng dot guo at intel dot
   ||com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28074

[Bug libfortran/33055] Runtime error in INQUIRE unit existance with -fdefault-integer-8

[patchapp at dberlin dot org]

--- Comment #10 from patchapp at dberlin dot org  2007-10-06 15:11 ---
Subject: Bug number PR33055

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/2007-10/msg00081.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33055

[Bug fortran/33554] [4.3 regression] Seg.fault: Default initialization of derived type uses uninitialized values

[patchapp at dberlin dot org]

--- Comment #14 from patchapp at dberlin dot org  2007-10-06 15:10 ---
Subject: Bug number PR33554

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/2007-10/msg00030.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33554

[Bug libfortran/33253] namelist: reading back a string with apostrophe

[patchapp at dberlin dot org]

--- Comment #17 from patchapp at dberlin dot org  2007-10-06 15:10 ---
Subject: Bug number PR33253

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/2007-10/msg00011.html


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33253

[Bug libstdc++/33487] parallel v3: more functions not in right namespace

[bkoz at gcc dot gnu dot org]

--- Comment #4 from bkoz at gcc dot gnu dot org  2007-10-06 15:09 ---
Subject: Bug 33487

Author: bkoz
Date: Sat Oct  6 15:08:58 2007
New Revision: 129054

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129054
Log:
2007-10-06  Benjamin Kosnik  <[EMAIL PROTECTED]>

PR libstdc++/33487
* include/parallel/algorithmfwd.h (for_each, generate, generate_n,
transform, replace, replace_if, max_element, min_element, count,
count_if): Consistently construct overloads.
* include/parallel/numericfwd.h (accumulate, adjacent_difference,
inner_product): Same.
* include/parallel/algobase.h: Same.
* include/parallel/algo.h: Same.
* include/parallel/numeric: Same.

* include/bits/algorithmfwd.h: Correct find_end placement.

* docs/html/parallel_mode.html: Document some of the interface
conventions.

* include/parallel/search.h (calc_borders): Only use operator ==.

* include/parallel/algorithmfwd.h: Move __gnu_sequential bits to...
* include/parallel/tags.h: ...here, and use a using directive.

* include/parallel/random_shuffle.h: Include stl_numeric. Qualify
uses of partial_num with __gnu_sequential.

* include/parallel/tree.h: Formatting.


Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/docs/html/parallel_mode.html
trunk/libstdc++-v3/include/bits/algorithmfwd.h
trunk/libstdc++-v3/include/parallel/algo.h
trunk/libstdc++-v3/include/parallel/algobase.h
trunk/libstdc++-v3/include/parallel/algorithmfwd.h
trunk/libstdc++-v3/include/parallel/numeric
trunk/libstdc++-v3/include/parallel/numericfwd.h
trunk/libstdc++-v3/include/parallel/random_shuffle.h
trunk/libstdc++-v3/include/parallel/search.h
trunk/libstdc++-v3/include/parallel/tags.h
trunk/libstdc++-v3/include/parallel/tree.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33487

[Bug fortran/20923] gfortran slow for large array constructors

[tobi at gcc dot gnu dot org]

--- Comment #9 from tobi at gcc dot gnu dot org  2007-10-06 14:43 ---
And this looks like the right place for an attack:
/* Given an array constructor, determine if the constructor is
   constant or not by expanding it and making sure that all elements
   are constants.  This is a bit of a hack since something like (/ (i,
   i=1,1) /) will take a while as* opposed to a more clever
   function that traverses the expression tree. FIXME.  */

int
gfc_constant_ac (gfc_expr *e)
{


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug fortran/19925] Implied do-loop in an initialization expression is broken

[tobi at gcc dot gnu dot org]

--- Comment #9 from tobi at gcc dot gnu dot org  2007-10-06 14:09 ---
There's no related bug field, but it's worth mentioning that PR20923 and this
should probably be attacked at the same time.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925

[Bug fortran/20923] gfortran slow for large array constructors

[tobi at gcc dot gnu dot org]

--- Comment #8 from tobi at gcc dot gnu dot org  2007-10-06 14:08 ---
There's no related bug field, but it's worth mentioning that PR19925 and this
should probably be attacked at the same time.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

Summary|Compile time is high for the|gfortran slow for large
   |following code  |array constructors


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923

[Bug c++/33677] New: Member with same name as class

[s__nakayama at infoseek dot jp]

GCC accept test1.cc. But GCC reject test2.cc.
IMHO, this code is valid. 

test1.cc:
struct foo
{
  ~foo(){}
  int foo;
};

test2.cc:
struct foo
{
  int foo;
  ~foo(){}
};


-- 
   Summary: Member with same name as class
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s__nakayama at infoseek dot jp


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33677

[Bug rtl-optimization/33638] [4.3 regression]: wrong code with -fforce-addr

[zadeck at naturalbridge dot com]

--- Comment #18 from zadeck at naturalbridge dot com  2007-10-06 13:07 
---
Subject: Re:  [4.3 regression]: wrong code with
 -fforce-addr

ubizjak at gmail dot com wrote:
> --- Comment #16 from ubizjak at gmail dot com  2007-10-06 06:49 ---
> (In reply to comment #14)
>   
>> The testcase works for me, that is, it produces the expected output good.out.
>> 
>
> Uh, you have to un-comment the line 315 of the comunpack.f test. The testcase,
> as attached, produces good code. Un-commenting line 315, you will get:
>
> .L80:
> movl$0x4000, (%esp)
> callpowf
> fstps   -152(%ebp)
> negl-136(%ebp)
> fildl   -136(%ebp)
> fstps   4(%esp)
> movl$0x4120, (%esp)
> callpowf
>
> Note that only one argument is loaded to the stack before first powf.
>
> Without -fforce-address on un-commented testcase, we got:
>
> .L80:
> fildl   -132(%ebp)
> fstps   4(%esp)
> movl$0x4000, (%esp)
> callpowf
> fstps   -140(%ebp)
> negl-128(%ebp)
> fildl   -128(%ebp)
> fstps   4(%esp)
> movl$0x4120, (%esp)
> callpowf
>
>
>   
ian,

As you may remember, the dse code assumes that it can "see" all of the
stores that are frame_related.   It appears that with the  -fforce-addr
option this is not true.  in this particular example, a frame related
pointer gets loaded into register 755 very early on (in a different
block) and since const calls only disqualify frame-related stores,
(since they may push params onto the stack), the parameter push is
considered dead.

My question to you, is the proper fix to check flag_force-addr and if it
is set just assume that every store may be frame related or is there
some sort of tea leaf that i might have access to know that reg 755 is
used in this way?

(note that you have to jump thru a few hoops to recreate this, since
comunpack.f is in a separate attachment from the rest of the code and
you have to uncomment line 315 to recreate the bug.)


Kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638

[Bug middle-end/33675] Badly optimized negations on x86 with -frounding-math

[bagnara at cs dot unipr dot it]

--- Comment #2 from bagnara at cs dot unipr dot it  2007-10-06 13:03 ---
I don't understand.  Do you mean that what I consider the natural compilation
of that piece of code (the shorter assembly listing) is incorrect?  In other
words: do you think that the shorter assembly listing does not properly honor
the volatile qualifier?
If so, why?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33675

[Bug rtl-optimization/33673] [4.3 Regression] ICE in verify_flow_info, missing barrier, when multiple tree opts disabled

[steven at gcc dot gnu dot org]

--- Comment #3 from steven at gcc dot gnu dot org  2007-10-06 12:36 ---
10 to 1 this is a problem with coming out of cfglayout mode somewhere.


-- 

steven at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33673

[Bug rtl-optimization/33638] [4.3 regression]: wrong code with -fforce-addr

[zadeck at naturalbridge dot com]

--- Comment #17 from zadeck at naturalbridge dot com  2007-10-06 12:27 
---
Subject: Re:  [4.3 regression]: wrong code with
 -fforce-addr

ubizjak at gmail dot com wrote:
> --- Comment #16 from ubizjak at gmail dot com  2007-10-06 06:49 ---
> (In reply to comment #14)
>   
>> The testcase works for me, that is, it produces the expected output good.out.
>> 
>
> Uh, you have to un-comment the line 315 of the comunpack.f test. The testcase,
> as attached, produces good code. Un-commenting line 315, you will get:
>
>
>   
you are making this into something of a scavenger hunt.

Kenny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33638

[Bug tree-optimization/33655] [4.3 Regression] ICE in bitfield_overlaps_p, at tree-sra.c:2901

[aoliva at gcc dot gnu dot org]

--- Comment #4 from aoliva at gcc dot gnu dot org  2007-10-06 11:48 ---
Subject: Bug 33655

Author: aoliva
Date: Sat Oct  6 11:47:51 2007
New Revision: 129052

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129052
Log:
gcc/ChangeLog:
PR tree-optimization/33655
* tree-sra.c (bitfield_overlaps_p): Handle array and complex
elements.
gcc/testsuite/ChangeLog:
PR tree-optimization/33655
* gcc.dg/torture/pr33655.c: New.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr33655.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-sra.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33655

[Bug bootstrap/33676] New: selected_int_kind.f90:22:

[gerald at pfeifer dot com]

libtool: compile:  /usr/nabil-files/pfeifer/OBJ-1003-1117/./gcc/gfortran
-B/usr/
nabil-files/pfeifer/OBJ-1003-1117/./gcc/
-B/files/pfeifer/gcc/i386-unknown-freeb
sd6.2/bin/ -B/files/pfeifer/gcc/i386-unknown-freebsd6.2/lib/ -isystem
/files/pfe
ifer/gcc/i386-unknown-freebsd6.2/include -isystem
/files/pfeifer/gcc/i386-unknow
n-freebsd6.2/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring
-fallow
-leading-underscore -g -O2 -c
/sw/test/GCC/trunk/libgfortran/intrinsics/selected
_int_kind.f90  -fPIC -o .libs/selected_int_kind.o
/sw/test/GCC/trunk/libgfortran/intrinsics/selected_int_kind.f90:22: internal
com
piler error: Segmentation fault: 11


Forcing a core dump with -dH doesn't really seem very helpful here:

% gdb ../../gcc/f951 f951.core 
(gdb) bt
#0  0x488b3ecb in kill () from /lib/libc.so.6
#1  0x488b3e68 in raise () from /lib/libc.so.6
#2  0x488b2b78 in abort () from /lib/libc.so.6
#3  0x08148fa6 in diagnostic_action_after_output (context=0x5,
diagnostic=0x662a) at /sw/test/GCC/trunk/gcc/diagnostic.c:670
#4  0x08149173 in diagnostic_report_diagnostic (context=0x8777860,
diagnostic=0xbfbfde8c) at /sw/test/GCC/trunk/gcc/diagnostic.c:425
#5  0x081492a7 in internal_error (gmsgid=0x869d6e5 "%s")
at /sw/test/GCC/trunk/gcc/diagnostic.c:606
#6  0x082c72a7 in crash_signal (signo=Variable "signo" is not available.
) at /sw/test/GCC/trunk/gcc/toplev.c:610
#7  0x0007 in ?? ()


-- 
   Summary: selected_int_kind.f90:22:
libgfortran bootstrap failure: selected_int_kind.f90:22:
internal compiler error: Segmentation fault: 11
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gerald at pfeifer dot com
  GCC host triplet: i386-unknown-freebsd5.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33676

[Bug middle-end/33675] Badly optimized negations on x86 with -frounding-math

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2007-10-06 11:45 ---
That is becasue there is a cast to volatile float which causes an extra store.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu dot
   ||org
  Component|c   |middle-end


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33675

[Bug tree-optimization/33572] [4.3 Regression] wrong code with -O

[aoliva at gcc dot gnu dot org]

--- Comment #16 from aoliva at gcc dot gnu dot org  2007-10-06 11:44 ---
Subject: Bug 33572

Author: aoliva
Date: Sat Oct  6 11:43:56 2007
New Revision: 129051

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129051
Log:
gcc/ChangeLog:
PR tree-optimization/33572
* tree-cfg.c (verify_stmts): Check for missing PHI defs.
* tree-inline.c (update_ssa_across_eh_edges): Renamed to...
(update_ssa_across_abnormal_edges): ... this.  Set slots in the
return PHI node.
(copy_edges_for_bb): Handle nonlocal label edges.
(make_nonlocal_label_edges): Deleted.
(optimize_inline_calls): Don't call it.
gcc/testsuite/ChangeLog:
PR tree-optimization/33572
* g++.dg/torture/pr33572.C: New.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr33572.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c
trunk/gcc/tree-inline.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33572

[Bug fortran/33664] crash on invalid program

[pault at gcc dot gnu dot org]

--- Comment #3 from pault at gcc dot gnu dot org  2007-10-06 11:14 ---
This fails in execution, for the same reason:

  call func_1((/1,2/), 1)
contains
  subroutine func_1(u,n)
integer :: n, u(n(1))
print *, u
  end subroutine
end

n is determined to be a function and so must be pure, since it is in a
specification expression.

Fixing this, causes char_result_7.f90 to fail.  g95 and lahey agree that this
is wrong.  I'll submit something soon... ie. just as soon as it has stopped
regtesting.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-10-05 11:15:04 |2007-10-06 11:14:40
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33664

[Bug inline-asm/33674] Nonexistent i386 register name `%SIL' used

[bonzini at gnu dot org]

--- Comment #2 from bonzini at gnu dot org  2007-10-06 10:01 ---
(which means, you should replace "=r" with "=q").

Paolo


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33674

[Bug middle-end/21032] [4.0 Regression] With -frounding-math, incorrectly reorders unary minus

[bagnara at cs dot unipr dot it]

--- Comment #25 from bagnara at cs dot unipr dot it  2007-10-06 09:51 
---
Done: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33675


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21032

[Bug c/33675] New: Badly optimized negations on x86 with -frounding-math

[bagnara at cs dot unipr dot it]

If you compile the function

void assign2(float* a, double b) {
  volatile float v = -b;
  *a = -v;
}

you will see that GCC 4.1.2, e.g., at -O2, produces

fldl12(%ebp)
fchs
movl8(%ebp), %eax
fstps   -20(%ebp)
flds-20(%ebp)
fstps   -4(%ebp)
flds-4(%ebp)
fchs
fstps   (%eax)

insted of simply

fldl12(%ebp)
fchs
fstps   -4(%ebp)
flds-4(%ebp)
fchs
fstps   (%eax)


-- 
   Summary: Badly optimized negations on x86 with -frounding-math
   Product: gcc
   Version: 4.1.2
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bagnara at cs dot unipr dot it


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33675

[Bug fortran/25076] FORALL triplet subscript must not reference any index-name

[tobi at gcc dot gnu dot org]

--- Comment #5 from tobi at gcc dot gnu dot org  2007-10-06 09:10 ---
Fixed.


-- 

tobi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.3.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25076

[Bug fortran/25076] FORALL triplet subscript must not reference any index-name

[tobi at gcc dot gnu dot org]

--- Comment #4 from tobi at gcc dot gnu dot org  2007-10-06 08:55 ---
Subject: Bug 25076

Author: tobi
Date: Sat Oct  6 08:55:30 2007
New Revision: 129050

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129050
Log:
PR fortran/25076
fortran/
* resolve.c (gfc_find_forall_index): Move towards top,
renaming to ...
(find_forall_index): ... this.  Add check for NULL expr.
(resolve_forall_iterators): Verify additional constraint.
(resolve_forall): Remove checks obsoleted by new code in
resolve_forall_iterators.
testsuite/
* gfortran.dg/forall_11.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/forall_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25076

[Bug inline-asm/10153] [3.3/3.4 regression] selection of %dil or %sil on ia32 by valid C source

[schwab at suse dot de]

--- Comment #10 from schwab at suse dot de  2007-10-06 07:50 ---
*** Bug 33674 has been marked as a duplicate of this bug. ***


-- 

schwab at suse dot de changed:

   What|Removed |Added

 CC||richardpku at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10153

[Bug inline-asm/33674] Nonexistent i386 register name `%SIL' used

[schwab at suse dot de]

--- Comment #1 from schwab at suse dot de  2007-10-06 07:50 ---


*** This bug has been marked as a duplicate of 10153 ***


-- 

schwab at suse dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33674

[Bug c/33674] New: Nonexistent i386 register name `%SIL' used

[richardpku at gmail dot com]

GCC tries to use a register `%SIL' in my test on an i386 machine. However, the
lowest 8 bits of ESI can be directly accessed only in x86-64, but not i386. I
also observe in other tests the use of another two bad register names `%DIL'
and `%BPL'.

The following code can reproduce the bug:

static inline char contain (const char *ptr, int len, char c)
{
charr;
int od,oc;
asm volatile (
"cld\n\t"
"repnz scasb\n\t"
"sete %0"
:"=r"(r),"=D"(od),"=c"(oc)
:"c"(len),"a"(c),"D"(ptr)
);
return r;
}

__attribute__((regparm(3)))
int test(int a, int b, int c, int d, const char *buf, int len, int ch)
{
d += a * b;
if (contain (buf, len, ch))
a++;
return a+b+c+d;
}


The command line and the error message:
$ gcc -save-temps -O1 -c test.c -Wall -Wextra
test.s: Assembler messages:
test.s:21: Error: bad register name `%sil'

I checked the assembly output and found that GCC had allocated `%SIL' for `r'
in function `contain'.

The following is my GCC version info:
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/lib
--without-included-gettext --enable-threads=posix --enable-nls
--with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-targets=all --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.2.1 (Debian 4.2.1-6)


-- 
   Summary: Nonexistent i386 register name `%SIL' used
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: richardpku at gmail dot com
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33674