[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[Joey dot ye at intel dot com]

--- Comment #13 from Joey dot ye at intel dot com  2008-05-05 07:22 ---
It is helpful. Root cause is that memory allocated by new is only aligned to 8
bytes under i386. In your case, object Environment is allocated by new and its
constructor tried to use movdqa to initialize its members. Following small case
shows the problem:
/* Compile with option -m32 -msse2 
   Current behavior: runtime segment fault
 */
#include 
#include 

struct A {
public:
__m128i m;
void init() { m = _mm_setzero_si128(); }
};

int main()
{
A * a = new A;
printf("Address of A: %p\n", a);
a->init();
delete a;
return 0;
}


-- 


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

[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[Joey dot ye at intel dot com]

--- Comment #14 from Joey dot ye at intel dot com  2008-05-05 07:29 ---
HJ, 

AVX will have the similar problem on x86_64, whose new only returns object
aligned at 16 bytes. Dynamically allocated __m256 won't be guaranteed at 32
bytes boundary.


-- 


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

[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671

[irar at gcc dot gnu dot org]

--- Comment #12 from irar at gcc dot gnu dot org  2008-05-05 07:48 ---
Subject: Bug 36119

Author: irar
Date: Mon May  5 07:47:49 2008
New Revision: 134944

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134944
Log:
PR tree-optimization/36119
* tree-vect-transform.c (vectorizable_assignment): Set NCOPIES to 1
in case of SLP.


Added:
trunk/gcc/testsuite/gfortran.dg/vect/pr36119.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-transform.c


-- 


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

[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Comment #15 from pinskia at gcc dot gnu dot org  2008-05-05 07:49 
---
See http://gcc.gnu.org/ml/gcc/2006-10/msg00166.html and a couple others about a
way to have an aligned operator new.


-- 


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

[Bug tree-optimization/36119] [4.4 regression] internal compiler error: in vectorizable_assignment, at tree-vect-transform.c:3671

[irar at gcc dot gnu dot org]

--- Comment #13 from irar at gcc dot gnu dot org  2008-05-05 07:49 ---
Subject: Bug 36119

Author: irar
Date: Mon May  5 07:48:58 2008
New Revision: 134945

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134945
Log:
PR tree-optimization/36119
* tree-vect-transform.c (vectorizable_assignment): Set NCOPIES to 1
in case of SLP.


Added:
branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/vect/pr36119.f
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-vect-transform.c


-- 


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

[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Comment #16 from pinskia at gcc dot gnu dot org  2008-05-05 07:50 
---
malloc has the same issue really.  And from what I heard last time, glibc does
not want to change malloc to return the alignment.


-- 


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

[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[jakub at gcc dot gnu dot org]

--- Comment #17 from jakub at gcc dot gnu dot org  2008-05-05 08:53 ---
Comment #c16 doesn't make sense.  Of course malloc(3) can't be changed to
return 
alignment, that would break all programs out there, violate many standards,
etc.
There are posix_memalign and memalign, which work just fine.


-- 


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

[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[tim at klingt dot org]

--- Comment #18 from tim at klingt dot org  2008-05-05 09:09 ---
hm, if that code is broken, what about the following one on x86_64
(__sync_bool_compare_and_swap_16 requires an alignment of 16 byte)?

struct __attribute__((aligned(16))) foo_t
{
foo_t(int a = 0, int b = 0): a_(a), b_(b) {}

void CAS (foo_t const & rhs)
{
typedef int TItype __attribute__ ((mode (TI)));

union cu
{
long c[2];
TItype l;
};

cu old;
old.c[0] = (long)a_;
old.c[1] = (long)b_;

cu nw;
nw.c[0] = (long)rhs.a_;
nw.c[1] = (long)rhs.b_;


__sync_bool_compare_and_swap_16(reinterpret_cast(this), old.l, nw.l);
}

int a_, b_;
};

int main()
{
foo_t * f = new foo_t();
f->CAS(foo_t(1,2));
}

thanks, tim


-- 


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

[Bug tree-optimization/36054] bad code generation with -ftree-vectorize

[pinskia at gcc dot gnu dot org]

--- Comment #19 from pinskia at gcc dot gnu dot org  2008-05-05 09:14 
---
(In reply to comment #17)
> Comment #c16 doesn't make sense.  Of course malloc(3) can't be changed to
> return 
> alignment, that would break all programs out there, violate many standards,
> etc.

Right now malloc violates the C standard with respect of alignment.  I am not
saying we should add an alignment argument to malloc but if the standard there
is an alignment on the returned value, likewise for operator new.

-- Pinski


-- 


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

[Bug other/29975] [meta-bugs] ICEs with CP2K

[jv244 at cam dot ac dot uk]

--- Comment #154 from jv244 at cam dot ac dot uk  2008-05-05 10:31 ---
this PR remains meaningful, but indeed the component should be changed to
'other'


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

  Component|fortran |other


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

[Bug middle-end/36106] #pragma omp atomic issues with floating point types

[jakub at gcc dot gnu dot org]

--- Comment #2 from jakub at gcc dot gnu dot org  2008-05-05 10:39 ---
This is nothing target specific though, on many targets reading a float or
double sNaN into a FPU register and storing back somewhere else leads to qNaN
being stored.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |middle-end


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

[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.

[ubizjak at gmail dot com]

--- Comment #7 from ubizjak at gmail dot com  2008-05-05 10:53 ---
validate_unshare_change was introduced by:

2007-06-26  Jan Hubicka  <[EMAIL PROTECTED]>

* fwprop.c (try_fwprop_subst): Use validate_unshare_change.
* postreload.c (reload_cse_simplify_set): Instead of copying the rtx
early use validate_unshare_change.
(reload_combine): Likewise.
* recog.c (change_t): New field unshare.
(validate_change_1): Rename from validate_change; add argument unshare.
(validate_change): Turn into wrapper of validate_change_1; update
prototype for bools.
(validate_unshare_change): New.
(confirm_change_group): Unshare changes if asked for; avoid unnecesary
calls of df_insn_rescan.
* recog.h (validate_change): Replace ints by bools.
(validate_unshare_change): Declare.

The problem is, that validate_unshare_change logic creates sharing violation if
the same RTX is propagated into two places in the same insn pattern.


-- 


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

[Bug rtl-optimization/36111] [4.4 Regression] GCC 4.4.0-20080501 failed to compile openmpi's malloc.c file.

[ubizjak at gmail dot com]

--- Comment #6 from ubizjak at gmail dot com  2008-05-05 10:29 ---
This patch works for me:

Index: recog.c
===
--- recog.c (revision 134943)
+++ recog.c (working copy)
@@ -537,7 +537,8 @@ validate_replace_rtx_1 (rtx *loc, rtx fr
   || (GET_CODE (x) == GET_CODE (from) && GET_MODE (x) == GET_MODE (from)
  && rtx_equal_p (x, from)))
 {
-  validate_unshare_change (object, loc, to, 1);
+  to = copy_rtx_if_shared (to);
+  validate_change (object, loc, to, 1);
   return;
 }



-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com


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

[Bug middle-end/36129] New: ICE with -fprofile-use

[jv244 at cam dot ac dot uk]

current CP2K CVS fails to compile with [trunk revision 134945]

/data03/vondele/clean/cp2k/src/../src/atomic_kind_types.F: In function
‘read_atomic_kind’:
/data03/vondele/clean/cp2k/src/../src/atomic_kind_types.F:1158: error: Dead
histogram
IOR value ior:0.
__builtin_memset (&element_symbol[2]{lb: 1 sz: 1}, 32, 1);

/data03/vondele/clean/cp2k/src/../src/atomic_kind_types.F:1158: internal
compiler error: verify_h istograms
failed
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

when compiled with command line:

gfortran -c -fprofile-use -O3 -ffast-math -funroll-loops -ftree-vectorize
-march=native -ffree-form -D__GFORTRAN -D__FFTSG 
-D__COMPILE_ARCH="\"Linux-x86-64-gfortran\"" -D__COMPILE_DATE="\"Mon May  5
12:27:17 CEST 2008\"" -D__COMPILE_HOST="\"pcihopt3\""
-D__COMPILE_LASTCVS="\"/qs_integrate_potential.F/1.136/Fri May  2 13:45:49
2008//\"" /data03/vondele/clean/cp2k/src/../src/atomic_kind_types.F

what is the best way to get this to a reasonable testcase?


-- 
   Summary: ICE with -fprofile-use
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
 nThis:


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

[Bug libstdc++/36130] New: Atomics regression test fail to compile when parallel mode is enabled

[singler at gcc dot gnu dot org]

"make check-parallel" makes the following regression tests with respect to the
atomics library fail:

FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c (test for excess errors)
WARNING: 29_atomics/atomic_flag/test_and_set/explicit.c compilation failed to
produce executable
FAIL: 29_atomics/atomic_flag/test_and_set/implicit.c (test for excess errors)
WARNING: 29_atomics/atomic_flag/test_and_set/implicit.c compilation failed to
produce executable
FAIL: 29_atomics/headers/stdatomic.h/functions.c (test for excess errors)
FAIL: 29_atomics/headers/stdatomic.h/macros.c (test for excess errors)
FAIL: 29_atomics/headers/stdatomic.h/types.c (test for excess errors)

x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu/bits/c++config.h:190:
error: expected '=', ',', ';', 'asm' or '__attribute__' before 'std'

None of these appear for "make check".
I suspect that there is a problem with all the namespaces.


-- 
   Summary: Atomics regression test fail to compile when parallel
mode is enabled
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: singler at gcc dot gnu dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug middle-end/36129] ICE with -fprofile-use

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-05-05 12:29 ---
at least a back trace, but I guess that is not very useful:

#0  internal_error (gmsgid=0xc34369 "verify_histograms failed") at
/data03/vondele/gcc_trunk/gcc/gcc/diagnostic.c:594
#1  0x008c949d in verify_histograms () at
/data03/vondele/gcc_trunk/gcc/gcc/value-prof.c:393
#2  0x00701aab in verify_stmts () at
/data03/vondele/gcc_trunk/gcc/gcc/tree-cfg.c:4411
#3  0x008531a9 in verify_ssa (check_modified_stmt=1 '\001') at
/data03/vondele/gcc_trunk/gcc/gcc/tree-ssa.c:732
#4  0x0067886d in execute_function_todo (data=) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:970
#5  0x00678a4f in execute_todo (flags=3919132792) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:996
#6  0x00678de1 in execute_one_pass (pass=0xf09780) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1276
#7  0x00678fc5 in execute_pass_list (pass=0xf09780) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1304
#8  0x00678fdd in execute_pass_list (pass=0xf090c0) at
/data03/vondele/gcc_trunk/gcc/gcc/passes.c:1305
#9  0x00763d26 in tree_rest_of_compilation (fndecl=0x2b40e9c56c30) at
/data03/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:420
#10 0x00916f82 in cgraph_expand_function (node=0x2b40e9d83000) at
/data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1157
#11 0x00919934 in cgraph_optimize () at
/data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1220
#12 0x00483855 in gfc_be_parse_file (set_yydebug=)
at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:262


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 CC||jh at suse dot cz


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

[Bug fortran/36131] New: [4.4 Regression] wrong IO

[jv244 at cam dot ac dot uk]

gfortran [trunk revision 134945] generates wrong output for the following
testcase (derived from CP2K) :

 write(6,FMT='(T2,A,T10,A)') "23456789012345","ABC"
 END

yields:
 23456789012345ABC

instead of:
 23456789ABC345


-- 
   Summary: [4.4 Regression] wrong IO
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
 nThis:


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

[Bug middle-end/36129] ICE with -fprofile-use

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-05-05 13:11 ---
also happens if profiles are generated/used at -O2 instead of -O3


-- 


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

[Bug fortran/36132] New: [4.4 Regression] issue with _gfortran_internal_pack

[jv244 at cam dot ac dot uk]

the following testcase, derived from CP2K, illustrates an issue with
_gfortran_internal_pack. In CP2K this causes crashes such as:

Operating system error: Cannot allocate memory
Memory allocation failed

while this testcase shows under valgrind:

> gfortran -g -O0 test.f90

> valgrind --tool=memcheck ./a.out
==21339== Memcheck, a memory error detector.
==21339== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==21339== Using LibVEX rev 1732, a library for dynamic binary translation.
==21339== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==21339== Using valgrind-3.2.3, a dynamic binary instrumentation framework.
==21339== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==21339== For more details, rerun with: -v
==21339==
==21339== Conditional jump or move depends on uninitialised value(s)
==21339==at 0x4BF449B: _gfortran_internal_pack (in_pack_generic.c:56)
==21339==by 0x4008BC: __m1_MOD_s2 (test.f90:12)
==21339==by 0x400967: MAIN__ (test.f90:17)
==21339==by 0x40099B: main (fmain.c:21)
==21339==
==21339== Conditional jump or move depends on uninitialised value(s)
==21339==at 0x4008FA: __m1_MOD_s2 (test.f90:12)
==21339==by 0x400967: MAIN__ (test.f90:17)
==21339==by 0x40099B: main (fmain.c:21)


-- 
   Summary: [4.4 Regression] issue with _gfortran_internal_pack
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jv244 at cam dot ac dot uk
OtherBugsDependingO 29975
 nThis:


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

[Bug fortran/36132] [4.4 Regression] issue with _gfortran_internal_pack

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-05-05 13:25 ---
testcase:

MODULE M1
  INTEGER, PARAMETER :: dp=KIND(0.0D0)
CONTAINS
  SUBROUTINE S1(a)
 REAL(dp), DIMENSION(45), INTENT(OUT), &
  OPTIONAL   :: a
  IF (PRESENT(a)) a=0.0_dp
  END SUBROUTINE S1
  SUBROUTINE S2(a)
  REAL(dp), DIMENSION(:, :), INTENT(OUT), &
  OPTIONAL   :: a
  CALL S1(a)
  END SUBROUTINE
END MODULE M1
USE M1
REAL(dp) :: a(5,9)
CALL S2()
END


-- 


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

[Bug libfortran/36131] [4.4 Regression] wrong IO

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|fortran |libfortran
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-05 13:37:00
   date||
Summary|[4.4 Regression] wrong IO   |[4.4 Regression] wrong IO


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

[Bug c/36133] New: GCC creates suboptimal ASM : Code includes unneeded TST instructions

[gunnar at greyhound-data dot com]

Hello,

The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.


One problem that was visible in very many places was
that GCC created unnecessary TST instructions.

Please see the below example for details.
The TST.L instruction at address 36 is in the loop and unneeded.
The lsrl at address (10) and the subql #1,%d0 at address (34) do both set the
condition codes already, there is no need for using an extra TST instruction at
all.



Example: C-source
Code:
void * copy_32x4a(void *destparam, const void *srcparam, size_t size)
{
int *dest = destparam;
const int *src = srcparam;
int size32;
size32 = size / 16;
for (; size32; size32--) {
*dest++ = *src++;
*dest++ = *src++;
*dest++ = *src++;
*dest++ = *src++;
}
}

Compile option: m68k-linux-gnu-gcc -mcpu=54455 -msoft-float -o example -Os
-fomit-frame-pointer example.c

Code generated by GCC 4.2:
04:   202f 000c   movel %sp@(12),%d0
08:   226f 0004   moveal %sp@(4),%a1
0c:   206f 0008   moveal %sp@(8),%a0
10:   e888lsrl #4,%d0
12:   6022bras 36
14:   2290movel %a0@,%a1@
16:   2368 0004 0004  movel %a0@(4),%a1@(4)
1c:   2368 0008 0008  movel %a0@(8),%a1@(8)
22:   2368 000c 000c  movel %a0@(12),%a1@(12)
28:   d3fc  0010  addal #16,%a1
2e:   d1fc  0010  addal #16,%a0
34:   5380subql #1,%d0
36:   4a80tstl %d0
38:   66dabnes 14
3a:   4e75rts

For comparison here is code that you would expect:
04:   202f 000c   movel %sp@(12),%d0
08:   226f 0004   moveal %sp@(4),%a1
0c:   206f 0008   moveal %sp@(8),%a0
10:   e888lsrl #4,%d0
12:   6022beq 20
14:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
16:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
18:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
1a:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
1c:   5380subql #1,%d0
1e:   66dabnes 14
20:   4e75rts 

Compiler used:
m68k-linux-gnu-gcc -v
Using built-in specs.
Target: m68k-linux-gnu
Configured with: /scratch/shinwell/cf-fall-linux-lite/src/gcc-4.2/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=m68k-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp --disable-libgomp
--disable-libstdcxx-pch --with-arch=cf --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion=Sourcery G++ Lite 4.2-47
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux
--with-sysroot=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux/m68k-linux-gnu/libc
--with-build-sysroot=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/libc
--enable-poison-system-directories
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
Thread model: posix
gcc version 4.2.1 (Sourcery G++ Lite 4.2-47)


I hope that this report help you to improve the quality of GCC.

Kind regards

Gunnar von Boehn


-- 
   Summary: GCC creates suboptimal ASM : Code includes unneeded TST
instructions
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug fortran/36132] [4.4 Regression] issue with _gfortran_internal_pack

[burnus at gcc dot gnu dot org]

--- Comment #2 from burnus at gcc dot gnu dot org  2008-05-05 13:46 ---
I have probably a too old gfortran 4.4.0 (namely 20080424), but it does not
crash here. I see the same valgrind output using gfortran 4.1, 4.2, 4.3 and
4.4.


-- 


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

[Bug c/36134] New: GCC creates suboptimal ASM : usage of ADDA.L where LEA could be used

[gunnar at greyhound-data dot com]

+++ This bug was initially created as a clone of Bug #36133 +++

Hello,

The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.


One problem that was visible a lot was that GCC used ADDA.L instead using the
shorter LEA instruction.

Please see the below example for details.
In line 28 and 2E you can see that two times the ADDA.L instructions was used,
where instead the shorter LEA instruction could have been used.



Example: C-source
Code:
void * copy_32x4a(void *destparam, const void *srcparam, size_t size)
{
int *dest = destparam;
const int *src = srcparam;
int size32;
size32 = size / 16;
for (; size32; size32--) {
*dest++ = *src++;
*dest++ = *src++;
*dest++ = *src++;
*dest++ = *src++;
}
}

Compile option: m68k-linux-gnu-gcc -mcpu=54455 -msoft-float -o example -Os
-fomit-frame-pointer example.c

Code generated by GCC 4.2:
04:   202f 000c   movel %sp@(12),%d0
08:   226f 0004   moveal %sp@(4),%a1
0c:   206f 0008   moveal %sp@(8),%a0
10:   e888lsrl #4,%d0
12:   6022bras 36
14:   2290movel %a0@,%a1@
16:   2368 0004 0004  movel %a0@(4),%a1@(4)
1c:   2368 0008 0008  movel %a0@(8),%a1@(8)
22:   2368 000c 000c  movel %a0@(12),%a1@(12)
28:   d3fc  0010  addal #16,%a1
2e:   d1fc  0010  addal #16,%a0
34:   5380subql #1,%d0
36:   4a80tstl %d0
38:   66dabnes 14
3a:   4e75rts

For comparison here is code that you would expect:
04:   202f 000c   movel %sp@(12),%d0
08:   226f 0004   moveal %sp@(4),%a1
0c:   206f 0008   moveal %sp@(8),%a0
10:   e888lsrl #4,%d0
12:   6022beq 20
14:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
16:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
18:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
1a:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
1c:   5380subql #1,%d0
1e:   66dabnes 14
20:   4e75rts 

Compiler used:
m68k-linux-gnu-gcc -v
Using built-in specs.
Target: m68k-linux-gnu
Configured with: /scratch/shinwell/cf-fall-linux-lite/src/gcc-4.2/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=m68k-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp --disable-libgomp
--disable-libstdcxx-pch --with-arch=cf --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion=Sourcery G++ Lite 4.2-47
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux
--with-sysroot=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux/m68k-linux-gnu/libc
--with-build-sysroot=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/libc
--enable-poison-system-directories
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
Thread model: posix
gcc version 4.2.1 (Sourcery G++ Lite 4.2-47)


I hope that this report help you to improve the quality of GCC.

Kind regards

Gunnar von Boehn
--
P.S. I put the noticed issues in indivitual tivkets for easier tracking. I hope
that this is helpfull.


-- 
   Summary: GCC creates suboptimal ASM : usage of ADDA.L where LEA
could be used
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug c/36135] New: GCC creates suboptimal ASM : suboptimal Adressing-Modes used

[gunnar at greyhound-data dot com]

+++ This bug was initially created as a clone of Bug #36133 +++

Hello,

The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.


One problem that was visible a lot was that GCC uses suboptimal addressing
modes.

Please see the below example for details.
In line 14 to line 2E this code was created:
14:   2290movel %a0@,%a1@
16:   2368 0004 0004  movel %a0@(4),%a1@(4)
1c:   2368 0008 0008  movel %a0@(8),%a1@(8)
22:   2368 000c 000c  movel %a0@(12),%a1@(12)
28:   d3fc  0010  addal #16,%a1
2e:   d1fc  0010  addal #16,%a0

Much shorter and more efficient would have been this:
14:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
16:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
18:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
1a:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]


Example: C-source
Code:
void * copy_32x4a(void *destparam, const void *srcparam, size_t size)
{
int *dest = destparam;
const int *src = srcparam;
int size32;
size32 = size / 16;
for (; size32; size32--) {
*dest++ = *src++;
*dest++ = *src++;
*dest++ = *src++;
*dest++ = *src++;
}
}

Compile option: m68k-linux-gnu-gcc -mcpu=54455 -msoft-float -o example -Os
-fomit-frame-pointer example.c

Code generated by GCC 4.2:
04:   202f 000c   movel %sp@(12),%d0
08:   226f 0004   moveal %sp@(4),%a1
0c:   206f 0008   moveal %sp@(8),%a0
10:   e888lsrl #4,%d0
12:   6022bras 36
14:   2290movel %a0@,%a1@
16:   2368 0004 0004  movel %a0@(4),%a1@(4)
1c:   2368 0008 0008  movel %a0@(8),%a1@(8)
22:   2368 000c 000c  movel %a0@(12),%a1@(12)
28:   d3fc  0010  addal #16,%a1
2e:   d1fc  0010  addal #16,%a0
34:   5380subql #1,%d0
36:   4a80tstl %d0
38:   66dabnes 14
3a:   4e75rts

For comparison here is code that you would expect:
04:   202f 000c   movel %sp@(12),%d0
08:   226f 0004   moveal %sp@(4),%a1
0c:   206f 0008   moveal %sp@(8),%a0
10:   e888lsrl #4,%d0
12:   6022beq 20
14:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
16:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
18:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
1a:   20d9movel [EMAIL PROTECTED],[EMAIL PROTECTED]
1c:   5380subql #1,%d0
1e:   66dabnes 14
20:   4e75rts 

Compiler used:
m68k-linux-gnu-gcc -v
Using built-in specs.
Target: m68k-linux-gnu
Configured with: /scratch/shinwell/cf-fall-linux-lite/src/gcc-4.2/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=m68k-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp --disable-libgomp
--disable-libstdcxx-pch --with-arch=cf --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion=Sourcery G++ Lite 4.2-47
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux
--with-sysroot=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux/m68k-linux-gnu/libc
--with-build-sysroot=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/libc
--enable-poison-system-directories
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
Thread model: posix
gcc version 4.2.1 (Sourcery G++ Lite 4.2-47)


I hope that this report help you to improve the quality of GCC.

Kind regards

Gunnar von Boehn
--
P.S. I put the noticed issues in individual tickets for easier tracking. I hope
that this is helpful to you.


-- 
   Summary: GCC creates suboptimal ASM : suboptimal Adressing-Modes
used
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug c/36136] New: GCC creates suboptimal ASM : constant work registers are set up inside work loops and not outside of the loop

[gunnar at greyhound-data dot com]

+++ This bug was initially created as a clone of Bug #36133 +++

Hello,

The ASM code created by GCC 4.2.1 for 68k/Coldfire platform is not optimal.
Comparing ASM output created by GCC 2.9 with GCC 4.2,
the generated code got partially much worse with GCC 4.


One problem that was visible a lot was that GCC set ups constant work registers
inside of working loops and not outside of them.
At address (1c): the instruction moveq #1,%d1 to set up the work register is
inside the working loop and will be unneeded executed with very iteration.

Second problem:
At address (16) the instruction movel #1,%a0@ uses the literal value #1 and not
the work register that has the same value. The literal move.l #1 has a length
of 6 bytes while using the work register would have 2 bytes only.


Example: C-source
Code:
void * write_32x4(void *destparam, const void *srcparam, size_t size)
{
int  value=1;
int *dst = destparam;
size = size / 16;
for (; size; size--) {
 *dst++=value;
 *dst++=value;
 *dst++=value;
 *dst++=value;
}
} 
Compile option: m68k-linux-gnu-gcc -mcpu=54455 -msoft-float -o example -Os
-fomit-frame-pointer example.c

Code generated by GCC 4.2:
:
0a:   202f 000c   movel %sp@(12),%d0
0e:   206f 0004   moveal %sp@(4),%a0
12:   e888lsrl #4,%d0
14:   601cbras 32
16:   20bc  0001  movel #1,%a0@
1c:   7201moveq #1,%d1
1e:   2141 0004   movel %d1,%a0@(4)
22:   2141 0008   movel %d1,%a0@(8)
26:   2141 000c   movel %d1,%a0@(12)
2a:   d1fc  0010  addal #16,%a0
30:   5380subql #1,%d0
32:   4a80tstl %d0
34:   66e0bnes 16
36:   4e75rts 
Generated code length = 46 Byte
Length of Workloop: 9 instructions, 32 byte 


For comparison here is code that you would expect:
0a:   202f 000c   movel %sp@(12),%d0
0e:   206f 0004   moveal %sp@(4),%a0
12:   7201moveq #1,%d1
14:   e888lsrl #4,%d0
16:   601cbeqs 24
18:   21c0movel %d1,[EMAIL PROTECTED]
1a:   21c0movel %d1,[EMAIL PROTECTED]
1c:   21c0movel %d1,[EMAIL PROTECTED]
1e:   21c0movel %d1,[EMAIL PROTECTED]
20:   5380subql #1,%d0
22:   66e0bnes 18
24:   4e75rts 
Expected code length = 28 Byte
Length of Workloop: 6 instructions, 12 byte 


Compiler used:
m68k-linux-gnu-gcc -v
Using built-in specs.
Target: m68k-linux-gnu
Configured with: /scratch/shinwell/cf-fall-linux-lite/src/gcc-4.2/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=m68k-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp --disable-libgomp
--disable-libstdcxx-pch --with-arch=cf --with-gnu-as --with-gnu-ld
--enable-languages=c,c++ --enable-shared --enable-symvers=gnu
--enable-__cxa_atexit --with-pkgversion=Sourcery G++ Lite 4.2-47
--with-bugurl=https://support.codesourcery.com/GNUToolchain/ --disable-nls
--prefix=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux
--with-sysroot=/opt/freescale/usr/local/gcc-4.2.47-eglibc-2.5.47/m68k-linux/m68k-linux-gnu/libc
--with-build-sysroot=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/libc
--enable-poison-system-directories
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
--with-build-time-tools=/scratch/shinwell/cf-fall-linux-lite/install/m68k-linux-gnu/bin
Thread model: posix
gcc version 4.2.1 (Sourcery G++ Lite 4.2-47)


I hope that this report help you to improve the quality of GCC.

Kind regards

Gunnar von Boehn
--
P.S. I put the noticed issues in individual tickets for easier tracking. I hope
that this is helpful to you.


-- 
   Summary: GCC creates suboptimal ASM : constant work registers are
set up inside work loops and not outside of the loop
   Product: gcc
   Version: 4.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gunnar at greyhound-data dot com
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-linux-gnu


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

[Bug libfortran/36131] [4.4 Regression] wrong IO

[burnus at gcc dot gnu dot org]

-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org
   Keywords||wrong-code
  Known to fail||4.4.0
  Known to work||4.2.2 4.1.3 4.3.0
   Target Milestone|--- |4.4.0


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

[Bug c/36137] New: gcc can't do math

[otte at gnome dot org]

The attached program prints (unsigned) -1 as opposed to 1.
This doesn't happen if intermediate variables are used somewhere in the
process.

I tested gcc 3.4, 4.2.3 (on both x86 and x86-64) with -O0 and -O2, all ended up
with -1.
suncc printed 1.


-- 
   Summary: gcc can't do math
   Product: gcc
   Version: 4.2.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: otte at gnome dot org
 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=36137

[Bug c/36137] gcc can't do math

[otte at gnome dot org]

--- Comment #1 from otte at gnome dot org  2008-05-05 14:17 ---
Created an attachment (id=15581)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15581&action=view)
testcase


-- 


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

[Bug tree-optimization/36138] New: [4.4 Regression]: FAIL: g++.dg/opt/pr30965.C

[hjl dot tools at gmail dot com]

Gcc 4.4 revision 134946 has

FAIL: g++.dg/opt/pr30965.C scan-tree-dump-times optimized ";; Function" 2

I think it is caused by revision 134859:

http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00019.html


-- 
   Summary: [4.4 Regression]: FAIL: g++.dg/opt/pr30965.C
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug libfortran/36131] [4.4 Regression] wrong IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-05-05 14:49 
---
I will have a look.  Odd, I don't recall anything going near this recently.


-- 

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|2008-05-05 13:37:00 |2008-05-05 14:49:53
   date||


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

[Bug middle-end/35973] Incorrect warning: will never be executed

[dot at dotat dot at]

--- Comment #3 from dot at dotat dot at  2008-05-05 14:52 ---
The code is executed when the function selog_on() returns true. The warning is
also inconsistent, which also points to an analysis bug.


-- 

dot at dotat dot at changed:

   What|Removed |Added

 CC||dot at dotat dot at
 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug fortran/36132] issue with _gfortran_internal_pack

[jv244 at cam dot ac dot uk]

--- Comment #3 from jv244 at cam dot ac dot uk  2008-05-05 15:28 ---
right, it is actually new CP2K code since I checked 4.3. No regression thus.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

Summary|[4.4 Regression] issue with |issue with
   |_gfortran_internal_pack |_gfortran_internal_pack


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

[Bug target/36106] #pragma omp atomic issues with floating point types

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-05 15:40 ---
That sounds like a bug in the target back-ends for not storing exactly the
bit-wise for NaNs.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|middle-end  |target


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

[Bug middle-end/36106] #pragma omp atomic issues with floating point types

[jakub at gcc dot gnu dot org]

--- Comment #4 from jakub at gcc dot gnu dot org  2008-05-05 15:47 ---
Not really, as IEEE754 mandates turning sNaN into qNaN after raising the
exception.  I have a fix in the works in omp-low.c (so far works for non-SSA
and not yet for -ftree-parallelize-loops) and that's middle-end.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

  Component|target  |middle-end


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

[Bug fortran/35997] [4.3/4.4 regression] Used function interface bug

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P4


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

[Bug target/36079] [4.3/4.4 Regression] cld instruction is not emitted anymore.

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P1


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

[Bug c/35961] Erroneous error message using gcc-4.3.0 when signedness warning thrown

[tj at castaglia dot org]

--- Comment #2 from tj at castaglia dot org  2008-05-05 16:11 ---
What was the reasoning behind this change in behavior?  It violates the
principle of least surprise, and will cause problems for e.g. configure scripts
which use simple tests to determine whether the system's compiler accepts a
particular command-line option.


-- 

tj at castaglia dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug other/28322] GCC new warnings and compatibility

[pinskia at gcc dot gnu dot org]

--- Comment #18 from pinskia at gcc dot gnu dot org  2008-05-05 16:15 
---
*** Bug 35961 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tj at castaglia dot org


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

[Bug c/35961] Erroneous error message using gcc-4.3.0 when signedness warning thrown

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-05 16:15 ---
(In reply to comment #2)
> What was the reasoning behind this change in behavior?

See PR 28322.

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


-- 

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=35961

gcc-4.3.0 stdio.h: No such file or directory

[sebastian]

Hello.
At compiling gcc-4.3.0 with   ../gcc-4.3.0/./configure prefix=/I get this 
error:

--
...
checking whether the target asssembler upports thread-local storage... yes
updating cache ./config.cache
configure: creating ./config.status
config.status: creating Makefile
config.status: executing default commands
Adding multilib support to Makefile in ../../../gcc-4.3.0/./libgcc
multidirs=
with_multisubdir=
make[3]: Entering directory `/prog/GCC/build2/i686-pc-linux-gnu/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
make[4]: Entering directory `/prog/GCC/build2/i686-pc-linux-gnu/libgcc'
if [ -z "" ]; then
  true;
else
  rootpre=`${PWDCMD-pwd}`/; export rootpre;
  srcrootpre=`cd ../../../gcc-4.3.0/./libgcc; ${PWDCMD-pwd}`/; export 
srcrootpre;
  lib=`echo "${rootpre}" | sed -e 's,^.*/([^/][^/]*)/$,1,'`;
  
compiler="/prog/GCC/build2/./gcc/xgcc -B/prog/GCC/build2/./gcc/ 
-B//i686-pc-linux-gnu/bin/ -B//i686-pc-linux-gnu/lib/ -isystem 
//i686-pc-linux-gnu/include -isystem //i686-pc-linux-gnu/sys-include";
  for i in `${compiler} --print-multi-lib 2>/dev/null`; do
dir=`echo $i | sed -e 's/;.*$//'`;
if [ "${dir}" = "." ]; then
  true;
else
  if [ -d ../${dir}/${lib} ]; then
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`;
if (cd ../${dir}/${lib}; 
make "AR=//i686-pc-linux-gnu/bin/ar" "AR_FLAGS=rc" 
"CC=/prog/GCC/build2/./gcc/xgcc -B/prog/GCC/build2/./gcc/ 
-B//i686-pc-linux-gnu/bin/ -B//i686-pc-linux-gnu/lib/ -isystem 
//i686-pc-linux-gnu/include -isystem //i686-pc-linux-gnu/sys-include" 
"CFLAGS=-g -fkeep-inline-functions" "DESTDIR=" "EXTRA_OFILES=" "HDEFINES=" 
"INSTALL=/bin/install -c" "INSTALL_DATA=/bin/install -c -m 
644" "INSTALL_PROGRAM=/bin/install -c" "LDFLAGS=" "LOADLIBES=" 
"RANLIB=//i686-pc-linux-gnu/bin/ranlib" "SHELL=/bin/sh" "prefix=/" 
"exec_prefix=/" "libdir=//lib" "libsubdir=//lib/gcc/i686-pc-linux-gnu/4.3.0" 
"tooldir=//i686-pc-linux-gnu"
CFLAGS="-g -fkeep-inline-functions ${flags}"
CCASFLAGS=" ${flags}"
FCFLAGS=" ${flags}"
FFLAGS=" ${flags}"
ADAFLAGS=" ${flags}"
prefix="/"
exec_prefix="/"
GCJFLAGS=" ${flags}"
CXXFLAGS="-g -O2   -D_GNU_SOURCE ${flags}"
LIBCFLAGS="-g -fkeep-inline-functions 
${flags}"

LIBCXXFLAGS="-g -O2   -D_GNU_SOURCE -fno-implicit-templates ${flags}"
LDFLAGS=" ${flags}"
MULTIFLAGS="${flags}"
DESTDIR=""
INSTALL="/bin/install -c"
INSTALL_DATA="/bin/install -c -m 644"
INSTALL_PROGRAM="/bin/install -c"
INSTALL_SCRIPT="/bin/install -c"
all); then
  true;
else
  exit 1;
fi;
  else true;
  fi;
fi;
  done;
fi
make[4]: Leaving directory `/prog/GCC/build2/i686-pc-linux-gnu/libgcc'
/prog/GCC/build2/./gcc/xgcc -B/prog/GCC/build2/./gcc/ 
-B//i686-pc-linux-gnu/bin/ -B//i686-pc-linux-gnu/lib/ -isystem 
//i686-pc-linux-gnu/include -isystem //i686-pc-linux-gnu/sys-include -g 
-fkeep-inline-functions -O2  -O2 -g -g -O2   -DIN_GCC-W -Wall 
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition 
 -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../.././gcc -I../../../gcc-4.3.0/./libgcc 
-I../../../gcc-4.3.0/./libgcc/. -I../../../gcc-4.3.0/./libgcc/../gcc 
-I../../../gcc-4.3.0/./libgcc/../include 
-I../../../gcc-4.3.0/./libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT 
-DHAVE_CC_TLS -DUSE_TLS -o 
_muldi3.o -MT _muldi3.o -MD -MP -MF 
_muldi3.dep -DL_muldi3 -c ../../../gcc-4.3.0/./libgcc/../gcc/libgcc2.c
  -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../gcc-4.3.0/./libgcc/../gcc/libgcc2.c:33:
../../../gcc-4.3.0/./libgcc/../gcc/tsystem.h:90:19: error: stdio.h: No such 
file or directory
../../../gcc-4.3.0/./libgcc/../gcc/tsystem.h:93:23: error: sys/types.h: No 
such file or directory
../../../gcc-4.3.0/./libgcc/../gcc/tsystem.h:96:19: error: errno.h: No such 
file or directory
../../../gcc-4.3.0/./libgcc/../gcc/tsystem.h:103:20: error: string.h: No such 
file or directory
../../../gcc-4.3.0/./libgcc/../gcc/tsystem.h:104:20: error: stdlib.h: No such 
file or directory
../../../gcc-4.3.0/./libgcc/../gcc/tsystem.h:105:20: error: unistd.h: No such 
file or directory
../../../gcc-4.3.0/

[Bug fortran/36139] New: ICE in snapshot of 05/02/08 under HPPA Linux with IMPLICIT, PARAMETER, and function call

[michael dot a dot richmond at nasa dot gov]

The 05/02/08 snapshot of gfortran 4.4.0 produces a variety of bugs on different
platforms. The bug described here is specific to HPPA Linux.

The following subroutine segfaults when I type "gfortran -c mnbrak.f90":

SUBROUTINE mnbrak
IMPLICIT REAL(a-f)
PARAMETER(a=0.0)
f=func()
END SUBROUTINE mnbrak

The following function segfaults when I type "gfortran -c -ffree-form
qgobfu.f". It does not segfault when I type "gfortran -c qgobfu.f":

  LOGICAL FUNCTION qgobfu()
  IMPLICIT INTEGER (A-B,F), LOGICAL (Q)
  PARAMETER (flnmlm=5)
  qok = qgtchr()
  END FUNCTION qgobfu


-- 
   Summary: ICE in snapshot of 05/02/08 under HPPA Linux with
IMPLICIT, PARAMETER, and function call
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug fortran/35997] [4.3/4.4 regression] Used function interface bug

[burnus at gcc dot gnu dot org]

--- Comment #4 from burnus at gcc dot gnu dot org  2008-05-05 17:05 ---
It would be nice if this could go into 4.3.1; its release was scheduled for
today, but it got delayed by three P1 regressions.


-- 


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

[Bug other/28322] GCC new warnings and compatibility

[pmaydell at chiark dot greenend dot org dot uk]

--- Comment #19 from pmaydell at chiark dot greenend dot org dot uk  
2008-05-05 17:57 ---
Bug 35961 does suggest that we didn't quite get this patch right, though:
  At top level:
  cc1: error: unrecognized command line option "-Wno-long-double"

The deferred 'unrecognised -Wno*' output should only be a warning, not an
error. (In particular, it shouldn't cause compilation to fail if it would
otherwise have succeeded, which it looks as if it has done here.)


-- 


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

[Bug fortran/36140] New: ICE in snapshot of 05/02/08 under MIPS Linux with IMPLICIT LOGICAL and function call

[michael dot a dot richmond at nasa dot gov]

The following programs produce a segfault when compiled with the 05/02/08
snapshot of gfortran 4.4.0 under MIPS Linux. I believe this is related to Bug
36139, even though these programs do not segfault under HPPA, and the programs
in Bug 36139 do not segfault in MIPS.

PROGRAM kmci
IMPLICIT LOGICAL (q)
DO i = 1, 2
IF (cumsur .EQ. 0.0) GO TO 20
20 qroot = quadsl(a)
ENDDO
END PROGRAM kmci

PROGRAM summt
IMPLICIT LOGICAL (q)
qqzero(zx) = zx .EQ. 0.0
DO i = 1, 2
IF (ii .EQ. 0) CONTINUE
IF (qqzero(0.0)) CONTINUE
END DO
END PROGRAM summt


-- 
   Summary: ICE in snapshot of 05/02/08 under MIPS Linux with
IMPLICIT LOGICAL and function call
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov


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

[Bug fortran/35719] pointer to zero sized array not associated

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-05-05 18:24 ---
(In reply to comment #3)

> One possibility is to allocate something for zero-sized arrays, e.g. one
> element. The array bounds ensure than that the program still knows that the
> size of the array is zero. The extra allocation wastes memory, but usually one
> element is quite small and zero-sized arrays are not very common.

I agree in principle; but we could also allocate a single array,
like we do for ALLOCATE.

This is probably the cleanest solution.


-- 


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

[Bug bootstrap/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[hjl dot tools at gmail dot com]

-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-05 18:55 ---
Can you attach the preprocessed source?  The source is very ia64 dependent.


-- 


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

[Bug fortran/36132] _gfortran_internal_pack on optional arguments

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-05-05 18:57 ---
The problem isn't specific to in_pack, it's the
fact that we don't initialize the array descriptor
correctly.

s2 shows

  if (a != 0B)
{
  {
integer(kind=4) D.638;

D.638 = a->dim[0].stride;
stride.1 = D.638 != 0 ? D.638 : 1;

...
  }
}
so we set stride.1 only if a is present.  So far, so good.

Later, unconditionally, we have

struct array2_real(kind=8) parm.6;

...

D.633 = stride.1;
parm.6.dim[0].lbound = 1;
parm.6.dim[0].ubound = ubound.0;
parm.6.dim[0].stride = NON_LVALUE_EXPR ;
parm.6.data = (void *) &(*a.0)[0];
parm.6.offset = NON_LVALUE_EXPR ;
D.635 = _gfortran_internal_pack (&parm.6);

We need to call _gfortran_internal_pack on optional arguments
only when the optional arguments are present.

Setting subject.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-05-05 18:57:28
   date||
Summary|issue with  |_gfortran_internal_pack on
   |_gfortran_internal_pack |optional arguments


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

[Bug bootstrap/36141] New: [4.4 Regression]: Gcc 4.4 failed to boostrap

[hjl dot tools at gmail dot com]

On Linux/ia64, gcc 4.4 revision 134951 failed with
/export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/./gcc/
-B/usr/gcc-4.4/ia64-unknown-linux-gnu/bin/
-B/usr/gcc-4.4/ia64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-4.4/ia64-unknown-linux-gnu/include -isystem
/usr/gcc-4.4/ia64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I.
-I/net/gnu-13/export/gnu/src/gcc/gcc/libffi -I. -I.
-I/net/gnu-13/export/gnu/src/gcc/gcc/libffi/include -Iinclude
-I/net/gnu-13/export/gnu/src/gcc/gcc/libffi/src -Wall -g -fexceptions -g -O2
-MT src/ia64/ffi.lo -MD -MP -MF src/ia64/.deps/ffi.Tpo -c
/net/gnu-13/export/gnu/src/gcc/gcc/libffi/src/ia64/ffi.c  -fPIC -DPIC -o
src/ia64/.libs/ffi.o
/net/gnu-13/export/gnu/src/gcc/gcc/libffi/src/ia64/ffi.c: In function
'ffi_prep_closure_loc':
/net/gnu-13/export/gnu/src/gcc/gcc/libffi/src/ia64/ffi.c:408: internal compiler
error: in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:580
Please submit a full bug report, 
with preprocessed source if appropriate.
See  for instructions.

Revision 134946 is OK. I think revision 134947:

http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00219.html

is the cause.


-- 
   Summary: [4.4 Regression]: Gcc 4.4 failed to boostrap
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com
GCC target triplet: ia64-unknown-linux-gnu


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-05 19:00 ---
This libffi code is a bit weird really, we are looking into a function pointer
here.


-- 


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-05-05 19:01 ---
Created an attachment (id=15582)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15582&action=view)
A testcase

[EMAIL PROTECTED] libffi]$ /export/build/gnu/gcc/build-ia64-linux/./gcc/xgcc
-B/export/build/gnu/gcc/build-ia64-linux/./gcc/  ffi.i -S -O
/net/gnu-13/export/gnu/src/gcc/gcc/libffi/src/ia64/ffi.c: In function
‘ffi_prep_closure_loc’:
/net/gnu-13/export/gnu/src/gcc/gcc/libffi/src/ia64/ffi.c:408: internal compiler
error: in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:580
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


-- 


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

[Bug middle-end/36137] gcc can't do math

[tromey at gcc dot gnu dot org]

--- Comment #2 from tromey at gcc dot gnu dot org  2008-05-05 19:10 ---
test.c.t02.original says:

  u = MAX_EXPR <(unsigned int) i, 1>;

... but this is wrong.


-- 

tromey at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||tromey at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-05 19:10:16
   date||


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-05-05 19:20 ---
Note with the preprocessed source, I cannot reproduce this under
powerpc64-linux-gnu which means ia64 is setting FUNCTION_TYPEs' TYPE_SIZE
funny.


-- 


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #5 from hjl dot tools at gmail dot com  2008-05-05 19:35 ---
(In reply to comment #4)
> Note with the preprocessed source, I cannot reproduce this under
> powerpc64-linux-gnu which means ia64 is setting FUNCTION_TYPEs' TYPE_SIZE
> funny.
> 

Can you try it with a cross compiler for Linux/ia64? You just need
to build cc1, not the whole cross compiler.


-- 


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #6 from pinskia at gcc dot gnu dot org  2008-05-05 19:43 ---
> Can you try it with a cross compiler for Linux/ia64? You just need
> to build cc1, not the whole cross compiler

It was building right now.  

-- Pinski


-- 


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

[Bug libfortran/36142] New: T edit descriptor doesn't work for non-seekable streams

[jb at gcc dot gnu dot org]

Consider the following testcase:

! { dg-do  run }
! Adapted from fmt_t_6.f testcase for PR 34782
  character a(6)
  data a / 'a', 'b', 'c', 'd', 'e', 'f' /
  write(*,'(T20,A3,  T1,A4,  T5,A2,  T7,A2,  T9,A4, T17,A2)')
 1 'a', 'b', 'c', 'd', 'e', 'f' 
  print *, 'should be'
  write (*, '(A)') "   b c d   e f   a"
  end

gcc version 4.4.0 20080427

% ./fmtstdout.gf44
 a   b c d   e f
 should be
   b c d   e f   a

% ./fmtstdout.gf44 > foo
% cat foo
   b c d   e f   a
 should be
   b c d   e f   a


I stumbled upon this when working on part I of pr 25561. My patch regtests
cleanly except for fmt_t_6.f. However with the more strict read/write/seek
interface the kind of dirty trick that allowed T edit descriptor to work for
seekable streams won't work anymore as we don't have direct access to the
buffer. T and TL descriptors are special in that they're the only one that can
force us to go backwards in the formatted record. Or are there others?

The only way I can think of to fix this would be something like

On output, if we encounter a T or TL edit descriptor
allocate a temporary buffer, fill it with blanks (' ')
create a temporary internal unit, using the above temp buffer as the 'file'
do all the formatting to this internal unit
when the record is completed
copy the contents from the temp internal unit to the real stream
deallocate temp unit and buffer

On input there are similar concerns, but we already use
st_parameter_dt.u.p.line_buffer there.

Or then one could of course use line_buffer in the write functions just like
they are used for reading.


-- 
   Summary: T edit descriptor doesn't work for non-seekable streams
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jb at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #7 from pinskia at gcc dot gnu dot org  2008-05-05 20:49 ---
So we get:
VIEW_CONVERT_EXPR(ffi_closure_unix).code_pointer

Where we have a function_decl.

The easy fix is not to build a VCE for a function decl which I am testing right
now.  

Thanks,
Andrew Pinski


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-05 20:49:37
   date||


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #8 from pinskia at gcc dot gnu dot org  2008-05-05 20:50 ---
That is:
Index: gcc/gcc/tree-ssa-forwprop.c
===
--- gcc/gcc/tree-ssa-forwprop.c (revision 134951)
+++ gcc/gcc/tree-ssa-forwprop.c (working copy)
@@ -657,6 +657,9 @@ forward_propagate_addr_expr_1 (tree name
   && TREE_OPERAND (rhs, 0) == name
   && TYPE_SIZE (TREE_TYPE (rhs))
   && TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
+  /* Function decls should not be used for VCE either as it could be
+a function descriptor that we want and not the actual function code. 
*/
+  && TREE_CODE (TREE_OPERAND (def_rhs, 0)) != FUNCTION_DECL
   /* We should not convert volatile loads to non volatile loads. */
   && !TYPE_VOLATILE (TREE_TYPE (rhs))
   && !TYPE_VOLATILE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))


If you could test that on ia64-linux too, that would be nice.

Thanks,
Andrew Pinski


-- 


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #9 from pinskia at gcc dot gnu dot org  2008-05-05 21:04 ---
A reduced testcase:
extern void ffi_closure_unix (void);
ffi_prep_closure_loc (void)
{
  struct ia64_fd
  {
unsigned long long code_pointer;
unsigned long long gp;
  };
  struct ffi_ia64_trampoline_struct
  {
unsigned long long code_pointer;
  };
  struct ffi_ia64_trampoline_struct *tramp;
  struct ia64_fd *fd;
  fd = (struct ia64_fd *)(void *)ffi_closure_unix;
  tramp->code_pointer = fd->code_pointer;
}


-- 


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

[Bug libgcj/34521] SSLEngine - Clone not supported (Null pointer) exception

[jarygrove at yahoo dot com]

--- Comment #4 from jarygrove at yahoo dot com  2008-05-05 21:08 ---
Please close this bug, I synchronized the handshake thread and no longer
getting the exception


Never miss a thing.  Make Yahoo your home page. http://www.yahoo.com/r/hs   
Best LDAP Client http://www.ldapsoft.com/ldapadmintool.html
Best LDAP Browswer http://www.ldapsoft.com/ldapbrowser.html


-- 


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

[Bug middle-end/36143] New: [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[hjl dot tools at gmail dot com]

Revision 134947 caused

FAIL: g++.dg/tree-ssa/pr19637.C scan-tree-dump-times dom1 "return 1;" 3

on Linux/ia32 and Linux/Intel64.


-- 
   Summary: [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-05 21:30 ---
Yes I saw this, this is because we are not creating a VIEW_CONVERT_EXPR for the
first indirect reference, I think it has something to do with the placement
new.  I will look at it when I get home tonight.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |pinskia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Keywords||missed-optimization
   Last reconfirmed|-00-00 00:00:00 |2008-05-05 21:30:39
   date||
Summary|[4.4 Regression]: FAIL: |[4.4 Regression]: FAIL:
   |g++.dg/tree-ssa/pr19637.C   |g++.dg/tree-ssa/pr19637.C
   Target Milestone|--- |4.4.0


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

[Bug middle-end/36137] gcc can't do math

[tromey at gcc dot gnu dot org]

--- Comment #3 from tromey at gcc dot gnu dot org  2008-05-05 22:27 ---
fold_binary sees both MAX_EXPRs and reassociates.
(I think this is why it works with intermediate variables.)

Then associate_trees creates a new MAX_EXPR, converting each
argument to unsigned:

  return fold_build2 (code, type, fold_convert (type, t1),
  fold_convert (type, t2));

So, this is where the error enters.
I'm not sure where this is best fixed though.


-- 


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #10 from hjl dot tools at gmail dot com  2008-05-05 22:30 
---
(In reply to comment #8)
> That is:
> Index: gcc/gcc/tree-ssa-forwprop.c
> ===
> --- gcc/gcc/tree-ssa-forwprop.c (revision 134951)
> +++ gcc/gcc/tree-ssa-forwprop.c (working copy)
> @@ -657,6 +657,9 @@ forward_propagate_addr_expr_1 (tree name
>&& TREE_OPERAND (rhs, 0) == name
>&& TYPE_SIZE (TREE_TYPE (rhs))
>&& TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
> +  /* Function decls should not be used for VCE either as it could be
> +a function descriptor that we want and not the actual function code. 
> */
> +  && TREE_CODE (TREE_OPERAND (def_rhs, 0)) != FUNCTION_DECL
>/* We should not convert volatile loads to non volatile loads. */
>&& !TYPE_VOLATILE (TREE_TYPE (rhs))
>&& !TYPE_VOLATILE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
> 
> 
> If you could test that on ia64-linux too, that would be nice.
> 

This passed the failed point. I am rebuilding the whole tree now. Thanks.


-- 


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

[Bug target/35657] Alignments of DFP types aren't consistent

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2008-05-05 22:49 
---
An updated patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00271.html


-- 


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

[Bug target/36144] New: [4.4 Regression] gcc.dg/vect/vect-reduc-1short.c and gcc.dg/vect/vect-reduc-9.c fail

[pinskia at gcc dot gnu dot org]

>From http://gcc.gnu.org/ml/gcc-testresults/2008-05/msg00391.html .

Between revision 134953 and 134958, they showed up.

The only revision which could have caused this is revision 134957.

http://gcc.gnu.org/ml/gcc-cvs/2008-05/msg00117.html


-- 
   Summary: [4.4 Regression] gcc.dg/vect/vect-reduc-1short.c and
gcc.dg/vect/vect-reduc-9.c fail
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu


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

[Bug target/36144] [4.4 Regression] gcc.dg/vect/vect-reduc-1short.c and gcc.dg/vect/vect-reduc-9.c fail

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug target/36144] [4.4 Regression] gcc.dg/vect/vect-reduc-1short.c and gcc.dg/vect/vect-reduc-9.c fail

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-05-05 23:31 ---

XPASS: gcc.dg/tree-ssa/ltrans-3.c scan-tree-dump-times ltrans "transformed
loop" 1
FAIL: gcc.dg/vect/vect-reduc-1short.c (test for excess errors)
WARNING: gcc.dg/vect/vect-reduc-1short.c compilation failed to produce
executable
FAIL: gcc.dg/vect/vect-reduc-9.c (test for excess errors)


-- 


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

[Bug target/36144] [4.4 Regression] gcc.dg/vect/vect-reduc-1short.c and gcc.dg/vect/vect-reduc-9.c fail

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-05-05 23:32 ---

/tmp/ccdYPpfu.s:66: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:70: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:77: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:81: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:85: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:88: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:95: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:103: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:111: Error: invalid character '<' in mnemonic
/tmp/ccdYPpfu.s:119: Error: invalid character '<' in mnemonic


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||assemble-failure
   Last reconfirmed|-00-00 00:00:00 |2008-05-05 23:32:50
   date||


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

[Bug target/36144] [4.4 Regression] gcc.dg/vect/vect-reduc-1short.c and gcc.dg/vect/vect-reduc-9.c fail

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-05-06 00:30 ---
Fixed by revision 134966.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug libfortran/36142] T edit descriptor doesn't work for non-seekable streams

[jvdelisle at gcc dot gnu dot org]

--- Comment #1 from jvdelisle at gcc dot gnu dot org  2008-05-06 00:33 
---
This is a regression and probably the same as PR36131.  When I first saw this,
I was having dejavu.  I knew we fixed this already once before.


-- 

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|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
  Known to work||4.3.1
   Last reconfirmed|-00-00 00:00:00 |2008-05-06 00:33:34
   date||


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

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[hp at gcc dot gnu dot org]

--- Comment #2 from hp at gcc dot gnu dot org  2008-05-06 01:05 ---
FWIW, noticed on cris-elf as well, where additionally, for the record,
gfortran.dg/transfer_assumed_size_1.f90 regressed.  From gfortran.log:

PASS: gfortran.dg/transfer_assumed_size_1.f90  -O2  (test for excess errors)
core: 4 byte read to unmapped address 0x2a000 at 0x16248^M
program stopped with signal 11.^M
FAIL: gfortran.dg/transfer_assumed_size_1.f90  -O2  execution test

which I'd rather not dig further into until the g++.dg/tree-ssa/pr19637.C s
fixed.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[hjl dot tools at gmail dot com]

--- Comment #11 from hjl dot tools at gmail dot com  2008-05-06 01:13 
---
(In reply to comment #10)
> (In reply to comment #8)
> > That is:
> > Index: gcc/gcc/tree-ssa-forwprop.c
> > ===
> > --- gcc/gcc/tree-ssa-forwprop.c (revision 134951)
> > +++ gcc/gcc/tree-ssa-forwprop.c (working copy)
> > @@ -657,6 +657,9 @@ forward_propagate_addr_expr_1 (tree name
> >&& TREE_OPERAND (rhs, 0) == name
> >&& TYPE_SIZE (TREE_TYPE (rhs))
> >&& TYPE_SIZE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
> > +  /* Function decls should not be used for VCE either as it could be
> > +a function descriptor that we want and not the actual function 
> > code. 
> > */
> > +  && TREE_CODE (TREE_OPERAND (def_rhs, 0)) != FUNCTION_DECL
> >/* We should not convert volatile loads to non volatile loads. */
> >&& !TYPE_VOLATILE (TREE_TYPE (rhs))
> >&& !TYPE_VOLATILE (TREE_TYPE (TREE_OPERAND (def_rhs, 0)))
> > 
> > 
> > If you could test that on ia64-linux too, that would be nice.
> > 
> 
> This passed the failed point. I am rebuilding the whole tree now. Thanks.
> 

It works on Linux/ia64.


-- 


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

[Bug libfortran/36131] [4.4 Regression] wrong IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-05-06 01:43 
---
*** Bug 36142 has been marked as a duplicate of this bug. ***


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jb at gcc dot gnu dot org


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

[Bug libfortran/36142] [4.4 Regression] T edit descriptor doesn't work for non-seekable streams

[jvdelisle at gcc dot gnu dot org]

--- Comment #2 from jvdelisle at gcc dot gnu dot org  2008-05-06 01:43 
---
I have confirmed this is a duplicate of pr36131.  The regression occurs from
r132512, the change to transfer.c

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


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug libfortran/36142] [4.4 Regression] T edit descriptor doesn't work for non-seekable streams

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-05-06 02:25 
---
Regarding Janne's thoughts on fixing this problem.  One of the features that
the stream alloc provides is the ability to grow the buffer size as needed. We
will have to rethink this problem as part of eliminating the stream alloc
layer.


-- 


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

[Bug libfortran/36131] [4.4 Regression] wrong IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #3 from jvdelisle at gcc dot gnu dot org  2008-05-06 02:27 
---
The regression occurs from r132512, the change to transfer.c

The test case from pr36142 is:

! { dg-do  run }
! Adapted from fmt_t_6.f testcase for PR 34782
  character a(6)
  data a / 'a', 'b', 'c', 'd', 'e', 'f' /
  write(*,'(T20,A3,  T1,A4,  T5,A2,  T7,A2,  T9,A4, T17,A2)')
 1 'a', 'b', 'c', 'd', 'e', 'f' 
  print *, 'should be'
  write (*, '(A)') "   b c d   e f   a"
  end

By reverting the relevant portion of the patch, these two test cases pass which
leaves fmt_t_7.f failing which the original patch was intended for.  fmt_t_7.f
is an extreme case which is not time critical to fix.

I plan to revert the patch and xfail fmt_t_7.f90 until we sort this out
further.
See my comment to pr36142 on the alloc facility.


-- 


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

[Bug libstdc++/36130] Atomics regression test fail to compile when parallel mode is enabled

[bkoz at gcc dot gnu dot org]

--- Comment #1 from bkoz at gcc dot gnu dot org  2008-05-06 03:11 ---

These are all failures in "C" mode, and are due to running into C++ constructs
like the keyword "namespace." 


-- 

bkoz at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |bkoz at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-05-06 03:11:46
   date||


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #12 from pinskia at gcc dot gnu dot org  2008-05-06 03:47 
---
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/36141] [4.4 Regression]: Gcc 4.4 failed to boostrap

[pinskia at gcc dot gnu dot org]

--- Comment #13 from pinskia at gcc dot gnu dot org  2008-05-06 03:48 
---
Subject: Bug 36141

Author: pinskia
Date: Tue May  6 03:47:29 2008
New Revision: 134972

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134972
Log:
2008-05-05  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/36141
* tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Don't create VCE
for function decls.

2008-05-05  Andrew Pinski  <[EMAIL PROTECTED]>

PR middle-end/36141
* gcc.c-torture/pr36141.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.c-torture/pr36141.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-forwprop.c


-- 


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

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[pinskia at gcc dot gnu dot org]

--- Comment #3 from pinskia at gcc dot gnu dot org  2008-05-06 03:56 ---
(In reply to comment #2)
> FWIW, noticed on cris-elf as well, where additionally, for the record,
> gfortran.dg/transfer_assumed_size_1.f90 regressed.  From gfortran.log:

I just checked on i686-darwin and there is no changes that were produced by the
VIEW_CONVERT_EXPR changes in forwprop.  That is forwprop does not produce any
VIEW_CONVERT_EXPR for that testcase.

g++.dg/tree-ssa/pr19637.C is just a missed optimization and not about wrong
code in this case.


-- 


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

[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #12 from jvdelisle at gcc dot gnu dot org  2008-05-06 04:01 
---
Reverted patch which caused pr36131. Reopening this one.


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug libfortran/36131] [4.4 Regression] wrong IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #4 from jvdelisle at gcc dot gnu dot org  2008-05-06 04:01 
---
Subject: Bug 36131

Author: jvdelisle
Date: Tue May  6 04:00:38 2008
New Revision: 134973

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=134973
Log:
2008-05-05  Jerry DeLisle  <[EMAIL PROTECTED]>

PR libfortran/36131
* io/transfer.c (formatted_transfer_scalar): Revert patch for PR34974.
(next_record_w): Likewise.

Modified:
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/transfer.c


-- 


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

[Bug libfortran/36131] [4.4 Regression] wrong IO

[jvdelisle at gcc dot gnu dot org]

--- Comment #5 from jvdelisle at gcc dot gnu dot org  2008-05-06 04:02 
---
Fixed on trunk, reopened PR34974


-- 

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=36131

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-05-06 04:09 ---
So for &i[0], we don't convert it to VCE but the others we convert it but we
don't get to the point convert to VCE for the placement new case for some
reason ...


-- 


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

[Bug middle-end/36143] [4.4 Regression]: FAIL: g++.dg/tree-ssa/pr19637.C

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-05-06 04:15 ---
Oh we don't handle VCE On the left hand side for many different reasons.  One
is because if we set only part of the variable, we could get possible invalid
gimple as we are only setting part of a SSA_NAME.  I am un-assigning myself for
now.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||rguenther at suse dot de
 AssignedTo|pinskia at gcc dot gnu dot  |unassigned at gcc dot gnu
   |org |dot org
 Status|ASSIGNED|NEW


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

[Bug libfortran/34974] null bytes when reverse-tabbing long records (regression vs. g77)

[jvdelisle at gcc dot gnu dot org]

--- Comment #13 from jvdelisle at gcc dot gnu dot org  2008-05-06 04:35 
---
Janne, see discussion in comment #6


-- 

jvdelisle at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jb at gcc dot gnu dot org


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