[Bug c++/53036] [c++11] trivial class fails std::is_trivial test

[marc.glisse at normalesup dot org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||marc.glisse at normalesup
   ||dot org

--- Comment #1 from Marc Glisse  2012-04-19 
06:28:57 UTC ---
(In reply to comment #0)
> In my understanding of the new C++ standard, the following code should 
> compile.
> It does not.
> 
>   struct D
>   {
>   D() = default;
>   D(D const &) = default;
>   template
>   constexpr D(U ...u)
>   {}
>   };
>   static_assert(std::is_trivial::value, "here");

With the declarations in this order, it seems easy to fix, in
grok_special_member_properties, only set TYPE_HAS_COMPLEX_DFLT to 1 if we
didn't already have TYPE_HAS_DEFAULT_CONSTRUCTOR (might have hidden issues, but
they are not obvious to me).

Now if you put the defaulted constructor after the user-provided variadic one,
it becomes much harder, and it looks like we'd have to remember one extra bit
of information: the reason why we set TYPE_HAS_COMPLEX_DFLT.

[Bug c++/52995] Change in the handling of templates and visibility attributes

[rafael.espindola at gmail dot com]

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

--- Comment #3 from Rafael Avila de Espindola  2012-04-19 06:00:59 UTC ---
This just got discussed on the clang list. In the end we implemented what gcc
does. The winning argument was that it is not just the class that is templated,
but its members too. If a template argument can change the visibility of a
class, it should have the same power over its members.

My suggestion is to close this bug and mark it as working as intended, but I
will leave it open for the week in case someone else wants to comment.

[Bug c/53037] warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  2012-04-19 00:33:55 
UTC ---
We need to add another field to tree_type_common and tree_decl_common to
store the warn_if_not_aligned value.

[Bug other/46770] Replace .ctors/.dtors with .init_array/.fini_array on targets supporting them

[ian at airs dot com]

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

--- Comment #94 from Ian Lance Taylor  2012-04-19 00:14:01 
UTC ---
It is misleading to think that the linker accumulates code in translation unit
order for a C++ program.  E.g., that is not what happens for template code or
string constants.  And of course the placement of functions called in different
translation units is arbitrary.

A lot of work was done in both GNU ld and gold to move constructors from .ctors
to .init_array, all to improve startup latency for firefox.  If that same
amount of work were done on better layout of initialization code, we would
improve all programs.

Gold already supports arbitrarily sophisticated section layout via plugins, and
I do not think it would be hard to add that support to GNU ld as well.

I really think that this whole approach has been chasing the wrong thing,
fixing a side effect rather than attempting to address the real problem.

In any case, on the issue at hand, changing the default order is the
conservative approach.  Firefox can use an option.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #27102|0   |1
is obsolete||
  Attachment #27183|0   |1
is obsolete||

--- Comment #12 from H.J. Lu  2012-04-19 00:12:13 
UTC ---
Created attachment 27184
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27184
A new patch

This patch adds config/sparc/sparc.opt and uses it when
config/sparc/long-double-switch.opt isn't used.

[Bug target/47197] ICE in gimplify_expr, at gimplify.c:7153 on AltiVec code (vec_dst)

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-18
 CC||jsm28 at gcc dot gnu.org,
   ||wschmidt at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from William J. Schmidt  2012-04-18 
23:52:41 UTC ---
Confirmed.  The ICE occurs when an unexpected tree code (C_MAYBE_CONST_EXPR) is
encountered during gimplification.  From what I can tell, this should have been
scrubbed out during parsing but wasn't.  The offending call to gimplify_expr ()
has the following in *expr_p:

 
unit size 
align 32 symtab 0 alias set -1 canonical type 0xfffb5d40690 precision
32 min  max 
pointer_to_this >

arg 1 
used unsigned SI file pr47197.c line 3 col 40 size  unit size 
align 32 context  arg-type
>>

The problem disappears if I change the call to __builtin_vec_dst into a normal
function call, or if I pre-compute the cond-expr rather than computing it
within the argument list.

Joseph, could you please take a look?  Or let me know if you think it's not a
front end problem.

Thanks,
Bill

[Bug rtl-optimization/50191] Strange debug insn produced for TOC compiling 416.gamess with profile-generate

[wschmidt at gcc dot gnu.org]

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

William J. Schmidt  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #21 from William J. Schmidt  
2012-04-18 23:15:48 UTC ---
Fixed some time ago.  Thanks all...

[Bug c/53037] New: warn_if_not_aligned(X)

[hjl.tools at gmail dot com]

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

 Bug #: 53037
   Summary: warn_if_not_aligned(X)
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


What I'd like to have is an __attribute__((warn_if_not_aligned(X)))
which issues a warning if the object/type/field in question is not
aligned to X.  In particular, I'd like to build with:

typedef unsigned long long __u64
   __attribute__((aligned(4),warn_if_not_aligned(8)));

... in order to get a list of the places where we have misaligned 64-bit
data pieces in x86.  Then we can do Linus' requested cleanups which
ultimately aims to getting __u64 to be __attribute__((aligned(8))) even
on i386, with an explicit __compat_u64 for the places where we need to
be misaligned for legacy reasons.

[Bug tree-optimization/37242] missed FRE opportunity because of signedness of addition

[pinskia at gcc dot gnu.org]

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

--- Comment #21 from Andrew Pinski  2012-04-18 
22:50:42 UTC ---
I have a patch.

[Bug testsuite/53028] add dg-pedantic

[mikestump at comcast dot net]

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

--- Comment #6 from Mike Stump  2012-04-18 
22:42:55 UTC ---
So, do you have a pointer to where a maintainer said that they require 3
duplicates for a piece of work?  For all similar future work?  They usually
say, please include a testcase, meaning, one testcase.  One is certainly
reasonable.  For some work, for some cases, they might want 2 or 3 testcases,
but, those I suspect should be rare to very rare.  The requirements for 3 for
that change should not be read as to be generally require 3 for all future
changes...  or, at least, that'd be my interpretation.

[Bug c++/53036] New: [c++11] trivial class fails std::is_trivial test

[eric.niebler at gmail dot com]

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

 Bug #: 53036
   Summary: [c++11] trivial class fails std::is_trivial test
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: eric.nieb...@gmail.com


In my understanding of the new C++ standard, the following code should compile.
It does not.

  struct D
  {
  D() = default;
  D(D const &) = default;
  template
  constexpr D(U ...u)
  {}
  };
  static_assert(std::is_trivial::value, "here");

The problem is the variadic constexpr constructor. I'm guessing here that the
problem is that it could also be used as a default constructor, making the type
non-trivial. However, I have explicitly defaulted the default constructor, so
the variadic constructr should never be considered for 0 arguments.

I base the above supposition on the fact that if I add a dummy argument to the
variadic as below, it works:

  struct D
  {
  D() = default;
  D(D const &) = default;
  template
  constexpr D(int, U ...u) // dummy arg, not default c'tor, ok.
  {}
  };
  static_assert(std::is_trivial::value, "here");

[Bug testsuite/53028] add dg-pedantic

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  2012-04-18 
21:47:10 UTC ---
(In reply to comment #4)
> 
> So, to recap, ripping out all but one solve the duplication problem you point
> out, it solves the duplication of creation effort you point out, it solves the
> duplication of maintaining the testsuite you point out.  It also has the added
> benefit of not wasting valuable testing time testing things that never fail.
> 

OK, now I understand your point of view. I agree to a certain extent, in the
sense that the current cost/benefit effort is not worth it. If we had already
something like dg-pedantic, the human overhead disappears, but then one could
argue that it is still not worth the extra testing time. Unfortunately, such
testcases are still required during the review process. Well, since you are
testsuite maintainer, I can try to point to this report in the future as to why
I didn't bother to add them. ;-)

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[hjl.tools at gmail dot com]

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

--- Comment #11 from H.J. Lu  2012-04-18 21:42:39 
UTC ---
One approach is to provide masks.opt to provide those masks without
switch.  masks.opt should be used when long-double-switch.opt isn't
used.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  2012-04-18 
21:17:47 UTC ---
> For a target which doesn't use long-double-switch.opt, will
> TARGET_LONG_DOUBLE_128 be a fixed value? If no, how is its
> value determined? If yes, what is the fixed value?

Yes, and it is determined by setting the mask flag MASK_LONG_DOUBLE_128 in
TARGET_DEFAULT, see e.g. sol2.h.  Harcoding any value isn't acceptable.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  2012-04-18 21:04:37 
UTC ---
(In reply to comment #8)
> > If someone can provide a description of what TARGET_LONG_DOUBLE_128
> > should be in all cases, I can try to come up with a patch.
> 
> It should be:
> 
> options.h:#define MASK_LONG_DOUBLE_128 (1 << 16)
> options.h:#define TARGET_LONG_DOUBLE_128 ((target_flags & 
> MASK_LONG_DOUBLE_128)
> != 0)
> 
> on SPARC/Solaris, but of course the (1 << 16) is dependent on other options, 
> so
> a patch that hardcodes it isn't acceptable, IOW this must be fixed in
> opth-gen.awk.

For a target which doesn't use long-double-switch.opt, will
TARGET_LONG_DOUBLE_128 be a fixed value? If no, how is its
value determined? If yes, what is the fixed value?

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[ebotcazou at gcc dot gnu.org]

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

--- Comment #8 from Eric Botcazou  2012-04-18 
20:59:16 UTC ---
> If someone can provide a description of what TARGET_LONG_DOUBLE_128
> should be in all cases, I can try to come up with a patch.

It should be:

options.h:#define MASK_LONG_DOUBLE_128 (1 << 16)
options.h:#define TARGET_LONG_DOUBLE_128 ((target_flags & MASK_LONG_DOUBLE_128)
!= 0)

on SPARC/Solaris, but of course the (1 << 16) is dependent on other options, so
a patch that hardcodes it isn't acceptable, IOW this must be fixed in
opth-gen.awk.

[Bug fortran/53035] New: Internal Compiler Error

[clerman at fuse dot net]

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

 Bug #: 53035
   Summary: Internal Compiler Error
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: cler...@fuse.net


Bugzilla fortran tech support:

  I have attached a compressed archive that should allow you to reproduce an
Internal Compiler Error. Place the file in a directory, decompress it, and
extract its entire contents. Then enter

automake
autoconf
./configure
make

  When I do this I see the following compiling the file syspars.f90:

gfortran  -I/home/norm/opcon/gfortran/focus11-bug1-4.7.1-test-dir/include -c -v
-Wall -Wextra -O3 -ffast-math -funroll-loops -std=f2003 -fno-backslash -c -o
syspars.o  syspars.f90
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7-source/gcc-4.7-20120414/configure
--enable-languages=c,c++,fortran --enable-checking=release --disable-bootstrap
--disable-libmudflap --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=/usr/bin/gold --prefix=/usr/local/gcc-4.7
Thread model: posix
gcc version 4.7.1 20120414 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-I'
'/home/norm/opcon/gfortran/focus11-bug1-4.7.1-test-dir/include' '-c' '-v'
'-Wall' '-Wextra' '-O3' '-ffast-math' '-funroll-loops' '-std=f2003'
'-fno-backslash' '-c' '-o' 'syspars.o' '-mtune=generic' '-march=x86-64'
 /usr/gcc-4.7/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/f951
syspars.f90 -I /home/norm/opcon/gfortran/focus11-bug1-4.7.1-test-dir/include
-quiet -dumpbase syspars.f90 -mtune=generic -march=x86-64 -auxbase-strip
syspars.o -O3 -Wall -Wextra -std=f2003 -version -ffast-math -funroll-loops
-fno-backslash -fintrinsic-modules-path
/usr/gcc-4.7/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.1/finclude -o
/tmp/ccL2ZOZY.s
GNU Fortran (GCC) version 4.7.1 20120414 (prerelease)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 (SUSE Linux), GMP version 4.3.2, MPFR
version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.7.1 20120414 (prerelease)
(x86_64-unknown-linux-gnu)
compiled by GNU C version 4.2.1 (SUSE Linux), GMP version 4.3.2, MPFR
version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:158
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Yours truly,

Norman S. Clerman

[Bug tree-optimization/45830] [4.5 Regression] Code+rodata increase with -ftree-switch-conversion

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||steven at gcc dot gnu.org

--- Comment #7 from Steven Bosscher  2012-04-18 
20:33:05 UTC ---
*** Bug 53034 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/53034] [4.5 Regression] tree-switch-conversion is too aggressive

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||DUPLICATE

--- Comment #3 from Steven Bosscher  2012-04-18 
20:33:03 UTC ---
Never mind me, Bugzilla didn't find this older copy of the same bug for me...

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

[Bug tree-optimization/53034] [4.5 Regression] tree-switch-conversion is too aggressive

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org
Summary|[4.5/4.6/4.7/4.8|[4.5 Regression]
   |Regression] |tree-switch-conversion is
   |tree-switch-conversion is   |too aggressive
   |too aggressive  |
  Known to fail||4.5.0

--- Comment #2 from Steven Bosscher  2012-04-18 
20:30:39 UTC ---
This was fixed in GCC 4.6 and later. Why not in GCC 4.5?

[Bug tree-optimization/53034] [4.5/4.6/4.7/4.8 Regression] tree-switch-conversion is too aggressive

[steven at gcc dot gnu.org]

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

--- Comment #1 from Steven Bosscher  2012-04-18 
20:25:45 UTC ---
The gimple switch conversion pass is much too aggressive, worse code is
generated for the examples that were used to introduce the implementation of
switch statements with bit tests.
(see http://gcc.gnu.org/ml/gcc-patches/2003-01/msg01733.html)

For example, "GCC: (GNU) 4.5.0 20091228 (experimental) [trunk revision 155486]"
applied to the first test case:

$ cat t.c
int foo(int x)
{
  switch (x)
{
case 4:
case 6:
case 9:
case 11:
  return 30;
}
  return 31;
}

$ gcc-4.5.0 -S -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c -m32
-fno-tree-switch-conversion && cat t.s
.file"t.c"
.text
.globl foo
.typefoo, @function
foo:
pushl%ebp
movl%esp, %ebp
movl8(%ebp), %ecx
cmpl$11, %ecx
ja.L4
movl$1, %edx
movl$30, %eax
sall%cl, %edx
andl$2640, %edx
jne.L2
.L4:
movl$31, %eax
.L2:
popl%ebp
ret
.sizefoo, .-foo
.ident"GCC: (GNU) 4.5.0 20091228 (experimental) [trunk revision
155486]"
.section.note.GNU-stack,"",@progbits
$ gcc-4.5.0 -S -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c -m32 && cat
t.s 
.file"t.c"
.text
.globl foo
.typefoo, @function
foo:
pushl%ebp
movl$31, %eax
movl%esp, %ebp
movl8(%ebp), %edx
subl$4, %edx
cmpl$7, %edx
ja.L2
movlCSWTCH.1(,%edx,4), %eax
.L2:
popl%ebp
ret
.sizefoo, .-foo
.section.rodata
.align 4
.typeCSWTCH.1, @object
.sizeCSWTCH.1, 32
CSWTCH.1:
.long30
.long31
.long30
.long31
.long31
.long30
.long31
.long30
.ident"GCC: (GNU) 4.5.0 20091228 (experimental) [trunk revision
155486]"
.section.note.GNU-stack,"",@progbits

Without switch conversion, there are 12 instructions including 2 forward
branches and no loads from memory and no rodata. With switch conversion there
are 10 insns including one load and one branch. So size takes a penalty, and
for throughput the load may be more expensive than the branch (for larger test
cases anyway).

$ gcc-4.5.0 -c -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c
-fno-tree-switch-conversion  -m32 && size t.o
   text   databssdechexfilename
 38  0  0 38 26t.o
$ gcc-4.5.0 -c -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c
-ftree-switch-conversion  -m32 && size t.o
   text   databssdechexfilename
 60  0  0 60 3ct.o



For the second test case:

$ cat t.c
int bar(int x)
{
  switch (x)
{
case '0':  case '1':  case '2':  case '3':  case '4':
case '5':  case '6':  case '7':  case '8':  case '9':
case 'A':  case 'B':  case 'C':  case 'D':  case 'E':
case 'F':
  return 1;
}
  return 0;
}

$ gcc-4.5.0 -c -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c
-ftree-switch-conversion  -m32 && size t.o
   text   databssdechexfilename
117  0  0117 75t.o
$ gcc-4.5.0 -c -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c
-fno-tree-switch-conversion  -m32 && size t.o
   text   databssdechexfilename
 38  0  0 38 26t.o
$ gcc-4.5.0 -c -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c
-ftree-switch-conversion  -m64 && size t.o
   text   databssdechexfilename
161  0  0161 a1t.o
$ gcc-4.5.0 -c -Os -fdump-tree-optimized -fdump-rtl-expand-slim t.c
-fno-tree-switch-conversion  -m64 && size t.o
   text   databssdechexfilename
 80  0  0 80 50t.o

Without switch conversion (-m64):

.file"t.c"
.text
.globl bar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
leal-48(%rdi), %ecx
cmpl$22, %ecx
ja.L4
movl$1, %edx
movl$1, %eax
salq%cl, %rdx
testl$8258559, %edx
jne.L2
.L4:
xorl%eax, %eax
.L2:
ret
.cfi_endproc
.LFE0:
.sizebar, .-bar
.ident"GCC: (GNU) 4.5.0 20091228 (experimental) [trunk revision
155486]"
.section.note.GNU-stack,"",@progbits


With switch conversion enabled:
.file"t.c"
.text
.globl bar
.typebar, @function
bar:
.LFB0:
.cfi_startproc
subl$48, %edi
xorl%eax, %eax
cmpl$22, %edi
ja.L2
movslq%edi, %rdi
movlCSWTCH.1(,%rdi,4), %eax
.L2:
ret
.cfi_endproc
.LFE0:
.sizebar, .-bar
.section.rodata
.align 16
.typeCSWTCH.1, @object
.sizeCSWTCH.1, 92
CSWTCH.1:
.long1
.long1
.long

[Bug tree-optimization/53034] New: [4.5/4.6/4.7/4.8 Regression] tree-switch-conversion is too aggressive

[steven at gcc dot gnu.org]

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

 Bug #: 53034
   Summary: [4.5/4.6/4.7/4.8 Regression] tree-switch-conversion is
too aggressive
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ste...@gcc.gnu.org

[Bug target/53033] [avr]: Wrong register number for 3-byte loads via X

[gjl at gcc dot gnu.org]

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

--- Comment #2 from Georg-Johann Lay  2012-04-18 
20:07:43 UTC ---
Until the issue is fixed you can use the command option -mstrict-X as a
work-around.

[Bug testsuite/53028] add dg-pedantic

[mikestump at comcast dot net]

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

--- Comment #4 from Mike Stump  2012-04-18 
20:01:23 UTC ---
You explained yourself properly.  Just because there are hundreds that do this,
doesn't mean that I necessarily agree with them.  Personally, I'd rip out all
but one of them that either test for the warning or error, it is a cost benefit
valuation.

As for what is possible in DjeaGnu, it is turing complete, so, one can put in
anything for which a turing machine can compute the answer, however, the bar is
higher than that.  The question is, is it a good idea.  To answer this, my
experience tells me, no, not really.  Now, other people's experiences differ,
and I could be swayed by their experience.  For example, please provide 10 PRs
in which we had regressions that could have been caught, but weren't, because
we didn't have such testing.  If none, then, what exactly is the benefit you
see?  For the torture options, history is littered with oodles of such bugs, in
fact, the shear numbers caused people to do the entire torture framework.  It
was put in, to try and permanently stem the tide of such bugs, so they never
happen again, or, at least to reduce in a major way, the shear numbers and to
enhance the reliability of the compiler, and hence, it's reputation. 
Experience tells me, 20-20 hind sight, that the motivation was good and the
results are worth it and that it was the right decision.  It also tells me that
removing the torture options would be a mistake and we would sink back into
where we were before if we wanted to try and remove them.

Now, a counter point.  -pedantic-errors often will not work well because of
things in system header files.  It might be reasonable to #include all the
system headers in a torture setup to ensure that C, C++, pedantic, pedantic
errors, c89, c99 and so on, all work.  The benefit, as failures are found, we
can fixinclude or engineer some sort of solution, so that the user has a nice
experience with the compiler.  I think spending time on this, it a better
cost/benefit choice.

So, to recap, ripping out all but one solve the duplication problem you point
out, it solves the duplication of creation effort you point out, it solves the
duplication of maintaining the testsuite you point out.  It also has the added
benefit of not wasting valuable testing time testing things that never fail.

The above I think is generally true, but I concede there are specific instances
where it is not.

I'll help you understand what I wrote, but I don't know what part you don't
understand.  That dejagnu is a regression suite?  What the word regression
means?  That one test is sufficient to test a pedantic message?

[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7

[gjl at gcc dot gnu.org]

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

--- Comment #9 from Georg-Johann Lay  2012-04-18 
20:00:17 UTC ---
(In reply to comment #6)
> We can see this bug on avr target too.

Thanks for the test case.

It's a bug, but completely unrelated to this one. See PR53033.

[Bug target/53033] [avr]: Wrong register number for 3-byte loads via X

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2012-04-18
 CC||mhlavink at redhat dot com
 AssignedTo|unassigned at gcc dot   |gjl at gcc dot gnu.org
   |gnu.org |
   Target Milestone|--- |4.7.1
 Ever Confirmed|0   |1

--- Comment #1 from Georg-Johann Lay  2012-04-18 
19:57:27 UTC ---
Bug is in avr.c:avr_out_load_psi

[Bug target/53033] New: [avr]: Wrong register number for 3-byte loads via X

[gjl at gcc dot gnu.org]

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

 Bug #: 53033
   Summary: [avr]: Wrong register number for 3-byte loads via X
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
Target: avr


void foo (__int24 *p)
{
void bar (__int24);
asm ("" : "+x" (p));
bar (*++p);
}

Compile with

$ avr-gcc foo.c -S -Os

and the generated code is

foo:
mov r26,r24
mov r27,r25
adiw r26,3
ld r24,X+
ld r25,X+
ld r26,X
sbiw r26,3+2
rjmp bar

The destination register of the PSI move is always R24.

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org 2012-04-18 19:38:10 UTC ---
To implement this, we'll presumably need to modify 'gfc_compare_interfaces' in
interface.c (for the case of generic_flag=1 and strict_flag=0). Possibly the
changes should go directly into 'generic_correspondence'.

[Bug fortran/45521] [F08] GENERIC resolution with ALLOCATABLE/POINTER and PROCEDURE

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||janus at gcc dot gnu.org
Summary|Fortran 2008: GENERIC   |[F08] GENERIC resolution
   |resolution with |with ALLOCATABLE/POINTER
   |ALLOCATABLE/POINTER and |and PROCEDURE
   |PROCEDURE   |

--- Comment #2 from janus at gcc dot gnu.org 2012-04-18 19:16:59 UTC ---
(In reply to comment #1)
> *** Bug 51736 has been marked as a duplicate of this bug. ***

carrying over test case:

module a
  interface testAlloc
module procedure::testAlloc1
module procedure::testAlloc2
  end interface
contains
  function testAlloc1(obj)
integer,allocatable,intent(in)::obj(:)
logical testAlloc1
testAlloc1=allocated(obj)
  end function
  function testAlloc2(obj)
integer,pointer,intent(in)::obj(:)
logical testAlloc2
testAlloc2=associated(obj)
  end function
end module

program test
  use a
  integer,pointer::a1(:)=>null()
  integer,allocatable::a2(:)
  write(*,*),testAlloc(a1),testAlloc(a2)
end program


With current trunk one gets:

module procedure::testAlloc2
1   
Error: Ambiguous interfaces 'testalloc2' and 'testalloc1' in generic interface
'testalloc' at (1)

[Bug testsuite/53028] add dg-pedantic

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez  2012-04-18 
18:25:46 UTC ---
(In reply to comment #2)
> I don't see much value in this.  The primary idea of the gcc testsuite is as a
> regression suite.  For a regression, there is just one bit of code that you're
> testing, with one set of options.

I don't understand this. Maybe I didn't explain myself properly. There are
already hundreds of testcases that are triplicated with the only difference of
not using -pedantic and testing that no warning is given, and using -pedantic
and testing for a warning and using -pedantic-errors and testing that an error
is given. Such testcases imply:

* a duplication of code, which is perhaps not very important nowadays.

* a duplication of creation effort, the developer has to create three testcases
and add the appropriate markers in all of them.

* a duplication of maintainer effort, if a testcase needs to be modified, one
has to check whether a warning/error was caused by -pedantic or not and update
the corresponding duplicated testcases.

Using dg-pedantic will solve the above issues.

This is not very different from the torture testcases that test the same code
with different optimization options or the c-c++-common testcases, but in this
case the meaning of dg-pedantic should change accordingly. Is it possible to
implement this in DejaGNU?

[Bug c++/52985] Postincrement not applied after indexing ternary array expression

[will at benfold dot com]

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

--- Comment #2 from Will Benfold  2012-04-18 18:08:16 
UTC ---
Another test case; this one doesn't need any headers and also cuts out the
loop.  The exit status should always be 1, but in fact it's 0 if no
command-line args are supplied and 1 otherwise.



struct Counter 
{
  Counter (int val = 0)
  : m_val(val)
  {}

  int operator* () const
  {
return m_val;
  }

  Counter operator++ (int)
  {
return Counter(m_val++);
  }

  int m_val;
};

int main (int argc, char *[])
{
  int a[] = {0};
  int b[] = {0};

  Counter c;

  ((argc > 1) ? a : b)[*c++];  

  return *c;
}

[Bug libitm/53008] abort in _ITM_getTMCloneSafe

[daveboutcher at gmail dot com]

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

--- Comment #1 from Dave Boutcher  2012-04-18 
17:46:17 UTC ---
The problem seems to be that functions referenced only by function pointers are
not put in the tmclone table.  I can work around the problem by making a bogus
call to the function anywhere inside a transaction.

[Bug testsuite/53028] add dg-pedantic

[mikestump at comcast dot net]

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

--- Comment #2 from Mike Stump  2012-04-18 
17:35:23 UTC ---
I don't see much value in this.  The primary idea of the gcc testsuite is as a
regression suite.  For a regression, there is just one bit of code that you're
testing, with one set of options.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  2012-04-18 17:32:38 
UTC ---
If someone can provide a description of what TARGET_LONG_DOUBLE_128
should be in all cases, I can try to come up with a patch.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[ebotcazou at gcc dot gnu.org]

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

--- Comment #6 from Eric Botcazou  2012-04-18 
17:23:24 UTC ---
> I've combined HJ's two patches to one and verified that it restores bootstrap
> on sparc64-linux.

But it probably breaks SPARC/Solaris, as TARGET_LONG_DOUBLE_128 must be
non-zero for this target.  MASK_LONG_DOUBLE_128 and TARGET_LONG_DOUBLE_128 must
always be defined to meaningful values, irrespective of whether
long-double-switch.opt is included; that's why sparc.opt also contains the
entry.

If the original patch breaks this mechanism, it should IMO provide a general
replacement, as other architectures might be affected.

[Bug c++/33925] gcc -Waddress lost some useful warnings

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-04-18 
17:04:25 UTC ---
... That's not an argument against improving the warning though.  GCC's uses
occur in system headers so warnings are suppressed, and could be worked around
anyway with further extensions such as #pragma GCC diagnostic

[Bug c++/33925] gcc -Waddress lost some useful warnings

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  2012-04-18 
17:01:23 UTC ---
(In reply to comment #3)
> First, I think the C++ standard forbids a function from having a null 
> address:

But GCC extensions allow it, see the weakref attribute:

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#index-g_t_0040code_007bweakref_007d-attribute-2648

That's used (among other places) by GCC's pthreads abstraction layer to declare
a weak alias to pthread_create, which has a null address unless libpthread is
linked to.  Testing whether the address is null (i.. whether the application
was linked to libpthread) is used for important optimisations.

[Bug c++/33715] Suggest -Wmemleak warning for C++

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  2012-04-18 
16:53:37 UTC ---
(In reply to comment #0)
> I would like to have a warning in C++ that warns about local variables 
> assigned
> via operator new or operator new[], but then are not freed in an exception
> handling clause in case of an exception.

Simple solution: don't do that. Ever.

Then you don't need a compiler warning.

If you insist on writing such code the cppcheck tool can issue the sort of
warning you want (but it gives lots of false positives too).

[Bug target/42689] bad formatting of specs diagnostics

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-18
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  2012-04-18 
16:45:14 UTC ---
So confirmed.

[Bug middle-end/44600] warnings about possibly uninitialized locals

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||WONTFIX

--- Comment #2 from Manuel López-Ibáñez  2012-04-18 
16:46:08 UTC ---
Closing then:

http://gcc.gnu.org/wiki/FAQ#stage1warnings

[Bug c/34455] Request warning for casts to _Bool

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-18
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  2012-04-18 
16:42:46 UTC ---
To be honest, I am not sure whether this is really useful or not for other
people. And I am not sure whether it is actually possible.

What I am sure is that there is nobody except you interested in implementing
it, so if you want to get it done, you will have to work on it (or pay someone
to do it).

Meanwhile, I am putting this in WAITING, so it doesn't show up as pending
confirmation.

[Bug bootstrap/52878] [4.8 regression] bootstrap failure: "MASK_LONG_DOUBLE_128" redefined

[mikpe at it dot uu.se]

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

--- Comment #5 from Mikael Pettersson  2012-04-18 
16:38:18 UTC ---
Created attachment 27183
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27183
combined patch

I've combined HJ's two patches to one and verified that it restores bootstrap
on sparc64-linux.

[Bug middle-end/39731] Separate warning classes for maybe-uninitialized and known-uninitialized variables.

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||FIXED

--- Comment #3 from Manuel López-Ibáñez  2012-04-18 
16:35:23 UTC ---
Fixed at least since GCC 4.7.0:

http://gcc.gnu.org/onlinedocs/gcc-4.7.0/gcc/Warning-Options.html#Warning-Options

See -Wmaybe-uninitialized.

[Bug c++/33925] gcc -Waddress lost some useful warnings

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Target|i686-pc-linux-gnu   |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-18
   Host|i686-pc-linux-gnu   |
 Ever Confirmed|0   |1
  Build|i686-pc-linux-gnu   |

--- Comment #4 from Manuel López-Ibáñez  2012-04-18 
16:32:46 UTC ---
OK, but I don't think anyone is going to step up soon to implement this, so
feel free to give it a try yourself.

[Bug c++/33715] Suggest -Wmemleak warning for C++

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-18
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #2 from Manuel López-Ibáñez  2012-04-18 
16:30:59 UTC ---
I don't even know if we would ever want this. And since nobody seems to care, I
am putting it in WAITING until someone that cares enough steps up.

[Bug middle-end/33443] Compiler warnings in gcc sources

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||INVALID

--- Comment #4 from Manuel López-Ibáñez  2012-04-18 
16:28:56 UTC ---
Warnings that don't break bootstrap are irrelevant:

http://gcc.gnu.org/wiki/FAQ#stage1warnings

(I am not sure why stage1 does not build with -w).

[Bug c/32960] no warning for conflicting attributes on separate decls

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-18
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  2012-04-18 
16:25:26 UTC ---
So confirmed.

[Bug c/29467] -ansi -pedantic accepts _Bool without diagnostic

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2012-04-18
 CC||manu at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #3 from Manuel López-Ibáñez  2012-04-18 
16:23:10 UTC ---
So? Is this a bug or not?

[Bug tree-optimization/43833] false warning: array subscript is above array bounds with -O3

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||FIXED

--- Comment #5 from Manuel López-Ibáñez  2012-04-18 
16:21:36 UTC ---
Seems fixed. Closing.

[Bug fortran/53015] free_pi_tree(): Unresolved fixup is back

[brainschrat at gmx dot de]

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

--- Comment #3 from brainschrat at gmx dot de 2012-04-18 15:22:01 UTC ---
Maybe this is related to using both -I and -J to the same directory.

As I wanted to use delta, I tried to simplify my folder layout for the test
case:

project
 - src
 - lib
 - testsuite
o test_1
o test_2 etc

Usually, make is called in project, compiles .f90 files in src and puts all
.mod and .o files there as well via -J switch. The bug happens if I compile
file B in test_2, but points to file A in src (or rather, A.mod).

When I put all files in test_2 for using delta, the bug disappeared. After some
tinkering I found out that putting the .mod files anywhere else than src (via
-J) works. There is both a -I and a -J to src, directly after one another.

If I -I and -J point to the same directory, I get the free pi_tree stuff.
Removing the -I (as it is not needed for this purpose) solves the problem. The
module files produced by the two different calls have the same number of lines,
the same size but the ordering in the file.

Should the generation of the module files be deterministic? Are there any known
problems with -I an d -J? (I could not find anything in bugzilla.)

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo.carlini at oracle dot |
   |com |
 AssignedTo|unassigned at gcc dot   |paolo.carlini at oracle dot
   |gnu.org |com

--- Comment #11 from Paolo Carlini  2012-04-18 
15:20:57 UTC ---
Good. Then, let's see if my idea of tweaking joust to know about sfinae works.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[jason at gcc dot gnu.org]

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

--- Comment #10 from Jason Merrill  2012-04-18 
15:14:58 UTC ---
std::is_assignable uses SFINAE, so it should always act pedantic, and the
assert should fail.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

--- Comment #9 from Paolo Carlini  2012-04-18 
14:59:02 UTC ---
Ah, thanks Daniel. Therefore the situation is becoming more clear.

Then - assuming this interpretation is correct - I'm not sure what we want to
do from a practical point of view: should we arrange the front-end to always
have the static_assertion triggered (thus, even without -pedantic) or we really
want that only when -pedantic is passed? I'm not clear whether the user may
like to see the value is std::is_assignable changing depending on -pedantic?!?
I never pondered that possibility in the past.

I guess Jason should give a direction, here.

[Bug c++/53032] New: [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to build

[hjl.tools at gmail dot com]

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

 Bug #: 53032
   Summary: [4.8 Regression] 447.dealII in SPEC CPU 2006 failed to
build
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 186566 gave

g++ -c -o mg_dof_tools.o -DSPEC_CPU -DNDEBUG  -Iinclude -DBOOST_DISABLE_THREADS
-Ddeal_II_dimension=3 -O3 -funroll-loops -ffast-math-DSPEC_CPU_LP64  
mg_dof_tools.cc
...
mg_dof_tools.cc: In static member function 'static void
MGTools::count_dofs_per_component(const MGDoFHandler&,
std::vector >&, std::vector) [with int
dim = 3]':
mg_dof_tools.cc:299:1: internal compiler error: Segmentation fault
 MGTools::count_dofs_per_component (
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Revision 186516 is OK.

[Bug middle-end/53031] New: [4.8 Regression] gcc.dg/tree-ssa/vrp54.c scan-tree-dump-not vrp1 "link_error"

[hjl.tools at gmail dot com]

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

 Bug #: 53031
   Summary: [4.8 Regression] gcc.dg/tree-ssa/vrp54.c
scan-tree-dump-not vrp1 "link_error"
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com
CC: areg.melikadam...@gmail.com


On Linux/x86-64, revision 186563 gave

FAIL: gcc.dg/tree-ssa/vrp54.c scan-tree-dump-not vrp1 "link_error"

Revision 186559 is OK.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[daniel.kruegler at googlemail dot com]

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

--- Comment #8 from Daniel Krügler  
2012-04-18 14:41:38 UTC ---
(In reply to comment #7)
> Daniel, can you have a look to snippet in Comment #5? Should it compile or 
> not?

It needed a while until I recognized that the second operator= overload is a
const function: With this fact my *tentative* interpretation is that the static
assertion should fire, because we have a non-const proxy rvalue and a non-const
int rvalue. The non-const proxy argument has a better match with the non-const
object parameter of the first function, but the int rvalue has a better match
with the int&& argument of the second function. The corresponding C++03 problem
would be described by

struct proxy
{
  void operator=(int const&);
  void operator=(int &) const;
};

template
T& create();

int v = sizeof(create() = create(), 0);

and is ambiguous as well. The alternative fix (instead of removing the const
from the function) is to *add* a const to left hand type (i.e. use "const
proxy" instead).

[Bug bootstrap/53030] New: [4.8 Regression] LTO bootstrap failed with bootstrap-profiled

[hjl.tools at gmail dot com]

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

 Bug #: 53030
   Summary: [4.8 Regression] LTO bootstrap failed with
bootstrap-profiled
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: hjl.to...@gmail.com


On Linux/x86-64, revision 186564 LTO bootstrap
failed with bootstrap-profiled:

../../src-trunk/gcc/config/i386/i386.c: In function 'void
ix86_option_override_internal(bool)':
../../src-trunk/gcc/config/i386/i386.c:3962:31: error: 'mask' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
recip_mask_explicit |= mask;
   ^
Revision 186559 is OK.

[Bug target/53016] memcpy optimization can cause unaligned access on ARM

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #8 from Richard Earnshaw  2012-04-18 
14:23:04 UTC ---
Casts do not change the fact that the pointer initialized in statement I
highlighted creates undefined behaviour.  The fact that you are using memcpy is
a red herring.

>From c99:

6.3.2.3 Pointers

7) A pointer to an object or incomplete type may be converted to a pointer to a
different object or incomplete type. If the resulting pointer is not correctly
aligned for the pointed-to type, the behavior is undefined. ...

[Bug libstdc++/52681] [C++11] Using std::thread without -pthread crashes without warning

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  2012-04-18 
14:16:20 UTC ---
Entirely feasible, and probably safe enough for the 4.6 and 4.7 branches too.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini  2012-04-18 
14:24:47 UTC ---
Ah, thanks Jon, that may indeed explain it!

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #22 from Paolo Carlini  2012-04-18 
14:14:37 UTC ---
To be clear: for some reason, on my Linux machine, I badly need
-static-libstdc++, what suggested by Jon in Comment #17 doesn't change much. If
code compiles and links then runs fine. So, assuming we are able to handle the
link-time issues ;) things seem in pretty good shape.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #19 from Paolo Carlini  2012-04-18 
13:10:59 UTC ---
At the moment I'm using an x86_64-linux machine using glibc 2.14.1, not a RH,
really no problem with this specific testcase, no Seg fault, no valgrind
errors, with 4.7.1 too.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-04-18 
13:29:10 UTC ---
Oh, and isn't really a run-time issue:

#include 

struct proxy
{
  void operator=(int const&);
  void operator=(int &&) const;
};

static_assert( std::is_assignable::value, "" );

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  2012-04-18 
14:02:37 UTC ---
(In reply to comment #20)
> now it worked for Paolo without it :-(

Some distros rebuild libpthread.a to make it work automatically.

http://lists.opensuse.org/opensuse-bugs/2010-07/msg02319.html

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||daniel.kruegler at
   ||googlemail dot com

--- Comment #7 from Paolo Carlini  2012-04-18 
14:08:45 UTC ---
Daniel, can you have a look to snippet in Comment #5? Should it compile or not?

Because, if it should not, then it seems we should simply arrange for joust to
know about sfinae-mode and in that case behave as-if pedantic were always set.
Would be doable, I think.  On the other hand, if it should compile, things
seems a bit more fuzzy to me, it's as if the behavior due to the piece of code
at the end of joust is what we really want, even in -pedantic mode?!?

[Bug libstdc++/52681] [C++11] Using std::thread without -pthread crashes without warning

[mkline at cs dot wisc.edu]

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

--- Comment #5 from Matt Kline  2012-04-18 14:04:37 
UTC ---
That, if feasible, would be perfect.

[Bug c/36446] unexplained warning in struct initialization

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||darren at kulp dot ch
 CC||yar at bsd dot chem.msu.ru

--- Comment #5 from Manuel López-Ibáñez  2012-04-18 
13:23:53 UTC ---
*** Bug 47772 has been marked as a duplicate of this bug. ***

--- Comment #6 from Manuel López-Ibáñez  2012-04-18 
13:25:13 UTC ---
*** Bug 30006 has been marked as a duplicate of this bug. ***

[Bug c/30006] Compound literal in structure initializer causes missing initializer warning to happen

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||DUPLICATE
  Known to fail|4.2.0   |

--- Comment #4 from Manuel López-Ibáñez  2012-04-18 
13:25:03 UTC ---
See comments in PR36446.

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

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #6 from Paolo Carlini  2012-04-18 
13:56:23 UTC ---
This block of code in joust changes the behavior without -pedantic:

Index: call.c
===
--- call.c  (revision 186565)
+++ call.c  (working copy)
@@ -8305,7 +8305,7 @@ tweak:

   /* Extension: If the worst conversion for one candidate is worse than the
  worst conversion for the other, take the first.  */
-  if (!pedantic)
+  if (0 && !pedantic)
 {
   conversion_rank rank1 = cr_identity, rank2 = cr_identity;
   struct z_candidate *w = 0, *l = 0;

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[chrbr at gcc dot gnu.org]

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

--- Comment #20 from chrbr at gcc dot gnu.org 2012-04-18 13:32:31 UTC ---
(In reply to comment #17)
> does it help if you link to libpthread using --whole-archive ?
> 
> g++ deallocate_global_thread-1.cc -static  -Wl,--whole-archive -lpthread
> -Wl,--no-whole-archive -lrt

yes it works ! without whole-archive:

nm a.out | grep pthread_key_delete
w pthread_key_delete

with whole-archive:
004064a0 T pthread_key_delete

now it worked for Paolo without it :-(

So final conclusion is that there seems to have no problem with
deallocate_global_thread-1.cc 

thanks !

[Bug c/36446] unexplained warning in struct initialization

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||darren at kulp dot ch
 CC||yar at bsd dot chem.msu.ru

--- Comment #5 from Manuel López-Ibáñez  2012-04-18 
13:23:53 UTC ---
*** Bug 47772 has been marked as a duplicate of this bug. ***

--- Comment #6 from Manuel López-Ibáñez  2012-04-18 
13:25:13 UTC ---
*** Bug 30006 has been marked as a duplicate of this bug. ***

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely  2012-04-18 
12:57:15 UTC ---
(In reply to comment #16)
> by the way, (not the bug), I'm wondering if there is another way than
> using pthread_key_create to hold the thread's freelist ? like using TLS in the
> mt_allocator ?

Probably, but TLS isn't supported everywhere so it might need to be a separate
tls_allocator that's only conditionally available.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

--- Comment #4 from Paolo Carlini  2012-04-18 
13:01:37 UTC ---
And this is enough to see the inconsistency vs -pedantic:

#include 
#include 

struct proxy
{
  void operator=(int const&);
  void operator=(int &&) const;
};

int main()
{
  assert( (std::is_assignable::value) );
}

[Bug c/36446] unexplained warning in struct initialization

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2012-04-18
   Host|i386-redhat-linux   |
 Ever Confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  2012-04-18 
13:19:49 UTC ---
manuel@gcc12:~$ ~/trunk/186353/build/gcc/cc1 -Wextra pr36446.c
pr36446.c:13:3: warning: missing initializer [-Wmissing-field-initializers]
   .c = 2,
   ^
pr36446.c:13:3: warning: (near initialization for ‘m1.h.b’)
[-Wmissing-field-initializers]
   .c = 2,
   ^

Apart from the warnings, there are several things wrong with this:

* The second message should use inform() and check the output of warning().

* The first message should say "missing initializer for field '.h.b'", and the
second should say "'struct h' defined here".

For comparison, this is what Clang prints when the warning is valid:

pr36446.c:12:10: warning: missing field 'b' initializer
[-Wmissing-field-initializers]
  .h = {1},
 ^
1 warning generated.


I don't think this bug is hard to fix, but unfortunately, I don't have time to
work on them. So if anyone here can help, this may get fixed for GCC 4.8. 

The first step is to launch gdb, find where the warning text is given, and put
a breakpoint at the call to warning(). Then figure out why the conditions for
warning are satisfied. Even if you cannot code a patch, this information would
be useful.

[Bug c/47772] warnings from -Wmissing-field-initializers contradict documentation

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution||DUPLICATE

--- Comment #4 from Manuel López-Ibáñez  2012-04-18 
13:23:42 UTC ---
Duplicated. See my comments in PR36446.

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

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[redi at gcc dot gnu.org]

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

--- Comment #17 from Jonathan Wakely  2012-04-18 
12:43:00 UTC ---
does it help if you link to libpthread using --whole-archive ?

g++ deallocate_global_thread-1.cc -static  -Wl,--whole-archive -lpthread
-Wl,--no-whole-archive -lrt

[Bug middle-end/52693] Wrong code with SRA and arrays

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED

--- Comment #13 from Martin Jambor  2012-04-18 
13:13:44 UTC ---
Damn it, I said fixed.

[Bug libfortran/51646] Make libgfortran compile on Android

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #7 from Tobias Burnus  2012-04-18 
12:54:20 UTC ---
Given that the problem of comment 0 is fixed and comment 5 is also not a bug -
especially not a libgfortran bug, I close now the PR as FIXED.

Regarding comment 0: The current blog does no longer list any libgfortran
patches, cf.
http://specificimpulses.blogspot.de/2011/10/android-fortran-step-by-step-part-2.html

Regarding comment 5: See comment 6.

[Bug c/47772] warnings from -Wmissing-field-initializers contradict documentation

[vadmium+gc at gmail dot com]

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

Marty  changed:

   What|Removed |Added

 CC||vadmium+gc at gmail dot com

--- Comment #3 from Marty  2012-04-18 12:30:44 UTC 
---
Possibly related: Bug 36446, Bug 47772

[Bug c/36446] unexplained warning in struct initialization

[vadmium+gc at gmail dot com]

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

Marty  changed:

   What|Removed |Added

 CC||vadmium+gc at gmail dot com

--- Comment #3 from Marty  2012-04-18 12:26:38 UTC 
---
Possibly related: Bug 30006, Bug 47772

[Bug fortran/53029] New: missed optimization in internal read (without implied-do-loop)

[manfred99 at gmx dot ch]

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

 Bug #: 53029
   Summary: missed optimization in internal read (without
implied-do-loop)
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: manfre...@gmx.ch


Followup to Bug 32382.

!234567C234567
  program internalread
  implicit none
  integer m
  parameter(m=100)
  character value*10
  integer i,j,intvalues(m)

  DO j=1,100
write(value,'(i3,a5)') j," 5 69"
write(*,*) value
!!read(value,*,end=20) (intvalues(i),i=1,m)  ! this is BUG 32382
read(value,*,end=20) intvalues
   20   write(*,*) j,(intvalues(i),i=1,4)
  ENDDO
  end program internalread

This version needs 2.7s on my box, the commented version
needs 0.27s (BUG 32382).

The array version is about 10x slower than the implied do loop variant.

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  2012-04-18 
12:52:04 UTC ---
Interestingly, removing the const from the move assignment avoids the issue
with -pedantic.

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[wschmidt at gcc dot gnu.org]

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

--- Comment #17 from William J. Schmidt  
2012-04-18 12:29:39 UTC ---
Author: wschmidt
Date: Wed Apr 18 12:29:23 2012
New Revision: 186568

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186568
Log:
gcc:

2012-04-18  Bill Schmidt  

PR tree-optimization/52976
* tree-ssa-reassoc.c (add_to_ops_vec_max_rank): Delete.
(possibly_move_powi): New function.
(rewrite_expr_tree): Call possibly_move_powi.
(rewrite_expr_tree_parallel): Likewise.
(attempt_builtin_powi): Change call of add_to_ops_vec_max_rank to
call add_to_ops_vec instead.


gcc/testsuite:

2012-04-18  Bill Schmidt  

PR tree-optimization/52976
gfortran.dg/reassoc_11.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/reassoc_11.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug target/52415] memcpy to local variable generates unnecessary stack frame for armv7

[mhlavink at redhat dot com]

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

--- Comment #8 from Michal Hlavinka  2012-04-18 
12:22:34 UTC ---
Created attachment 27182
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27182
pre-processed reproducer (avr)

(In reply to comment #7)
> Would you please post a complete test case to reproduce?
> See http://gcc.gnu.org/bugs/#need

$ avr-gcc --version
avr-gcc (Fedora 4.7-0.fc17.1.20120302) 4.7.1 20120414 (prerelease)
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.

(ignore old date in package name)

$ uname -ra
Linux nbone.mihlnet 3.3.0-8.fc16.x86_64 #1 SMP Thu Mar 29 18:37:19 UTC 2012
x86_64 x86_64 x86_64 GNU/Linux

command for compilation:
avr-g++ -mmcu=atmega2560  -gdwarf-2 -DF_CPU=1600UL -O1 -Wall
-Wno-unused-variable -fno-inline-small-functions -fwhole-program testitb.cpp
--output test0.S  -S

In reproducer there are 3 options for structure swapping. First two reproduce
the problem. The last one works. This problem does not exist in avr-gcc 4.6.2

Original code:
DirEnttmp = eeFs.files[i_fileId1];
eeFs.files[i_fileId1] = eeFs.files[i_fileId2];
eeFs.files[i_fileId2] = tmp;
s_sync_write = true;
EeFsFlushDirEnt(i_fileId1);
EeFsFlushDirEnt(i_fileId2);

What happens:
it copies structures and then it calls EeFsFlushDirEnt but with corrupted
values.
.L__stack_usage = 4
mov r28,r22
.LBB2:
.loc 1 50 0
mov r18,r24
ldi r19,0
movw r26,r18
lsl r26
rol r27
add r26,r18
adc r27,r19
subi r26,lo8(-(eeFs))
sbci r27,hi8(-(eeFs))
adiw r26,4
ld r24,X+
ld r25,X+
ld r26,X
sbiw r26,4+2
.LVL2:
.loc 1 51 0
mov r30,r22
ldi r31,0
movw r12,r30
lsl r12
rol r13
add r30,r12
adc r31,r13
subi r30,lo8(-(eeFs))
sbci r31,hi8(-(eeFs))
ldd r12,Z+4
ldd r13,Z+5
ldd r14,Z+6
adiw r26,4
st X+,r12
st X+,r13
st X,r14
.loc 1 52 0
std Z+4,r18
std Z+5,r19
std Z+6,r20
.LVL3:
.loc 1 60 0
call _ZL15EeFsFlushDirEnth
.LVL4:
.loc 1 61 0
mov r24,r28
call _ZL15EeFsFlushDirEnth

First call is made with r24 that got overwritten during structure copy.
In the third structure copy code (the working one) r24 is not changed.

I'm not too good in assembler interpretation, so this is what it seems to me is
happening, but I can be wrong and there can be different problem than r24.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[chrbr at gcc dot gnu.org]

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

--- Comment #16 from chrbr at gcc dot gnu.org 2012-04-18 12:37:47 UTC ---
(In reply to comment #14)
> But anyway -static-libstdc++ works on Linux too to avoid the link-time 
> problem.
> Still (on x86_64-linux) the testcase runs Ok for me.

Interesting, it segfaults for me on a RH-5.4while calling __gthread_key_delete.

I thought that gthread_key_delete would be mapped to pthread_key_delete from
the gthr-posix but it is not, because_GLIBCXX_GTHREAD_USE_WEAK is defined.
which seems to be the problem.

(I configured with --enable-threads=posix with the glibc). But I was using the
system's glibc. I'll try to recompile my own.

by the way, (not the bug), I'm wondering if there is another way than
using pthread_key_create to hold the thread's freelist ? like using TLS in the
mt_allocator ?

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[iains at gcc dot gnu.org]

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

--- Comment #15 from Iain Sandoe  2012-04-18 12:31:06 
UTC ---
(In reply to comment #14)
> But anyway -static-libstdc++ works on Linux too to avoid the link-time 
> problem.
> Still (on x86_64-linux) the testcase runs Ok for me.

OK. 
Just for the record - in case anyone is trying permutations;

libc, libm,  libpthread etc. are combined into libSystem.dylib on Darwin -
which is always required to be a dynamic link for User space code.

The compiler target libraries (less the NeXT objc one) can be linked statically
- including libgomp (since pthreads are always available via libSystem),

so static-lib{stdcc++, fortran, gcc} will work (barring other errors).

Note, however, that using -static-libgcc will *only* work so long as you don't
want to use any library [other than libSystem] or framework from /usr/lib or
/System or /Library that uses the unwinder.

Also, there is another (so far unhandled) bug with unwind generated by gcc >
4.5 - if you want to test code 'by hand' you should do
DYLD_LIBRARY_PATH=/path/to/gcc/build/dir  executable.

Sorry, it's on my TODO - but only applies to Darwin 9 (Darwin >= 10 is OK, so
far).

[Bug libfortran/51646] Make libgfortran compile on Android

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #6 from Tobias Burnus  2012-04-18 
12:36:18 UTC ---
(In reply to comment #5)
> Another build problem at
> http://stackoverflow.com/questions/10202966/android-ndk-fortran-build-of-lapack-problems-with-unresolved-sincos

Judging from the line given at the stackoverflow posting, the problem is
related to:
  COMPLEX_ASSIGN (v, cosf (b), sinf (b));

Thus, the middle-end should convert this into a sincosf - but only if it is
available. Given that the compilation is for arm-linux-androideabi, I assume
that gcc/config/linux.h applies, which has:

/* Whether we have sincos that follows the GNU extension.  */
#undef TARGET_HAS_SINCOS
#define TARGET_HAS_SINCOS (OPTION_GLIBC || OPTION_BIONIC)

For Android/Bionic, one finds:
   /bionic/libc/docs/CHANGES.TXT
   ...
   Differences between Android 2.3 and Android 2.2:
   ...
   - : Added sincos(), sincosf() and sincosl() (GLibc compatibility).

Cf. http://source-android.frandroid.com/bionic/libc/docs/CHANGES.TXT


Hence, there are two options:
a) Using a newer Bionic
b) Manually patch gcc/config/linux.h to simply claim that no sincos is
available.

The latter is what is also suggested at
https://bugs.launchpad.net/linaro-android/+bug/908125

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[wschmidt at gcc dot gnu.org]

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

--- Comment #16 from William J. Schmidt  
2012-04-18 12:25:30 UTC ---
Author: wschmidt
Date: Wed Apr 18 12:25:17 2012
New Revision: 186567

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186567
Log:
gcc:

2012-04-18  Bill Schmidt  

PR tree-optimization/52976
* tree-ssa-reassoc.c (stmt_is_power_of_op): New function.
(decrement_power): Likewise.
(propagate_op_to_single_use): Likewise.
(zero_one_operation): Handle __builtin_pow* calls in linearized
expression trees; factor logic into propagate_op_to_single_use.
(undistribute_ops_list): Allow operands with repeat counts > 1.


gcc/testsuite:

2012-04-18  Bill Schmidt  

PR tree-optimization/52976
gfortran.dg/reassoc_7.f: New test.
gfortran.dg/reassoc_8.f: Likewise.
gfortran.dg/reassoc_9.f: Likewise.
gfortran.dg/reassoc_10.f: Likewise.

Added:
trunk/gcc/testsuite/gfortran.dg/reassoc_10.f
trunk/gcc/testsuite/gfortran.dg/reassoc_7.f
trunk/gcc/testsuite/gfortran.dg/reassoc_8.f
trunk/gcc/testsuite/gfortran.dg/reassoc_9.f
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #13 from Paolo Carlini  2012-04-18 
12:15:56 UTC ---
I'm on Linux (I'm always on Linux by default)

[Bug c/30006] Compound literal in structure initializer causes missing initializer warning to happen

[vadmium+gc at gmail dot com]

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

Marty  changed:

   What|Removed |Added

 CC||vadmium+gc at gmail dot com

--- Comment #3 from Marty  2012-04-18 12:22:48 UTC 
---
Possibly related: Bug 36446, Bug 47772

Here’s an example where the warning is completely false. There are no missing
initialisers because I’ve listed them both.

struct {
struct {
int first;
int second;
} inner;
} outer = {
.inner.first = 1,
/* Warning -> */ .inner.second = 2,
};

With the -Wextra flag, GCC 4.7.0 produced:

bug.c:8:22: warning: missing initializer [-Wmissing-field-initializers]
bug.c:8:22: warning: (near initialization for ‘outer.inner.second’)
[-Wmissing-field-initializers]

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #14 from Paolo Carlini  2012-04-18 
12:19:04 UTC ---
But anyway -static-libstdc++ works on Linux too to avoid the link-time problem.
Still (on x86_64-linux) the testcase runs Ok for me.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe  2012-04-18 12:08:55 
UTC ---
(In reply to comment #11)
> Of course I meant it doesn't *link*. I guess I have never noticed this error
> before:
> 
> /usr/bin/ld: cannot find -lm
> /usr/bin/ld: cannot find -lpthread
> /usr/bin/ld: cannot find -lc

darwin does not support -static for user space code.
-static-libstdc++ should work.

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

--- Comment #11 from Paolo Carlini  2012-04-18 
12:01:27 UTC ---
Of course I meant it doesn't *link*. I guess I have never noticed this error
before:

/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc

[Bug libstdc++/47762] FAIL: ext/mt_allocator/deallocate_global_thread-1.cc execution test

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jwakely.gcc at gmail dot
   ||com

--- Comment #10 from Paolo Carlini  2012-04-18 
11:54:27 UTC ---
You mean that with -static it doesn't even compile?!? It seems weird indeed,
let's add Jon in CC, maybe there is a simple explanation for that.

Otherwise, without -static the testcase seems pretty benign...

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther  2012-04-18 
11:34:01 UTC ---
Author: rguenth
Date: Wed Apr 18 11:33:51 2012
New Revision: 186566

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186566
Log:
2012-04-18  Richard Guenther  

PR tree-optimization/44688
* cfgloop.h (record_niter_bound): Declare.
* tree-ssa-loop-niter.c (record_niter_bound): Export.
Update the estimation with the upper bound here...
(estimate_numbers_of_iterations_loop): ... instead of here.
Do not forcefully reset a recorded upper bound.
* tree-vect-loop-manip.c (vect_do_peeling_for_alignment):
Record the maximum number of loop iterations of the
prologue loop.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.h
trunk/gcc/tree-ssa-loop-niter.c
trunk/gcc/tree-vect-loop-manip.c

[Bug c++/52363] Presence/absence of -pedantic compilation affects run-time behavior

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Paolo Carlini  2012-04-18 
11:03:18 UTC ---
Jason, this is the -pedantic issue I was referring too.

[Bug tree-optimization/52976] [4.8 Regression] Revision 186384 breaks the polyhedron tests aermod.f90 and doduc.f90 at -O3 -ffast-math

[rguenth at gcc dot gnu.org]

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

Richard Guenther  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #15 from Richard Guenther  2012-04-18 
10:22:37 UTC ---
*** Bug 53022 has been marked as a duplicate of this bug. ***

[Bug c++/50478] [C++0x] Internal compiler error when using initializer lists

[paolo.carlini at oracle dot com]

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

--- Comment #5 from Paolo Carlini  2012-04-18 
10:35:59 UTC ---
Seems fixed in mainline.

[Bug c++/52108] declval() with incomplete type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #3 from Jonathan Wakely  2012-04-18 
10:22:33 UTC ---
I agree with Richard's analysis, I hadn't thought of operator,

[Bug c++/52422] [C++11][SFINAE] Hard errors with void or arithmetic expressions

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED
  Alias|jason at gcc dot gnu.org|

--- Comment #4 from Paolo Carlini  2012-04-18 
10:23:56 UTC ---
Fixed for 4.8.0.