[Bug tree-optimization/53986] missing vrp on bit-mask test, LSHIFT_EXPR not handled

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org 2012-07-23 06:29:51 UTC ---
 Btw, if the switch is not converted to a bit-test the path to link_error is
 also not removed by vrp, because it doesn't handle anti-ranges for switches

submitted patch for this:
http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01056.html

[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

[redi at gcc dot gnu.org]

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

--- Comment #20 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-23 
08:11:48 UTC ---
The vtable should be defined in the same file as ctypechar::~ctype() i.e. in
libstdc++-v3/src/c++98/ctype.cc

You could try adding this to ctype.cc around line 54

  inline template class ctypechar;

That's a GCC extension that explicitly instantiates the vtable.

[Bug tree-optimization/43716] [4.6/4.7/4.8 Regression] Revision 158105 miscompiles doduc.f90

[rguenth at gcc dot gnu.org]

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

--- Comment #40 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-23 
08:12:55 UTC ---
tree if-conversion happily executes both arms of the conditional
unconditionally
with -ffast-math, so for example

  if (x != 0)
tem = y / x;
  else
tem = 0.;
  ... do sth with tem ...

will execute y / x unconditionally based on the fact that it cannot trap.
So simply generation of NaNs is not what you should check for, but
usage of 'tem' with NaN in the above should be (it shouldn't be used
if x is zero).

[Bug c++/54053] [4.7 Regression] g++ accepts (invalid?) 0; expression.

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.7.2

[Bug middle-end/54068] Compiler passes wrong argument to function when using optimize attribute with -O3

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Target||i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-07-23
 CC||hubicka at gcc dot gnu.org
 Ever Confirmed|0   |1
  Known to fail||4.4.7, 4.5.4, 4.6.3, 4.7.1,
   ||4.8.0

--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-23 
08:25:58 UTC ---
Confirmed.  Note that I would not expect

void myfn (int a, int b) __attribute__((optimize(-O3)));

to work reliably.  Attribute optimize is supposed to be used for debugging
only.  C testcase, compile with -O0 -m32:

extern void abort (void);
void myfn (int a, int b) __attribute__((optimize(-O3)));
static inline void showme (int b)
{
   if (b != 12)
 abort ();
}
void myfn (int a, int b)
{
   showme (b);
}
int main ()
{
   myfn (5, 12);
   return 0;
}

I suppose this is the known issue with tail-call optimization which
may get upset if you have parts compiled with -O0 and parts with -O3.

[Bug target/54063] [4.8 regression] on powerpc64 gcc 4.8 generates larger code for global variable accesses than gcc 4.7

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.8.0

[Bug plugins/54069] New: linkage type of plugin API wrong

[wein...@gns-mbh.com]

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

 Bug #: 54069
   Summary: linkage type of plugin API wrong
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wein...@gns-mbh.com


Created attachment 27856
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27856
plugin source

gcc 4.7.0 and 4.7.1
created with:
./configure --prefix=/usr/local --program-suffix=-4.7.1 --with-mpc=/usr/local
--with-mpfr=/usr/local --with-gmp=/usr/local --enable-serial-configure
--enable-languages=c,c++,fortran,objc,obj-c++

plugin (see attached source) compiled with:
gcc-4.7.1 -I`gcc -print-file-name=plugin`/include -fPIC -shared -O2 plugin.c -o
plugin.so

try to use with:
gcc-4.7.1 -fplugin=./plugin.so test.c

where test.c is simply:
int main(int argc, char *argv[]) { return 0; }
or may be any other source, doesn't matter, the test plugin does nothing...

generates following error lines:

cc1: error: cannot load plugin ./plugin.so
./plugin.so: undefined symbol: list_length

Looking at the generated compiler (libgcc, gcc-executable, etc.) it seems that
presumably all functions from tree.h, input.h, and many others seem to have
C++-linkage though they are part of a C-API. Using
#ifdef __cplusplus
extern C {
#endif /* __cplusplus */
 declarations 
#ifdef __cplusplus
} /* extern C */
#endif /* __cplusplus */

in those headers cures the problem (after long recompile)...
the function used in the plugin is only example, there are tons(!!) of others
there that have the same problem..
it would be great if you could restore ability to use C for the plugin-API..
thanks...

[Bug plugins/54069] linkage type of plugin API wrong

[wein...@gns-mbh.com]

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

--- Comment #1 from wein...@gns-mbh.com 2012-07-23 08:39:51 UTC ---
oh... forgot to mention...
system is:
linux x86-64 (openSuSe 10.3)

[Bug plugins/54069] linkage type of plugin API wrong

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE
   Severity|major   |normal

--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-23 
08:46:22 UTC ---
This is expected.  See PR 53258.

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

[Bug plugins/53258] Many symbols cannot lookup when loading plugin in configured with --enable-build-with-cxx.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wein...@gns-mbh.com

--- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-07-23 
08:46:22 UTC ---
*** Bug 54069 has been marked as a duplicate of this bug. ***

[Bug plugins/48425] installed plugin headers fail to compile, include non-existent files

[pinskia at gcc dot gnu.org]

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

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

   Severity|critical|normal

[Bug plugins/54069] linkage type of plugin API wrong

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2012-07-23 
08:49:16 UTC ---
(In reply to comment #0)
 Looking at the generated compiler (libgcc, gcc-executable, etc.) it seems that
 presumably all functions from tree.h, input.h, and many others seem to have
 C++-linkage though they are part of a C-API. 

They're not part of a C API, they're part of a C++ API.

[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true

[steven at gcc dot gnu.org]

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

--- Comment #12 from Steven Bosscher steven at gcc dot gnu.org 2012-07-23 
09:26:46 UTC ---
Author: steven
Date: Mon Jul 23 09:26:41 2012
New Revision: 189779

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189779
Log:
gcc/
PR tree-optimization/53881
* tree-cfg.c (group_case_labels_stmt): Look up the basic block
for each label and compare them instead of labels.

testsuite/
PR tree-optimization/53881
* gcc.dg/pr53881.c: Renamed to ...
* gcc.dg/pr53881-1.c: ... this.
* gcc.dg/pr53881-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/pr53881-1.c
  - copied unchanged from r189758, trunk/gcc/testsuite/gcc.dg/pr53881.c
trunk/gcc/testsuite/gcc.dg/pr53881-2.c
Removed:
trunk/gcc/testsuite/gcc.dg/pr53881.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfg.c

[Bug fortran/54070] New: Wrong code with allocatable deferred-length (array) function results

[burnus at gcc dot gnu.org]

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

 Bug #: 54070
   Summary: Wrong code with allocatable deferred-length (array)
function results
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: dam...@rouson.net, pa...@gcc.gnu.org


As reported by Damian at http://gcc.gnu.org/ml/fortran/2012-07/msg00117.html ,
allocatable deferred-length (array) function results have issues.


The following code gives a segfault - or with tree checking:
gfc_add_modify_loc, at fortran/trans.c:160

function f()
  character(len=:),allocatable :: f
  f =ABC
end function


The following (invalid) program gives an ICE:
  in gimplify_var_or_parm_decl, at gimplify.c:2048
(the program is invalid as one assigns a scalar to an unallocated array)

function f(a)
  character(len=*) :: a
  character(len=:),allocatable :: f(:)
  f = a
end function



One gets the same ICE for the original example. Looking at the dump, there is
no (re)allocation - but there should be one!

module deferred_length_char_array
contains
  function return_string(argument)
character(*) :: argument
character(:), dimension(:), allocatable :: return_string
return_string = argument
  end function 
end module

[Bug translation/54067] arm-none-eabi with -mapcs and attribute((interrupt)) generates wrong stack alignment

[rearnsha at gcc dot gnu.org]

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

--- Comment #1 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-23 
10:00:41 UTC ---
The -mapcs option isn't expected to work on AAPCS based targets.  We should fix
the compiler to reject this combination.

[Bug tree-optimization/53881] [4.8 regression] ICE in hoist_edge_and_branch_if_true

[steven at gcc dot gnu.org]

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

Steven Bosscher steven at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #13 from Steven Bosscher steven at gcc dot gnu.org 2012-07-23 
10:12:28 UTC ---
This should be fixed now. No, really. Fixed! BE FIXED!!!

[Bug middle-end/54068] Compiler passes wrong argument to function when using optimize attribute with -O3

[steven at gcc dot gnu.org]

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

Steven Bosscher steven at gcc dot gnu.org changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #2 from Steven Bosscher steven at gcc dot gnu.org 2012-07-23 
10:17:07 UTC ---
(In reply to comment #1)
 I suppose this is the known issue with tail-call optimization which
 may get upset if you have parts compiled with -O0 and parts with -O3.

If this is a known issue, then I'd expect there is already a PR for this...?

[Bug fortran/54070] Wrong code with allocatable deferred-length (array) function results

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-23 
10:23:15 UTC ---
(In reply to comment #0)
 function f()
   character(len=:),allocatable :: f
   f =ABC
 end function

Here, one has for the internal length assignment:
  .__result = 3

The RHS is a simple 3, but the LHS is a pointer to an integer ...

 * * *

(In reply to comment #0)
 One gets the same ICE for the original example. Looking at the dump, there is
 no (re)allocation - but there should be one!

Pilot error of mine: As that code also lacks an ALLOCATE, it is also invalid
without an explicit ALLOCATE statement.

(The real-world program uses an array on the RHS. When the result_string has no
dimension(:), it compiled. For both, cf. email.)

[Bug translation/54067] arm-none-eabi with -mapcs and attribute((interrupt)) generates wrong stack alignment

[rearnsha at gcc dot gnu.org]

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

--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org 2012-07-23 
10:26:06 UTC ---
Hmm, I got myself confused with the undocumented option.  -mapcs has the same
behaviour as -mapcs-frame, which should work (generate code that will execute
correctly) even in this context; though back-tracing through an interrupt frame
is probably never going to work.

[Bug c/54071] New: out data in object file is correct only for -s0 optimize flag

[arkadiusz.krysiak.wroclaw at gmail dot com]

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

 Bug #: 54071
   Summary: out data in object file is correct only for -s0
optimize flag
Classification: Unclassified
   Product: gcc
   Version: 4.3.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arkadiusz.krysiak.wroc...@gmail.com


Created attachment 27857
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27857
object file with bad optymalisation

ut block command is made by part of source functions.
some functionss have no prolog and epilog.
out data in object file is correct only for -s0 optimize flag


I have in big source code for atmega644p functions:


//==
void console_process(console_st *base)
{
   do
   {
  base-temp=(uint16_t)cgetc((base-com_port) );
  base-char_in=(uint8_t)base-temp;
  if (EOF==(int)base-temp) 
  {
 base-char_in=0;
  }
  if (0x00!=base-char_in)
  {
  if (base-status.console_enable)
  {
 if (sizeof(console_lock_string)base-status.locker_match)
 {
if(pgm_read_byte
 ((console_lock_string[0])+base-status.locker_match)
  ==
  base-char_in
   )
{   /*char in is in accord to unlock string char from
base-locker_match position*/
   base-status.locker_match++;
   if ((sizeof(console_lock_string)-1)==base-status.locker_match)
   {
  base-status.console_enable=false;
  base-status.locker_match=0;
   }
}
else
{
   base-status.locker_match=0;
}
 }
if (0x00!=base-char_in)
{
   base-time_out_ticks=base-timeout; 
   if   (user_log_in_test(base)){console_embedded_cmd_run(base);}
  console_ansi_process(base);   
 if  (
(!(base-status.esc))

(C_ESC!=base-char_in)

(base-status.passwd!=true)
 )
  {
 console_process_to_lowercase(base);   
 console_auto_fill_cmd(base); 
 console_fn_key_select(base);
  }
}
base-status.hold_char=0;/*false*/
  }
  else
  {
 if   (sizeof(console_unlock_string)base-status.locker_match)
 {
if   (
  pgm_read_byte
  (
 (console_unlock_string[0])
 +
 base-status.locker_match
  )
  ==
  base-char_in
   ) 
{
   base-status.locker_match++;
   if   (
 (sizeof(console_unlock_string)-1)
 ==
 base-status.locker_match
  )
   {
  base-status.console_enable=true;
  base-status.locker_match=0; 
   }
}
else
{
   base-status.locker_match=0;
}
 }
  }
   }
   }while(  (EOF) != (int)(base-temp) );
}







void set_new_passwd(console_st *base)
{
//zapisz haslo
switch (base-priviledge)
{
case 0x80 :{base-temp=6; break;}
case 0x40 :{base-temp=5; break;}
case 0x20 :{base-temp=4; break;}
case 0x10 :{base-temp=3; break;}
case 0x08 :{base-temp=2; break;}
case 0x04 :{base-temp=1; break;}
case 0x02 :{base-temp=0; break;}
default :{base-temp=255; break;}
}
if (base-temp255)
{
pass_tab[base-temp].hash=base-temp_val;
}
if (base-temp255)
{
cfseek( /*ustaw w odpowiednim miejscu w pliku*/
EEFILE,
(uint8_t
*)(ee_pass_tab[0])+(base-temp*sizeof(user_st)),
0
);
cfputc(*((uint8_t *)(base-temp_val)+0),EEFILE);
cfputc(*((uint8_t *)(base-temp_val)+1),EEFILE);
cfputc(*((uint8_t *)(base-temp_val)+2),EEFILE);
cfputc(*((uint8_t *)(base-temp_val)+3),EEFILE);
}
}



void console_ansi_process(console_st *base)
{
if (
(C_ESC==base-char_in)

(true!=base-status.passwd)

(true!=base-status.passwd_ask)

(true!=base-status.log_in)
)
{
base-status.esc=true;

[Bug c++/54043] [C++11] cout nullptr does not work

[ayg at aryeh dot name]

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

--- Comment #11 from Aryeh Gregor ayg at aryeh dot name 2012-07-23 11:00:01 
UTC ---
(In reply to comment #3)
 You can submit an issue, see
 http://cplusplus.github.com/LWG/lwg-active.html#submit_issue

I sent an e-mail to Alisdair Meredith per the instructions on that page.

[Bug fortran/54072] New: BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

 Bug #: 54072
   Summary: BOZ with -std=f2008: wrongly accepted to
TRANSFER/ABS/...; two BOZ not rejected for
IOR/IEOR/IAND
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org


Motivated by the question at
http://www.rhinocerus.net/forum/lang-fortran/710304-why-does-boz-literal-work-ok-transfer-call-but-not-declarationwith-gfortran.html

Note that for INT(overflowing BOZ) the standard has: If A is a
boz-literal-constant, the value of the result is the value whose bit sequence
according to the model in 13.3 is the same as that of A as modified by padding
or truncation according to 13.3.3. The interpretation of a bit sequence whose
most significant bit is 1 is processor dependent. - Thus, printing an error
should be fine.

 * * *

Fortran 2008 only allows BOZ at:

C4102 (R463) A boz-literal-constant shall appear only as a data-stmt-constant
in a DATA statement, or where explicitly allowed in subclause 13.7 as an actual
argument of an intrinsic procedure.

If one looks for BOZ for TRANSFER, one finds nothing:

   SOURCE shall be a scalar or array of any type.

Thus, I think one has to conclude that it is not allowed. - But gfortran
silently accepts it.  Similarly for, e.g., ABS.

 * * *

The following is accepted
  print *, ior(z'111',z'010')

However, the standard requires:
  I and J shall not both be boz-literal-constants.
Similarly for iand and ieor. However, two BOZ to dshiftr are properly rejected.

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-23 
12:46:18 UTC ---
Misleading error message:

   Error: Extension: BOZ literal at (1) outside a DATA statement and outside
  INT/REAL/DBLE/CMPLX 

As comment 0 shows, there are now many more intrinsics where BOZ literals are
allowed. The message text should be updated.

[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[vbyakovl23 at gmail dot com]

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

--- Comment #10 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-07-23 
12:48:59 UTC ---
Created attachment 27858
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27858
Reduced test case

[Bug lto/53572] Some public symbols don't get to serialized LTO

[Christopher.Hite at partner dot commerzbank.com]

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

Christopher Hite Christopher.Hite at partner dot commerzbank.com changed:

   What|Removed |Added

 CC||Christopher.Hite at partner
   ||dot commerzbank.com

--- Comment #10 from Christopher Hite Christopher.Hite at partner dot 
commerzbank.com 2012-07-23 12:54:04 UTC ---
So this fix will be in gcc 4.7.2?

Could you check if it fixes #52900 too?

[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[vbyakovl23 at gmail dot com]

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

Vladimir Yakovlev vbyakovl23 at gmail dot com changed:

   What|Removed |Added

 CC||vbyakovl23 at gmail dot com

--- Comment #11 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-07-23 
12:53:13 UTC ---
Miscompare in 416 .games is caused by a wrong transformation of a loop in file
grd2b.f, lines 113-121.

  DO 110 M=1,3
P12(M,1)= C(M,IAT)
P12(M,2)= C(M,JAT)
P12(M,3)= P12(M,2)-P12(M,1)
  R12= R12+P12(M,3)*P12(M,3)
 P34(M,1)= C(M,KAT)
 P34(M,2)= C(M,LAT)
 P34(M,3)= P34(M,2)-P34(M,1)
  110 R34= R34+P34(M,3)*P34(M,3)

After transformation we have

  P12(:,1) = C(:,IAT)
  P12(:,2) = C(:,jAT)
  DO 110 M=1,3
P12(M,3)= P12(M,2)-P12(M,1)
  R12= R12+P12(M,3)*P12(M,3)
 P34(M,3)= P34(M,2)-P34(M,1)
  110 R34= R34+P34(M,3)*P34(M,3)
  P34(:,1) = C(:,KAT)
  P34(:,2) = C(:,LAT)

That is we changed order of operators in the loop. Right transformation should
be

  P12(:,1) = C(:,IAT)
  P12(:,2) = C(:,jAT)
  DO 110 M=1,3
P12(M,3)= P12(M,2)-P12(M,1)
  110   R12= R12+P12(M,3)*P12(M,3)
  P34(:,1) = C(:,KAT)
  P34(:,2) = C(:,LAT)
  DO 111 M=1,3
 P34(M,3)= P34(M,2)-P34(M,1)
  111 R34= R34+P34(M,3)*P34(M,3)

I attached a reduced test case and dumps with and without transformations.
Command line to compile is 

gfortran   m.f t.f -O3
The result of run is differed from a result of code compiled with -O0 opt
level.
I used compiler

Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --with-arch=corei7 --with-cpu=corei7
--enable-clocale=gnu --with-system-zlib --enable-shared --with-demangler-in-ld
--enable-cloog-backend=isl --with-fpmath=sse --enable-languages=c,c++,fortran
--enable-bootstrap=no
Thread model: posix
gcc version 4.8.0 20120606 (experimental) (GCC)

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-23 
13:17:33 UTC ---
Currently, gfortran prints the following error message if the BOZ exceeds (for
integers) the positive value:

Error: Arithmetic overflow converting INTEGER(8) to INTEGER(4) at (1). This
check can be disabled with the option -fno-range-check 


That perfectly matches the behaviour of Fortran 95, which had:

If a data-statement-constant is a boz-literal-constant, the corresponding
object shall be of type integer. A data-stmt-constant that is a
boz-literal-constant is treated as if the constant were an int-literalconstant
with a kind-param that specifies the representation method with the largest
decimal exponent range supported by the processor.


I am not sure that the message text is the best for Fortran 2008, which has for
DATA:

If a data-stmt-constant is a boz-literal-constant, the corresponding variable
shall be of type integer. The boz-literal-constant is treated as if it were
converted by the intrinsic function INT (13.7.81) to type integer with the kind
type parameter of the variable

And for INT see the text quoted in comment 0, i.e. it is is processor
dependent.

[Bug middle-end/53616] [4.8 Regression] 416.gamess in SPEC CPU 2006 miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Guenther rguenth at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2012-07-23 
13:29:22 UTC ---
Thanks for the detective work!  Mine.

[Bug fortran/54072] BOZ with -std=f2008: wrongly accepted to TRANSFER/ABS/...; two BOZ not rejected for IOR/IEOR/IAND

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2012-07-23 
13:44:47 UTC ---
(In reply to comment #1)
 Misleading error message:
Error: Extension: BOZ literal at (1) outside a DATA statement and outside
   INT/REAL/DBLE/CMPLX 
 As comment 0 shows, there are now many more intrinsics where BOZ literals are
 allowed. The message text should be updated.

http://gcc.gnu.org/onlinedocs/gfortran/BOZ-literal-constants.html has a similar
issue: It also only lists the 4 Fortran 2003 intrinsics; one should mention
that some additional Fortran 2008 intrinsics also accept BOZ.

[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot
   ||com

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-23 
13:46:43 UTC ---
Dodji, just in case isn't clear already, this is the PR about
-ftrack-macro-expansion + PCHs which I mentioned in Prague...

[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code

[oeste.sebastian at googlemail dot com]

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

--- Comment #1 from sebastian oeste.sebastian at googlemail dot com 
2012-07-23 14:47:00 UTC ---
Created attachment 27859
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27859
preprocessed minimal reproduction of the bug

[Bug middle-end/52544] compilation fails with -finstrument-functions and sse c code

[oeste.sebastian at googlemail dot com]

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

sebastian oeste.sebastian at googlemail dot com changed:

   What|Removed |Added

 CC||oeste.sebastian at
   ||googlemail dot com

--- Comment #2 from sebastian oeste.sebastian at googlemail dot com 
2012-07-23 14:49:46 UTC ---
I've make a similar observation, with the function __mm_xor_si128 from
emmintrin.h and the flag -finstrument-functions. 

gcc Version 4.7.0 (same results with 4.7.1)

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/oeste/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/oeste/gcc/
Thread model: posix
gcc version 4.7.0 (GCC) 


$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -save-temps
-finstrument-functions ./test.c 
test.o: In function `main':
test.c:(.text+0x50): undefined reference to `_mm_xor_si128'
test.c:(.text+0x61): undefined reference to `_mm_xor_si128'
collect2: error: ld returned 1 exit status

When compile without -finstrument-functions all will be done.

[Bug tree-optimization/54073] New: SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

[t.artem at mailcity dot com]

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

 Bug #: 54073
   Summary: SciMark Monte Carlo test performance has seriously
decreased in recent GCC releases
Classification: Unclassified
   Product: gcc
   Version: 4.7.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t.ar...@mailcity.com


Created attachment 27860
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27860
Sci Mark Monte Carlo test

On an Intel Core i7 CPU (see the attached screenshot):

GCC 4.2.x - 380
GCC 4.7.x - 265

i.e. 44% slower.

SciMark 2.0 sources can be fetched here:
http://math.nist.gov/scimark2/download_c.html

[Bug tree-optimization/54073] SciMark Monte Carlo test performance has seriously decreased in recent GCC releases

[t.artem at mailcity dot com]

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

--- Comment #1 from Artem S. Tashkinov t.artem at mailcity dot com 2012-07-23 
15:43:50 UTC ---
The results are obtained from here:

http://openbenchmarking.org/result/1207077-SU-GCCPERFOR59

Benchmarking of GCC 4.2 through GCC 4.8 when building the compiler the same and
setting CFLAGS/CXXFLAGS of -O3 and -march=native prior to test installation and
execution. Benchmarking for a future article on Phoronix.com by Michael
Larabel. Testing on an Intel Core i7 and AMD Opteron 2384 when using the 64-bit
(x86_64 target) build of Ubuntu Linux.

The CPU is:

Nehalem microarchitecture, Clarksfield (45 nm), Intel® Core™ i7-720QM
Processor (6M Cache, 1.60 GHz)

http://ark.intel.com/products/43122/Intel-Core-i7-720QM-Processor-%286M-Cache-1_60-GHz%29

[Bug target/53961] internal compiler error: in memory_address_length, at config/i386/i386.c:23341

[uros at gcc dot gnu.org]

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

--- Comment #18 from uros at gcc dot gnu.org 2012-07-23 16:04:30 UTC ---
Author: uros
Date: Mon Jul 23 16:04:23 2012
New Revision: 189787

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189787
Log:
PR target/53961
* config/i386/i386.md (*lea): Add asserts to detect invalid addresses.
* config/i386/i386.c (ix86_print_operand_address): Ditto.
(ix86_decompose_address): Allow (zero_extend:DI (subreg:SI (...)))
addresses.  Prevent zero extensions of CONST_INT operands.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md

[Bug bootstrap/53238] Bootstrap failure: error: 'pthread_mutex_timedlock' was not declared in this scope

[skunk at iskunk dot org]

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

--- Comment #21 from Daniel Richard G. skunk at iskunk dot org 2012-07-23 
18:52:06 UTC ---
(In reply to comment #20)
 You could try adding this to ctype.cc around line 54

--- libstdc++-v3/src/c++98/ctype.cc.orig2012-01-23 18:12:01.2 -0500
+++ libstdc++-v3/src/c++98/ctype.cc2012-07-23 13:31:55.2 -0400
@@ -52,6 +52,8 @@

   const size_t ctypechar::table_size;

+  inline template class ctypechar;// added by skunk
+
   ctypechar::~ctype()
   { 
 _S_destroy_c_locale(_M_c_locale_ctype);


I rebuilt ctype.o and the libraries it goes into. Unfortunately, I still get
the link error. If I compare the output of nm -A on the old and new ctype.o
objects, I don't see a difference in the defined symbols.

The mangled form of vtable for std::ctypechar is _ZTVSt5ctypeIcE. If I
grep for that in nm -A ctype.o, I see

ctype.o:17c0 d _ZTVSt5ctypeIcE.P8

but no instances without the .P8 suffix. Looking through all the objects of
libstdc++, grep only turns up these:

ctype_configure_char.o: U _ZTVSt5ctypeIcE
ctype_configure_char.o:08a4 d _ZTVSt5ctypeIcE.P8

For comparison, I grepped for _ZTVNSt6locale5facetE, the mangled form of
vtable for std::locale::facet, and got the below:

time_members.o: U _ZTVNSt6locale5facetE
time_members.o:1778 d _ZTVNSt6locale5facetE.P8
codecvt.o: U _ZTVNSt6locale5facetE
codecvt.o:15d0 d _ZTVNSt6locale5facetE.P8
locale-inst.o: U _ZTVNSt6locale5facetE
locale-inst.o:00023974 d _ZTVNSt6locale5facetE.P8
wlocale-inst.o: U _ZTVNSt6locale5facetE
wlocale-inst.o:00023c2c d _ZTVNSt6locale5facetE.P8
numeric_members.o: U _ZTVNSt6locale5facetE
numeric_members.o:0e64 d _ZTVNSt6locale5facetE.P8
ctype.o: U _ZTVNSt6locale5facetE
ctype.o:17bc d _ZTVNSt6locale5facetE.P8
monetary_members.o: U _ZTVNSt6locale5facetE
monetary_members.o:1b80 d _ZTVNSt6locale5facetE.P8
locale_init.o: U _ZTVNSt6locale5facetE
locale_init.o:4a50 d _ZTVNSt6locale5facetE.P8
ctype_configure_char.o: U _ZTVNSt6locale5facetE
ctype_configure_char.o:08a0 d _ZTVNSt6locale5facetE.P8
locale.o:2b08 d _ZTVNSt6locale5facetE
locale.o:2b08 D _ZTVNSt6locale5facetE
locale.o:2b3c d _ZTVNSt6locale5facetE.P8


The fact of the symbol being a vtable for a template class appears to be
relevant. Maybe a different kind of explicit instantiation is needed?

[Bug web/51195] upgrade request for viewvc to version 1.1.13

[gseanmcg at gmail dot com]

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

Sean McGovern gseanmcg at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #3 from Sean McGovern gseanmcg at gmail dot com 2012-07-23 
19:16:26 UTC ---
seems to work OK now.

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler daniel.kruegler at googlemail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |

--- Comment #8 from Daniel Krügler daniel.kruegler at googlemail dot com 
2012-07-23 21:01:09 UTC ---
I agree that the actual test examples work now, but I also found that only
*slight* variations of the call context of the test expression
sizeof(fC(0)) again lead to access errors. The following variants
demonstrate this:

//---
class C {
  typedef int type; // Line 2
};

templateclass T, class = typename T::type
auto f(int) - char;

templateclass
auto f(...) - char ()[2];

static_assert(sizeof(fC(0)) == 2, ); // OK

typedef int test[sizeof(fC(0)) == 2 ? 1 : -1]; // Error

templateint
struct I {};

Isizeof(fC(0)) i; // Error

enum E { e1 = sizeof(fC(0)) }; // Error
//---

13|error: size of array 'test' is negative|
2|error: 'typedef int C::type' is private|
5|error: within this context|
2|error: 'typedef int C::type' is private|
18|error: within this context|
2|error: 'typedef int C::type' is private|
5|error: within this context|


Jason suggested to reopen the issue, so I did.

[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost

[steven at gcc dot gnu.org]

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

Steven Bosscher steven at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-07-23
 CC||steven at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #5 from Steven Bosscher steven at gcc dot gnu.org 2012-07-23 
21:28:56 UTC ---
What are the callers of gt_pch_p_9line_maps?

[Bug c++/54074] New: [C++0x] initializer list accepts incorrect nested input

[ebeworld at gmail dot com]

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

 Bug #: 54074
   Summary: [C++0x] initializer list accepts incorrect nested
input
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ebewo...@gmail.com


#includecstring
#includestring
using namespace std;

struct S1 {
int i;
string str;
};

//nested
struct S2 {
int i;
string str;
S1 s1;
};

int main() {
//should be S2 s22{ 3, Hello3, {4,Hello4} }; 
//but it compiles
S2 s22{ 3, Hello3, 4,Hello4 };  
FINISH_TEST();
}

[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost

[steven at gcc dot gnu.org]

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

--- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-07-23 
22:46:19 UTC ---
FWIW this shows up in GCC's own libstdc++ PCHs also.

[Bug target/53511] SH Target: Add support for fma patterns

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-23 
22:54:13 UTC ---
Author: olegendo
Date: Mon Jul 23 22:54:06 2012
New Revision: 189796

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189796
Log:
PR target/53511
* config/sh/sh.md (mulsf3_ie): Delete.
(mulsf3_i4): Rename to mulsf3_i.
(mulsf3): Emit mulsf3_i insn.


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

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

--- Comment #42 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-23 
22:57:42 UTC ---
Author: olegendo
Date: Mon Jul 23 22:57:36 2012
New Revision: 189797

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189797
Log:
PR target/51244
* config/sh/predicates.md (general_movsrc_operand,
general_movdst_operand): Reject T_REG.
* config/sh/sh.md (*extendqisi2_compact_reg, *extendhisi2_compact_reg,
movsi_i, movsi_ie, movsi_i_lowpart, *movqi_reg_reg, *movhi_reg_reg):
Remove T_REG alternatives.
(*negtstsi): New insn.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/predicates.md
trunk/gcc/config/sh/sh.md

[Bug target/53511] SH Target: Add support for fma patterns

[olegendo at gcc dot gnu.org]

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

Oleg Endo olegendo at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #15 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-23 
23:00:36 UTC ---
Should be OK now.

[Bug libstdc++/54075] New: [4.7.1] unordered_map 3x slower than 4.6.2

[likan_999.student at sina dot com]

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

 Bug #: 54075
   Summary: [4.7.1] unordered_map 3x slower than 4.6.2
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: likan_999.stud...@sina.com


The following piece of code shows 3x performance regression from 4.6.2 to
4.7.1.  The reason should come from the change in libstdc++.  The code is
compiled with -O2 -std=c++0x. -O3 doesn't make much difference; with or without
the call to reserve doesn't make much difference.  The attachment contains
profiling using google-perftool.  Looks like the major cost comes from the
rehashing.  Does anyone aware of the issue, or I am the first one to report
this?


#include unordered_map

using namespace std;

int main() {
const int N = 1000;
unordered_mapint, int m;
m.reserve(2 * N);
for (int i = 0; i  N; i++) {
m[i] = i;
}
}


Timing:
[hidden]$ time ./a-4.6.2.out 

real0m1.029s
user0m0.787s
sys0m0.239s
[hidden]$ time ./a-4.7.1.out 

real0m3.364s
user0m2.596s
sys0m0.761s

[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2

[likan_999.student at sina dot com]

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

--- Comment #1 from likan_999.student at sina dot com 2012-07-23 23:08:07 UTC 
---
Created attachment 27861
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27861
Profiling using google-perftools

[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2

[likan_999.student at sina dot com]

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

--- Comment #2 from likan_999.student at sina dot com 2012-07-23 23:09:43 UTC 
---
Created attachment 27862
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27862
Profiling of gcc-4.6.2 using google-perftools

[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2

[paolo.carlini at oracle dot com]

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

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-07-23
 CC||fdumont at gcc dot gnu.org
 Ever Confirmed|0   |1
   Severity|critical|normal

--- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-23 
23:12:15 UTC ---
Francois, can you have a look? Thanks!

[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-23 
23:23:27 UTC ---
I wonder, anyway, if the apparent slow down is just an artifact caused by a
different handling of the load factor in the reworked unordered containers
which we have been delivering since 4.7.0. I would suggest submitter to
experiment a bit with max_load_factor, and see if when 4.6.x seems faster at
insertion time actually the load factor is higher (too searching would be
slower).

[Bug target/51244] SH Target: Inefficient conditional branch

[olegendo at gcc dot gnu.org]

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

--- Comment #43 from Oleg Endo olegendo at gcc dot gnu.org 2012-07-23 
23:29:02 UTC ---
I have noticed that on SH the CANONICALIZE_COMPARISON macro is not defined,
although it seems to be useful for the combine pass.

Another thing that I'd like to try out is using zero-displacement branches to
implement conditional execution patterns and see how it performs.

[Bug c++/51213] [C++11][DR 1170] Access control checking has to be done under SFINAE conditions

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-23 
23:35:42 UTC ---
Weird indeed, thanks Daniel. Tomorrow I will have a look and either will send a
patch or will post an analysis (if I will get stuck).

[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2

[likan_999.student at sina dot com]

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

--- Comment #5 from likan_999.student at sina dot com 2012-07-24 00:17:10 UTC 
---
@Paolo Carlini: can you talk more about how to experiment with max_load_factor?
 As long as I use the same max_load_factor for 4.6 and 4.7, I can still see the
performance difference (3x slower is the best result):

max_load_factor  gcc-4.6.2 gcc-4.7.1
0.2  1.600s  7.650s
0.5  1.125s  4.251s
1.0  1.004s  3.378s
2.0  0.914s  20.471s
5.0  0.917s  29.132s

[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com 2012-07-24 
00:29:38 UTC ---
In some cases 4.6.x was handling max_load_factor incorrectly. Thus, the idea
isn't comparing 4.6.x to 4.7.x with the same max_load_factor (I don't think
it's useful), instead, actually measure load_factor(s), see if for some values
of max_load_factor, the actual load_factor(s) are different in 4.6.x vs 4.7.x.
In any case, measure the actual load_factor while the map grows.

[Bug libstdc++/54075] [4.7.1] unordered_map 3x slower than 4.6.2

[likan_999.student at sina dot com]

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

--- Comment #7 from likan_999.student at sina dot com 2012-07-24 00:42:57 UTC 
---
@Paolo Carlini: the problem is, with different max_load_factor in range
[0.2-5], the *best* result of 4.7.1 is still 2x slower than the *worst* of
4.6.2.  

I printed out the average load factor during the insertion.  Looks like 4.7.1's
load factor is very close to the max_load_factor, and the average for 4.6.2 is
about 1/4 of the max_load_factor.  But what conclusion can we get from this
result?

[Bug target/53914] poor code generated for offset addressing on ppc32

[amodra at gcc dot gnu.org]

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

--- Comment #2 from Alan Modra amodra at gcc dot gnu.org 2012-07-24 05:55:56 
UTC ---
Author: amodra
Date: Tue Jul 24 05:55:50 2012
New Revision: 189801

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189801
Log:
PR target/53914
PR target/54009
* config/rs6000/constraints.md (Y): Use mem_operand_gpr.
* config/rs6000/predicates.md (word_offset_memref_operand): Delete.
Adjust all rs6000_legitimate_offset_address_p calls.
* config/rs6000/rs6000-protos.h (mem_operand_gpr): Declare.
(rs6000_secondary_reload_gpr): Declare.
(rs6000_legitimate_offset_address_p): Update prototype.
(rs6000_offsettable_memref_p): Delete.
(rs6000_secondary_reload_ppc64): Delete.
* config/rs6000/rs6000.c (address_offset): New function.
(mem_operand_gpr): Likewise.
(rs6000_legitimate_offset_address_p): Add worst_case param.  When
not worst_case assume class of regs with least restrictive offsets.
Adjust all calls.
(legitimate_lo_sum_address_p): Simplify register mode tests.
(rs6000_legitimize_address): Likewise.  Assume best case offset
addressing.  Combine ELF and MACHO lo_sum code.
(rs6000_mode_dependent_address): Correct offset addressing limits.
(rs6000_offsettable_memref_p): Make static, add reg_mode param.
Use reg_mode to help rs6000_legitimate_offset_address_p.
(rs6000_secondary_reload): Use address_offset.  Handle 32-bit multi
gpr load/store when offset too large.
(rs6000_secondary_reload_gpr): Renamed rs6000_secondary_reload_ppc64.
(rs6000_split_multireg_move): Adjust rs6000_offsettable_memref_p calls.
* config/rs6000/rs6000.md (movdf_hardfloat32): Use 'Y' constraint
for gpr load/store.  Order alternatives as r-Y,Y-r,r-r and
d-m,m-d,d-d.  Correct size of gpr load/store.
(movdf_softfloat32): Use 'Y' constraint for gpr load/store.  Order
alternatives.
(movti_ppc64): Likewise.
(movdi_internal32): Likewise.  Also disparage fprs.
(movdi_mfpgpr, movdi_internal64): Likewise.
(movtf_internal): Use 'm' for fpr load/store.  Order alternatives.
(movtf_softfloat): Order alternatives.
(extenddftf2_internal): Use 'm' and 'Y' for store.
(movti_power, movti_string): Use 'Y' for gpr load/store.  Order.
(stack_protect_setdi, stack_protect_testdi): Likewise.
(movdf_hardfloat64_mfpgpr, movdf_hardfloat64): Order alternatives.
(movdf_softfloat64): Likewise.
(reload_mode_store): Adjust reload_di_store to provide
reload_si_store as well.
(reload_mode_load): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/constraints.md
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md

[Bug target/54009] incorrect code generated for DFmode lo_sum mem

[amodra at gcc dot gnu.org]

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

--- Comment #1 from Alan Modra amodra at gcc dot gnu.org 2012-07-24 05:55:56 
UTC ---
Author: amodra
Date: Tue Jul 24 05:55:50 2012
New Revision: 189801

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=189801
Log:
PR target/53914
PR target/54009
* config/rs6000/constraints.md (Y): Use mem_operand_gpr.
* config/rs6000/predicates.md (word_offset_memref_operand): Delete.
Adjust all rs6000_legitimate_offset_address_p calls.
* config/rs6000/rs6000-protos.h (mem_operand_gpr): Declare.
(rs6000_secondary_reload_gpr): Declare.
(rs6000_legitimate_offset_address_p): Update prototype.
(rs6000_offsettable_memref_p): Delete.
(rs6000_secondary_reload_ppc64): Delete.
* config/rs6000/rs6000.c (address_offset): New function.
(mem_operand_gpr): Likewise.
(rs6000_legitimate_offset_address_p): Add worst_case param.  When
not worst_case assume class of regs with least restrictive offsets.
Adjust all calls.
(legitimate_lo_sum_address_p): Simplify register mode tests.
(rs6000_legitimize_address): Likewise.  Assume best case offset
addressing.  Combine ELF and MACHO lo_sum code.
(rs6000_mode_dependent_address): Correct offset addressing limits.
(rs6000_offsettable_memref_p): Make static, add reg_mode param.
Use reg_mode to help rs6000_legitimate_offset_address_p.
(rs6000_secondary_reload): Use address_offset.  Handle 32-bit multi
gpr load/store when offset too large.
(rs6000_secondary_reload_gpr): Renamed rs6000_secondary_reload_ppc64.
(rs6000_split_multireg_move): Adjust rs6000_offsettable_memref_p calls.
* config/rs6000/rs6000.md (movdf_hardfloat32): Use 'Y' constraint
for gpr load/store.  Order alternatives as r-Y,Y-r,r-r and
d-m,m-d,d-d.  Correct size of gpr load/store.
(movdf_softfloat32): Use 'Y' constraint for gpr load/store.  Order
alternatives.
(movti_ppc64): Likewise.
(movdi_internal32): Likewise.  Also disparage fprs.
(movdi_mfpgpr, movdi_internal64): Likewise.
(movtf_internal): Use 'm' for fpr load/store.  Order alternatives.
(movtf_softfloat): Order alternatives.
(extenddftf2_internal): Use 'm' and 'Y' for store.
(movti_power, movti_string): Use 'Y' for gpr load/store.  Order.
(stack_protect_setdi, stack_protect_testdi): Likewise.
(movdf_hardfloat64_mfpgpr, movdf_hardfloat64): Order alternatives.
(movdf_softfloat64): Likewise.
(reload_mode_store): Adjust reload_di_store to provide
reload_si_store as well.
(reload_mode_load): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/constraints.md
trunk/gcc/config/rs6000/predicates.md
trunk/gcc/config/rs6000/rs6000-protos.h
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/rs6000.md