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

2012-03-09 Thread kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244

--- Comment #29 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-09 
08:40:32 UTC ---
(In reply to comment #28)
Regtest on sh4-unknown-lunix-gnu has been done successfully.
Oleg, your patch is pre-approved.


[Bug libfortran/52537] New: slow trim function

2012-03-09 Thread talebi.hossein at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

 Bug #: 52537
   Summary: slow trim function
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: talebi.hoss...@gmail.com


Hello,

The trim function in Gfortran seems to be a a lot slower than the intel
compiler. Sometimes I have to read some input text files which can very
large(1.5GB); Comparing the intel and gfortran, the gfortran takes 150 seconds
where intel spends only 50 seconds. I checked, and there seems to a large time
spend on the trim function. 

I am not sure if intel does some other optimization but I never got such huge
performance difference between gfortran and ifort.

Thank you.


[Bug c++/52538] New: Extend C++11 UDLs to be compatible with inttypes.h macros

2012-03-09 Thread jyasskin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538

 Bug #: 52538
   Summary: Extend C++11 UDLs to be compatible with inttypes.h
macros
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org


C++11 defines user-defined literals in a way that breaks compatibility with
some code that uses the formatting macros from inttypes.h:

$ cat test.cc
#define __STDC_FORMAT_MACROS
#include inttypes.h
#include stdio.h

int main() {
  int64_t i64 = 123;
  printf(My int64: %PRId64\n, i64);
}
$ install_gcc46/bin/g++ -Wall test.cc -o test  ./test
My int64: 123
$ install_gcc46/bin/g++ -std=c++0x -Wall test.cc -o test  ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall test.cc -o test  ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -Wall -Wc++11-compat test.cc -o test  ./test
My int64: 123
$ install_gcc47/bin/g++-4.7pre -std=c++0x -Wall test.cc -o test  ./test
test.cc: In function ‘int main()’:
test.cc:7:29: error: unable to find string literal operator ‘operator PRId64’


Clang is working around this by interpreting literal suffixes that don't start
with underscores as separate tokens, which allows them to expand as macros:
http://llvm.org/viewvc/llvm-project?view=revrevision=152287

According to [lex.ext]p10 and [usrlit.suffix], these suffixes are ill-formed,
no diagnostic required, so allowing them to expand as macros is a conforming
extension.

It would also be possible to fix the code by inserting a space between the 
and the macro name, but in Google's codebase, this cleanup would be 3-4x as
large as the narrowing conversion cleanup, which you have already made
optional.


[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros

2012-03-09 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538

--- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-09 
09:07:10 UTC ---
If you want to use C++11, then you have to write C++11 code.  That is the way
forward I think we have discussed this before.


[Bug libfortran/52537] slow trim function

2012-03-09 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52537

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||burnus at gcc dot gnu.org,
   ||jb at gcc dot gnu.org

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-09 
09:14:00 UTC ---
Some related bugs: PR 47065, PR 50673, PR 38199.


[Bug tree-optimization/51988] value_replacement in PHIOPT should handle even the cases where there are other PHIs even with non equal value

2012-03-09 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51988

--- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org 2012-03-09 
09:27:35 UTC ---
Author: pinskia
Date: Fri Mar  9 09:27:29 2012
New Revision: 185131

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185131
Log:
2012-03-09  Andrew Pinski  apin...@cavium.com

PR middle-end/51988
* tree-ssa-phiopt.c: Include tree-pretty-print.h for
print_generic_expr.
(tree_ssa_phiopt_worker): Go through all the PHIs for
value_replacement instead of just the singleton one.
(value_replacement): Change return type to int.  Return 0 instead of
false.
Allow the middle basic block to contain more than just the definings
tatement. 
Handle non empty middle basic blocks.
* Makefile.in (tree-ssa-phiopt.o): Add tree-pretty-print.h.

2012-03-09  Andrew Pinski  apin...@cavium.com

PR middle-end/51988
* gcc.dg/tree-ssa/phi-opt-8.c: New testcase.
* gcc.dg/tree-ssa/phi-opt-9.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/Makefile.in
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-phiopt.c


[Bug c++/52538] Extend C++11 UDLs to be compatible with inttypes.h macros

2012-03-09 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52538

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-09 
09:51:34 UTC ---
(In reply to comment #1)
 If you want to use C++11, then you have to write C++11 code.  That is the way
 forward I think we have discussed this before.

Yes, in PR 52485, and see also PR 51282 and PR 50917 - this is affecting a lot
of large codebases. The committee are discussing whether this is a defect worth
addressing in the standard, as the scope of the problems is larger than
previously realised.

(In reply to comment #0)
 It would also be possible to fix the code by inserting a space between the 
 and the macro name, but in Google's codebase, this cleanup would be 3-4x as
 large as the narrowing conversion cleanup, which you have already made
 optional.

Ack. When UDL support was added to G++ I also found more problems due to
PRId64 than I had found when narrowing errors where added (in a much smaller
codebase, obviously.)


[Bug c++/52536] internal compiler error: Illegal instruction

2012-03-09 Thread redi at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52536

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-03-09
 Ever Confirmed|0   |1

--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-03-09 
10:02:14 UTC ---
(In reply to comment #0)
 See URL:http://gcc.gnu.org/bugs.html for instructions.

But 4.2 is no longer supported anyway


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

2012-03-09 Thread olegendo at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244

--- Comment #30 from Oleg Endo olegendo at gcc dot gnu.org 2012-03-09 
10:02:25 UTC ---
(In reply to comment #29)
 (In reply to comment #28)
 Regtest on sh4-unknown-lunix-gnu has been done successfully.
 Oleg, your patch is pre-approved.

Thanks a lot!
Could you please attach the testsuite summary of your setup?  I'd like to
compare them to my results (in particular the libstdc++ tests).
I'm now getting similar effects as in #comment 9 again, where a bunch of
libstdc++ failures disappear and this time one new failure appears:
FAIL: 21_strings/basic_string/cons/char/6.cc execution test

This is weird...


[Bug libfortran/52539] New: I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write

2012-03-09 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539

 Bug #: 52539
   Summary: I/O: Wrong result for UTF-8/UCS-4 list-directed and
namelist read and nml write
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libfortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org


Example using UTF-8 string with UCS-4 character variables; the string contains
(a)(ni)(hao)(b) (a你好).

The following program prints here the following. One sees that list-directed
writing correctly works but namelist writing doesn't. (Also the fort.99
contains the correct string.)

For reading, neither list-directed reading nor namelist reading works.


Looking at list_read.c, UTF-8 seems to be unhandled. (And in nml_get_obj_data,
the array_loop_spec ind initialization won't survive the array descriptor
reform unmodified.)


a你好!  OK
 a你好   !  OK
NML
 STR=a,  !  WRONG
 /
�XX  !  WRONG
 �XX !  WRONG
NML
 STR=a��,!  WRONG
 /
 aä½ !  WRONG
aä½  !  WRONG




character(len=3, kind=4) :: str, str2
namelist /nml/ str

str = 4_'a'//char (int (z'4F60'),4) 
  //char (int (z'597D'), 4)//4_'b'

open(6, encoding='utf-8')
write(*, '(a)') 4_''//str//4_''
write(*, *) 4_''//str//4_''
write(*,nml=nml)

open(99, encoding='utf-8',form='formatted')
write(99, '(3a)') 'nml str = ', str, ' /'
write(99, '(a)') str
rewind(99)

str = 4_''
str2 = 4_''
read(99,nml=nml)
read(99, *) str2
close(99, status='delete')

write(*, '(a)') 4_''//str//4_''
write(*, *) 4_''//str//4_''
write(*,nml=nml)
write(*, *) 4_''//str2//4_''
write(*, '(a)') 4_''//str2//4_''
end


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

2012-03-09 Thread kkojima at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51244

--- Comment #31 from Kazumoto Kojima kkojima at gcc dot gnu.org 2012-03-09 
10:36:31 UTC ---
Created attachment 26859
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26859
A test result

testresult on sh4-unknown-linux-gnu [trunk revision 185088].


[Bug libstdc++/52540] New: std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG

2012-03-09 Thread pluto at agmk dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540

 Bug #: 52540
   Summary: std::use_facet throws bad_cast when compiled with
_GLIBCXX_DEBUG
Classification: Unclassified
   Product: gcc
   Version: 4.6.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pl...@agmk.net
Target: x86_64-w64-mingw32


#include iostream
#include locale
#include cstring
#include ctime

int main()
{
std::tm tm;
std::time_t tt;
std::time( tt );
tm = *std::localtime( tt );
std::locale lc( C );
std::cout.imbue( lc );
std::time_put char  const timeFacet = std::use_facet std::time_put
char  ( std::cout.getloc() );
char const pattern[] = %x %X;
timeFacet.put( std::cout, std::cout, std::cout.fill(), tm, pattern,
pattern + std::strlen( pattern ) );
}

$ x86_64-w64-mingw32-g++ main.cpp -o main-release.exe -g2
$ x86_64-w64-mingw32-g++ main.cpp -o main-debug.exe -g2 -D_GLIBCXX_DEBUG

release-run:

Starting program: main-release.exe
[New Thread 2776.0xdbc]

Breakpoint 1, main () at main.cpp:7
7   {
(gdb) n
10  std::time( tt );
(gdb)
11  tm = *std::localtime( tt );
(gdb)
12  std::locale lc( C );
(gdb)
13  std::cout.imbue( lc );
(gdb) p lc
$2 = {static none = 0, static ctype = 1, static numeric = 2, static collate =
4, static time = 8, static monetary = 16,
  static messages = 32, static all = 63, _M_impl = 0x626e9460, static
_S_classic = 0x626e9460, static _S_global = 0x626e9460,
  static _S_categories = 0x626eadc0, static _S_once = {done = 1, started = 0}}
(gdb) c
Continuing.
03/09/12 11:53:50
Program exited normally.


debug-run:

Starting program: main-debug.exe
[New Thread 2704.0xd4c]

Breakpoint 1, main () at main.cpp:7
7   {
(gdb) l
2   #include locale
3   #include cstring
4   #include ctime
5
6   int main()
7   {
8   std::tm tm;
9   std::time_t tt;
10  std::time( tt );
11  tm = *std::localtime( tt );
(gdb) n
10  std::time( tt );
(gdb)
11  tm = *std::localtime( tt );
(gdb)
12  std::locale lc( C );
(gdb)
13  std::cout.imbue( lc );
(gdb) p lc
$1 = {static none = 0, static ctype = 1, static numeric = 2, static collate =
4, static time = 8, static monetary = 16,
  static messages = 32, static all = 63, _M_impl = 0x626e9460, static
_S_classic = 0x626e9460, static _S_global = 0x626e9460,
  static _S_categories = 0x626eadc0, static _S_once = {done = 1, started = 0}}
(gdb) n
14  std::time_put char  const timeFacet = std::use_facet
std::time_put char  ( std::cout.getloc() );
(gdb)
terminate called after throwing an instance of 'std::bad_cast'
  what():  std::bad_cast


[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG

2012-03-09 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||dave.korn.cygwin at gmail
   ||dot com, ktietz at gcc dot
   ||gnu.org

--- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-09 
11:02:37 UTC ---
Doesn't happen on Linux, a mingw maintainer is needed.


[Bug c++/52541] New: g++ allows definition of const POD

2012-03-09 Thread konrad_rudolph at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541

 Bug #: 52541
   Summary: g++ allows definition of const POD
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konrad_rudo...@hotmail.com


g++ 4.6.2 compiles the attached code without error. However, it *should* yield
an error similar to uninitialized const ‘a’ (according to §8.5 of the
standard). In particular, prior versions of GCC treat this as an error,
suggesting a regression. It's also worth noting that the compiler does issue an
error once the class `c` contains member variables.

System: OS X 10.7.3

Configured with: ../configure --prefix=MASKED
--with-gmp=/usr/local/Cellar/gmp/5.0.2/lib/
--with-mpfr=/usr/local/Cellar/mpfr/3.1.0/lib
--with-mpc=/usr/local/Cellar/libmpc/0.9/lib --program-suffix=4.6.2
--enable-languages=c,c++,fortran

Command line: g++-4.6.2 -pedantic main.cpp

Compiler output: none

More information: http://stackoverflow.com/q/9632229/1968, in particular the
discussion in the comments.


[Bug c++/52541] g++ allows definition of const POD

2012-03-09 Thread konrad_rudolph at hotmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541

--- Comment #1 from Konrad Rudolph konrad_rudolph at hotmail dot com 
2012-03-09 11:09:23 UTC ---
Created attachment 26860
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26860
MWE


[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG

2012-03-09 Thread ktietz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540

--- Comment #2 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-09 11:19:34 
UTC ---
Hmm, I tested this testcase on my cygwin-cross-compiler for x64 and
I didn't noticed this failure.

I get for it by shown samples always proper output (eg '03/09/12 12:18:20').
So it might be related to something else in your crt/header-set?

I can't confirm it.


[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG

2012-03-09 Thread ktietz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540

Kai Tietz ktietz at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-09
 Ever Confirmed|0   |1

--- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-09 11:21:23 
UTC ---
Ah, with -g2 -D_GLIBCXX_DEBUG I can confirm it.


[Bug c++/52541] g++ allows definition of const POD

2012-03-09 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52541

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-09 
11:29:04 UTC ---
This behavior changed on purpose, see testcase: g++.dg/init/const8.C.

2011-09-23  Jason Merrill  ja...@redhat.com

Core 253 - allow const objects with no initializer or
user-provided default constructor if the defaulted constructor
initializes all the subobjects.
PR c++/20039
PR c++/42844
* class.c (default_init_uninitialized_part): New.
* cp-tree.h: Declare it.
* decl.c (check_for_uninitialized_const_var): Use it.
* init.c (perform_member_init): Likewise.
(build_new_1): Likewise.
* method.c (walk_field_subobs): Likewise.


[Bug tree-optimization/52533] [4.8 Regression] ice in remove_range_assertions

2012-03-09 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52533

--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-09 
11:44:27 UTC ---
Created attachment 26861
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26861
gcc47-pr52533.patch

Untested fix.


[Bug fortran/52542] New: Procedure with a Bind (C) named interface does not inherit the Bind (C)

2012-03-09 Thread mathewc at nag dot co.uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52542

 Bug #: 52542
   Summary: Procedure with a Bind (C) named interface does not
inherit the Bind (C)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: math...@nag.co.uk


$ uname -a
Linux stonehenge 3.2.9-1.fc16.x86_64 #1 SMP Thu Mar 1 01:41:10 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux

$ gfortran --version
GNU Fortran (GCC) 4.8.0 20120309 (experimental) [trunk revision 185121]

$ cat bind.f90
interface
  subroutine s() bind(c)
  end subroutine s
end interface
procedure(s) :: t
call t
end

$ gfortran -c bind.f90 ; nm bind.o
 t MAIN__
 U _gfortran_set_args
 U _gfortran_set_options
000b T main
 r options.0.1852
 U t_

Note: that should be 't', not 't_'.


[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG

2012-03-09 Thread ktietz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540

--- Comment #4 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-09 12:00:00 
UTC ---
Issue happens in
include/bits/locale_classes.tcc:

  templatetypename _Facet
const _Facet
use_facet(const locale __loc)
{
  const size_t __i = _Facet::id._M_id();
  const locale::facet** __facets = __loc._M_impl-_M_facets;
134if (__i = __loc._M_impl-_M_facets_size || !__facets[__i])
135 __throw_bad_cast();
   #ifdef __GXX_RTTI
 return dynamic_castconst _Facet(*__facets[__i]);
   #else
 return static_castconst _Facet(*__facets[__i]);
   #endif
   }

The variable __i has value 30, but __loc.M_impl-_M_factes_size is just 28.


[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG

2012-03-09 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540

--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-09 
12:55:30 UTC ---
I would recommend trying to figure out first when the problem has been
introduced, without excluding some sort of compiler issue, because these
library facilities are in general pretty old and stable.


[Bug libstdc++/52540] std::use_facet throws bad_cast when compiled with _GLIBCXX_DEBUG

2012-03-09 Thread ktietz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52540

--- Comment #6 from Kai Tietz ktietz at gcc dot gnu.org 2012-03-09 13:00:40 
UTC ---
Hmm, it seems to be a shared/static issue on Windows.
As if I pass to command-line -static with the define, the test passes too.


[Bug fortran/52542] Procedure with a Bind (C) named interface does not inherit the Bind (C)

2012-03-09 Thread burnus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52542

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-09
 CC||burnus at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2012-03-09 
13:31:19 UTC ---
Confirmed. It's an interesting issue, but fortunately clearly specified in the
standard (F2008):

C1222 (R1211) If proc-language-binding-spec is specified, the proc-interface
  shall appear, it shall be an interface-name, and interface-name shall be
  declared with a proc-language-binding-spec.

and then in 12.4.3.6p5 (normative):

A proc-language-binding-spec without a NAME= is allowed, but is redundant with
the proc-interface required by C1222.


Untested patch:

--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -4857,2 +4857,5 @@ match_procedure_decl (void)

+  if (proc_if  proc_if-attr.is_bind_c)
+sym-attr.is_bind_c = 1;
+
   /* Get procedure symbols.  */


[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

2012-03-09 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2012-03-09
 Resolution|FIXED   |
 Ever Confirmed|0   |1

--- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2012-03-09 14:55:18 
UTC ---
However, there is a problem with Pmode != DImode. Consider following test:

struct foo
{
  int *f;
  int i;
};

void
__attribute__ ((noinline))
bar (struct foo x)
{
  *(x.f) = 1;
}

This will compile with -mx32 to:

bar:
   movl$1, (%rdi)
   ret

which is wrong.

The move is:

#(insn:TI 6 3 13 2 (set (mem:SI (reg:SI 5 di [orig:60 x ] [60]) [4 *D.1704_1+0
S4 A32])
#(const_int 1 [0x1])) ptr.c:11 64 {*movsi_internal}
# (expr_list:REG_DEAD (reg:SI 5 di [orig:60 x ] [60])
#(nil)))
movl$1, (%rdi)  # 6 *movsi_internal/2   [length = 6]

So we want to output address in SImode, while avoiding addr32 prefixes for
LEAs.

The patch from H.J. should be applied and LEAs should be fixed.


[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

2012-03-09 Thread hjl.tools at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530

--- Comment #6 from H.J. Lu hjl.tools at gmail dot com 2012-03-09 15:17:07 
UTC ---
This patch works for me:

---
diff --git a/gcc/ChangeLog.addr32 b/gcc/ChangeLog.addr32
index 066f1ec..a191e47 100644
--- a/gcc/ChangeLog.addr32
+++ b/gcc/ChangeLog.addr32
@@ -1,3 +1,8 @@
+2012-03-08  H.J. Lu  hongjiu...@intel.com
+
+* config/i386/i386.c (ix86_print_operand_address): Only handle
+zero-extended DImode addresses if Pmode == DImode.
+
 2012-03-06  Uros Bizjak  ubiz...@gmail.com

 * config/i386/i386.md (*zero_extendsidi2_rex64): Allow loading
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 69cb6ae..c2cad5a 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -14548,7 +14548,7 @@ ix86_print_operand_address (FILE *file, rtx addr)

   /* Print SImode registers for zero-extended addresses to force
  addr32 prefix.  Otherwise print DImode registers to avoid it.  */
-  if (TARGET_64BIT)
+  if (Pmode == DImode)
 code = ((GET_CODE (addr) == ZERO_EXTEND
  || GET_CODE (addr) == AND)
 ? 'l'
--


[Bug rtl-optimization/52543] New: lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543

 Bug #: 52543
   Summary: lower-subreg.c: code bloat of 300%-400% for bulti-word
memory splits
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr


lower-subreg.c causes extreme code bloat for some memory accesses because it
does not take into account the additional costs caused by the split.

Example code for AVR address spaces:

long readx (const __memx long *p)
{
return *p;
}

long read1 (const __flash1 long *p)
{
return *p;
}

long read0 (const __flash long *p)
{
return *p;
}

Reason is that read from these address spaces need one preparation sequence
(set up segment register) per read. Thus:

For one 4-byte read there will be one preparation sequence.
For 4 one-byte reads there will be 4 preparation sequences.

For the __flash address space no preparation is needed, but a 32-bit read can
use post-increment addressing whereas a split to 4 byte moves won't use
post-increment because GCC is completely afraid of pre-/post-modify addressing.

The only place to hook in could be mode_dependent_address, however, that hook
just passes the address down to the backend but omits the address space in use.
As all 16-bit address spaces (including generic) use HImode as pointer mode,
the target cannot take a decision based on the address alone.

Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --with-dwarf2
--enable-checking=yes,rtl --enable-languages=c,c++

gcc version 4.8.0 20120307 (experimental) (GCC)


[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543

--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09 
15:39:41 UTC ---
Created attachment 26862
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26862
lower.c: C source


[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543

--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09 
15:40:58 UTC ---
Created attachment 26863
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26863
lower.s: Assembler output

Compiled with

avr-gcc lower.c -Os -S -dp -mmcu=atmega128


[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543

--- Comment #3 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09 
15:44:46 UTC ---
Created attachment 26864
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26864
lower.s: Assembler output with -fno-split-wide-types

Compiled with

avr-gcc lower.c -Os -S -dp -mmcu=atmega128 -fno-split-wide-types

The code size for this module is 38 bytes whereas with lobreg lowering the code
size is 142 bytes, which is a factor of 3.7


[Bug rtl-optimization/52543] lower-subreg.c: code bloat of 300%-400% for bulti-word memory splits

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52543

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2012-03-09
 CC||eric.weddington at atmel
   ||dot com
 Ever Confirmed|0   |1
   Target Milestone|--- |4.7.1


[Bug target/47631] Support native TLS on Tru64 UNIX

2012-03-09 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47631

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2012-03-09 16:11:41 UTC 
---
Given that the Tru64 UNIX port is about to be removed in 4.8 and the TLS model
differs sufficiently from the ELF one, this won't be fixed anywhere.

  Rainer


[Bug libstdc++/52104] go1 fails to run on Solaris 10/11 x86 with with gld

2012-03-09 Thread ro at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52104

Rainer Orth ro at gcc dot gnu.org changed:

   What|Removed |Added

 Target|i386-pc-solaris2.[89]   |i386-pc-solaris2.1[01]
   Host|i386-pc-solaris2.[89]   |i386-pc-solaris2.1[01]
Summary|go1 fails to link on|go1 fails to run on Solaris
   |Solaris 8/9 x86 with native |10/11 x86 with with gld
   |TLS |
  Known to fail||4.7.0, 4.8.0
  Build|i386-pc-solaris2.[89]   |i386-pc-solaris2.1[01]

--- Comment #15 from Rainer Orth ro at gcc dot gnu.org 2012-03-09 16:15:07 
UTC ---
The Solaris 8/9 x86 link error is gone, but the go1 failure to run when linked
with gld remains on Solaris 10/11 x86, so adapting summary.

  Rainer


[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

2012-03-09 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530

Uros Bizjak ubizjak at gmail dot com changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED

--- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-03-09 16:50:12 
UTC ---
(In reply to comment #6)
 This patch works for me:
 
 ---
 diff --git a/gcc/ChangeLog.addr32 b/gcc/ChangeLog.addr32
 index 066f1ec..a191e47 100644
 --- a/gcc/ChangeLog.addr32
 +++ b/gcc/ChangeLog.addr32
 @@ -1,3 +1,8 @@
 +2012-03-08  H.J. Lu  hongjiu...@intel.com
 +
 +* config/i386/i386.c (ix86_print_operand_address): Only handle
 +zero-extended DImode addresses if Pmode == DImode.
 +
  2012-03-06  Uros Bizjak  ubiz...@gmail.com
 
  * config/i386/i386.md (*zero_extendsidi2_rex64): Allow loading
 diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
 index 69cb6ae..c2cad5a 100644
 --- a/gcc/config/i386/i386.c
 +++ b/gcc/config/i386/i386.c
 @@ -14548,7 +14548,7 @@ ix86_print_operand_address (FILE *file, rtx addr)
 
/* Print SImode registers for zero-extended addresses to force
   addr32 prefix.  Otherwise print DImode registers to avoid it.  */
 -  if (TARGET_64BIT)
 +  if (Pmode == DImode)
  code = ((GET_CODE (addr) == ZERO_EXTEND
   || GET_CODE (addr) == AND)
  ? 'l'
 --

You will have addr32 added to all lea(%SImode),%SImode instructions.

I have a patch in testing that emits addresses in their natural mode (SImode or
DImode), forces 'l' override for the above RTXes and 'q' for all LEA insns.

For LEAs, we introduce %E modifier that enables special handling:

+case 'E':
+  /* Wrap address in an UNSPEC to declare special handling.  */
+  if (TARGET_64BIT)
+x = gen_rtx_UNSPEC (DImode, gen_rtvec (1, x), UNSPEC_LEA_ADDR);
+
+  output_address (x);
+  return;

And in ix86_print_operand_address:

+  else if (GET_CODE (addr) == UNSPEC  XINT (addr, 1) == UNSPEC_LEA_ADDR)
+{
+  gcc_assert (TARGET_64BIT);
+  ok = ix86_decompose_address (XVECEXP (addr, 0, 0), parts);
+  code = 'q';
+}


[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

2012-03-09 Thread ubizjak at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530

--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-03-09 17:08:13 
UTC ---
Created attachment 26865
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26865
Patch that introduces %E modifier

Patch in testing.


[Bug c/52544] New: compilation fails with -finstrument-functions and sse c code

2012-03-09 Thread jgpiccinali at free dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544

 Bug #: 52544
   Summary: compilation fails with -finstrument-functions and sse
c code
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jgpiccin...@free.fr


Created attachment 26866
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26866
the src code that reproduce the issue.

Hi,

I'd like to report an issue with gcc versions = 4.6.x :
when compiling my sse.c code with gcc -Wall -Wextra -fno-strict-aliasing
-fwrapv sse.c, 
all versions of gcc (434, 453, 462, 463, 47 and 480) create a correct
executable, 
that will give the correct output at runtime : 

* x = [1.25 1.25 1.25 1.25]

BUT 

if i add -finstrument-functions to the compilation line, 
then only version  4.6.x (versions 434 and 453 in my tests) will compile my
code, 
otherwise (= gcc versions 462, 463, 47 and 480), compilation will stop with the
following message :

* /tmp/cckYj6ai.o: In function `main':
* sse.c:(.text+0x2a): undefined reference to `_mm_set1_ps'
* sse.c:(.text+0x50): undefined reference to `_mm_set1_ps'
* sse.c:(.text+0x79): undefined reference to `_mm_store_ps'
* sse.c:(.text+0x95): undefined reference to `_mm_store_ps'
* collect2: ld returned 1 exit status

gcc was compiled with :
configure \
  --enable-languages=c \
  --enable-threads=posix \
  --enable-shared \
  --with-mpfr=/apps/rothorn/mpfr/3.0.0/gcc-4.3.4 \
  --with-gmp=/apps/rothorn/gmp/4.3.2/gcc-4.3.4 \
  --with-mpc=/apps/rothorn/mpc/0.8.2/gcc-4.3.4

gcc/4.7   was compiled with revision 184577 of the svn.
gcc/4.8.0 was compiled with revision 185132 of the svn.
Tested on GNU/Linux with Intel (Ubuntu/11.04) and AMD (SLES/11.1) cpus.

What's wrong please ?

Thanks in advance for your help.

The original src is sse.c :
#include stdio.h
#include xmmintrin.h

int main(void)
{
float xf[4];
__m128 x = _mm_set1_ps(1.25f);
_mm_store_ps(xf[0], x);
printf(x = [%f %f %f %f]\n, xf[0], xf[1], xf[2], xf[3]);
return 0;
}

The preprocessed src (with gcc version 4.6.3) is attached, and the full output
is here :


rothorn:/apps/rothorn/sandbox/jgp/gcc/bugA $ ./463 -v -save-temps -Wall -Wextra
-fno-strict-aliasing -fwrapv sse.c -finstrument-functions 

Using built-in specs.
COLLECT_GCC=./463
COLLECT_LTO_WRAPPER=/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /apps/rothorn/sandbox/jgp/gcc/src/gcc-4.6.3/configure
--prefix=/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434 --enable-languages=c
--enable-threads=posix --enable-shared
--with-mpfr=/apps/rothorn/mpfr/3.0.0/gcc-4.3.4
--with-gmp=/apps/rothorn/gmp/4.3.2/gcc-4.3.4
--with-mpc=/apps/rothorn/mpc/0.8.2/gcc-4.3.4
Thread model: posix
gcc version 4.6.3 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing'
'-fwrapv' '-finstrument-functions' '-mtune=generic' '-march=x86-64'

/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/cc1
-E -quiet -v sse.c -mtune=generic -march=x86-64 -Wall -Wextra
-fno-strict-aliasing -fwrapv -finstrument-functions -fpch-preprocess -o sse.i
ignoring nonexistent directory
/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:

/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/include
 /usr/local/include
 /apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/include

/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/lib/gcc/x86_64-unknown-linux-gnu/4.6.3/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-fno-strict-aliasing'
'-fwrapv' '-finstrument-functions' '-mtune=generic' '-march=x86-64'

/apps/rothorn/sandbox/jgp/gcc/4.6.3/gnu434/libexec/gcc/x86_64-unknown-linux-gnu/4.6.3/cc1
-fpreprocessed sse.i -quiet -dumpbase sse.c -mtune=generic -march=x86-64
-auxbase sse -Wall -Wextra -version -fno-strict-aliasing -fwrapv
-finstrument-functions -o sse.s
GNU C (GCC) version 4.6.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 3.0.0, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C (GCC) version 4.6.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.6.3, GMP version 4.3.2, MPFR version 3.0.0, MPC
version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 221f59dff4d036c76c9a0dfc4c602ad0
COLLECT_GCC_OPTIONS='-v' '-save-temps' 

[Bug tree-optimization/52267] a~N where N has all the bits set up till a specific point can be folded to ((unsigned)a) N

2012-03-09 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52267

Jakub Jelinek jakub at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |jakub at gcc dot gnu.org
   |gnu.org |

--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-09 
17:52:47 UTC ---
Created attachment 26867
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26867
gcc48-pr52267.patch

Unfinished, WIP, patch.  Will continue working on this next week.
On top of the two VRP patches I've posted today to gcc-patches.


[Bug target/52530] [4.8 regression] Many 64-bit execution failures on Solaris 10/11 with Sun as

2012-03-09 Thread uros at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52530

--- Comment #9 from uros at gcc dot gnu.org 2012-03-09 18:01:56 UTC ---
Author: uros
Date: Fri Mar  9 18:01:47 2012
New Revision: 185148

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185148
Log:
PR target/52530
* config/i386/i386.c (ix86_print_operand): Handle 'E' operand modifier.
(ix86_print_operand_address): Handle UNSPEC_LEA_ADDR. Do not fallback
to set code to 'q'.
* config/i386/i386.md (UNSPEC_LEA_ADDR): New unspec.
(*movdi_internal_rex64): Use %E operand modifier for lea.
(*movsi_internal): Ditto.
(*lea_1): Ditto.
(*leamode_2): Ditto.
(*lea_{3,4,5,6}_zext): Ditto.
(*tls_global_dynamic_32_gnu): Ditto.
(*tls_global_dynamic_64): Ditto.
(*tls_dynamic_gnu2_lea_32): Ditto.
(*tls_dynamic_gnu2_lea_64): Ditto.
(pro_epilogue_adjust_stack_mode_add): Ditto.


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


[Bug libstdc++/52456] FAIL: libstdc++-abi/abi_check

2012-03-09 Thread bkoz at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52456

--- Comment #7 from Benjamin Kosnik bkoz at gcc dot gnu.org 2012-03-09 
18:46:52 UTC ---

Hey all. Undesignated are optionally-added symbols (like tls) that are
configure or platform dependant and so are not set into the baselines. This is
new.

They are not FAIL. It's the incompatible symbols that are making this FAIL.

As of the fix for 52191, abi_check assumes that baseline_symbols.txt file is
current as per the last release. For the 4.7.0 release, this means:

Current in 4.7.0:
GLIBCXX_3.4.17, CXXABI_1.3.6, CXXABI_TM_1

It seems as if HPPA-linux baselines are in no way current. Looking back at the
repository, the last time this file was updated for hppa was jan 2009.
(gcc-4.3/4.4 ish)

From your diff, hppa-linux is adding into:

+OBJECT:0:CXXABI_1.3.3
+OBJECT:0:CXXABI_1.3.4
+OBJECT:0:CXXABI_1.3.5
+OBJECT:0:CXXABI_1.3.6

GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17

Which is every release post 4.3.x, starting with 4.4. So, this could make
sense.

None of the symbol additions for hppa-linux diverge from x86-linux in name or
version, so this seems ok to me if you just want to update the hppa-linux
baselines to 4.7.0 exports. 

Once you update the trunk hppa baselines, abi_check will stop failing.


[Bug other/52545] New: output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545

 Bug #: 52545
   Summary: output.h: SECTION_EXCLUDE flag clobbers
SECTION_MACH_DEP
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org


All section flags from SECTION_MACH_DEP on are reserved for target specific
purposes and must not be allocated/used by any other flags like
SECTION_EXCLUDE.

Otherwise, setting a machine specific section flag might lead to
unintentionally mark a section as SECTION_EXCLUDE.

This bug is explicit for the AVR target that uses these flags (4 bits) to
encode target specific address spaces.

The output.h source comment reads:

#define SECTION_MACH_DEP 0x200/* subsequent bits reserved for target */


[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-09
 CC||tmsriram at google dot com
   Target Milestone|--- |4.7.1
 Ever Confirmed|0   |1

--- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09 
19:17:52 UTC ---
FYI, this is the wrong line:

#define SECTION_EXCLUDE  0x400


[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545

--- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09 
19:21:09 UTC ---
...and here is the change:

http://gcc.gnu.org/viewcvs?view=revisionrevision=179288


[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP

2012-03-09 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545

--- Comment #3 from Sriraman Tallam tmsriram at google dot com 2012-03-09 
19:36:21 UTC ---
Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it ok
to just bump SECTION_MACH_DEP?

The patch I have in mind is:

-#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */
-#define SECTION_EXCLUDE  0x400
+#define SECTION_EXCLUDE 0x200
+#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */

I can bump SECTION_MACH_DEP even more to reserve more bits.

-Sri.


[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP

2012-03-09 Thread gjl at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545

--- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09 
20:27:42 UTC ---
(In reply to comment #3)
 Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it 
 ok
 to just bump SECTION_MACH_DEP?
 
 The patch I have in mind is:
 
 -#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */
 -#define SECTION_EXCLUDE  0x400
 +#define SECTION_EXCLUDE 0x200
 +#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */
 
 I can bump SECTION_MACH_DEP even more to reserve more bits.

The reserved bits start at SECTION_MACH_DEP, with the patch above you just
waste the bit at 0x400.

Any bits covered by 
  SECTION_MACH_DEP * (~0)
are reserved for the machine. The bigger SECTION_MACH_DEP is, the less bits are
left for machine specific needs.

Machine specific section flag masks could be, e.g.:

#define SECTION_FLAG_MACH_1 (SECTION_MACH_DEP)
#define SECTION_FLAG_MACH_2 (SECTION_MACH_DEP  1)
#define SECTION_FLAG_MACH_3 (SECTION_MACH_DEP  2)
...


[Bug c/52546] New: -fstack-usage not working with __attribute__((naked))

2012-03-09 Thread marek.vasut at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546

 Bug #: 52546
   Summary: -fstack-usage not working with __attribute__((naked))
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marek.va...@gmail.com


Dear GCC hackers,

I get the following output while compiling my code (isolated snippet follows):

spl_mem_init.c: In function 'data_abort_memdetect_handler':
spl_mem_init.c:180:1: warning: -fstack-usage not supported for this target
[enabled by default]

Culprit:
void data_abort_memdetect_handler(void) __attribute__((naked));
void data_abort_memdetect_handler(void)
{
asm volatile(subs pc, r14, #4);
}

gcc --version
arm-linux-gnueabi-gcc (Debian 4.6.2-14) 4.6.2
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Though this is observed also with stock GCC 4.6.

Is there any way to tell the compiler how much stack does a naked function
consume (or that it consumes zero stack)? Is this a GCC bug?

Thanks in advance!


[Bug libitm/52482] libitm INVALID MNEMONIC in .S (powerpc asm)

2012-03-09 Thread fang at csl dot cornell.edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52482

--- Comment #4 from David Fang fang at csl dot cornell.edu 2012-03-09 
20:44:14 UTC ---
Also, from my testing, it looks like AS=odas is needed; if I just pass
AS_FOR_TARGET=odas, then the wrong assembler is used and sjlj.S fails.


[Bug c/52547] New: Internal compiler Error in create_tmp_var in gimplify.c:465

2012-03-09 Thread iamrohitbanga at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52547

 Bug #: 52547
   Summary: Internal compiler Error in create_tmp_var in
gimplify.c:465
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: iamrohitba...@gmail.com


Created attachment 26868
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26868
Preprocessed Source

I get the following error when trying to compile a piece of software.
Commenting out the call to qsort in the original source file (the corresponding
line number in the attached preprocessed file is 7176) does not produce any
error.

gcc -std=gnu9x -fopenmp   -g -O2 -Iinclude -o main main.c src/stinger.c
src/stinger-utils.c src/timer.c src/xmalloc.c \
 -lm -lrt
src/stinger-utils.c: In function ‘stinger_to_sorted_csr’:
src/stinger-utils.c:450:13: internal compiler error: in create_tmp_var, at
gimplify.c:465
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccAzPZP8.out file, please attach this to
your bugreport.
make: *** [main] Error 1


[Bug middle-end/52548] New: missed PRE optimization when function call follows to-be hoisted variable

2012-03-09 Thread aldyh at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548

 Bug #: 52548
   Summary: missed PRE optimization when function call follows
to-be hoisted variable
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: al...@gcc.gnu.org


For the following code (for -O2):

int flag, hoist, y, z;

void
foo (void)
{
  if (flag)
y = hoist + 4;
  else
flag = 888;
  z = hoist + 4;
  bark ();
}

...PRE should be moving hoist + 4 to the else arm, but it fails to do so.

If you remove the call to bark(), [hoist + 4] gets moved appropriately.

The bark() function call is in the same basic block as z = hoist + 4.  I wild
guess is that hoist isn't anticipatable at the *end* of the BB beginning with
z = hoist + 4.  Splitting BB's at function calls may improve PRE.  Just a
guess...


[Bug c++/52521] [C++11] user defined literals and order of declaration

2012-03-09 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52521

--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-03-09 
21:21:15 UTC ---
Created attachment 26869
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26869
gcc48-pr52521.patch

If ignoring possibility of parameters with default arguments, I guess the fix
could look like this.  If operator could have default arguments, it would
complicate things a little bit.
[over.literal]/3 lists what argument types are allowed, so IMHO it isn't
possible to have say
int operator _w (long double, long double = 2.0L);, but what if there is
say
int operator _w (const char *, std::size_t = 0);
?  Can it be called for int i = 123_w; ?  Though, [over.literal]/4 says that
a raw literal operator contains a single const char * argument and
[lex.ext]/{3,4} says that a raw literal operator is called for integer/floating
udlits, so perhaps it shouldn't call int operator _w (const char *,
std::size_t = 0); and the attached patch is sufficient.

Jason, what do you think?


[Bug other/52545] output.h: SECTION_EXCLUDE flag clobbers SECTION_MACH_DEP

2012-03-09 Thread tmsriram at google dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545

--- Comment #5 from Sriraman Tallam tmsriram at google dot com 2012-03-09 
21:30:54 UTC ---
On Fri, Mar 9, 2012 at 12:27 PM, gjl at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52545

 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org 2012-03-09 
 20:27:42 UTC ---
 (In reply to comment #3)
 Right, I was not looking at SECTION_MACH_DEP when I defined the macro. Is it 
 ok
 to just bump SECTION_MACH_DEP?

 The patch I have in mind is:

 -#define SECTION_MACH_DEP 0x200 /* subsequent bits reserved for target */
 -#define SECTION_EXCLUDE  0x400
 +#define SECTION_EXCLUDE 0x200
 +#define SECTION_MACH_DEP 0x800 /* subsequent bits reserved for target */

 I can bump SECTION_MACH_DEP even more to reserve more bits.

 The reserved bits start at SECTION_MACH_DEP, with the patch above you just
 waste the bit at 0x400.

I thought I will leave some bits for future flags but I guess whoever
adds a flag can also bump SECTION_MACH_DEP. I will send a patch to fix
this.

Thanks,
-Sri.


 Any bits covered by
  SECTION_MACH_DEP * (~0)
 are reserved for the machine. The bigger SECTION_MACH_DEP is, the less bits 
 are
 left for machine specific needs.

 Machine specific section flag masks could be, e.g.:

 #define SECTION_FLAG_MACH_1 (SECTION_MACH_DEP)
 #define SECTION_FLAG_MACH_2 (SECTION_MACH_DEP  1)
 #define SECTION_FLAG_MACH_3 (SECTION_MACH_DEP  2)
 ...

 --
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You are on the CC list for the bug.


[Bug c/52546] -fstack-usage not working with __attribute__((naked))

2012-03-09 Thread ebotcazou at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-09
 CC||ebotcazou at gcc dot
   ||gnu.org
 Ever Confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-03-09 
21:48:46 UTC ---
 Is there any way to tell the compiler how much stack does a naked function
 consume (or that it consumes zero stack)? Is this a GCC bug?

It's a limitation.  We could indeed do better, but if you know how much stack
space the function uses, what's the point in asking the compiler? :-)


[Bug c/52547] Internal compiler Error in create_tmp_var in gimplify.c:465

2012-03-09 Thread iamrohitbanga at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52547

--- Comment #1 from Rohit Banga iamrohitbanga at gmail dot com 2012-03-09 
21:59:25 UTC ---
Removing -fopenmp resolves the problem. That piece of information should be
helpful in solving the bug.


[Bug libstdc++/51785] gets not anymore declared

2012-03-09 Thread jsm28 at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785

--- Comment #26 from Joseph S. Myers jsm28 at gcc dot gnu.org 2012-03-09 
22:13:49 UTC ---
The __USE_GNU conditional has now been removed from glibc after further
discussion on libc-alpha, so the libstdc++ changes can be reverted (probably
after 4.7.0).


[Bug c/52546] -fstack-usage not working with __attribute__((naked))

2012-03-09 Thread marek.vasut at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52546

--- Comment #2 from Marek Vasut marek.vasut at gmail dot com 2012-03-09 
22:53:04 UTC ---
(In reply to comment #1)
  Is there any way to tell the compiler how much stack does a naked function
  consume (or that it consumes zero stack)? Is this a GCC bug?
 
 It's a limitation.  We could indeed do better, but if you know how much stack
 space the function uses, what's the point in asking the compiler? :-)

Ok, that's understandable and it's a really good function. It'd be certainly
favorable to avoid using such feature (specify how much the function uses), but
exactly for cases like this, it'd be very helpful to have. I'm no GC hacker
myself so I have no idea how much work it'd be to write such a thing and if
it'd be acceptable at all.

Thanks for your quick reply!


[Bug libstdc++/51785] gets not anymore declared

2012-03-09 Thread paolo.carlini at oracle dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785

--- Comment #27 from Paolo Carlini paolo.carlini at oracle dot com 2012-03-09 
23:48:17 UTC ---
Thanks a lot Joseph, a very good solution.


[Bug middle-end/52548] missed PRE optimization when function call follows to-be hoisted variable

2012-03-09 Thread steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52548

Steven Bosscher steven at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from Steven Bosscher steven at gcc dot gnu.org 2012-03-10 
00:15:12 UTC ---
(In reply to comment #0)

 The bark() function call is in the same basic block as z = hoist + 4.  I 
 wild
 guess is that hoist isn't anticipatable at the *end* of the BB beginning 
 with
 z = hoist + 4.  Splitting BB's at function calls may improve PRE.  Just a
 guess...

What is anticipated at the end of BB is uninteresting. It is computed but not
stored (only needed to compute ANTIC_IN, see compute_antic_aux).

You can check the ANTIC sets and AVAIL_OUT set with -fdump-tree-pre-details.
The value for the expression hoist+4 should be in EXP_GEN of the basic block
with the call, and in AVAIL_OUT of the basic block with y=hoist+4. But this
isn't the case here:
* the value representative for y=hoist+4 is y.2_3-{plus_expr,hoist.1_2,4}
* the value representative for z=hoist+4 is y.2_5-{plus_expr,hoist.1_2,4}
  (the name of the representative is y instead of z, probably due to
copyrename)
* SCCVN finds Value numbers:(...)y.2_5=y.2_3, as expected
* y.2_3 is in AVAIL_OUT of the then-block, as expected
* {plus_expr,hoist.1_2,4} is in EXP_GEN of the block with the call, as expected
* {plus_expr,hoist.1_2,4} is *not* in ANTIC_IN of the block with the call!

This is strange because ANTIC_IN = ANTIC_OUT U EXP_GEN - TMP_GEN

Function foo() at the .084.pre dump:

foo ()
{
  int y.2;
  int hoist.1;
  int flag.0;

bb 2:
  flag.0_1 = flag;
  if (flag.0_1 != 0)
goto bb 3;
  else
goto bb 4;

bb 3:
  hoist.1_2 = hoist;
  y.2_3 = hoist.1_2 + 4;
  y = y.2_3;
  goto bb 5;

bb 4:
  flag = 888;

bb 5:
  hoist.1_4 = hoist;
  y.2_5 = hoist.1_4 + 4;
  z = y.2_5;
  bark ();
  return;
}

Value numbers:
hoist.1_4 = hoist.1_2
y.2_5 = y.2_3

All the sets that are computed without iterations:
exp_gen[0] := {  } // BB0 is ENTRY_BLOCK
phi_gen[0] := {  }
tmp_gen[0] := {  }
avail_out[0] := {  }
exp_gen[2] := { {mem_ref0B,addr_exprflag}@.MEM_7(D) (0002) }
phi_gen[2] := {  }
tmp_gen[2] := { flag.0_1 (0002) }
avail_out[2] := { flag.0_1 (0002) }
exp_gen[3] := { {mem_ref0B,addr_exprhoist}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
phi_gen[3] := {  }
tmp_gen[3] := { hoist.1_2 (0003), y.2_3 (0004) }
avail_out[3] := { flag.0_1 (0002), hoist.1_2 (0003), y.2_3 (0004) }
exp_gen[4] := {  }
phi_gen[4] := {  }
tmp_gen[4] := {  }
avail_out[4] := { flag.0_1 (0002) }
exp_gen[5] := { {mem_ref0B,addr_exprhoist}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
phi_gen[5] := {  }
tmp_gen[5] := { hoist.1_4 (0003), y.2_5 (0004) }
avail_out[5] := { flag.0_1 (0002), hoist.1_4 (0003), y.2_5 (0004) }
exp_gen[1] := {  }
phi_gen[1] := {  }
tmp_gen[1] := {  }
avail_out[1] := {  } // BB1 is EXIT_BLOCK

Starting iteration 0
ANTIC_OUT[5] := {  }
ANTIC_IN[5] := {  }
S[5] := {  }
ANTIC_OUT[4] := {  }
ANTIC_IN[4] := {  }
S[4] := {  }
ANTIC_OUT[3] := {  }
ANTIC_IN[3] := { {mem_ref0B,addr_exprhoist}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
S[3] := {  }
ANTIC_OUT[2] := {  }
ANTIC_IN[2] := { {mem_ref0B,addr_exprflag}@.MEM_7(D) (0002) }
S[2] := {  }
Starting iteration 1
ANTIC_OUT[3] := {  }
ANTIC_IN[3] := { {mem_ref0B,addr_exprhoist}@.MEM_7(D) (0003),
{plus_expr,hoist.1_2,4} (0004) }
S[3] := {  }
ANTIC_OUT[2] := {  }
ANTIC_IN[2] := { {mem_ref0B,addr_exprflag}@.MEM_7(D) (0002) }
S[2] := {  }


[Bug ada/48835] porting GNAT to m68k-linux

2012-03-09 Thread tg at mirbsd dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835

--- Comment #52 from Thorsten Glaser tg at mirbsd dot org 2012-03-10 00:52:32 
UTC ---
Mikael’s patches work fine for me, gnat-4.6 (4.6.3-1+m68k.2) has just made its
way to debian-ports.org unreleased, chances are it’ll become part of the stock
unstable sources soon. Full three-stage bootstrap passes (with assorted GCC
bugfix backports applied by Mikael’s suggestion of course), although I did not
run the testsuite due to lack of time.

Thanks to everyone involved!


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

2012-03-09 Thread pinskia at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52544

Andrew Pinski pinskia at gcc dot gnu.org changed:

   What|Removed |Added

  Component|c   |middle-end
   Severity|major   |normal