[Bug tree-optimization/43940] DOM doesn't propagate constants properly

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Depends on||52424
 Resolution||FIXED
   Target Milestone|--- |4.7.0

--- Comment #6 from Richard Guenther  2012-03-19 
09:34:58 UTC ---
I think this was fixed by

2012-02-29  Bill Schmidt  

PR tree-optimization/52424
* tree-ssa-dom.c (dom_opt_leave_block): Push a marker before
calling dom_thread_across_edge.

[Bug libfortran/38199] missed optimization: I/O performance

[manfred99 at gmx dot ch]

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

--- Comment #16 from Manfred Schwarb  2012-03-19 
09:42:29 UTC ---
Thanks, Janne, for your patch. It does not help very much, though.
[ As expected, as the reading part is the bottleneck ]

My current timings of the second test case:
g77: 12.41s
4.3: 14.60s
4.5: 18.55s
4.7: 17.21s
4.8: 16.80s (inkl. Janne's patch)
len_trim variant, 4.3: 0.92s
len_trim variant, 4.8: 0.24s

That's still a factor 70 (sic!) away from the optimized variant.
And we are still slower than GCC 4.3 and g77.

The len_trim variant improved a lot, probably due
to Janne's patch.


Now, the interesting thing is:
I tried to figure out at which point the len_trim variant
is slower due to the len_trim overhead.
On my box, this point does not exist, i.e. the len_trim
variant is always faster!

I.e. even for
  character buffer*10

the len_trim variant is faster!

Which suggests that a brute-force approach to unconditionally 
issue a "len_trim" in the relevant gfortran reading routine 
would always be a win!

[Bug libstdc++/52612] New: std::tr1::bind doesn't work with placeholders

[anthony.ajw at gmail dot com]

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

 Bug #: 52612
   Summary: std::tr1::bind doesn't work with placeholders
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: anthony@gmail.com


Created attachment 26913
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26913
Example code that fails

The following simple code doesn't compile:

#include 

int return_int2(int,int)
{
return 42;
}

int main(){
std::tr1::bind(return_int2,32,std::tr1::placeholders::_1)(5);
}

Compiler output:

$g++ t2.cpp 
t2.cpp: In function ‘int main()’:
t2.cpp:9:64: error: no match for call to ‘(std::tr1::_Bind))(int, int)>) (int)’
/usr/include/c++/4.6/tr1/functional:1134:11: note: candidates are:
/usr/include/c++/4.6/tr1/functional:1205:9: note: typename
std::tr1::result_of<_Functor(typename
std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor(_Bound_args ...)>::operator()(_Args& ...) [with _Args
= {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder<1>}, typename std::tr1::result_of<_Functor(typename
std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type = int]
/usr/include/c++/4.6/tr1/functional:1205:9: note:   no known conversion for
argument 1 from ‘int’ to ‘int&’
/usr/include/c++/4.6/tr1/functional:1216:9: note: typename
std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor(_Bound_args ...)>::operator()(_Args& ...) const [with
_Args = {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder<1>}, typename std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type = int]
/usr/include/c++/4.6/tr1/functional:1216:9: note:   no known conversion for
argument 1 from ‘int’ to ‘int&’
/usr/include/c++/4.6/tr1/functional:1228:9: note: typename
std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor(_Bound_args ...)>::operator()(_Args& ...) volatile
[with _Args = {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder<1>}, typename std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type = int]
/usr/include/c++/4.6/tr1/functional:1228:9: note:   no known conversion for
argument 1 from ‘int’ to ‘int&’
/usr/include/c++/4.6/tr1/functional:1241:9: note: typename
std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type
std::tr1::_Bind<_Functor(_Bound_args ...)>::operator()(_Args& ...) const
volatile [with _Args = {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder<1>}, typename std::tr1::result_of(_Bound_args,
std::tr1::tuple<_UElements ...>)>::type ...)>::type = int]
/usr/include/c++/4.6/tr1/functional:1241:9: note:   no known conversion for
argument 1 from ‘int’ to ‘int&’


$ g++ --version
g++ (Ubuntu 4.6.0-3~ppa1) 4.6.1 20110409 (prerelease)
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.

[Bug fortran/52559] [4.8 Regression] Spurious \x00 in error messages of lines with tab

[fxcoudert at gcc dot gnu.org]

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

--- Comment #2 from Francois-Xavier Coudert  
2012-03-19 09:50:46 UTC ---
Author: fxcoudert
Date: Mon Mar 19 09:50:35 2012
New Revision: 185517

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185517
Log:
PR fortran/52559
* error.c (gfc_widechar_display_length): Consider tabs as
one character wide, as they're displayed as spaces.
(show_locus): Move tab handling to...
(print_wide_char_into_buffer): ... here.

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

[Bug tree-optimization/43940] DOM doesn't propagate constants properly

[stevenb.gcc at gmail dot com]

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

--- Comment #7 from stevenb.gcc at gmail dot com  
2012-03-19 09:51:41 UTC ---
> --- Comment #6 from Richard Guenther  2012-03-19 
> 09:34:58 UTC ---
> I think this was fixed by
>
> 2012-02-29  Bill Schmidt  
>
>        PR tree-optimization/52424
>        * tree-ssa-dom.c (dom_opt_leave_block): Push a marker before
>        calling dom_thread_across_edge.

I think it was fixed by ifcombine. But in any case, yes, resolved AFAIC.

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-03-19 
09:55:15 UTC ---
This statement,

  MEM[(int *)&a][i_13] = 100;

is expected to be like,

  D.4086_21 = (void *) ivtmp.11_9;
  MEM[base: D.4086_21, offset: 0B] = 100;

after loop ivopt.

If the mem is not changed then we failed to analyze it.

(In reply to comment #4)
> Hi,
> 
>   /* In general,
>  (TYPE) (BASE + STEP * i) = (TYPE) BASE + (TYPE -- sign extend) STEP * i,
>  but we must check some assumptions.
> 
>  1) If [BASE, +, STEP] wraps, the equation is not valid when precision
> of CT is smaller than the precision of TYPE.  For example, when we
> cast unsigned char [254, +, 1] to unsigned, the values on left side
> are 254, 255, 0, 1, ..., but those on the right side are
> 254, 255, 256, 257, ...
>  2) In case that we must also preserve the fact that signed ivs do not
> overflow, we must additionally check that the new iv does not wrap.
> For example, unsigned char [125, +, 1] casted to signed char could
> become a wrapping variable with values 125, 126, 127, -128, -127, ...,
> which would confuse optimizers that assume that this does not
> happen.  */
>   must_check_src_overflow = TYPE_PRECISION (ct) < TYPE_PRECISION (type);
> 
> The code above in function convert_affine_scev set must_check_src_overflow to
> true for 32-bit, while set false for 64-bit code.
> 
> This means 64-bit mode fails to unfold the address expression for array 
> element
> because of the case 1) as listed in comments above.
> 
> For the address of array element a[i], "&a + unitsize * i" has different
> representation for 32-bit and 64-bit. For 32-bit, it is "(32-bit pointer) +
> (32-bit integer)", while for 64-bit, it is "(64-bit pointer) + (32-bit
> integer)".

Of course.  'i' is 'int', thus 32bit on 64bit, so it is
&a + 4 * (sizetype) i

this is the usual issue that we lose overflow knowledge with the current
POINTER_PLUS_EXPR representation (forced unsigned offset, forced sizetype
precision offset).

> If you try the case scev-5.c as below, you may find the case can pass.
> 
> /* { dg-do compile } */
> /* { dg-options "-O2 -fdump-tree-optimized" } */
> 
> int *a_p;
> int a[1000];
> 
> f(int k)
> {
> long long i;
> 
> for (i=k; i<1000; i+=k) {
> a_p = &a[i];
> *a_p = 100;
> }
> }
> 
> /* { dg-final { scan-tree-dump-times "&a" 1 "optimized" } } */
> /* { dg-final { cleanup-tree-dump "optimized" } } */
> 
> Any idea to fix this problem?

We cannot fix it without relaxing the POINTER_PLUS_EXPR constraints.
I was working on that, but as usual the TYPE_IS_SIZETYPE removal
has priority.

Please consider fixing/XFAILing the testcases as they still FAIL and you
are responsible for this.  You can open a new enhancement PR covering
this.

> Thanks,
> -Jiangning

[Bug c++/52613] New: [C++11] ICE with noexcept in lambda expression in member function of class template

[ai.azuma at gmail dot com]

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

 Bug #: 52613
   Summary: [C++11] ICE with noexcept in lambda expression in
member function of class template
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com


Created attachment 26914
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26914
Output of -v option and preprocessed file

The following valid code causes an ICE.

///
template
struct S
{
  void f()
  {
[&] { noexcept(!b_); };
  }
  bool b_;
};
///

main.cpp: In lambda function:
main.cpp:6:21: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug fortran/52559] [4.8 Regression] Spurious \x00 in error messages of lines with tab

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #3 from Francois-Xavier Coudert  
2012-03-19 09:59:10 UTC ---
Fixed on trunk.

[Bug middle-end/52614] New: [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access

[dominiq at lps dot ens.fr]

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

 Bug #: 52614
   Summary: [4.8 Regression] Test failures in gcc.dg/vect:
vectorizing unaligned access
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domi...@lps.ens.fr
CC: greta.yo...@arm.com, ia...@gcc.gnu.org,
rgue...@gcc.gnu.org
Target: arm*-*-* ppc*-*-* ia64-*-*


AFAICT pr52603 is not fixed after revision 185474 (see
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02065.html ). In addition
similar errors occur on ppc*-*-* and ia64-*-* (see
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02068.html ,
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02104.html , and
http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02063.html ).

On powerpc-apple-darwin9, the tests pass with the following patch

--- ../../_gcc_clean/gcc/testsuite/gcc.dg/vect/vect.exp2011-11-10
13:08:06.0 +0100
+++ ../../work/gcc/testsuite/gcc.dg/vect/vect.exp2012-03-19
10:47:12.0 +0100
@@ -40,7 +40,7 @@ if ![check_vect_support_and_set_flags] {
 }

 # These flags are used for all targets.
-lappend DEFAULT_VECTCFLAGS "-ftree-vectorize" "-fno-vect-cost-model"
+lappend DEFAULT_VECTCFLAGS "-ftree-vectorize" "-fno-vect-cost-model"
"-fno-common"

 # Initialize `dg'.
 dg-init

=== gcc Summary for unix/-m64 ===

# of expected passes3709
# of expected failures127
# of unsupported tests37

=== gcc Summary ===

# of expected passes7443
# of expected failures241
# of unsupported tests64

I don't know if this related, but the failures reported in pr52491 disappeared
between revisions 185328 and 185486. Also on x86_64-apple-darwin10, the
polyhedron test gas_dyn.f90 runs 10% faster after revision 185454 than for
revision 185095.

[Bug libstdc++/52612] std::tr1::bind doesn't work with placeholders

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2012-03-19 
10:39:10 UTC ---
I seem to remember that this is a known problem of the tr1 version of this
facility, per the specs. Changing the snippet like the following works:

  ...

  int main()
  {
int n = 5;
std::tr1::bind(return_int2,32,std::tr1::placeholders::_1)(n);
  }

[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

  Component|middle-end  |testsuite
   Target Milestone|--- |4.8.0

[Bug c/52611] ia64-hp-hpux11.31, internal compiler error: verify_gimple failed

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Guenther  2012-03-19 
10:53:23 UTC ---
(In reply to comment #4)
> I don't think we should drop a cast that changes a machine mode:
> 
> --- tree-ssa.c.orig 2012-03-18 17:32:32.0 +0100
> +++ tree-ssa.c  2012-03-18 17:30:40.0 +0100
> @@ -1264,6 +1264,10 @@ useless_type_conversion_p (tree outer_ty
>if (POINTER_TYPE_P (inner_type)
>&& POINTER_TYPE_P (outer_type))
>  {
> +  /* Do not lose casts between pointers in different machine modes.  */
> +  if (TYPE_MODE (inner_type) != TYPE_MODE (outer_type))
> +   return false;
> +
>/* Do not lose casts between pointers to different address spaces.  */
>if (TYPE_ADDR_SPACE (TREE_TYPE (outer_type))
>   != TYPE_ADDR_SPACE (TREE_TYPE (inner_type)))
> 
> GCC 4.7 and GCC 4.8 have a similar check in place.

Yes, the patch that introduced this can/should be backported.

[Bug other/52609] -Wstrict-aliasing / missed diagnostics

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther  2012-03-19 
10:54:24 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > >accessing unsigned* via float* looks buggy
> > 
> > It does not have to be if the original argument was originally of type 
> > float.
> > Aliasing is not about type of pointers but the type which is used to access 
> > and
> > such.
> 
> ok, here's an updated testcase:
> 
> $ cat alias-bug.c
> unsigned buffer[1];
> 
> float bug1( unsigned u )
> {
> buffer[0]=u;
> return *(float*)(&buffer[0]); // warning.
> }
> 
> float bug2( unsigned u )
> {
> buffer[0]=u;
> float* ptr=(float*)&buffer[0];
> return *ptr; // missed strict aliasing warning.
> }
> 
> gcc repots warning only for bug1() and misses warning for bug2():

There is a duplicate bug for this somewhere.  The warning machinery
only looks at a single stmt.

[Bug other/52438] [4.7 Regression] Some files still GPLv2

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.0

[Bug libstdc++/35569] [c++0x] std::bind result functor doesn't accept rvalues

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||anthony.ajw at gmail dot
   ||com

--- Comment #14 from Jonathan Wakely  2012-03-19 
10:57:38 UTC ---
*** Bug 52612 has been marked as a duplicate of this bug. ***

[Bug libstdc++/52612] std::tr1::bind doesn't work with placeholders

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #2 from Jonathan Wakely  2012-03-19 
10:57:38 UTC ---
See my comments on PR 50320

C++11 std::bind works with rvalues, as of GCC 4.5

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

[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  2012-03-19 
11:13:52 UTC ---
Created attachment 26915
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26915
gcc48-pr52607.patch

AVX2 changes.
This improves:
1) for {x, x, x, x} V4DFmode permutations we now don't generate
vpermpd+vperm2f128, and just emit vpermpd (for all other V4DFmode permutations
we were already emitting just vpermpd)
2) for most of V8SFmode permutations we now emit code like
vmovdqa .LC0(%rip), %ymm1; vpermps %ymm0, %ymm1, %ymm0 instead of
vperm2f128 $0, %ymm0, %ymm0, %ymm0; vpermilps .LC0(%rip), %ymm0, %ymm0
3) broadcast permutations improvements for V8SFmode (using vbroadcastss) as
well
as some integer modes

[Bug libstdc++/52612] std::tr1::bind doesn't work with placeholders

[anthony.ajw at gmail dot com]

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

--- Comment #3 from Anthony Williams  2012-03-19 
11:15:45 UTC ---
It's frustrating that the TR1 spec specifies lvalues (I assumed it was the same
as std::bind). This came up in supposedly-portable code that works with MSVC's
TR1 bind.

Good thing it's fixed for std::bind.

[Bug libstdc++/52612] std::tr1::bind doesn't work with placeholders

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  2012-03-19 
11:24:15 UTC ---
Yeah, it's not ideal, but I have very little motivation (and even less time!)
to improve tr1::bind now. For C++03 code there's boost::bind and for C++11 code
there's std::bind.

[Bug libstdc++/52604] mt allocator crashes on multi-threaded

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #2 from Paolo Carlini  2012-03-19 
12:26:56 UTC ---
To be clear: are you seeing the valgrind errors going away with the patchlet
applied? First blush, I don't.

[Bug c/52615] New: function pointer casting bug

[cglbftm at gmail dot com]

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

 Bug #: 52615
   Summary: function pointer casting bug
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cglb...@gmail.com


gcc compiler can't create any working code for my programm.

Full programm here:

int a(char x)
{
  return x;
}

int main()
{
  float result;

  result = (*(float (*)(double, int, char *))a)(4.5f, 7, "Hello");
  return 0;
}

gcc input:

gcc main.c

gcc output: 

main.c: In function 'main':
main.c:10:48: warning: function called through a non-compatible type [enabled
by
 default]
main.c:10:48: note: if this code is reached, the program will abort

Compiler create executable file. But it doesn't work.
Other compilers(g++, MSVC 10) works fine. No warnings and working programm.

[Bug c/52615] function pointer casting bug

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #1 from Richard Guenther  2012-03-19 
13:20:36 UTC ---
I believe your program invokes undefined behavior.

But, since 4.7 we can DWIM, the middle-end should be able to handle a local
differing call ABI by means of gimple_call_fntype which can be different from
the type of the FUNCTION_DECL we refer to.  I think the only requirement
for the frontends is that the function in the CALL_EXPR is (fntype2 *)&f
with f being of fntype1.

[Bug driver/52616] New: problem with '-m32' and specific arguments to '-o'

[adpstw at yahoo dot co.uk]

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

 Bug #: 52616
   Summary: problem with '-m32' and specific arguments to '-o'
Classification: Unclassified
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adp...@yahoo.co.uk


On Centos 6.2 x64 with gcc that identifies itself as follows:

  gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)

linking fails for certain cases of '-m32' and '-o ' options:

  $ make
  gcc -m32 -c -o hello.o hello.c
  gcc -m32 -o dm32 hello.o
  /usr/bin/ld: i386 architecture of input file `hello.o' is incompatible with
i386:x86-64 output
  collect2: ld returned 1 exit status
  make: *** [dm32] Error 1

It looks like using an output filename of the form '.m32', where . is any
character, causes 'gcc' to get confused. If the '-o' option has an argument
that doesn't contain 'm32', linking succeeds. A workaround seems to be to use
'-o', i.e. no space between '-o' and its argument.

hello.c is any old "hello world!" program.

Incorrect behaviour with '-v' option:
--
$ gcc -v -m32 -o dm32 hello.o
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'dm32' '-mtune=generic'
 /usr/libexec/gcc/x86_64-redhat-linux/4.4.6/collect2 --eh-frame-hdr --build-id
-m elf_x86_64 --hash-style=gnu -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
dm32 /usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.6
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.6
-L/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../.. hello.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed /usr/lib/gcc/x86_64-redhat-linux/4.4.6/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../lib64/crtn.o
/usr/bin/ld: i386 architecture of input file `hello.o' is incompatible with
i386:x86-64 output
collect2: ld returned 1 exit status

Correct behaviour with '-v' option:
--
$ gcc -v -m32 -o hello hello.o
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC)
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/:/usr/libexec/gcc/x86_64-redhat-linux/4.4.6/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/4.4.6/:/usr/lib/gcc/x86_64-redhat-linux/

[Bug driver/52616] problem with '-m32' and specific arguments to '-o'

[adpstw at yahoo dot co.uk]

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

--- Comment #1 from Tomas Whitlock  2012-03-19 
14:11:13 UTC ---
Created attachment 26916
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26916
Makefile for test case

[Bug driver/52616] problem with '-m32' and specific arguments to '-o'

[adpstw at yahoo dot co.uk]

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

--- Comment #2 from Tomas Whitlock  2012-03-19 
14:11:53 UTC ---
Created attachment 26917
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26917
C code for test case

[Bug c/52617] New: -Wconversion does not work for strlen

[mathieu.malaterre at gmail dot com]

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

 Bug #: 52617
   Summary: -Wconversion does not work for strlen
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mathieu.malate...@gmail.com


Hi,

  gcc -Wconversion does not work for strlen function. For example:


#include 

size_t my_strlen( const char *input )
{
  return strlen( input );
}

int main()
{
  int s1 = strlen("bla");
  int s2 = my_strlen("bla");
  return 0;
}


leads to:

$ gcc -Wconversion t.c
t.c: In function ‘main’:
t.c:11: warning: conversion to ‘int’ from ‘size_t’ may alter its value


Clearly one warning is missing (on line 10).

Thanks

[Bug fortran/47692] Numeric inaccuracy reported in testing lapack-3.3.0 BLAS module

[sliwa at blue dot cft.edu.pl]

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

Cezary Sliwa  changed:

   What|Removed |Added

 CC||sliwa at blue dot
   ||cft.edu.pl

--- Comment #15 from Cezary Sliwa  2012-03-19 
14:28:43 UTC ---

I just received a message saying:

"The problem with the BLAS testing programs sometimes not computing the machine
epsilon correctly has been fixed in revision r1224, available in the LAPACK SVN
repository (https://icl.cs.utk.edu/svn/lapack-dev/lapack/trunk)."

[Bug c/52617] -Wconversion does not work for strlen

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-03-19 
14:50:34 UTC ---
You should get two warnings if you use -fno-builtin

But do you really want it? The compiler is smart enough to know that
strlen("bla") returns 3 so the warning would be wrong.

[Bug c++/52618] New: Explicit template specialization ignores access rights

[blobbyvolley at mailmetrash dot com]

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

 Bug #: 52618
   Summary: Explicit template specialization ignores access rights
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: blobbyvol...@mailmetrash.com


Created attachment 26918
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26918
Example code

Compilation of the following code should fail but it is accepted instead.
Explicit specialization of get_type for class B is able to access a private
member of B even without a friend declaration.

 example.cpp 

template struct get_type {
  typedef typename T::type type;
};

struct A {
  typedef int type;
};

class B {
  typedef double type; // this is a private member
  //friend class get_type; // this declaration should be required
};

template<> struct get_type {
  typedef typename B::type type; // should not access B::type without friend
declaration
};

template void f(T) {
  typedef typename get_type::type sometype;
}

int main(int, char*[]) {
  A a;
  B b;
  f(a);
  f(b);
}

 end example.cpp

I also tried compiling under LLVM (the simple online demo) and it correctly
gives me an error.

compiled with: g++ -c example.cpp

Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

[Bug c++/52618] Explicit template specialization ignores access rights

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-03-19
 Ever Confirmed|0   |1

--- Comment #1 from Jonathan Wakely  2012-03-19 
15:06:31 UTC ---
Confirmed, this is one of many access-checking bugs in templates, see PR 47346

Reduced:

class B {
  typedef double type; // this is a private member
};

template struct get_type;

template<> struct get_type {
  typedef typename B::type type;
};

typedef typename get_type::type sometype;

[Bug c++/52619] New: ICE/segmentation fault in lambda function

[t.schuele at web dot de]

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

 Bug #: 52619
   Summary: ICE/segmentation fault in lambda function
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: t.schu...@web.de


Hi, the following piece of code causes an ICE (segmentation fault) when
compiled with gcc-4.7.0-RC-20120302 (no problem with gcc 4.6.3):

#include 

template
struct test {
  std::atomic x;
  void foo() {
auto cond = [this] {return x != 0;};
  }
};

It works if the value of x is loaded explicitly:

auto cond = [this] {return x.load() != 0;};

[Bug middle-end/51255] Using -fwhole-program breaks code which puts values in .ctors or .init_array

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka  2012-03-19 
15:35:28 UTC ---
I would incline to declare this an user error. GCC does not control the meaning
of all of the user specified sections and thus I would say that user is either
required to use constructor/destructor attributes or "used" attribute.

For sure we can add magic and make cgraph_finalize_function or so to drop an
attribute implicitly.

Note that constructor/destructor attributes are different from used
attribute+named section. We know how to optimize away ctors/dtors without side
effects etc. So it would be better to convert such code to an dedicated
attribute.

Honza

[Bug c++/14710] Warning about useless casts

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  
2012-03-19 15:51:36 UTC ---
Author: paolo
Date: Mon Mar 19 15:51:25 2012
New Revision: 185524

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185524
Log:
2012-03-16  Paolo Carlini  

PR c++/14710
* doc/invoke.texi: Document -Wuseless-cast.

/c-family
2012-03-16  Paolo Carlini  

PR c++/14710
* c.opt ([Wuseless-cast]): Add.

/cp
2012-03-16  Paolo Carlini  

PR c++/14710
* cp-tree.h (maybe_warn_about_useless_cast): Declare.
* typeck.c (maybe_warn_about_useless_cast): Define.
(build_reinterpret_cast, build_const_cast,
build_static_cast, cp_build_c_cast): Use it.
* rtti.c (build_dynamic_cast): Likewise.
* pt.c (tsubst_copy_and_build, case CAST_EXPR): Increment/decrement
c_inhibit_evaluation_warnings before/after the build_* calls.

/testsuite
2012-03-16  Paolo Carlini  

PR c++/14710
* g++.dg/warn/Wuseless-cast.C: New.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wuseless-cast.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/rtti.c
trunk/gcc/cp/tree.c
trunk/gcc/cp/typeck.c
trunk/gcc/doc/invoke.texi

[Bug c++/14710] Warning about useless casts

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #11 from Paolo Carlini  2012-03-19 
15:54:35 UTC ---
Done.

[Bug driver/52616] problem with '-m32' and specific arguments to '-o'

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.6.0
 Resolution||FIXED
   Target Milestone|--- |4.6.0
  Known to fail||4.5.3

--- Comment #3 from Richard Guenther  2012-03-19 
15:55:37 UTC ---
Fixed since GCC 4.6.0.

[Bug c++/52620] New: using cannot import types in (non direct) base classes

[akim.demaille at gmail dot com]

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

 Bug #: 52620
   Summary: using cannot import types in (non direct) base classes
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: akim.demai...@gmail.com


Created attachment 26919
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26919
Test case

I might be missing something, sorry if this is just noise.  It looks
very much like http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51971 ,
but instead of "using" from the immediate base class, it fails when
"using" from a grand-child.  I checked the standard, and according to
_my_ reading it should work, yet this case is not presented as an example.

Please note that neither "using" in "bot" work.  I have left both of
them, but of course one should suffice.  It is interesting to note that
both are accepted (g++ does not report the "using" declarations as
errors - except for the duplication), yet it seems impossible to use
the imported name.

Thanks!


$ g++-mp-4.7 -std=c++0x -Wall foo.cc
foo.cc:18:3: error: 'type' does not name a type
foo.cc: In instantiation of 'struct bot':
foo.cc:28:13:   required from here
foo.cc:17:26: error: redeclaration of 'using med::type'
foo.cc:16:14: note: previous declaration 'using top::type'
foo.cc: In function 'int main()':
foo.cc:26:19: warning: unused variable 'vm' [-Wunused-variable]
foo.cc:30:19: warning: unused variable 'vb' [-Wunused-variable]

$ g++-mp-4.7 --version
g++-mp-4.7 (GCC) 4.7.0 20120225 (experimental)
Copyright (C) 2012 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.



$ g++-4.2  -Wall foo.cc
foo.cc:18: error: ‘type’ does not name a type
foo.cc: In function ‘int main()’:
foo.cc:26: warning: unused variable ‘vm’
foo.cc:30: warning: unused variable ‘vb’

$ g++-4.2  --version
i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 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.



FWIW, clang 3.1 accepts both versions (using from top or from med).


PS/  It is extremely confusing to be submit possible "duplicates"
that are not even C++ :(

[Bug c++/52620] using cannot import types in (non direct) base classes

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  2012-03-19 
16:10:08 UTC ---
template 
struct bot: med
{
  using top::type;

This is not valid, med is a dependent base class so name lookup never looks
in it, so top is not known to be a base class.

If you remove that line G++ accepts the code.


> PS/  It is extremely confusing to be submit possible "duplicates"
> that are not even C++ :(

I assume you mean the list of possible dups when filling in the form?
Your "C++" bug might actually be a middle-end bug, or a preprocessor bug, or
something else, so it makes sense to look for dups across the whole database.

[Bug fortran/52621] New: ICE when compiling Fortran77 code with optimization

[pepalogik at seznam dot cz]

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

 Bug #: 52621
   Summary: ICE when compiling Fortran77 code with optimization
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pepalo...@seznam.cz


Created attachment 26920
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26920
Library source producing the ICE

I am compiling an old Fortran 77 code on Windows XP. I have fixed this code to
make it basically work in both FTN95 (Silverfrost) and gfortran compilers. But
when I try to make a highly optimized build with gfortran, I get an ICE.

Compiler version:
C:\MinGW\bin>gfortran.exe -v
Using built-in specs.
COLLECT_GCC=gfortran.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.6.1/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.1/configure
--enable-languages=c,c++,fortran,objc,ob
j-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp
-
-disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runti
me-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.6.1 (GCC)

Command:
gfortran.exe -std=legacy -march=native -mfpmath=sse -m3dnow -mmmx -msse -msse2
-msse3  -O3   -Wall-c D:\Jenda\cbp\SATLEED\LEEDSATL_SB\leedsatl_sb.f -o
obj\Release\leedsatl_sb.o

CPU: AMD Athlon x2, see


Important: The ICE is gone if I decrease the optimization level to -O2 or
exclude the machine specific options (from -march to -msse3).

The code and output are attached.

Copyright note: The code comes from

and I am actually not allowed to distribute it.

[Bug fortran/52621] ICE when compiling Fortran77 code with optimization

[pepalogik at seznam dot cz]

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

--- Comment #1 from Jan Lachnitt  2012-03-19 
16:13:22 UTC ---
Created attachment 26921
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26921
Compiler output

[Bug c++/52620] using cannot import types in (non direct) base classes

[akim.demaille at gmail dot com]

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

--- Comment #2 from Akim Demaille  2012-03-19 
16:16:37 UTC ---
(I pasted the wrong bug report, I meant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21484)

(In reply to comment #1)
> template 
> struct bot: med
> {
>   using top::type;
> 
> This is not valid, med is a dependent base class so name lookup never looks
> in it, so top is not known to be a base class.

Ah, thanks for the clarification!

> If you remove that line G++ accepts the code.

Ah, somehow I broke my tests.  4.6.3 does not accept it (and is the compiler
I am actually using), but you are right that 4.7.0 is fine with it.

> > PS/  It is extremely confusing to be submit[ted] possible "duplicates"
> > that are not even C++ :(
> 
> I assume you mean the list of possible dups when filling in the form?
> Your "C++" bug might actually be a middle-end bug, or a preprocessor bug, or
> something else, so it makes sense to look for dups across the whole database.

Candidates were about Java :)  But I understand, thanks.

[Bug c++/52620] using cannot import types in (non direct) base classes

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Jonathan Wakely  2012-03-19 
16:31:04 UTC ---
(In reply to comment #2)
> (I pasted the wrong bug report, I meant
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21484)

That's a dup of PR 14258 so should be fixed for 4.7, and I think this is the
same issue.


> (In reply to comment #1)
> > template 
> > struct bot: med
> > {
> >   using top::type;
> > 
> > This is not valid, med is a dependent base class so name lookup never 
> > looks
> > in it, so top is not known to be a base class.
> 
> Ah, thanks for the clarification!

I believe it's a bug in clang if it accepts it.


> > If you remove that line G++ accepts the code.
> 
> Ah, somehow I broke my tests.  4.6.3 does not accept it (and is the compiler
> I am actually using), but you are right that 4.7.0 is fine with it.

Yes, the 'using' code was significantly improved for 4.7, see the release notes
at http://gcc.gnu.org/gcc-4.7/changes.html#cxx

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

[Bug c++/14258] typename in a using declaration not supported

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||akim.demaille at gmail dot
   ||com

--- Comment #17 from Jonathan Wakely  2012-03-19 
16:31:04 UTC ---
*** Bug 52620 has been marked as a duplicate of this bug. ***

[Bug fortran/52622] New: ICE in gfortran 4.6.3, x86_64

[adrian at llnl dot gov]

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

 Bug #: 52622
   Summary: ICE in gfortran 4.6.3, x86_64
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: adr...@llnl.gov


Created attachment 26922
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26922
delta-reduced testcase

I'm getting an ICE in gfortran 4.6.3 .
The machine is running Ubuntu 10.04, 64 bit on an Intel Xeon.


  $ gfortran -I.  -c -o test.o test.f03 

  f951: internal compiler error: Segmentation fault
  Please submit a full bug report,
  with preprocessed source if appropriate.
  See  for instructions.

I've attached a (nonsensical) delta-reduced test case.

[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rth at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  2012-03-19 
17:13:53 UTC ---
I'm not very keen on having too many different routines, the more generic they
are, the better.  So IMHO e.g. the two insn sequence, vperm2[if]128 + some one
insn shuffle could look like:

/* A subroutine of ix86_expand_vec_perm_builtin_1.  Try to expand
   a vector permutation using two instructions, vperm2f128 resp.
   vperm2i128 followed by any single in-lane permutation.  */

static bool
expand_vec_perm_vperm2f128 (struct expand_vec_perm_d *d)
{
  struct expand_vec_perm_d dfirst, dsecond;
  unsigned i, j, nelt = d->nelt, nelt2 = nelt / 2, perm;
  bool ok;

  if (!TARGET_AVX
  || GET_MODE_SIZE (d->vmode) != 32
  || (d->vmode != V8SFmode && d->vmode != V4DFmode && !TARGET_AVX2))
return false;

  dsecond = *d;
  if (d->op0 == d->op1)
dsecond.op1 = gen_reg_rtx (d->vmode);
  dsecond.testing_p = true;

  /* ((perm << 2)|perm) & 0x33 is the vperm2[fi]128
 immediate.  For perm < 16 the second permutation uses
 d->op0 as first operand, for perm >= 16 it uses d->op1
 as first operand.  The second operand is the result of
 vperm2[fi]128.  */
  for (perm = 0; perm < 32; perm++)
{
  /* Ignore permutations which do not move anything cross-lane.  */
  if (perm < 16)
{
  if ((perm & 0xc) == (1 << 2)) continue;
  if ((perm & 3) == 0) continue;
  if ((perm & 0xf) == ((3 << 2) | 2)) continue;
}
  else
{
  if ((perm & 0xc) == (3 << 2)) continue;
  if ((perm & 3) == 2) continue;
  if ((perm & 0xf) == (1 << 2)) continue;
}

  for (i = 0; i < nelt; i++)
{
  j = d->perm[i] / nelt2;
  if (j == ((perm >> (2 * (i >= nelt2))) & 3))
dsecond.perm[i] = nelt + (i & nelt2) + (d->perm[i] & (nelt2 - 1));
  else if (j == (unsigned) (i >= nelt2) + 2 * (perm >= 16))
dsecond.perm[i] = d->perm[i] & (nelt - 1);
  else
break;
}

  if (i == nelt)
{
  start_sequence ();
  ok = expand_vec_perm_1 (&dsecond);
  end_sequence ();
}
  else
ok = false;

  if (ok)
{
  if (d->testing_p)
return true;

  dsecond.testing_p = false;
  dfirst = *d;
  if (d->op0 == d->op1)
dfirst.target = dsecond.op1;
  else
dfirst.target = gen_reg_rtx (d->vmode);
  for (i = 0; i < nelt; i++)
dfirst.perm[i] = (i & (nelt2 - 1))
 + ((perm >> (2 * (i >= nelt2))) & 3) * nelt2;

  ok = expand_vec_perm_1 (&dfirst);
  gcc_assert (ok);

  dsecond.op1 = dfirst.target;
  if (perm >= 16)
dsecond.op0 = dfirst.op1;

  ok = expand_vec_perm_1 (&dsecond);
  gcc_assert (ok);

  return true;
}

  /* For d->op0 == d->op1 the only useful vperm2f128 permutation
 is 0x10.  */
  if (d->op0 == d->op1)
return false;
}

  return false;
}

This will handle e.g. vperm2f128 + {vshufpd,vblendpd,vunpcklpd,vunpckhpd} etc.
But with the current expand_vselect implementation it might be too costly, at
least memory-wise.

[Bug bootstrap/52623] New: 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

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

 Bug #: 52623
   Summary: 4.7.0-RC-20120314: bootstrap failure on AIX due to
multilib and using C++ in post-stage1
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: michael.haubenwall...@salomon.at
  Host: powerpc-ibm-aix7.1.0.0
Target: powerpc-ibm-aix7.1.0.0
 Build: powerpc-ibm-aix7.1.0.0


Created attachment 26923
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26923
Output of 'gmake bootstrap' (single job)

Bootstrapping gcc-4.7.0-RC-20120314 on powerpc-ibm-aix7.1.0.0 fails because of
32bit gcc/xgcc cannot load a 64bit libstdc++.a.

It works when I do configure with --disable-build-poststage1-with-cxx

Prerequisites:

Installed binary:
  gcc-4.6.2 in /opt/freeware/ from perzl.org,
Self-built:
  gmp-5.0.1, configured with ABI=32
  mpfr-3.0.0,
  mpc-0.8.2,

Toplevel configured with --enable-languages=c,c++
'gmake bootstrap' with single job

The last lines in the output of 'gmake bootstrap' (from attached
bootstrap.out.bz2):

---
Adding multilib support to Makefile in
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/libquadmath
with_multisubdir=pthread
Running configure in multilib subdir ppc64
pwd:
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0
configure: creating cache ./config.cache
checking build system type... powerpc-ibm-aix7.1.0.0
checking host system type... powerpc-ibm-aix7.1.0.0
checking target system type... powerpc-ibm-aix7.1.0.0
checking for a BSD-compatible install...
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/install-sh
-c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p...
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/gcc-4.7.0-RC-20120314/libquadmath/../install-sh
-c -d
checking for gawk... nawk
checking whether gmake sets $(MAKE)... yes
checking for --enable-version-specific-runtime-libs... no
checking for style of include used by gmake... GNU
checking for powerpc-ibm-aix7.1.0.0-gcc...
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/bin/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/lib/
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/include
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/sys-include
 -maix64
checking for suffix of object files... configure: error: in
`/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libquadmath':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[1]: *** [configure-target-libquadmath] Error 1
gmake[1]: Leaving directory
`/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build'
gmake: *** [bootstrap] Error 2
---

The interesting lines in powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log
(attached as powerpc-ibm-aix7.1.0.0_ppc64_libquadmath_config.log.bz2):

---
configure:3239: checking for C compiler version
configure:3248: /big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/bin/
-B/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/lib/
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/include
-isystem
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/install/powerpc-ibm-aix7.1.0.0/sys-include
 -maix64 --version >&5
Could not load program
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/./gcc/xgcc:
Dependent module
/big1/local/src/test/gcc/gcc-4.7.0-RC-20120314/build/powerpc-ibm-aix7.1.0.0/ppc64/libstdc++-v3/src/.libs/libstdc++.a(libstdc++.so.6)
could not be loaded.
The module has an invalid magic number.
configure:3259: $? = 255
---

[Bug bootstrap/52623] 4.7.0-RC-20120314: bootstrap failure on AIX due to multilib and using C++ in post-stage1

[michael.haubenwallner at salomon dot at]

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

--- Comment #1 from Michael Haubenwallner  2012-03-19 17:20:23 UTC ---
Created attachment 26924
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26924
powerpc-ibm-aix7.1.0.0/ppc64/libquadmath/config.log

[Bug target/52624] New: Missing __builtin_bswap16

[hjl.tools at gmail dot com]

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

 Bug #: 52624
   Summary: Missing __builtin_bswap16
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: ubiz...@gmail.com
Target: x86


__builtin_bswap16 is supported on Powerpc, but is missing on x86.
We can use __builtin_bswap32 (x << 16).  But it it is less
efficient:

[hjl@gnu-6 tmp]$ cat b.c
#include 

short
b1 (short x)
{
  return  __bswap_16 (x);
}

short
b2 (short x)
{
  return  __builtin_bswap32 (x << 16);
}
[hjl@gnu-6 tmp]$ gcc -S -O b.c
[hjl@gnu-6 tmp]$ cat b.s
.file"b.c"
.text
.globlb1
.typeb1, @function
b1:
.LFB0:
.cfi_startproc
movl%edi, %eax
#APP
# 6 "b.c" 1
rorw $8, %ax
# 0 "" 2
#NO_APP
ret
.cfi_endproc
.LFE0:
.sizeb1, .-b1
.globlb2
.typeb2, @function
b2:
.LFB1:
.cfi_startproc
movl%edi, %eax
sall$16, %eax
bswap%eax
ret
.cfi_endproc
.LFE1:
.sizeb2, .-b2
.ident"GCC: (GNU) 4.6.3 20120306 (Red Hat 4.6.3-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 tmp]$

[Bug middle-end/45579] Re-enable IPA-CP for "fn spec"

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #3 from Martin Jambor  2012-03-19 
18:00:58 UTC ---
Confirmed as recently as this February?  How can that be?  I have just
checked that the testcase from PR 43665, comment #8 and verified the
checkoptimal subroutine is cloned and constants are propagated into
it, despite it having fnspec type attributes.  If you have a testcase
where you believe fnspec attributes are the reason for not performing
IPA-CP, then please post it here, I'd certainly like to have a look.

Having said that, it is certainly true that the new IPA-CP accomplish
this by simply not deleting the newly-unused parameters, whereas
arguably it should update the fnspec attributes instead.  If you think
that is something we should have a PR for, please change the
description accordingly, or open a new PR.

Otherwise I'll close this next week as a WORKSFORME.

(On a related and personal note, I dislike the representation of the
fnspec attributes very much, I think we should move it to the actual
parm_decls or to the call graph or someplace, updating a string_cst
just feels like a work-around.)

[Bug target/52624] Missing __builtin_bswap16

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2012-03-19 
18:26:58 UTC ---
static inline unsigned short __builtin_bswap16(unsigned short a)
{
  return (a<<8)|(a>>8);
}

[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}

[marc.glisse at normalesup dot org]

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

--- Comment #9 from Marc Glisse  2012-03-19 
18:29:50 UTC ---
(In reply to comment #8)
> I'm not very keen on having too many different routines, the more generic they
> are, the better.

Agreed, that was one of my concerns from the first message in this bug, but to
experiment it was easier to have separate functions.

> So IMHO e.g. the two insn sequence, vperm2[if]128 + some one
> insn shuffle could look like:
> 
> /* A subroutine of ix86_expand_vec_perm_builtin_1.  Try to expand
>a vector permutation using two instructions, vperm2f128 resp.
>vperm2i128 followed by any single in-lane permutation.  */

I haven't yet looked at it closely enough to understand what it does (those
functions are surprisingly confusing when you don't write them yourself), but
that looks interesting.

My first idea in order to make things more generic was to tentatively turn
__builtin_shuffle(x,m) into __builtin_shuffle(x,vperm2f128(x,x,33),mm) where mm
avoids any cross-lane. The 2-vector no-cross-lane shuffle should take at most 3
instructions in v4df or v8sf (I haven't checked if it works now) and that's
where most of the work would happen (instead of having many routines for
single-vector shuffles that almost all start with vperm2f128). Then you would
probably want to check how many instructions it used, since it could be more or
less than one of the few instruction sequences that don't start with
vperm2f128.

>From a quick look, it looks like you may be doing something even more
generic...

> This will handle e.g. vperm2f128 + {vshufpd,vblendpd,vunpcklpd,vunpckhpd} etc.

Cool!

[Bug testsuite/52614] [4.8 Regression] Test failures in gcc.dg/vect: vectorizing unaligned access

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org,
   ||pthaugen at gcc dot
   ||gnu.org, wschmidt at gcc
   ||dot gnu.org

--- Comment #1 from William J. Schmidt  2012-03-19 
18:58:44 UTC ---
I was about to open a PR on this as well.  Adding some powerpc folks to the CC
list.

[Bug target/50751] SH Target: Displacement addressing does not work for QImode and HImode

[olegendo at gcc dot gnu.org]

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

--- Comment #22 from Oleg Endo  2012-03-19 
18:59:22 UTC ---
Author: olegendo
Date: Mon Mar 19 18:59:16 2012
New Revision: 185534

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185534
Log:
PR target/50751
* config/sh/sh.h (CONST_OK_FOR_K04, CONST_OK_FOR_K12, DISP_ADDR_P,
DISP_ADDR_OFFSET): New macros.
* config/sh/sh.c (sh_address_cost): Add SH2A special case.
(sh_legitimate_index_p): Allow QImode displacements for non-SH2A.
(sh_legitimize_address): Add QImode displacement handling.
(sh_cannot_change_mode_class): Disallow GENERAL_REGS for SFmode 
vector subregs.
(sh_secondary_reload): Add QImode displacement handling.
* config/sh/predicates.md (movsrc_no_disp_mem_operand): New predicate.
* config/sh/constraints.md (K04, Snd, Sdd): New constraints.
* config/sh/sh.md (extendqisi2): Remove constraints from expander.
(*extendqisi2_compact): Rename to *extendqisi2_compact_reg, restrict
to register operands only.
(*extendqisi2_compact_mem_disp, *extendqisi2_compact_snd): New insns.
(extendqihi2): Change insn to expander.
(*extendqihi2_compact_reg): New insn.
(movqi_i, movqi): Replace with ... 
(movqi, *movqi_reg_reg, *movqi_store_mem_disp12,
*movqi_load_mem_disp, *movqi_load_mem_disp): ... these.
Add new peepholes for QImode displacement addressing.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/constraints.md
trunk/gcc/config/sh/predicates.md
trunk/gcc/config/sh/sh.c
trunk/gcc/config/sh/sh.h
trunk/gcc/config/sh/sh.md

[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  2012-03-19 
19:18:33 UTC ---
Created attachment 26925
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26925
gcc48-vselect.patch

Patch to decrease memory cost of expand_vselect{,_vconcat}, by keeping around
a skeleton of the vselect/vconcat insn.

[Bug target/31640] cache block alignment is too aggressive on sh-elf

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #6 from Oleg Endo  2012-03-19 19:28:40 
UTC ---
Should be OK now.

[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}

[rth at gcc dot gnu.org]

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

--- Comment #11 from Richard Henderson  2012-03-19 
19:36:03 UTC ---
The vselect patch looks pretty good.

+  if (icode >= 0 && !testing_p)
+x = copy_rtx (PATTERN (vselect_insn));
...
+  if (!testing_p)
+emit_insn (x);

could be merged for clarity.

The patch in comment #8 looks plausible.  It could
stand to have some comments added though.

[Bug target/50797] [x32] Use 32bit Pmode

[ubizjak at gmail dot com]

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

--- Comment #3 from Uros Bizjak  2012-03-19 20:08:26 
UTC ---
Fixed?

[Bug c++/52625] New: Incorrect specialization semantics of friend class template declaration

[daniel.kruegler at googlemail dot com]

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

 Bug #: 52625
   Summary: Incorrect specialization semantics of friend class
template declaration
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com


gcc 4.8.0 20120318 (experimental) rejects the following code:

//-
template
class base {};

class derived : public base
{
 template friend class base; // Error
};
//-

"error: specialization of 'base' after instantiation"

This code should be accepted, the friend declaration does not declare any
specialization.

[Bug target/50797] [x32] Use 32bit Pmode

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED
   Target Milestone|--- |4.8.0

--- Comment #4 from H.J. Lu  2012-03-19 20:13:04 
UTC ---
Fixed.

[Bug other/52626] New: make check fixinclude test FAILURES

[izamyatin at gmail dot com]

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

 Bug #: 52626
   Summary: make check fixinclude test FAILURES
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: izamya...@gmail.com
Target: x86_64-unknown-linux-gnu


Issue appeared after revision 185392:

Author: ro 
Date:   Wed Mar 14 17:08:03 2012 +

Remove obsolete Solaris 8 support


Snippet from make check report:
pthread.h
/export/users/izamyati/trunk_for_check/fixincludes/tests/base/pthread.h differ:
byte 2526, line 86
*** pthread.h2012-03-20 00:03:27.660335543 +0400
--- /export/users/izamyati/trunk_for_check/fixincludes/tests/base/pthread.h   
2012-03-16 13:25:18.787318293 +0400
***
*** 83,91 
  #define PTHREAD_MUTEX_INITIALIZER{{{0},0}, {{{0}}}, {0}}
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
! #define PTHREAD_COND_INITIALIZER{{{0}, 0}, 0}/* DEFAULTCV */
  #else
! #define PTHREAD_COND_INITIALIZER{{{0}, 0}, {0}}/* DEFAULTCV */
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
  #definePTHREAD_MUTEX_INITIALIZER/* = DEFAULTMUTEX */\
--- 83,91 
  #define PTHREAD_MUTEX_INITIALIZER{{{0},0}, {{{0}}}, {0}}
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
! #define PTHREAD_COND_INITIALIZER{{{0}, 0, 0x4356}, 0}/* DEFAULTCV */
  #else
! #define PTHREAD_COND_INITIALIZER{{{0}, 0, 0x4356}, {0}}/* DEFAULTCV
*/
  #endif
  #if __STDC__ - 0 == 0 && !defined(_NO_LONGLONG)
  #definePTHREAD_MUTEX_INITIALIZER/* = DEFAULTMUTEX */\

There were fixinclude test FAILURES
make: *** [check] Error 1

[Bug gcov-profile/52627] New: [4.8 Regression] Build of libgcc fails w/o __GTHREAD_MUTEX_INIT: error: 'mx' undeclared

[burnus at gcc dot gnu.org]

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

 Bug #: 52627
   Summary: [4.8 Regression] Build of libgcc fails w/o
__GTHREAD_MUTEX_INIT: error: 'mx' undeclared
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: gcov-profile
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: rgue...@gcc.gnu.org
 Build: i586-pc-mingw32


On i586-pc-mingw32, one gets the following failure:

../../../gcc-trunk/libgcc/libgcov.c: In function 'init_mx':
../../../gcc-trunk/libgcc/libgcov.c:716:35: error: 'mx' undeclared (first use
in this function)
../../../gcc-trunk/libgcc/libgcov.c:716:35: note: each undeclared identifier is
reported only once for each function it appears in


The source code has the following - and unless it is declared in an #include
file, no global "mx" variable exists. "grep -w mx" find just line 716:

   707  #ifdef __GTHREAD_MUTEX_INIT
   708  ATTRIBUTE_HIDDEN __gthread_mutex_t __gcov_flush_mx =
__GTHREAD_MUTEX_INIT;
   709  #define init_mx_once()
   710  #else
   711  __gthread_mutex_t __gcov_flush_mx ATTRIBUTE_HIDDEN;
   712  
   713  static void
   714  init_mx (void)
   715  {
   716__GTHREAD_MUTEX_INIT_FUNCTION (&mx);
   717  }


The code has been added by the commit:
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185231

2012-03-12  Richard Guenther  

* gthr.h (__GTHREAD_MUTEX_INIT_FUNCTION): Adjust specification.
* gthr-posix.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.
(__gthread_mutex_init_function): New function.
* gthr-single.h (__GTHREAD_MUTEX_INIT_FUNCTION): Define.

PR gcov/49484
* libgcov.c: Include gthr.h.
(__gcov_flush_mx): New global variable.
(init_mx, init_mx_once): New functions.
(__gcov_flush): Protect self with a mutex.
(__gcov_fork): Re-initialize mutex after forking.
* unwind-dw2-fde.c: Change condition under which to use
__GTHREAD_MUTEX_INIT_FUNCTION.

[Bug ada/40986] [4.5/4.6 regression] Assert_Failure sinfo.adb:360, error detected at a-unccon.ads:23:27

[nicolas.boulenguez at free dot fr]

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

--- Comment #9 from nicolas.boulenguez at free dot fr 2012-03-19 20:49:55 UTC 
---
4.6.3 (x86_64-pc-linux-gnu) Assert_Failure sinfo.adb:384

[Bug target/52628] New: SH Target: Inefficient shift by T bit result

[olegendo at gcc dot gnu.org]

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

 Bug #: 52628
   Summary: SH Target: Inefficient shift by T bit result
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: olege...@gcc.gnu.org
Target: sh*-*-*


int test_01 (int a, int b, int c)
{
  return c << (a > b ? 1 : 0);
}

-m4 -O2:
cmp/gtr5,r4
movr6,r0
movtr1
rts
shldr1,r0

better:
cmp/gtr5,r4
bf0f
add r6,r6 ! do not use shll because of T bit usage in shll
0:
rts
movr6,r0



int test_02 (int a, int b, int c)
{
  return c << (a > b ? 2 : 0);
}

-m4 -O2:
cmp/gtr5,r4
movr6,r0
movtr1
addr1,r1
rts
shldr1,r0

better:
cmp/gtr5,r4
bf0f
shll2r6
0:
rts
movr6,r0


The same goes for other shift amounts like 8 and 16.
On SH4 the zero-displacement conditional branch code should be faster.

[Bug rtl-optimization/52629] New: global buffer overflow in gcc/reload1.c

[konstantin.s.serebryany at gmail dot com]

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

 Bug #: 52629
   Summary: global buffer overflow in gcc/reload1.c
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: konstantin.s.serebry...@gmail.com


Building gcc trunk (r185531, linux, x86_64) with AddressSanitizer (a memory
error detector)
shows a global buffer overflow in gcc/reload1.c while compiling
libgcc/libgcc2.c with ./gcc/xgcc

==21687== ERROR: AddressSanitizer global-buffer-overflow on address
0x02ddc551 at pc 0xf98a5f bp 0x7fffdcbe1050 sp 0x7fffdcbe1048   
READ of size 1 at 0x02ddc551 thread T0  
#0 0xf98a5f in count_spilled_pseudo gcc/reload1.c:1830  
#1 0xf715a6 in bmp_iter_set_init gcc/bitmap.h:385   
#2 0xd55dc2 in do_reload gcc/ira.c:3733 
#3 0xea9e0d in execute_one_pass gcc/passes.c:2084   
#4 0xeaaf4d in execute_pass_list gcc/passes.c:2139  
#5 0xeaaf71 in execute_pass_list gcc/passes.c:2141  
#6 0x1200802 in invoke_plugin_callbacks gcc/plugin.h:57 
#7 0x81917d in cgraph_expand_function gcc/cgraphunit.c:1840 
#8 0x820425 in cgraph_expand_all_functions gcc/cgraphunit.c:1904
#9 0x81c655 in timevar_pop gcc/timevar.h:110
#10 0x4ebc2e in c_write_global_declarations gcc/c-decl.c:10053  
#11 0x10b82c5 in compile_file gcc/toplev.c:575  
#12 0x2b1cbf568c4d in __libc_start_main
/build/buildd/eglibc-2.11.1/csu/libc-start.c:258
0x02ddc551 is located 17 bytes to the right of global variable
'default_target_hard_regs (../../gcc_trunk/gcc/reginfo.c)' (0x2dd9d80) of size
10176  

The buggy lines: 

static void 
count_spilled_pseudo (int spilled, int spilled_nregs, int reg)  
{   
  int freq = REG_FREQ (reg);
  int r = reg_renumber[reg];
  int nregs = hard_regno_nregs[r][PSEUDO_REGNO_MODE (reg)]; 


the value of 'r' can be -1, thus the buffer overflow. 

One can confirm this bug by changing the code like this and performing full gcc
build:

count_spilled_pseudo (int spilled, int spilled_nregs, int reg)
{
  int freq = REG_FREQ (reg);
  int r = reg_renumber[reg];
  int nregs;
  gcc_assert(r >= 0);  /*<<*/
  nregs = hard_regno_nregs[r][PSEUDO_REGNO_MODE (reg)];

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

[paolo at gcc dot gnu.org]

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

--- Comment #16 from paolo at gcc dot gnu.org  
2012-03-19 23:48:21 UTC ---
Author: paolo
Date: Mon Mar 19 23:48:16 2012
New Revision: 185548

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185548
Log:
2012-03-19  Paweł Sikora  

PR libstdc++/52540
* include/Makefile.am (c++config.h): Fix sed rule to not break
the _GLIBCXX_EXTERN_TEMPLATE redefinition.
* include/Makefile.in: Regenerate.

2012-03-19  Paolo Carlini  

* testsuite/Makefile.in: Regenerate.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/Makefile.am
trunk/libstdc++-v3/include/Makefile.in
trunk/libstdc++-v3/testsuite/Makefile.in

[Bug middle-end/52630] New: [4.7 regression] ICE when compiling ppl-0.12 testsuite

[matt at use dot net]

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

 Bug #: 52630
   Summary: [4.7 regression] ICE when compiling ppl-0.12 testsuite
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@use.net


While PPL 0.12 itself built okay, it's "make check" target did not. I bootstrap
all required GCC libraries with a given GCC release, and run all their
testsuites. It usually weeds out subtle wrong-code issues and ICEs. GMP, MPC,
CLOOG-ISL, and MPFR were all fine.

g++ -DHAVE_CONFIG_H -I. -I../..  -DANALYZER_FP_FORMAT=float
-DANALYZED_FP_FORMAT=IEEE754_SINGLE   -I../../src -I../../src -I../../tests
-I../../utils -I/opt/gcc-4.7.0/include -DNDEBUG=1   -g -O3 -frounding-math 
-mcpu=v8 -W -Wall -MT digitalfilters1.o -MD -MP -MF .deps/digitalfilters1.Tpo
-c -o digitalfilters1.o digitalfilters1.cc
In file included from ../../src/Box.defs.hh:2260:0,
 from ../../src/Linear_Form.templates.hh:29,
 from ../../src/ppl_include_files.hh:8,
 from ../../src/ppl_header.hh:38,
 from ../../tests/ppl_test.hh:27,
 from digitalfilters1.cc:24:
../../src/Box.templates.hh: In constructor
‘Parma_Polyhedra_Library::Box::Box(const
Parma_Polyhedra_Library::Generator_System&) [with ITV =
Parma_Polyhedra_Library::Interval >]’:
../../src/Box.templates.hh:222:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [digitalfilters1.o] Error 1
make[3]: Leaving directory `/root/src/ppl-0.12/tests/Concrete_Expression'

Pre-processed sources are attached. ICE still happens with -O2, but does not
happen with -O1:
g++ -g -O2 -frounding-math  -mcpu=v8 -W -Wall -c digitalfilters1.cc.i  
   
 In file included from
../../src/Octagonal_Shape.defs.hh:2316:0,
 from ../../src/BD_Shape.inlines.hh:31,
 from ../../src/BD_Shape.defs.hh:2361,
 from ../../src/Box.templates.hh:38,
 from ../../src/Box.defs.hh:2260,
 from ../../src/Linear_Form.templates.hh:29,
 from ../../src/ppl_include_files.hh:8,
 from ../../src/ppl_header.hh:38,
 from ../../tests/ppl_test.hh:27,
 from digitalfilters1.cc:24:
../../src/Octagonal_Shape.templates.hh: In member function ‘void
Parma_Polyhedra_Library::Octagonal_Shape::refine_with_linear_form_inequality(const
Parma_Polyhedra_Library::Linear_Form >&, const
Parma_Polyhedra_Library::Linear_Form >&) [with Interval_Info =
Parma_Polyhedra_Library::Interval_Info_Bitset; T =
float]’:
../../src/Octagonal_Shape.templates.hh:874:1: internal compiler error:
Segmentation fault

[Bug middle-end/52630] [4.7 regression] ICE when compiling ppl-0.12 testsuite

[matt at use dot net]

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

--- Comment #1 from Matt Hargett  2012-03-20 00:00:46 UTC 
---
Created attachment 26926
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26926
pre-processed sources that exhibit the ICE

[Bug target/52630] [4.7 regression] ICE when compiling ppl-0.12 testsuite

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||sparc
  Component|middle-end  |target
   Severity|major   |normal

[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 #34 from Oleg Endo  2012-03-20 
01:04:19 UTC ---
(In reply to comment #33)
> FYI, looking into the libstdc++ failures for sh4-unknown-linux-gnu,
> it seems that the call insn was swapped before prologue frame insns
> and then it makes unwinder confused.  -fno-delayed-branch also stops
> that swapping for these failing cases.  The patch below works for me.
> [...]

Interesting, thanks!  I'll also test your patch and send it around, OK?

I'm a bit confused... was the issue caused by my patches to for this PR, or by
something else?

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

[kkojima at gcc dot gnu.org]

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

--- Comment #35 from Kazumoto Kojima  2012-03-20 
01:45:14 UTC ---
(In reply to comment #34)
> Interesting, thanks!  I'll also test your patch and send it around, OK?

OK, thanks!

> I'm a bit confused... was the issue caused by my patches to for this PR, or by
> something else?

I guess that it was caused by another changes but was latent for a while.

[Bug testsuite/52563] FAIL: gcc.dg/tree-ssa/scev-[3,4].c scan-tree-dump-times optimized "&a" 1

[liujiangning at gcc dot gnu.org]

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

--- Comment #6 from Jiangning Liu  2012-03-20 
02:32:12 UTC ---
> We cannot fix it without relaxing the POINTER_PLUS_EXPR constraints.
> I was working on that, but as usual the TYPE_IS_SIZETYPE removal
> has priority.

Do you mean you are also working on removing TYPE_IS_SIZETYPE?

> 
> Please consider fixing/XFAILing the testcases as they still FAIL and you
> are responsible for this.  You can open a new enhancement PR covering
> this.
> 

I think 64-bit mode should also have this optimization enabled. XFAIL implies
the missing of this optimization is a correct behavior. But I think this is not
what I expected. So I don't think we should add XFAIL for this case. Instead I
want to add a new test case scev-5.c to cover 64-bit testing.

Thanks,
-Jiangning

[Bug tree-optimization/52631] New: VN does not use simplified expression for lookup

[pinskia at gcc dot gnu.org]

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

 Bug #: 52631
   Summary: VN does not use simplified expression for lookup
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org


Take:
unsigned f(unsigned a)
{
  unsigned b = a >> 31;
  return b&1;
}

--- CUT ---
Even though we have a simplified expression of a>>31 for b, VN does not use it.
SCC consists of: a_1(D)
Setting value number of a_1(D) to a_1(D)
SCC consists of: b_2
Value numbering b_2 stmt = b_2 = a_1(D) >> 31;
Setting value number of b_2 to b_2 (changed)
SCC consists of: D.1708_3
Value numbering D.1708_3 stmt = D.1708_3 = b_2 & 1;
RHS b_2 & 1 simplified to a_1(D) >> 31 has constants 1
Setting value number of D.1708_3 to D.1708_3 (changed)

This is a regression from 4.3.

[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Keywords||missed-optimization
   Last reconfirmed||2012-03-20
 AssignedTo|unassigned at gcc dot   |pinskia at gcc dot gnu.org
   |gnu.org |
 Ever Confirmed|0   |1
Summary|VN does not use simplified  |[4.6/4.7/4.8 Regression] VN
   |expression for lookup   |does not use simplified
   ||expression for lookup
   Target Milestone|--- |4.7.1

--- Comment #1 from Andrew Pinski  2012-03-20 
06:09:18 UTC ---
I am working on a fix.  Note I did not find this because a performance issue
but rather I found this while working on my gimple SSA combiner/simplifer
patches.

[Bug tree-optimization/52631] [4.6/4.7/4.8 Regression] VN does not use simplified expression for lookup

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  2012-03-20 
06:57:51 UTC ---
Created attachment 26927
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26927
Patch which fixes the problem