[Bug bootstrap/37122] fixed-value.c and tree-ssa-loop-ivopts.c won't compile with Sun Studio 11 on Solaris 9 due to incompatible operand types

[ghazi at gcc dot gnu dot org]

--- Comment #5 from ghazi at gcc dot gnu dot org  2008-09-12 07:06 ---
(In reply to comment #4)
> Yes, your right it is a bug in Sun's Compiler. For those interested it is bug
> ID: 6406892. The sun patch that fixes this bug is 121015-06 available here:
> http://sunsolve.sun.com/show.do?target=patchpage

I believe 121015-06 is the sparc series.  There is also an x86 variant numbered
121016-07 that fixes the same bugid.  IMHO these patches should be listed in
the solaris-specific installtion instructions here:
http://gcc.gnu.org/install/specific.html#x-x-solaris2
as are the other required solaris patches.

David, would you consider posting a patch for gcc/doc/install.texi ?
Please CC: me if you do so.  Thanks!


-- 


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

[Bug tree-optimization/14703] [4.4 regression] Inadequate optimization of inline templated functions, infinite loop in ipa-reference and memory hog

[hubicka at gcc dot gnu dot org]

--- Comment #13 from hubicka at gcc dot gnu dot org  2008-09-12 08:33 
---
Having testcase would be great.  In theory removing unused things from debug
info should not make any difference.  Perhaps it is related to stack frame
packing, that is only other place walking blocks.
could you please try adding && is_gimple_reg (*t)?

Honza


-- 


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

[Bug tree-optimization/14703] [4.4 regression] Inadequate optimization of inline templated functions, infinite loop in ipa-reference and memory hog

[hubicka at gcc dot gnu dot org]

--- Comment #14 from hubicka at gcc dot gnu dot org  2008-09-12 08:39 
---
Created an attachment (id=16301)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16301&action=view)
patch that should fix the sixtrack problem.

This patch should solve the sixtrack problem.  Can you please test for me?

Honza


-- 


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

[Bug libstdc++/37470] parallel/base.h log2 conflicts with math.h

[singler at gcc dot gnu dot org]

--- Comment #2 from singler at gcc dot gnu dot org  2008-09-12 08:45 ---
Clearly, this is a potential conflict, and the solution is pretty obvious. 

However, I am unable to reproduce it on x86_64-unknown-linux-gnu, for a
definite test case. Do you have a simple testcase that triggers the bug (on
your platform)? Do you use the parallel mode by default (-D_GLIBCXX_PARALLEL)
or selectively? Do you have 'using namespace ...' statements?  or
?  or ? ? ? I might have some
mental block ;-)


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |singler at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-09-10 22:46:43 |2008-09-12 08:45:35
   date||


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

[Bug libstdc++/30915] [4.3 regression] bootstrap fails while building libstdc++-v3 on x86_64-pc-linux-gnu

[lthode at mail dot unomaha dot edu]

--- Comment #32 from lthode at mail dot unomaha dot edu  2008-09-12 10:36 
---
For all Gentoo users who are hitting this bug:

Update your GLibC to 2.7r2 or later, the new versions do not use multilib
wrappers any longer.


-- 


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

[Bug tree-optimization/37392] [4.4 Regression] Segfault in verify_ssa: !gimple_nop_p (stmt)

[hubicka at gcc dot gnu dot org]

--- Comment #7 from hubicka at gcc dot gnu dot org  2008-09-12 09:52 ---
Testing patch..


-- 

hubicka at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hubicka at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-09-06 22:27:54 |2008-09-12 09:52:53
   date||


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

[Bug fortran/35770] implicit character(s) hides type of internal function

[domob at gcc dot gnu dot org]

-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |domob at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-03-30 21:34:17 |2008-09-12 11:12:38
   date||


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

[Bug target/37096] conditional evaluation incorrect with -O3

[erik dot moller at cycos dot com]

--- Comment #9 from erik dot moller at cycos dot com  2008-09-12 11:33 
---
true, -fno-strict-aliasing makes even -O3 work... I don't know about the
liasing, the example is very simple, can that happen when the SSE2 intrinsics
are involved?


-- 


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

[Bug bootstrap/37086] [4.4 Regression] GCC 3.4 miscompiles trunk (for cross compiling)

[drow at gcc dot gnu dot org]

--- Comment #15 from drow at gcc dot gnu dot org  2008-09-12 12:43 ---
Reopening...


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug bootstrap/37086] [4.4 Regression] GCC 3.4 miscompiles trunk (for cross compiling)

[drow at gcc dot gnu dot org]

--- Comment #16 from drow at gcc dot gnu dot org  2008-09-12 12:43 ---
Fixed.


-- 

drow at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug inline-asm/37492] New: optimization causes inline assembler to emit syntax errors

[zeev dot tarantov at gmail dot com]

Compiling the following with -O0 works. Compiling with -O2 produces assembly
syntax errors.

Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.1-r1/work/gcc-4.3.1/configure --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.3.1
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.3.1/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.1/include/g++-v4
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec
--enable-nls --without-included-gettext --with-system-zlib --disable-checking
--disable-werror --enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-cld --enable-java-awt=gtk --with-arch=i686
--enable-languages=c,c++,java,treelang --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.1-r1 p1.1'
Thread model: posix
gcc version 4.3.1 (Gentoo 4.3.1-r1 p1.1)


#include 

void test(unsigned int val)
{
  unsigned int res, resz;
  asm(
  " xorl %1, %1\n"
  " movl $0x12345678, %0\n"
  " bsrl %2, %0 ; setz %b1 "
  : "=r" (res), "=r" (resz)
  : "g" (val)
  );
  printf("val : %d\n", val);
  printf("res : %d\n", res);
  printf("resz: %d\n", resz);
}

int main()
{
  test(0);
  test(1 << 7);
  test(1 << 15);
  test(1 << 30);
  return 0;
}


-- 
   Summary: optimization causes inline assembler to emit syntax
errors
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zeev dot tarantov at gmail dot com


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

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

[grosser at gcc dot gnu dot org]

--- Comment #2 from grosser at gcc dot gnu dot org  2008-09-12 12:55 ---
Created an attachment (id=16302)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16302&action=view)
Just a simple loop over an array

I can confirm this one using this simple test case.


-- 


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

[Bug c/37493] New: Auto inline when optimisation is enabled, causes problem.

[prafullat at kpitcummins dot com]

Hi, 
While using GCC 4.3.1, I observed that the specialized inline   
code is generated automatically which causes problem in the following   
case.   
-   
/*  File name: t.c   */ 
static int  
WaitLoop (unsigned int count)   
{
asm (" _loop: tst   %0, %0  \n" "bf/s _loop \n" "add #-1, %0": "=r"
(count):"0" (count));   
return count;   
}   

int 
main () 
{   
  volatile int a = WaitLoop (100);  
  a = WaitLoop (200);   
  return 0; 
}   
-   
When I compiled this test case using GCC 4.3.1, using following 
command line:   
#sh-elf-gcc -O2 t.c -c  

I got the following error:  

/tmp/cczqWWXN.s: Assembler messages:
/tmp/cczqWWXN.s:25: Error: symbol '_loop' is already defined

Note: This error was observed only when "-O2" and "-O3" are used
as optimization options. There is no error for "-O0" and "-O1"  
options.

For further investigation, I generated an assembly file.
It seems that, the function "WaitLoop" is getting in-lined. As the  
"WaitLoop" function is called twice from the "main", it was in-lined 
twice by the compiler.  

Below is the assembly file generated from "t.c".
-   
.file   "t.c"   
.text
.little
.text
.align 1
.align 2
.global _main
.type   _main, @function
_main:
mov.l   r14,@-r15
mov #0,r0
add #-4,r15
mov r15,r14
mov r14,r2
add #-60,r2
mov #100,r1
add #4,r14
! 4 "t.c" 1
_loop:  tst r1, r1  
bf/s_loop   
add #-1, r1 
! 0 "" 2
mov.l   r1,@(60,r2)
mov.w   .L3,r1
! 4 "t.c" 1
_loop:  tst r1, r1  
bf/s_loop   
add #-1, r1 
! 0 "" 2
mov.l   r1,@(60,r2)
mov r14,r15
rts 
mov.l   @r15+,r14
.align 1
.L3:
-   
As a workaround for the above issue, one can use either of the following:   
1.  "-fno-inline" switch used during compilation. OR
2. Used "noinline" attribute to the "WaitLoop" function.

Thanks and Regards, 
Prafulla


-- 
   Summary: Auto inline when optimisation is enabled, causes
problem.
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prafullat at kpitcummins dot com
 GCC build triplet: i686-pc-linux
  GCC host triplet: i686-pc-linux
GCC target triplet: sh*-unknown-linux


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

[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional

[jakub at gcc dot gnu dot org]

--- Comment #6 from jakub at gcc dot gnu dot org  2008-09-12 13:40 ---
Mine.


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-09-11 21:15:14 |2008-09-12 13:40:35
   date||


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

[Bug c/37493] Auto inline when optimisation is enabled, causes problem.

[graham dot stott at btinternet dot com]

--- Comment #1 from graham dot stott at btinternet dot com  2008-09-12 
14:04 ---
Subject: Re:   New: Auto inline when optimisation is enabled, causes problem.

All,

Read the documentation for "%=" w.r.t generating unique labels inline
assembler.

Replacing your uses of _loop with _loop%= will produce a unique label.

Cheers
Graham


-- 


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

[Bug inline-asm/37492] optimization causes inline assembler to emit syntax errors

[ubizjak at gmail dot com]

--- Comment #1 from ubizjak at gmail dot com  2008-09-12 14:13 ---
(In reply to comment #0)

>   asm(
>   " xorl %1, %1\n"
>   " movl $0x12345678, %0\n"
>   " bsrl %2, %0 ; setz %b1 "
>   : "=r" (res), "=r" (resz)
>   : "g" (val)

Use "q" constraint for operand 1. You will also need earlyclobbers on output
operands:

: "=&r" (res), "=&q" (resz)


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c/37493] Auto inline when optimisation is enabled, causes problem.

[hjl dot tools at gmail dot com]

--- Comment #2 from hjl dot tools at gmail dot com  2008-09-12 14:21 ---
Try

static int  
WaitLoop (unsigned int count)   
{
asm ("1: tst %0, %0\n" "bf/s 1b\n" "add #-1, %0": "=r"
(count):"0" (count));   
return count;   
}   


-- 


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

[Bug inline-asm/37492] optimization causes inline assembler to emit syntax errors

[zeev dot tarantov at gmail dot com]

--- Comment #2 from zeev dot tarantov at gmail dot com  2008-09-12 14:24 
---
Thank you so much and sorry for the spam in bugzilla. Is there anything like
lint that would have helped me understand the mistake, without actually
grokking the documentation?


-- 


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

[Bug target/37395] [4.4 Regression] Bootstrap fails in stage 2 due to segfault compiling c-parser

[jakub at gcc dot gnu dot org]

--- Comment #10 from jakub at gcc dot gnu dot org  2008-09-12 14:26 ---


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


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE


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

[Bug target/37483] [4.4 Regression] Segfault in noce_try_sign_mask (ifcvt.c): b_unconditional

[jakub at gcc dot gnu dot org]

--- Comment #7 from jakub at gcc dot gnu dot org  2008-09-12 14:26 ---
*** Bug 37395 has been marked as a duplicate of this bug. ***


-- 
Bug 37483 depends on bug 37395, which changed state.

Bug 37395 Summary: [4.4 Regression] Bootstrap fails in stage 2 due to segfault 
compiling c-parser
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37395

   What|Old Value   |New Value

 Status|ASSIGNED|RESOLVED
 Resolution||DUPLICATE

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

[Bug fortran/37494] New: function of a module not recognized by a subroutine in the same module

[Jean-Charles dot Gilbert at inria dot fr]

The function 'fonc' defined in the module below is not recognized by the
subroutine 'sub' in the same module.

module essai
!---
contains
!---
  subroutine sub ()
  implicit none
  double precision :: fonc
  double precision :: d
  d = fonc()
  return
  end subroutine sub
!---
  function fonc ()
  implicit none
  double precision :: fonc
  fonc = 1.d0
  return
  end function fonc
!---
end module essai

The compiled object 'essai.o' is obtained by

   gfortran -c essai.f90

and the following command

   nm essai.o | grep fonc

answers

    T ___essai_MOD_fonc
U _fonc_


This is so elementary that I would be glad to have made a trivial mistake. This
problem did not occurred in previous version of gfortran; it does not occur in
pgf90 either.


-- 
   Summary: function of a module not recognized by a subroutine in
the same module
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Jean-Charles dot Gilbert at inria dot fr


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

[Bug fortran/37494] function of a module not recognized by a subroutine in the same module

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2008-09-12 14:47 ---
Removing the

double precision :: fonc

from sub makes the program compile as expected (as I guess).  I'm not sure if
that's a bug or a problem with the original code, but I could imagine that this
declaration makes gfortran link to an external fonc without the module
interface.


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org


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

[Bug fortran/37494] function of a module not recognized by a subroutine in the same module

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-09-12 14:53 ---
Works with gfortran 4.2.3, but not with 4.3.2 nor 4.4.0 (trunk).


-- 


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

[Bug testsuite/37495] New: FAIL: gcc.c-torture/compile/vector-4.c

[dominiq at lps dot ens dot fr]

On i686-apple-darwin9, gcc.c-torture/compile/vector-4.c fails with:

/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccC7klQ7.s:19:no such
instruction: `vmovq (%eax), %xmm0'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccC7klQ7.s:20:no such
instruction: `vmovq %xmm0, -48(%ebp)'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccC7klQ7.s:58:no such
instruction: `vmovd -36(%ebp), %xmm0'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccC7klQ7.s:59:no such
instruction: `vpinsrd $0x1, %eax,%xmm0,%xmm0'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccC7klQ7.s:60:no such
instruction: `vmovq %xmm0, -32(%ebp)'

The test comiles with -m64.


-- 
   Summary: FAIL: gcc.c-torture/compile/vector-4.c
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: i686-apple-darwin9
  GCC host triplet: i686-apple-darwin9
GCC target triplet: i686-apple-darwin9


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

[Bug testsuite/37496] New: Missing SSE intrinsic tests

[hjl dot tools at gmail dot com]

There are no specific tests for following SSE intrinsics:

xmmintrin.h

_mm_extract_pi16
_mm_insert_pi16
_mm_shuffle_pi16
_mm_prefetch

_mm_cmpeq_ss
_mm_cmplt_ss
_mm_cmple_ss
_mm_cmpgt_ss
_mm_cmpge_ss
_mm_cmpneq_ss
_mm_cmpnlt_ss
_mm_cmpnle_ss
_mm_cmpngt_ss
_mm_cmpnge_ss
_mm_cmpord_ss
_mm_cmpunord_ss
_mm_cmpeq_ps
_mm_cmplt_ps
_mm_cmple_ps
_mm_cmpgt_ps
_mm_cmpge_ps
_mm_cmpneq_ps
_mm_cmpnlt_ps
_mm_cmpnle_ps
_mm_cmpngt_ps
_mm_cmpnge_ps
_mm_cmpord_ps
_mm_cmpunord_ps
_mm_cvt_ss2si
_mm_cvtss_si64x
_mm_cvtps_pi32
_mm_cvt_ps2pi
_mm_cvtt_ss2si
_mm_cvttss_si64x
_mm_cvttps_pi32
_mm_cvtt_ps2pi
_mm_cvt_si2ss
_mm_cvtsi64x_ss
_mm_cvtpi32_ps
_mm_cvt_pi2ps
_mm_cvtpi16_ps
_mm_cvtpu16_ps
_mm_cvtpi8_ps
_mm_cvtpu8_ps
_mm_cvtpi32x2_ps
_mm_cvtps_pi16
_mm_cvtps_pi8
_mm_storel_pi
_mm_getcsr
_mm_setcsr
_mm_set_ss
_mm_set_ps1
_mm_load1_ps
_mm_load_ps1
_mm_loadr_ps
_mm_setr_ps
_mm_cvtss_f32
_mm_store1_ps
_mm_store_ps1
_mm_storer_ps
_mm_max_pi16
_mm_max_pu8
_mm_min_pi16
_mm_min_pu8
_mm_movemask_pi8
_mm_mulhi_pu16
_mm_maskmove_si64
_mm_avg_pu8
_mm_avg_pu16
_mm_sad_pu8
_mm_stream_pi
_mm_sfence
_mm_pause

emmintrin.h

_mm_insert_epi16

_mm_set_sd
_mm_set1_pd
_mm_set_pd1
_mm_setr_pd
_mm_move_sd
_mm_load1_pd
_mm_load_pd1
_mm_loadr_pd
_mm_cvtsd_f64
_mm_store1_pd
_mm_store_pd1
_mm_storer_pd
_mm_cvtsi128_si64x
_mm_cmpeq_pd
_mm_cmplt_pd
_mm_cmple_pd
_mm_cmpgt_pd
_mm_cmpge_pd
_mm_cmpneq_pd
_mm_cmpnlt_pd
_mm_cmpnle_pd
_mm_cmpngt_pd
_mm_cmpnge_pd
_mm_cmpord_pd
_mm_cmpunord_pd
_mm_cmpeq_sd
_mm_cmplt_sd
_mm_cmple_sd
_mm_cmpgt_sd
_mm_cmpge_sd
_mm_cmpneq_sd
_mm_cmpnlt_sd
_mm_cmpnle_sd
_mm_cmpngt_sd
_mm_cmpnge_sd
_mm_cmpord_sd
_mm_cmpunord_sd
_mm_set1_epi64x
_mm_set1_epi64
_mm_set1_epi32
_mm_set1_epi16
_mm_setr_epi64
_mm_setr_epi32
_mm_setr_epi16
_mm_setr_epi8
_mm_loadl_epi64
_mm_storel_epi64
_mm_movepi64_pi64
_mm_movpi64_epi64
_mm_cvtpd_pi32
_mm_cvttpd_pi32
_mm_cvtpi32_pd
_mm_cvtsd_si64x
_mm_cvttsd_si64x
_mm_cvtsi64x_sd
_mm_subs_epu8
_mm_subs_epu16
_mm_mul_su32
_mm_cmplt_epi8
_mm_cmplt_epi16
_mm_cmplt_epi32
_mm_maskmoveu_si128
_mm_stream_si32
_mm_clflush
_mm_lfence
_mm_mfence
_mm_cvtsi64x_si128
_mm_castpd_ps
_mm_castpd_si128
_mm_castps_pd
_mm_castps_si128
_mm_castsi128_ps
_mm_castsi128_pd


-- 
   Summary: Missing SSE intrinsic tests
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
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=37496

[Bug c/37493] Auto inline when optimisation is enabled, causes problem.

[prafullat at kpitcummins dot com]

--- Comment #3 from prafullat at kpitcummins dot com  2008-09-12 15:18 
---
Thank you HJ.
This works.


-- 


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

[Bug fortran/37494] function of a module not recognized by a subroutine in the same module

[Jean-Charles dot Gilbert at inria dot fr]

--- Comment #3 from Jean-Charles dot Gilbert at inria dot fr  2008-09-12 
15:26 ---
(In reply to comment #1)
> Removing the
> 
> double precision :: fonc
> 
> from sub makes the program compile as expected (as I guess).  I'm not sure if
> that's a bug or a problem with the original code, but I could imagine that 
> this
> declaration makes gfortran link to an external fonc without the module
> interface.
> 

You are right. That was the problem. The shame on me not to have found it ! I
should have posted this on a discussion forum instead of on bugzilla. Thanks
again for your help.


-- 

Jean-Charles dot Gilbert at inria dot fr changed:

   What|Removed |Added

 CC||Jean-Charles dot Gilbert at
   ||inria dot fr


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

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

[hjagasia at gcc dot gnu dot org]

-- 

hjagasia at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hjagasia at gcc dot gnu dot
   |dot org |org
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-12 15:42:40
   date||


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

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

[hjagasia at gcc dot gnu dot org]

--- Comment #3 from hjagasia at gcc dot gnu dot org  2008-09-12 15:44 
---
Jan and I have a bug fix for this, which will be posted in some time.


-- 


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #8 from nickc at redhat dot com  2008-09-12 15:52 ---
Created an attachment (id=16303)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16303&action=view)
Implement alignment for non-local commons


-- 


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[nickc at redhat dot com]

--- Comment #9 from nickc at redhat dot com  2008-09-12 15:54 ---
Hi Brian,

  Please could you try out the uploaded patch which is an implementation of
your idea to add an extra alignment directive when emitting commons.  It seems
to work for the test case you gave, but I have not yet run it through a full
rebuild and retest cycle...

Cheers
  Nick


-- 


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

[Bug fortran/37494] function of a module not recognized by a subroutine in the same module

[domob at gcc dot gnu dot org]

--- Comment #4 from domob at gcc dot gnu dot org  2008-09-12 15:56 ---
(In reply to comment #3)
> (In reply to comment #1)
> > Removing the
> > 
> > double precision :: fonc
> > 
> > from sub makes the program compile as expected (as I guess).  I'm not sure 
> > if
> > that's a bug or a problem with the original code, but I could imagine that 
> > this
> > declaration makes gfortran link to an external fonc without the module
> > interface.
> > 
> 
> You are right. That was the problem. The shame on me not to have found it ! I
> should have posted this on a discussion forum instead of on bugzilla. Thanks
> again for your help.

You are very welcome, of course!  But as I stated, I'm not sure if your code is
still valid Fortran and this a bug.  I'm not the right one to judge here.


-- 


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

[Bug fortran/37494] function of a module not recognized by a subroutine in the same module

[dominiq at lps dot ens dot fr]

--- Comment #5 from dominiq at lps dot ens dot fr  2008-09-12 16:11 ---
> ... I'm not sure if your code is still valid Fortran and this a bug.  I'm not 
> the right one to judge here.

I am not the right one either and I did not find anything in the standard to
support the following:

It seems that declaring 'fonc' makes it external to the module, while without
any declaration, 'fonc' is found to be the "internal procedure" defined within
the module.

Note that g95 behaves as gfortran.


-- 


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

[Bug fortran/37497] New: Fortran openMP compiler error: Segmentation fault

[feilin at illinois dot edu]

When I try to compile a openMP fortran code, the following error message
occurs:

1230: internal compiler error: Segmentation fault

I can compile the code correct using Intel fortran compiler. Could anybody give
me instructions on what might be the problem?

Thanks a lot!


-- 
   Summary: Fortran openMP compiler error: Segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: feilin at illinois dot edu


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

[Bug fortran/37494] function of a module not recognized by a subroutine in the same module

[Jean-Charles dot Gilbert at inria dot fr]

--- Comment #6 from Jean-Charles dot Gilbert at inria dot fr  2008-09-12 
16:21 ---
(In reply to comment #5)
> > ... I'm not sure if your code is still valid Fortran and this a bug.  I'm 
> > not the right one to judge here.
> 
> I am not the right one either and I did not find anything in the standard to
> support the following:
> 
> It seems that declaring 'fonc' makes it external to the module, while without
> any declaration, 'fonc' is found to be the "internal procedure" defined within
> the module.
> 
> Note that g95 behaves as gfortran.

Thank you for the time you spent on the problem. I don't remember having seen
the convention you mention above in any Fortran-95++ documentation. Therefore,
the choice made by Gfortran could deserve a note in the GFortran documentation
(I don't think it is mentioned).


-- 


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

[Bug target/37466] [AVR] avr-gcc generating incorrect assembly for expression with the long constant operands

[aesok at gcc dot gnu dot org]

--- Comment #1 from aesok at gcc dot gnu dot org  2008-09-12 16:46 ---
Subject: Bug 37466

Author: aesok
Date: Fri Sep 12 16:45:34 2008
New Revision: 140321

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140321
Log:
PR target/37466
* config/avr/avr.md (movsi_lreg_const peephole2): Add match_dup for
scratch register after 'set' pattern.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr.md


-- 


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

[Bug fortran/37497] Fortran openMP compiler error: Segmentation fault

[kargl at gcc dot gnu dot org]

--- Comment #1 from kargl at gcc dot gnu dot org  2008-09-12 16:52 ---
(In reply to comment #0)

> I can compile the code correct using Intel fortran compiler. Could anybody 
> give
> me instructions on what might be the problem?

No.

You did not

1) tell us what version of gfortran you are using.
2) show the exact command line you used.
3) give us the code as either
   a) the actual code
   b) a reduced test case
   c) a URL to where we can get the code.
4) the entire error message


-- 


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

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

[hjagasia at gcc dot gnu dot org]

--- Comment #4 from hjagasia at gcc dot gnu dot org  2008-09-12 16:52 
---
The reduced test case block-2.c triggers 3 seperate bugs.

First:
In tranlate_clast when clast stmt is a stmt_user, we can end up disconnecting
the edge that is the exit_edge of the scop that is transformed. This state
creates problems because the exit_edge no longer has a destination. Hence when
after translate_clast, the exit_edge is redirected with redirect_edge_succ, the
edge is already disconnected.

Second:
Graphite does not handle clast user stmts with constant arguments.

Third:
Graphite can create scops which overlap. This is an issue if one of the
overlapping scops is transformed which can cause some edges to be redirected.
When the successive overlapping scops are attempted to be transformed, the
basic blocks in the scop are no longer the same.


-- 


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

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

[hjagasia at gcc dot gnu dot org]

--- Comment #5 from hjagasia at gcc dot gnu dot org  2008-09-12 16:54 
---
Created an attachment (id=16304)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16304&action=view)
This patch fixes all three problems in the reduced test case block-2.c


-- 


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

[Bug fortran/37498] New: Incorrect array value returned

[brtnfld at hdfgroup dot org]

GNU Fortran (GCC) 4.3.3 20080904 (prerelease)
FreeBSD  6.3-STABLE FreeBSD 6.3-STABLE, amd64

Given the program:

ROGRAM test_kind
 IMPLICIT NONE
 INTEGER :: i, j
 INTEGER, DIMENSION(1:3) :: kind_numbers
 kind_numbers(1:3) = 3
 DO i = 1, 3
j = kind_numbers(i)
PRINT*,i,j
 ENDDO
END PROGRAM test_kind

gfortran43 gives:
%a.out
  1   3
  2   0
  3   3 

gfortran44 and gfortran42 give the correct value of kind_numbers(2)=3


-- 
   Summary: Incorrect array value returned
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: brtnfld at hdfgroup dot org


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

[Bug middle-end/37485] [graphite] Disconnecting exit edge in process of code generation

[hjagasia at gcc dot gnu dot org]

--- Comment #6 from hjagasia at gcc dot gnu dot org  2008-09-12 16:59 
---
2008-09-05  Jan Sjodin  <[EMAIL PROTECTED]>
Harsha Jagasia  <[EMAIL PROTECTED]>

* graphite.c (gmp_cst_to_tree): Moved.
(iv_stack_entry_is_constant): New.
(iv_stack_entry_is_iv): New.
(loop_iv_stack_push): Renamed to loop_iv_stack_push_iv.
(loop_iv_stack_insert_constant): New.
(loop_iv_stack_pop): Use new datatpype.
(loop_iv_stack_get_iv): Same.
(loop_iv_stack_get_iv_from_name): Same.
(loop_iv_stack_debug): Renamed to debug_loop_iv_stack.
(loop_iv_stack_patch_for_consts): New.
(loop_iv_stack_remove_constants): New.
(graphite_create_new_loop): Use loop_iv_stack_push_iv.
(translate_clast): Call loop_iv_stack_patch_for_consts and
loop_iv_stack_remove_constants.
(gloog): Use new datatype.  Redirect construction edge to end
block to avoid accidental deletion.
(limit_scops): Prevent overlapping scops.
* graphite.h (enum iv_stack_entry_kind): New.  Tag for data in
iv stack entry.
(union iv_stack_entry_data): New.  Data in iv stack entry.
(struct iv_stack_entry): New.  Datatype for iv stack entries.


-- 


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

[Bug target/37466] [AVR] avr-gcc generating incorrect assembly for expression with the long constant operands

[aesok at gcc dot gnu dot org]

--- Comment #2 from aesok at gcc dot gnu dot org  2008-09-12 17:30 ---
Subject: Bug 37466

Author: aesok
Date: Fri Sep 12 17:29:38 2008
New Revision: 140323

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140323
Log:
PR target/37466
* config/avr/avr.md (movsi_lreg_const peephole2): Add match_dup for
scratch register after 'set' pattern.

Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/config/avr/avr.md


-- 


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

[Bug target/37466] [AVR] avr-gcc generating incorrect assembly for expression with the long constant operands

[aesok at gcc dot gnu dot org]

--- Comment #3 from aesok at gcc dot gnu dot org  2008-09-12 17:36 ---
Fixed.


-- 

aesok at gcc dot gnu dot org changed:

   What|Removed |Added

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


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

[Bug middle-end/37499] New: Scheduling pass 2 time increases by order of magnitude

[lucier at math dot purdue dot edu]

I'm testing gcc on the file all.i.gz in PR26854, configured as

Configured with: ../../mainline/configure --enable-checking=release
--with-gmp=/pkgs/gmp-4.2.2/ --with-mpfr=/pkgs/gmp-4.2.2/
--prefix=/pkgs/gcc-mainline --enable-languages=c
--enable-gather-detailed-mem-stats

and compiled with

/pkgs/gcc-mainline/bin/gcc -Wall -W -Wno-unused -O1 -fno-math-errno
-fschedule-insns2 -fno-trapping-math -fno-strict-aliasing -fwrapv
-fomit-frame-pointer -fPIC -ftime-report -fmem-report -c all.i >>&
mainline-stats-2008-09-11-b

On July 29, the time for the second scheduling pass was

 scheduling 2  :   2.62 ( 1%) usr   0.04 ( 0%) sys   2.67 ( 1%) wall   
   0 kB ( 0%) ggc
 TOTAL : 175.9015.47   191.42
802297 kB

with revision 140295, the time for the second scheduling pass was

 scheduling 2  :  32.40 (16%) usr   0.00 ( 0%) sys  32.43 (14%) wall   
   0 kB ( 0%) ggc
 TOTAL : 204.1615.17   225.52
794201 kB

I'll attach the two detailed memory and cpu time reports.

While the July 29th report did not use IRA, I tested the IRA branch on May 19
and got similar results to the mainline in July:

 scheduling 2  :   2.63 ( 1%) usr   0.00 ( 0%) sys   2.63 ( 1%) wall   
   0 kB ( 0%) ggc


-- 
   Summary: Scheduling pass 2 time increases by order of magnitude
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lucier at math dot purdue dot edu
 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=37499

[Bug middle-end/37499] Scheduling pass 2 time increases by order of magnitude

[lucier at math dot purdue dot edu]

--- Comment #1 from lucier at math dot purdue dot edu  2008-09-12 17:43 
---
Created an attachment (id=16305)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16305&action=view)
Mainline memory and time stats from July 29


-- 


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

[Bug middle-end/37499] Scheduling pass 2 time increases by order of magnitude

[lucier at math dot purdue dot edu]

--- Comment #2 from lucier at math dot purdue dot edu  2008-09-12 17:44 
---
Created an attachment (id=16306)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16306&action=view)
Mainline time and memory stats for revision 140295, 09/11/2008


-- 


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

[Bug target/37489] In cse.c:fold_rtx(), "true" is represented in floating-point modes as const_true_rtx, if FLOAT_STORE_FLAG_VALUE is undefined.

[hjl dot tools at gmail dot com]

--- Comment #4 from hjl dot tools at gmail dot com  2008-09-12 17:53 ---
We can't define FLOAT_STORE_FLAG_VALUE for SSE since we can't
represent 0xfff as a valid FP value. This patch makes
fold_rtx to match simplify_relational_operation:

--- ./cse.c.foo 2008-09-08 10:46:09.0 -0700
+++ ./cse.c 2008-09-12 10:46:18.0 -0700
@@ -3217,14 +3217,16 @@ fold_rtx (rtx x, rtx insn)
  rtx true_rtx = const_true_rtx, false_rtx = const0_rtx;
  enum machine_mode mode_arg1;

-#ifdef FLOAT_STORE_FLAG_VALUE
  if (SCALAR_FLOAT_MODE_P (mode))
{
+#ifdef FLOAT_STORE_FLAG_VALUE
  true_rtx = (CONST_DOUBLE_FROM_REAL_VALUE
  (FLOAT_STORE_FLAG_VALUE (mode), mode));
+#else
+ true_rtx = NULL_RTX;
+#endif
  false_rtx = CONST0_RTX (mode);
}
-#endif

  code = find_comparison_args (code, &folded_arg0, &folded_arg1,
   &mode_arg0, &mode_arg1);
@@ -3332,8 +3334,17 @@ fold_rtx (rtx x, rtx insn)
  const_arg1))
  || (REG_P (folded_arg1)
  && (REG_QTY (REGNO (folded_arg1)) ==
ent->comparison_qty
-   return (comparison_dominates_p (ent->comparison_code,
code)
-   ? true_rtx : false_rtx);
+   {
+ if (comparison_dominates_p (ent->comparison_code,
code))
+   {
+ if (true_rtx)
+   return true_rtx;
+ else
+   break;
+   }
+ else
+   return false_rtx;
+   }
}
}
}


-- 


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

[Bug fortran/37486] alignment of data in COMMON blocks

[jv244 at cam dot ac dot uk]

--- Comment #1 from jv244 at cam dot ac dot uk  2008-09-12 17:56 ---
the program is non-standard Fortran, but it is legacy, so an option would be
useful.


-- 


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

[Bug fortran/37494] function of a module not recognized by a subroutine in the same module

[jv244 at cam dot ac dot uk]

--- Comment #7 from jv244 at cam dot ac dot uk  2008-09-12 18:02 ---
(In reply to comment #5)
> It seems that declaring 'fonc' makes it external to the module, while without
> any declaration, 'fonc' is found to be the "internal procedure" defined within
> the module.

which is the correct behavior.


-- 

jv244 at cam dot ac dot uk changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug target/37096] conditional evaluation incorrect with -O3

[ubizjak at gmail dot com]

--- Comment #10 from ubizjak at gmail dot com  2008-09-12 18:03 ---
This is in fact undefined code. When Transform4x4() gets inlined in fun(), you
are accessing pAR[0] (aliased to *pMatrix) as "short" and as __m128i. Since
-fstrict-aliasing (the default) assumes that "short" can't alias __m128i, gcc
reorders stores and loads to the same address at will.

This is the diff between -fstrict-aliasing (t_.s) and -fno-strict-aliasing
(t.s):

--- t.s 2008-09-12 19:27:23.0 +0200
+++ t_.s2008-09-12 19:27:04.0 +0200
@@ -68,6 +68,7 @@
movq8(%rsp), %rax
movq%xmm2, 32(%rdi)
movq%xmm5, 64(%rdi)
+   movw$0, (%rdi)
movq%xmm0, 96(%rdi)
movl%eax, %esi
movq%rax, %rcx
@@ -77,10 +78,9 @@
shrq$48, %rdx
testw   %si, %si
movq%rax, (%rdi)
-   movw$0, (%rdi)
+   movl$.LC0, %edi
setne   %sil
cmpw$1, %cx
-   movl$.LC0, %edi
movzbl  %sil, %esi
sbbl$-1, %esi
cmpw$1, %dx

You can see that store of 0 to (%rdi) has been moved above store of %rax to the
same address. You should use unions to fix your code.


-- 

ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID


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

[Bug fortran/37498] Incorrect array value returned

[domob at gcc dot gnu dot org]

--- Comment #1 from domob at gcc dot gnu dot org  2008-09-12 18:07 ---
I've not checked, but maybe this is related to PR 37199?


-- 

domob at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||domob at gcc dot gnu dot org


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

[Bug middle-end/37500] New: [4.4 Regression] libstdc++ failed to compile at -O0

[hjl dot tools at gmail dot com]

On Linux/x86-64, libstdc++ failed to compile at -O0:

[EMAIL PROTECTED] gcc-work]$ 
/export/build/gnu/gcc-work/build-x86_64-linux/./gcc/xgcc
-shared-libgcc -B/export/build/gnu/gcc-work/build-x86_64-linux/./gcc
-nostdinc++
-L/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/usr/gcc-4.4-work/x86_64-unknown-linux-gnu/bin/
-B/usr/gcc-4.4-work/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/gcc-4.4-work/x86_64-unknown-linux-gnu/include -isystem
/usr/gcc-4.4-work/x86_64-unknown-linux-gnu/sys-include
-I/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/export/build/gnu/gcc-work/build-x86_64-linux/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/export/gnu/src/gcc-work/gcc/libstdc++-v3/libsupc++ -fno-implicit-templates
-Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -g -O0 -D_GNU_SOURCE -c
/export/gnu/src/gcc-work/gcc/libstdc++-v3/src/compatibility.cc  -fPIC -DPIC -o
.libs/compatibility.o
/export/gnu/src/gcc-work/gcc/libstdc++-v3/src/compatibility.cc:408: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] gcc-work]$ 
Program received signal SIGSEGV, Segmentation fault.
0x004ed628 in ggc_free (p=)
at ../../src-trunk/gcc/ggc-page.c:1421
1421pe->in_use_p[word] &= ~(1UL << bit);
Missing separate debuginfos, use: debuginfo-install glibc.x86_64 gmp.x86_64
mpfr.x86_64
(gdb) bt
#0  0x004ed628 in ggc_free (p=)
at ../../src-trunk/gcc/ggc-page.c:1421
#1  0x005233c1 in flow_loops_free (loops=0xff0620)
at ../../src-trunk/gcc/cfgloop.c:217
#2  0x00a1d2eb in rest_of_handle_ira ()
at ../../src-trunk/gcc/ira.c:1885
#3  0x006374d8 in execute_one_pass (pass=0xf672a0)
at ../../src-trunk/gcc/passes.c:1279
#4  0x00637705 in execute_pass_list (pass=0xf672a0)
at ../../src-trunk/gcc/passes.c:1327
#5  0x0063771d in execute_pass_list (pass=0xf625c0)
at ../../src-trunk/gcc/passes.c:1328
#6  0x00707487 in tree_rest_of_compilation (fndecl=0x7f3e946e2300)
at ../../src-trunk/gcc/tree-optimize.c:418
#7  0x00826554 in cgraph_expand_function (node=0x7f3e942d0700)
at ../../src-trunk/gcc/cgraphunit.c:1038
#8  0x00826764 in cgraph_output_in_order ()
at ../../src-trunk/gcc/cgraphunit.c:1186
#9  0x00827cfd in cgraph_optimize ()
at ../../src-trunk/gcc/cgraphunit.c:1297
#10 0x00451d6d in cp_write_global_declarations ()
at ../../src-trunk/gcc/cp/decl2.c:3608
#11 0x006cce81 in toplev_main (argc=, 
---Type  to continue, or q  to quit---
argv=) at ../../src-trunk/gcc/toplev.c:979
#12 0x00342da1e32a in __libc_start_main () from /lib64/libc.so.6
#13 0x00404369 in _start ()
(gdb)


-- 
   Summary: [4.4 Regression] libstdc++ failed to compile at -O0
   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=37500

[Bug fortran/37486] alignment of data in COMMON blocks

[kargl at gcc dot gnu dot org]

--- Comment #2 from kargl at gcc dot gnu dot org  2008-09-12 18:30 ---
(In reply to comment #1)
> the program is non-standard Fortran, but it is legacy, so an option would be
> useful.
> 

Why is it nonstandard?

Maybe I'm misreading 5.5.2.1 and 5.5.2.3 from the F95 standard, which
suggest to me that the program is conforming.


-- 


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

[Bug testsuite/37495] FAIL: gcc.c-torture/compile/vector-4.c

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-09-12 18:43 ---
Can you add

/* { dg-do compile } */

to gcc.c-torture/compile/vector-4.c?


-- 


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

[Bug fortran/37486] alignment of data in COMMON blocks

[kargl at gcc dot gnu dot org]

--- Comment #3 from kargl at gcc dot gnu dot org  2008-09-12 18:44 ---
(In reply to comment #2)
> (In reply to comment #1)
> > the program is non-standard Fortran, but it is legacy, so an option would be
> > useful.
> > 
> 
> Why is it nonstandard?
> 
> Maybe I'm misreading 5.5.2.1 and 5.5.2.3 from the F95 standard, which
> suggest to me that the program is conforming.
> 

Yeah, I'm responding to myself.  5.5.2.1 actually suggests that gfortran's
behavior of adding padding is violation of standard.


-- 


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

[Bug bootstrap/37441] [4.4 regression] dwarf2 unwind info patches produce undefined symbols

[ro at techfak dot uni-bielefeld dot de]

--- Comment #5 from ro at techfak dot uni-bielefeld dot de  2008-09-12 
18:47 ---
Subject: Re:  [4.4 regression] dwarf2 unwind info patches produce undefined
symbols

Patch here:

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00978.html


-- 


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

[Bug fortran/37486] alignment of data in COMMON blocks

[jv244 at cam dot ac dot uk]

--- Comment #4 from jv244 at cam dot ac dot uk  2008-09-12 18:48 ---
(In reply to comment #2)
> (In reply to comment #1)
> > the program is non-standard Fortran, but it is legacy, so an option would be
> > useful.
> > 
> 
> Why is it nonstandard?
> 

Maybe not, I was guessing based on 16.5.6 that n3 and n4 are actually undefined
at the point of printing.


-- 


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

[Bug fortran/37498] Incorrect array value returned

[jv244 at cam dot ac dot uk]

--- Comment #2 from jv244 at cam dot ac dot uk  2008-09-12 18:50 ---
(In reply to comment #1)
> I've not checked, but maybe this is related to PR 37199?
> 
I can not reproduce that with the 4.3 branch:

gcc version 4.3.3 20080912 (prerelease) (GCC)
[EMAIL PROTECTED]:/data03/vondele/bug> ./a.out
   1   3
   2   3
   3   3
nor with 4.3.0


-- 


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

[Bug target/37489] In cse.c:fold_rtx(), "true" is represented in floating-point modes as const_true_rtx, if FLOAT_STORE_FLAG_VALUE is undefined.

[raksit at gcc dot gnu dot org]

--- Comment #5 from raksit at gcc dot gnu dot org  2008-09-12 18:52 ---
Created an attachment (id=16307)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16307&action=view)
new test: gcc/testsuite/g++.dg/opt/cse3.C


-- 


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

[Bug target/37489] In cse.c:fold_rtx(), "true" is represented in floating-point modes as const_true_rtx, if FLOAT_STORE_FLAG_VALUE is undefined.

[raksit at gcc dot gnu dot org]

--- Comment #6 from raksit at gcc dot gnu dot org  2008-09-12 18:54 ---
(In reply to comment #4)
> We can't define FLOAT_STORE_FLAG_VALUE for SSE since we can't
> represent 0xfff as a valid FP value. This patch makes
> fold_rtx to match simplify_relational_operation:
> 
> --- ./cse.c.foo 2008-09-08 10:46:09.0 -0700
> +++ ./cse.c 2008-09-12 10:46:18.0 -0700
> @@ -3217,14 +3217,16 @@ fold_rtx (rtx x, rtx insn)
>   rtx true_rtx = const_true_rtx, false_rtx = const0_rtx;
>   enum machine_mode mode_arg1;
> 
> -#ifdef FLOAT_STORE_FLAG_VALUE
>   if (SCALAR_FLOAT_MODE_P (mode))
> {
> +#ifdef FLOAT_STORE_FLAG_VALUE
>   true_rtx = (CONST_DOUBLE_FROM_REAL_VALUE
>   (FLOAT_STORE_FLAG_VALUE (mode), mode));
> +#else
> + true_rtx = NULL_RTX;
> +#endif
>   false_rtx = CONST0_RTX (mode);
> }
> -#endif
> 
>   code = find_comparison_args (code, &folded_arg0, &folded_arg1,
>&mode_arg0, &mode_arg1);
> @@ -3332,8 +3334,17 @@ fold_rtx (rtx x, rtx insn)
>   const_arg1))
>   || (REG_P (folded_arg1)
>   && (REG_QTY (REGNO (folded_arg1)) ==
> ent->comparison_qty
> -   return (comparison_dominates_p (ent->comparison_code,
> code)
> -   ? true_rtx : false_rtx);
> +   {
> + if (comparison_dominates_p (ent->comparison_code,
> code))
> +   {
> + if (true_rtx)
> +   return true_rtx;
> + else
> +   break;
> +   }
> + else
> +   return false_rtx;
> +   }
> }
> }
> }
> 

I had a similar patch in mind. In case it helps, I have attached a testcase
that you can use for the submission. You might also want to fix the gcc-4.3
branch.

-raksit


-- 


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

[Bug fortran/37486] alignment of data in COMMON blocks

[kargl at gcc dot gnu dot org]

--- Comment #5 from kargl at gcc dot gnu dot org  2008-09-12 19:03 ---
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > the program is non-standard Fortran, but it is legacy, so an option would 
> > > be
> > > useful.
> > > 
> > 
> > Why is it nonstandard?
> > 
> 
> Maybe not, I was guessing based on 16.5.6 that n3 and n4 are actually
> undefined at the point of printing.

AFAICT, n3 and n4 are defined in one() because they are associated
with n3 and n4 of the main program which have the same type and kind.
n2(2) is undefined in one() and it would be undefined even if r1 had
been set in prog because their types are different.

This is equivalent to the ever popular use of EQUIVALENCE to set a
real type to Inf or NaN via integers.

   equivalence(x,i)
   ! The following makes x undefined.
   i = SOME_INT_BIT_PATTERN_FOR_INF 
   ! Do stuff with i.
   ! The following makes i undefined.
   x  = 1.
   end


-- 


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

[Bug fortran/37498] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

--- Comment #3 from tkoenig at gcc dot gnu dot org  2008-09-12 19:05 ---
This may be due to an incompatibility between the 4.3
and 4.4 libraries.

What result do you get when you compile with "-static",
to make sure that you get the right library?


-- 


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

[Bug fortran/37501] New: [4.4 regression] ABI breakage with _gfortran_set_options

[tkoenig at gcc dot gnu dot org]

$ cat 43.f90
end
$ cat 44.f90
end
$ gfortran-4.3 -fdump-tree-original 43.f90
$ gfortran -fdump-tree-original 44.f90
$ diff -u *original
--- 43.f90.003t.original2008-09-12 21:12:50.0 +0200
+++ 44.f90.003t.original2008-09-12 21:12:59.0 +0200
@@ -1,8 +1,8 @@
 MAIN__ ()
 {
-  static integer(kind=4) options.0[7] = {68, 127, 0, 0, 0, 1, 0};
+  static integer(kind=4) options.0[8] = {68, 255, 0, 0, 0, 1, 0, 1};

-  _gfortran_set_options (7, (void *) &options.0);
+  _gfortran_set_options (8, (void *) &options.0);
 }

This makes running 4.3 programs with the 4.4 libraries impossible,
as the library will receive garbage on its eigth argument.


-- 
   Summary: [4.4 regression] ABI breakage with _gfortran_set_options
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: wrong-code, ABI
  Severity: critical
  Priority: P3
 Component: fortran
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=37501

[Bug fortran/37498] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

--- Comment #4 from tkoenig at gcc dot gnu dot org  2008-09-12 19:19 ---
See PR 37501.


-- 


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

[Bug testsuite/37495] FAIL: gcc.c-torture/compile/vector-4.c

[dominiq at lps dot ens dot fr]

--- Comment #2 from dominiq at lps dot ens dot fr  2008-09-12 19:32 ---
Subject: Re:  FAIL: gcc.c-torture/compile/vector-4.c

> Can you add
>
> /* { dg-do compile } */
>
> to gcc.c-torture/compile/vector-4.c?

Yes, indeed I can, but will this work better than

[ibook-dhum] f90/bug% gcc44 -c -mavx
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.c-torture/compile/vector-4.c
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccK7JXKe.s:17:no such
instruction: `vmovq (%eax), %xmm0'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccK7JXKe.s:18:no such
instruction: `vmovq %xmm0, -48(%ebp)'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccK7JXKe.s:56:no such
instruction: `vmovd -36(%ebp), %xmm0'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccK7JXKe.s:57:no such
instruction: `vpinsrd $0x1, %eax,%xmm0,%xmm0'
/var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccK7JXKe.s:58:no such
instruction: `vmovq %xmm0, -32(%ebp)'

?


-- 


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

[Bug fortran/37498] Incorrect array value returned

[brtnfld at hdfgroup dot org]

--- Comment #5 from brtnfld at hdfgroup dot org  2008-09-12 19:38 ---
(In reply to comment #3)
> This may be due to an incompatibility between the 4.3
> and 4.4 libraries.
> 
> What result do you get when you compile with "-static",
> to make sure that you get the right library?
> 

That fixed the problem, my mistake. Thanks for pointing that out.


-- 


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

[Bug middle-end/37489] const_true_rtx returned for float compare

[hjl dot tools at gmail dot com]

--- Comment #7 from hjl dot tools at gmail dot com  2008-09-12 19:40 ---
A patch is posted at

http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00984.html


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

  Component|target  |middle-end
Summary|In cse.c:fold_rtx(), "true" |const_true_rtx returned for
   |is represented in floating- |float compare
   |point modes as  |
   |const_true_rtx, if  |
   |FLOAT_STORE_FLAG_VALUE is   |
   |undefined.  |


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

[Bug middle-end/37500] [4.4 Regression] libstdc++ failed to compile at -O0

[hjl dot tools at gmail dot com]

--- Comment #1 from hjl dot tools at gmail dot com  2008-09-12 19:42 ---
It is caused by revision 140285.


-- 

hjl dot tools at gmail dot com changed:

   What|Removed |Added

 CC||jh at suse dot cz


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

--- Comment #6 from tkoenig at gcc dot gnu dot org  2008-09-12 19:47 ---
(In reply to comment #5)
> (In reply to comment #3)
> > This may be due to an incompatibility between the 4.3
> > and 4.4 libraries.
> > 
> > What result do you get when you compile with "-static",
> > to make sure that you get the right library?
> > 
> 
> That fixed the problem, my mistake. Thanks for pointing that out.

Actually, this is a bug - the libraries are supposed to be upward
compatible, so that you can run a 4.3-compiled program with 4.4.
If that doesn't work, this is a bug in 4.4.

I get a different behaviour for you test case on i686-pc-linux-gnu -
and endless loop which outputs zeros only, so I can confirm this.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

   Severity|normal  |critical
 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Keywords||ABI, wrong-code
   Last reconfirmed|-00-00 00:00:00 |2008-09-12 19:47:33
   date||
Summary|Incorrect array value   |[4.4 Regression] Incorrect
   |returned|array value returned
   Target Milestone|--- |4.4.0


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

[Bug fortran/37501] [4.4 regression] ABI breakage with _gfortran_set_options

[tkoenig at gcc dot gnu dot org]

-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[tkoenig at gcc dot gnu dot org]

--- Comment #7 from tkoenig at gcc dot gnu dot org  2008-09-12 19:57 ---
The value of i gets overwritten in the library when assiging
a value to dtp->u.p.mode.  OUCH.

This is what I get when running the 4.3 - compiled program
against the 4.4 library:

$ gfortran-4.3 -g foo.f90
$ gdb ./a.out
GNU gdb 6.8-debian
Copyright (C) 2008 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"...
(gdb) b foo.f90:2
Breakpoint 1 at 0x80485a1: file foo.f90, line 2.
(gdb) r
Starting program: /home/ig25/Krempel/ABI/a.out

Breakpoint 1, test_kind () at foo.f90:5
5kind_numbers(1:3) = 3
Current language:  auto; currently fortran
(gdb) watch i
Hardware watchpoint 2: i
(gdb) c
Continuing.
Hardware watchpoint 2: i

Old value = -1208866858
New value = 1
0x080485d5 in test_kind () at foo.f90:6
6DO i = 1, 3
(gdb) c
Continuing.
Hardware watchpoint 2: i

Old value = 1
New value = 0
data_transfer_init (dtp=0xbf82f9f0, read_flag=0) at
../../../../gcc/trunk/libgfortran/io/transfer.c:1825
1825  dtp->u.p.mode = read_flag ? READING : WRITING;
Current language:  auto; currently c
(gdb)   


-- 


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

[Bug bootstrap/37424] [4.4 regression] IRA merge breaks Solaris/SPARC bootstrap

[ebotcazou at gcc dot gnu dot org]

--- Comment #6 from ebotcazou at gcc dot gnu dot org  2008-09-12 19:59 
---
Fixed by

2008-09-11  Jeff Law <[EMAIL PROTECTED]>

* reload1.c (alter_reg): Undo the BYTE_BIG_ENDIAN correction performed
by assign_stack_local on the IRA path for stack slot sharing
as well as the non-IRA path.


-- 

ebotcazou at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


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

[Bug fortran/37501] [4.4 regression] ABI breakage with _gfortran_set_options

[burnus at gcc dot gnu dot org]

--- Comment #1 from burnus at gcc dot gnu dot org  2008-09-12 19:59 ---
> This makes running 4.3 programs with the 4.4 libraries impossible,
> as the library will receive garbage on its eigth argument.

Why? The first argument should tell how many arguments exists.

set_options has:

  if (num >= 7)
compile_options.bounds_check = options[6];
  if (num >= 8)
compile_options.range_check = options[7];

Thus if there is no 8th argument, there should be no problem (assuming that
there are reasonable default values).


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu dot
   ||org


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

[Bug c/37502] New: no warning for always-false/true conditions due to too small bitfields

[j at uriah dot heep dot sax dot de]

Given the following code:

volatile struct {
unsigned char a: 1;
} bits;

unsigned char
getfoo(void)
{
while (bits.a < 3)
/* wait */;
return 42;
}

GCC does not emit a warning with -Wall -Wextra yet happily generates an
infinite loop since the while condition is always true due to the
limited size of the bitfield.  I expected to get a warning similar to
those when using a too small integer type.


-- 
   Summary: no warning for always-false/true conditions due to too
small bitfields
   Product: gcc
   Version: 4.3.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j at uriah dot heep dot sax dot de


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

[Bug fortran/37501] [4.4 regression] ABI breakage with _gfortran_set_options

[tkoenig at gcc dot gnu dot org]

--- Comment #2 from tkoenig at gcc dot gnu dot org  2008-09-12 20:02 ---
Ops, you're right.

Closing.


-- 

tkoenig at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/37503] New: autoconf detects g++ as having a remainder bug

[nightstrike at gmail dot com]

While trying to compile PPL using a gcc that targets Win64, an autoconf test
for a "remainder" bug fails.  The test basically tries to compute INT_MIN % -1.
 The program compiles cleanly, but execution results in a crash with exit code
149.  The compile line is without any -O optimization, and with a single -f
option:

g++ -frounding-math a.cpp

 The test is as follows:

#include 

int minus_one(int n) {
   return (n+1)*(n-1)-n*n;
}

int p(int x, int y) {
   int z = x % y;
   return z;
}

int main(int argc, char** argv) {
   if (p(INT_MIN, minus_one(argc)) != 0)
 return 1;
   else
 return 0;
}


-- 
   Summary: autoconf detects g++ as having a remainder bug
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nightstrike at gmail dot com


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

[Bug c++/37503] autoconf detects g++ as having a remainder bug

[pinskia at gcc dot gnu dot org]

--- Comment #1 from pinskia at gcc dot gnu dot org  2008-09-12 20:17 ---
INT_MIN % -1 is undefined as INT_MIN/-1 is undefined.  The reason why
INT_MIN/-1  is undefined is because  - INT_MIN overflows.  So this is not a GCC
bug but a PPL bug.  Report this to them.


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


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

[Bug c++/37503] autoconf detects g++ as having a remainder bug

[nightstrike at gmail dot com]

--- Comment #2 from nightstrike at gmail dot com  2008-09-12 20:32 ---
Re-opening, valid PR as per 30484.  Will close as duplicate.


-- 

nightstrike at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


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

[Bug c++/37503] autoconf detects g++ as having a remainder bug

[nightstrike at gmail dot com]

--- Comment #3 from nightstrike at gmail dot com  2008-09-12 20:32 ---
Marking as duplicate of 30484.

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


-- 

nightstrike at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE


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

[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family

[nightstrike at gmail dot com]

--- Comment #7 from nightstrike at gmail dot com  2008-09-12 20:32 ---
*** Bug 37503 has been marked as a duplicate of this bug. ***


-- 

nightstrike at gmail dot com changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com


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

[Bug middle-end/37500] [4.4 Regression] libstdc++ failed to compile at -O0

[pinskia at gcc dot gnu dot org]

--- Comment #2 from pinskia at gcc dot gnu dot org  2008-09-12 20:33 ---
(In reply to comment #1)
> It is caused by revision 140285.

That does not mean there is a bug in IRA.

Can you attach the preprocessed source?


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

 GCC target triplet||x86_64-unknown-linux-gnu
   Keywords||build, GC, ice-on-valid-code
   Target Milestone|--- |4.4.0


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

[Bug libstdc++/37470] parallel/base.h log2 conflicts with math.h

[paul dot isaacson at earthlink dot net]

--- Comment #3 from paul dot isaacson at earthlink dot net  2008-09-12 
20:41 ---
Subject: RE:  parallel/base.h log2 conflicts with math.h

Unfortunately I don't have a simple test case, but it's not too hard to
reproduce:

Download stxxl.1.2.1 and attempt to make it with pmode enabled.  The gcc
compiler will show the conflicting log2 usage while compiling various
modules.

http://sourceforge.net/project/showfiles.php?group_id=131632&package_id=1444
07&release_id=619867

My make.settings.local (see the install instructions)

STXXL_ROOT   = $(HOME)/stxxl-1.2.1
COMPILER_GCC =g++
OPT  =-O3 -march=k8 -mtune=k8
USE_BOOST=yes
BOOST_ROOT   =/usr/local/include/boost
PTHREAD_FLAG =
USE_PMODE=yes

Issue make library_g++_pmode and you will see the compilation errors.

I've already modified my local copies of the STL pmode parallel/* headers
and STXXL files that caused problems building STXXL, so I would have to
revert to the original versions and eliminate the STXXL dependencies  in my
project to see if the log2 statements in various pmode for-loops trigger the
same error.  If you need me to do this, let me know and I'll try to get you
a minimum test case.

Cheers,
Paul
-Original Message-
From: singler at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 12, 2008 1:46 AM
To: [EMAIL PROTECTED]
Subject: [Bug libstdc++/37470] parallel/base.h log2 conflicts with math.h



--- Comment #2 from singler at gcc dot gnu dot org  2008-09-12 08:45
---
Clearly, this is a potential conflict, and the solution is pretty obvious. 

However, I am unable to reproduce it on x86_64-unknown-linux-gnu, for a
definite test case. Do you have a simple testcase that triggers the bug (on
your platform)? Do you use the parallel mode by default
(-D_GLIBCXX_PARALLEL)
or selectively? Do you have 'using namespace ...' statements?  or
?  or ? ? ? I might have
some
mental block ;-)


-- 

singler at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |singler at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED
   Last reconfirmed|2008-09-10 22:46:43 |2008-09-12 08:45:35
   date||


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

--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.


-- 


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

[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family

[jsm28 at gcc dot gnu dot org]

--- Comment #9 from jsm28 at gcc dot gnu dot org  2008-09-12 20:41 ---
Note libgcc functions would only need to get it right for CPUs defining the
macro, if in other cases the source checks would be inserted anyway.  Or the
macro could depend on the mode of the division/modulo operation.


-- 


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

[Bug fortran/37486] alignment of data in COMMON blocks

[burnus at gcc dot gnu dot org]

--- Comment #6 from burnus at gcc dot gnu dot org  2008-09-12 20:42 ---
> This is equivalent to the ever popular use of EQUIVALENCE to set a
> real type to Inf or NaN via integers.

Actually, it is a bit different: Here, already the COMMON is invalid for
EQUIVALENCE only accessing the value is invalid as the value is undefined.
Default integer and default real are in the same storage sequence (and here
probably the analog to EQUIVALENCE holds). I think the following program is
valid according to the standard and it has the same problem:

subroutine one()
  integer :: i
  common /com/ i
  print *, i
end subroutine one

program test
integer :: j
real(8) :: r8
common /com/ i, r8 
i = 5
call one()
end program test

(If I recall correctly, the commons do not need to have the same size, but the
shorter ones need to be identical to the longer one minus the extra elements.)


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-09-12 20:42:06
   date||


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

[Bug target/30484] Miscompilation of remainder expressions on CPUs of the i386 family

[jsm28 at gcc dot gnu dot org]

--- Comment #8 from jsm28 at gcc dot gnu dot org  2008-09-12 20:39 ---
I suggest an option such as -fdivide-checks, off by default.  -std=c99 and
other conformance options, for languages where INT_MIN % -1 is defined, would
enable this option unless -fno-divide-checks is specified by the user.  -fwrapv
would enable this option unless -fno-divide-checks is specified by the user.

The option would cause checks to be inserted at gimplification time or earlier:
A % B would evaluate A and B for their side effects, then check whether B is -1
and if so evaluate to 0 instead of carrying out the modulo operation.  If
flag_wrapv is set as well, similar checks would be applied to division to catch
INT_MIN / -1.

If a target macro is defined that says that the implementations of the relevant
RTL insn patterns will generate the desired results (0 for modulo, INT_MIN
for division) without trapping, then the option would have no effect.  I don't
know what processors this might apply to.

libgcc functions for long long division and modulo need checking.  I'd guess
they can be arranged to get this right unconditionally rather than needing to
call different functions in the two modes.


-- 


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

[Bug fortran/37498] [4.4 Regression] Incorrect array value returned

[burnus at gcc dot gnu dot org]

--- Comment #8 from burnus at gcc dot gnu dot org  2008-09-12 20:49 ---
The problem is this harmless looking variable in the program (from
-fdump-tree-original):
  struct __st_parameter_dt dt_parm.2;
This struct matches st_parameter_dt in libgfortran/io/io.h. If one compares 4.3
with 4.4 one finds:
@@ -329,0 +384,9 @@ typedef struct st_parameter_dt
+  GFC_IO_INT *id;
+  GFC_IO_INT pos;
+  CHARACTER1 (asynchronous);
+  CHARACTER2 (blank);
+  CHARACTER1 (decimal);
+  CHARACTER2 (delim);
+  CHARACTER1 (pad);
+  CHARACTER2 (round);
+  CHARACTER1 (sign);
@@ -344 +407,2 @@ typedef struct st_parameter_dt
- enum {SIGN_S, SIGN_SS, SIGN_SP} sign_status;
+  unit_pad pad_status;
+ enum { SIGN_S, SIGN_SS, SIGN_SP } sign_status;
@@ -356,0 +421,2 @@ typedef struct st_parameter_dt
+ unit_decimal decimal_status;
+  unit_delim delim_status;

Ideas how to make this compatible? If not, shall we bump the version number
(and include the rank change ;-) ?


-- 

burnus at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu dot
   ||org


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

[Bug bootstrap/37424] [4.4 regression] IRA merge breaks Solaris/SPARC bootstrap

[andreast at gcc dot gnu dot org]

--- Comment #7 from andreast at gcc dot gnu dot org  2008-09-12 21:07 
---
Thanks!

First results here, but with disable-checking:
http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg01060.html

Same version is now building w/o disable-checking.


-- 


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

[Bug fortran/37504] New: Wrongly rejects: unprotected_pointer => protected_pointer

[burnus at gcc dot gnu dot org]

Found at:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/73c7b88ffbe8e1d5

The following (see URL above) is valid but gfortran rejects it with:
 Error: Pointer assignment target has PROTECTED attribute at (1)

> C538:
>
> "A pointer object that has the PROTECTED attribute and is accessed by
> use association shall not appear as (1) A pointer-object in a pointer-
> assignment-stmt..."
>
> C538 doesn't forbid using a protected pointer as the target of a
> pointer-assignment-stmt.

module m
  implicit none
  integer, pointer, protected :: protected_pointer
end module m

program p
  use m
  implicit none
  integer, pointer :: unprotected_pointer
  unprotected_pointer => protected_pointer
end program p


-- 
   Summary: Wrongly rejects: unprotected_pointer =>
protected_pointer
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org


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

[Bug middle-end/37500] [4.4 Regression] libstdc++ failed to compile at -O0

[hjl dot tools at gmail dot com]

--- Comment #3 from hjl dot tools at gmail dot com  2008-09-12 21:17 ---
Created an attachment (id=16308)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16308&action=view)
A testcase

[EMAIL PROTECTED] gcc]$ ./xgcc -B./ -S /tmp/x.ii
/export/gnu/src/gcc-work/gcc/libstdc++-v3/src/compatibility.cc:202: internal
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
[EMAIL PROTECTED] gcc]$ 


-- 


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

[Bug fortran/37486] alignment of data in COMMON blocks

[kargl at gcc dot gnu dot org]

--- Comment #7 from kargl at gcc dot gnu dot org  2008-09-12 21:18 ---
(In reply to comment #6)
> > This is equivalent to the ever popular use of EQUIVALENCE to set a
> > real type to Inf or NaN via integers.
> 
> Actually, it is a bit different: Here, already the COMMON is invalid for
> EQUIVALENCE only accessing the value is invalid as the value is undefined.

I can't parse the above sentence. :(

> Default integer and default real are in the same storage sequence (and here
> probably the analog to EQUIVALENCE holds). I think the following program is
> valid according to the standard and it has the same problem:
> 
> subroutine one()
>   integer :: i
>   common /com/ i
>   print *, i
> end subroutine one
> 
> program test
> integer :: j
> real(8) :: r8
> common /com/ i, r8 
> i = 5
> call one()
> end program test
> 
> (If I recall correctly, the commons do not need to have the same size, but the
> shorter ones need to be identical to the longer one minus the extra elements.)

Yes, the above is a valid program via 5.5.2.1(2) of the F95 standard.

A problem does not exist if by default gfortran does not pad the
common block to align double precision types on 8 byte boundaries.

Returning to your code in comment #1.  The two common statements
occupy 5 storage units.  As soon as gfortran puts padding into
the "common /foo/ n1,r1,n2,n3", gfortran has violated 5.5.2.1(1) of
the standard because it is changing the storage sequence of 
"common /foo/n1,n2(2),n3,n4".

To summarize, gfortran should not pad common blocks.  gfortran can
issue a warning alerting the user of an align issue if one exists.
gfortran should implement a -falign-common option to user a gun to
blow their feet off.


-- 


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

[Bug fortran/37486] alignment of data in COMMON blocks

[dominiq at lps dot ens dot fr]

--- Comment #8 from dominiq at lps dot ens dot fr  2008-09-12 21:31 ---
> If I recall correctly, the commons do not need to have the same size 

5.7.2.5 Differences between named common and blank common (F2008, 5.5.2.4 for
f95)

...

• Named common blocks of the same name shall be of the same size in all scoping
units of a program in which they appear, but blank common blocks may be of
different sizes.

For the test in comment #6, the common should be blank one to make the test
valid (detected with 
-Wall).


-- 


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

[Bug rtl-optimization/37377] [4.4 Regression] Bootstrap failure compiling libgcc

[vmakarov at gcc dot gnu dot org]

--- Comment #14 from vmakarov at gcc dot gnu dot org  2008-09-12 22:56 
---
Subject: Bug 37377

Author: vmakarov
Date: Fri Sep 12 22:55:23 2008
New Revision: 140325

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140325
Log:
2008-09-12  Vladimir Makarov  <[EMAIL PROTECTED]>

PR rtl-opt/37377

* ira-build.c (common_loop_tree_node_dominator): Remove.
(copy_live_ranges_to_removed_store_destinations): New function.
(regno_top_level_allocno_map): Move to top level from ...
(ira_flattening): ... here.  Use
copy_live_ranges_to_removed_store_destinations.

* ira-emit.c (generate_edge_moves): Fix a comment.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-build.c
trunk/gcc/ira-emit.c


-- 


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

[Bug c/37484] [graphite] Valgrind gives invalid reads/writes on CPU2006 403.gcc benchmark

[spop at gcc dot gnu dot org]

--- Comment #2 from spop at gcc dot gnu dot org  2008-09-12 23:05 ---
Subject: Bug 37484

Author: spop
Date: Fri Sep 12 23:03:54 2008
New Revision: 140327

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140327
Log:
2008-09-12  Sebastian Pop  <[EMAIL PROTECTED]>

PR tree-optimization/37484
* graphite.c (scop_record_loop): Use snprintf instead of sprintf.
(save_var_name): Same.
(initialize_cloog_names): Same.
(initialize_cloog_names): Same.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite.c


-- 


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

[Bug c/37484] [graphite] Valgrind gives invalid reads/writes on CPU2006 403.gcc benchmark

[spop at gcc dot gnu dot org]

--- Comment #3 from spop at gcc dot gnu dot org  2008-09-12 23:08 ---
Fixed.


-- 

spop at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED


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

[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3

[brian at dessent dot net]

--- Comment #10 from brian at dessent dot net  2008-09-12 23:59 ---
Subject: Re:  [cygming] Invalid alignment for SSE store to 
 .comm data generated with -O3

One thing I was unsure about is this method switches to the .bss section
without switching back to .text (or whatever) afterwards.  As far as I
can tell the common symbols are always emitted at the end of the file
after everything else so this should be ok, but is there any chance of
this function being called from anywhere else?  (It's a shame the PE
assembler doesn't have anything like .pushsection/.popsection.)


-- 


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

[Bug testsuite/37495] FAIL: gcc.c-torture/compile/vector-4.c

[dominiq at lps dot ens dot fr]

--- Comment #3 from dominiq at lps dot ens dot fr  2008-09-13 00:09 ---
Subject: Re:  FAIL: gcc.c-torture/compile/vector-4.c

> Can you add ...

With "/* { dg-do compile } */" the tests pass. 


-- 


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

[Bug c++/5305] wrong constructor called -- default argument in constructor not seen

[reichelt at gcc dot gnu dot org]

--- Comment #9 from reichelt at gcc dot gnu dot org  2008-09-13 01:12 
---
This has been fixed on mainline between 2008-06-26 and 2008-07-05.
I think this was 'fallout' from

2008-07-02  Jason Merrill  <[EMAIL PROTECTED]>

* Make-lang.in (cp/typeck2.o): Add $(REAL_H) dependency.

Implement WG21 N2672, Initializer List proposed wording
[...]


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.4.0


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

[Bug c++/35336] Broken diagnostic: 'bit_field_ref' not supported by dump_expr

[reichelt at gcc dot gnu dot org]

--- Comment #6 from reichelt at gcc dot gnu dot org  2008-09-13 01:23 
---
The bug reappeared on the 4.3 branch.
It remains fixed on mainline, though.
So no status change since it's not a regression.


-- 

reichelt at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.3.2   |4.4.0


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

[Bug middle-end/37500] [4.4 Regression] libstdc++ failed to compile at -O0

[pinskia at gcc dot gnu dot org]

--- Comment #4 from pinskia at gcc dot gnu dot org  2008-09-13 01:53 ---
g++.dg/cpp0x/variadic-tuple.C fails for me with an ICE during GC.


-- 


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

[Bug middle-end/37500] [4.4 Regression] libstdc++ failed to compile at -O0

[pinskia at gcc dot gnu dot org]

--- Comment #5 from pinskia at gcc dot gnu dot org  2008-09-13 03:52 ---
Here is a reduced testcase for the variadic-tuple.C failure.
Compile with --param ggc-min-expand=0 --param ggc-min-heapsize=0 -w:

namespace std __attribute__ ((__visibility__ ("default"))) {
  template class basic_string;
  typedef basic_string string;
  template
  struct basic_string {
void  _M_destroy() throw();
basic_string(const char* __s);
~basic_string()   {
  _M_destroy();
}
  };
  template   void basic_string<_CharT>:: _M_destroy() throw ()
{   }
  extern template class basic_string;
};
template class tuple;
template<> class tuple<> { };
template struct tuple : private
tuple  {
  typedef tuple inherited;
  tuple()  {  }
  template   tuple(const tuple& other)
:
m_head(other.head())
,inherited(other.tail())
  {  }
  const Head &head() const {  }
  const inherited& tail() const {  }
  Head m_head;
};
int main() {
  tuple t3a;
  tuple t3b(t3a);
}


-- 


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