[Bug fortran/58355] [4.7/4.8/4.9 Regression] [F03] ICE with TYPE, EXTENDS before parent TYPE defined

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Sep 23 07:40:39 2013
New Revision: 202823

URL: http://gcc.gnu.org/viewcvs?rev=202823&root=gcc&view=rev
Log:
2013-09-23  Janus Weil  

PR fortran/58355
* decl.c (check_extended_derived_type): Prevent segfault, modify error
message.

2013-09-23  Janus Weil  

PR fortran/58355
* gfortran.dg/extends_15.f90: New.

Added:
trunk/gcc/testsuite/gfortran.dg/extends_15.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/58355] [4.7/4.8/4.9 Regression] [F03] ICE with TYPE, EXTENDS before parent TYPE defined

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
Fixed on trunk with r202823. Backports pending ...

[Bug target/58442] bootstrapping vax crashes on NetBSD

[martin at netbsd dot org]

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

--- Comment #5 from Martin Husemann  ---
Just as a sanity check: I verified that the natively generated insn-recog.c is
the same as one cross compiled on an amd64 host.

[Bug c++/58506] New: gcc -E -C gives error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for "pthread_create' instead. */" does not give a valid preprocessi

[gcc-bug at sogetthis dot com]

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

Bug ID: 58506
   Summary: gcc -E -C gives error: pasting "__gthrw_" and "/*
Android's C library does not provide pthread_cancel,
check for"pthread_create' instead. */" does not
give a valid preprocessing token
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bug at sogetthis dot com
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

Running with gcc -E -C gives the following

In file included from
/usr/include/c++/4.6/x86_64-linux-gnu/32/bits/gthr.h:170:0,
 from /usr/include/c++/4.6/ext/atomicity.h:34,
 from /usr/include/c++/4.6/bits/basic_string.h:41,
 from /usr/include/c++/4.6/string:54,
 from
/opt/buildagent/workspace/p4testtics/code/Framework/Common/Logging/Interface/TTLog.h:9,
 from
/opt/buildagent/workspace/p4testtics/code/Framework/Common/Container/Implementation/AllocatorArray.cpp:1:
/usr/include/c++/4.6/x86_64-linux-gnu/32/bits/gthr-default.h:251:1: error:
pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel,
check for
   "pthread_create' instead. */" does not give a valid preprocessing token


Running without the -C flag (gcc -E) works fine.

The macro invocation can be found in
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a00892_source.html lines
243-251 and the macro definition in
http://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a00892_source.html line
75.


I have reproduced the problem with gcc 4.3.2 on another (GNU/Linux x86_64)
machine (see attached data). This contains some context (uname -a, gcc -v), a
self-contained source file (invalidpastetoken.c) and the resuls of 'gcc -E -C
invalidpastetoken.c' and 'gcc -E invalidpastetoken.c'.

The correct result gives the token

  __gthrw_pthread_cancel;

The incorrect result gives

  __gthrw_ /* Android's C library does not provide pthread_cancel, check for
   * 00245`pthread_create' instead.  */ pthread_cancel;

[Bug c++/58506] gcc -E -C gives error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for "pthread_create' instead. */" does not give a valid preprocessing to

[gcc-bug at sogetthis dot com]

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

--- Comment #1 from gcc-bug at sogetthis dot com ---
Created attachment 30883
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30883&action=edit
Reproduction test case.

[Bug target/58502] ICE with attribute(target) and -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-23
 CC||tmsriram at google dot com
  Component|lto |target
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
#1  0x00c34951 in tree_is_indexable (t=)
at /space/rguenther/src/svn/trunk/gcc/lto-streamer-out.c:131
131 return variably_modified_type_p (TREE_TYPE (DECL_CONTEXT (t)),
NULL_TREE);
(gdb) call debug_tree (t)
 >
public unsigned DI
size 
unit size 
align 64 symtab 0 alias set -1 canonical type 0x76d1fc78
pointer_to_this >
unsigned ignored DI file (null) line 0 col 0 size  unit size 
align 64>
(gdb) call t->decl_minimal.context 
$1 = 

it seems the decl doesn't have DECL_CONTEXT set despite being a RESULT_DECL.

(gdb) p function
$2 = 

target bug:

  /* Build result decl and add to function_decl. */
  t = build_decl (UNKNOWN_LOCATION, RESULT_DECL, NULL_TREE, ptr_type_node);
  DECL_ARTIFICIAL (t) = 1;
  DECL_IGNORED_P (t) = 1;
  DECL_RESULT (decl) = t;

which fails to set DECL_CONTEXT (t) = decl.

[Bug c++/58501] [4.7/4.8/4.9 regression] [c++0x] Crash with brace-enclosed initializer as default parameter

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug target/58475] SH4 insn swapb does not satisfy its constraints:

[chrbr at gcc dot gnu.org]

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

--- Comment #3 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Mon Sep 23 08:30:00 2013
New Revision: 202825

URL: http://gcc.gnu.org/viewcvs?rev=202825&root=gcc&view=rev
Log:
2013-09-23  Christian Bruel  

PR target/58475
* config/sh/sh.md (movsf_ie): Allow fpul_operand.
* config/sh/predicate.md (arith_reg_operand): Disallow FPUL_REG.


Added:
trunk/gcc/testsuite/gcc.target/sh/torture/pr58475.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/sh/predicates.md
trunk/gcc/config/sh/sh.md
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/58506] gcc -E -C gives error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for "pthread_create' instead. */" does not give a valid preproc

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Already fixed on the 4.6 branch:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=188250

[Bug preprocessor/58506] gcc -E -C gives error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for "pthread_create' instead. */" does not give a valid preproc

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
That change is in the 4.6.4 release, and the 4.6 branch is closed and
unmaintained anyway.

[Bug tree-optimization/58497] SLP vectorizes identical operations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-*-*
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-09-23
 Depends on||53947
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Heh ;)  I suppose this started with BIT_FIELD_REF support in SLP, 4.8 didn't
vectorize this at all.

Note that with for example

typedef float float4 __attribute__((vector_size(16)));

float4 g(int x)
{
  float4 W;
  W[0]=W[1]=x+1;
  W[2]=x+2;
  W[3]=x+3;
  return W;
}

vectorizing two same operations may be profitable.  But yes, if all
scalars are the same there is no point to do it.  And the cost model
should have disabled it as well (though likely the four "stores"
made it profitable in the end).

I will have a look at some point.

OTOH generated code is

g:
.LFB0:
.cfi_startproc
movl%edi, -12(%rsp)
movd-12(%rsp), %xmm1
pshufd  $0, %xmm1, %xmm0
paddd   .LC0(%rip), %xmm0
cvtdq2ps%xmm0, %xmm0
ret

vs. -fno-tree-vectorize:

g:
.LFB0:
.cfi_startproc
xorps   %xmm1, %xmm1
addl$1, %edi
xorps   %xmm0, %xmm0
cvtsi2ss%edi, %xmm1
movaps  %xmm0, %xmm2
movss   %xmm1, %xmm2
shufps  $36, %xmm2, %xmm0
movaps  %xmm0, %xmm2
movss   %xmm1, %xmm2
shufps  $196, %xmm2, %xmm0
movaps  %xmm0, %xmm2
unpcklps%xmm0, %xmm0
movss   %xmm1, %xmm0
shufps  $225, %xmm2, %xmm0
movss   %xmm1, %xmm0
ret

so clearly a win, but improvable to sth like

addl$1, %edi
cvtsi2ss%edi, %xmm1
pshufd  $0, %xmm1, %xmm0

the above also shows that vector init by BIT_FIELD_REF is not expanded
very well (sth for a generalized vector shuffle recognition in the bswap pass).

[Bug preprocessor/58506] gcc -E -C gives error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for "pthread_create' instead. */" does not give a valid preproc

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
GCC 4.6 is no longer supported, you are clearly missing the
r178258 fix, but even that has been backported to the 4.6 branch in r188250
quite some time before it's support has been stopped.

[Bug target/58475] SH4 insn swapb does not satisfy its constraints:

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from chrbr at gcc dot gnu.org ---
Fixed on trunk

[Bug tree-optimization/58497] SLP vectorizes identical operations

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Created attachment 30884
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30884&action=edit
prototype patch

A quick check shows generated code will be

g:
.LFB0:
.cfi_startproc
xorps   %xmm0, %xmm0
addl$1, %edi
cvtsi2ss%edi, %xmm0
shufps  $0, %xmm0, %xmm0
ret

and the patch shows possible issues with finding an insert location for
the init stmt (otherwise "external" is just outside of the current
basic-block).

[Bug preprocessor/58506] gcc -E -C gives error: pasting "__gthrw_" and "/* Android's C library does not provide pthread_cancel, check for "pthread_create' instead. */" does not give a valid preproc

[gcc-bug at sogetthis dot com]

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

--- Comment #5 from gcc-bug at sogetthis dot com ---
OK. Sorry for reporting a known (and resolved) problem. The change looks good.
Thank you for your time. Sorry for the inconvenience. (You guys are really
quick BTW:-).

[Bug tree-optimization/57400] [4.9 Regression] ICE: verify_ssa failed (definition in block n follows the use)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Richard Biener  ---
Dup.

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

[Bug tree-optimization/58494] ICE (verify_ssa failed)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Richard Biener  ---
Dup.

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

[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||ishiura-compiler at ml dot 
kwansei
   ||.ac.jp

--- Comment #38 from Richard Biener  ---
*** Bug 58494 has been marked as a duplicate of this bug. ***

[Bug middle-end/57393] [4.9 Regression] error: definition in block 4 follows the use / internal compiler error: verify_ssa failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||antoine.balestrat at gmail dot 
com

--- Comment #37 from Richard Biener  ---
*** Bug 57400 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/57442] [4.9 Regression] ICE in appears_later_in_bb, at tree-ssa-reassoc.c:2891

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
And fixed.

[Bug target/58493] loop is not correctly optimized with O3 and AVX

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
C testcase

void omb(int n, double *points, double *weights)
{
  int i;
  for(i=0;i

[Bug target/58493] loop is not correctly optimized with O3 and AVX

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target|amd64/sandy bridge  |x86_64-*-*, i?86-*-*
 Status|UNCONFIRMED |NEW
  Known to work||4.9.0
   Keywords||wrong-code
   Last reconfirmed||2013-09-23
  Component|rtl-optimization|target
   Host|Debian 3.9.6-1 x86_64   |
   |GNU/Linux;  Intel(R)|
   |Xeon(R) CPU E5-2687W|
 Ever confirmed|0   |1
  Known to fail||4.6.4, 4.7.2, 4.8.1

--- Comment #1 from Richard Biener  ---
Confirmed, works on trunk.

[Bug tree-optimization/58492] [4.9 Regression] ICE: verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-23
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|ICE: verify_flow_info   |[4.9 Regression] ICE:
   |failed  |verify_flow_info failed
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Results in


f.constprop ();
return;

and f.constprop is stmt_ends_bb_p () now, the original recursion isn't.
That's because it's likely got an endless loop and noreturn?

calling out IPA-PTA is probably bogus.

f is found const by IPA pure const (but f.constprop isn't updated via
clone hook?) and ends up const looping.  IPA-PTA doesn't do anything
and copyprop simply first triggers verification.

[Bug tree-optimization/58473] [4.9 regression] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
*** Bug 58491 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/58491] FAIL: ext/random/normal_mv_distribution/cons/default.cc (test for excess errors)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Richard Biener  ---
Yes.

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

[Bug preprocessor/58468] Macro gets undefined when source directory is same as macro name.

[ateuscher at datacomm dot ch]

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

Adrian  changed:

   What|Removed |Added

   Severity|critical|normal

[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Translating {component_ref,mem_ref<0B>,result_296}@.MEM_407 through

:
goto ;

:
# min_size_293 = PHI 
_294 = min_size_293 + 16;
# .MEM_406 = VDEF <.MEM_405>
base_295 = xmalloc (_294);
result_296 = base_295 + min_size_293;
# .MEM_407 = VDEF <.MEM_406>
result_296->cur = base_295;
goto ;

recurses via

1774  phitrans = phi_translate_1 (expr, set1, set2, pred, phiblock);
(gdb) call debug_pre_expr (expr)
{pointer_plus_expr,base_295,min_size_293}

1774  phitrans = phi_translate_1 (expr, set1, set2, pred, phiblock);
(gdb) call debug_pre_expr (expr)
{component_ref,mem_ref<0B>,result_296}@.MEM_407

where {component_ref,mem_ref<0B>,result_296}@.MEM_407 is the leader
for base_295 and {pointer_plus_expr,base_295,min_size_293} is the leader
for result_296.

So that circumvents

leader = find_leader_in_sets (op_val_id, set1, set2);
if (!leader)
  break;
/* Make sure we do not recursively translate ourselves
   like for translating a[n_1] with the leader for
   n_1 being a[n_1].  */
if (get_expression_id (leader) != get_expression_id (expr))
  {

because it's a recursion with two levels ...

[Bug target/58490] __sync_bool_compare_and_swap sign bit failure

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2013-09-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
Please attach a pre-processed, self-contained, test case that can be used to
demonstrate the problem.

[Bug target/58489] ICE: in reload_cse_simplify_operands, at postreload.c:411

[timo.teras at iki dot fi]

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

--- Comment #1 from Timo Teräs  ---
Simplifed commandline to:
armv6-alpine-linux-muslgnueabihf-gcc -Os -c -std=gnu99 aa.c -o aa.o

No ICE with:
armv6-alpine-linux-muslgnueabihf-gcc -c -std=gnu99 aa.c -o aa.o
armv6-alpine-linux-muslgnueabihf-gcc -march=armv7-a -Os -c -std=gnu99 aa.c -o
aa.o

So "-march=armv6 -Os" triggers the issue.

[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 23 12:37:17 2013
New Revision: 202826

URL: http://gcc.gnu.org/viewcvs?rev=202826&root=gcc&view=rev
Log:
2013-09-23  Richard Biener  

PR tree-optimization/58464
* tree-ssa-pre.c (phi_trans_lookup): Remove.
(phi_trans_add): Change to add conditionally on being not
present.
(phi_translate_1): Remove recursion detection here.
(phi_translate): Pre-seed the cache with NULL to catch
recursion here in a more generic way.
(bitmap_find_leader): Adjust comment.
(get_representative_for): Dump value-numbers.
(create_expression_by_pieces): Likewise.
(insert_into_preds_of_block): Likewise.

* g++.dg/torture/pr58464.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr58464.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-pre.c

[Bug target/58493] loop is not correctly optimized with O3 and AVX

[mikpe at it dot uu.se]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpe at it dot uu.se

--- Comment #3 from Mikael Pettersson  ---
The C test case started working for 4.9 with Richard's "Vectorizer TLC:
re-organize data dependence checking" patch in r196872.  The original patch
description  doesn't
mention any wrong-code fixes in that patch.

The code generation difference on the test case at r196872 is:

--- pr54893.s-r196871   2013-09-23 14:51:29.441292880 +0200
+++ pr54893.s-r196872   2013-09-23 14:54:55.000501714 +0200
@@ -12,8 +12,6 @@
sarl%edi
testl   %edi, %edi
jle .L25
-   cmpl$8, %edi
-   jbe .L3
leaq64(%rsi), %rax
cmpq%rax, %rdx
leaq64(%rdx), %rax
@@ -22,6 +20,8 @@
setae   %al
orb %al, %cl
je  .L3
+   cmpl$9, %edi
+   jbe .L3
leal-1(%rdi), %r9d
vmovapd .LC0(%rip), %ymm1
movq%rdx, %rax

[Bug tree-optimization/58464] [4.9 Regression] Crashes with SIGSEGV (infinite recursion in phi_translate)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Fixed.

[Bug target/58442] bootstrapping vax crashes on NetBSD

[martin at netbsd dot org]

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

--- Comment #6 from Martin Husemann  ---
To verify, I instrumented get_mem_attrs:

static inline struct mem_attrs *
get_mem_attrs (const_rtx x)
{
  struct mem_attrs *attrs;

  attrs = MEM_ATTRS (x);

  attrs = MEM_ATTRS (x);
  if (!attrs) {
attrs = mode_mem_attrs[(int) GET_MODE (x)];
if ((unsigned long)attrs < 1024) {
  fprintf(stderr, "ooops, mode_mem_attrs are bogus: %p mode %d\n", attrs,
G$
  debug_rtx(x);
}
  } else if ((unsigned long)attrs < 1024) {
fprintf(stderr, "ooops, bogus rtx mem attrs: %p\n", attrs);
debug_rtx(x);
  }

  return attrs;
}

and indeed this fires:

ooops, bogus rtx mem attrs: 0x4
(subreg:SI (reg/v:DI 71 [ __s ]) 4)
In file included from
/usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/bits/locale_facets_nonio.h:1903:0,
 from
/usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/locale:41,
 from
../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/locale-inst.cc:29:
...

[Bug target/58507] New: Incorrect parsing of `-mmcu=msp430*`

[errordeveloper at gmail dot com]

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

Bug ID: 58507
   Summary: Incorrect parsing of `-mmcu=msp430*`
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: errordeveloper at gmail dot com
CC: dj at redhat dot com, nickc at redhat dot com

% cat test.c
#include 

int main() { return 0; };

% msp430-elf-gcc -mmcu=msp430fr5739 test.c
-I/home/ilya/msp430/msp430-elf-21092013-0/msp430-elf/include/msp430
/home/ilya/msp430/msp430-elf-21092013-0/bin/../lib/gcc/msp430-elf/4.9.0/../../../../msp430-elf/bin/ld:
error: /tmp/cc5edjEZ.o uses MSP430X instructions but
/home/ilya/msp430/msp430-elf-21092013-0/bin/../lib/gcc/msp430-elf/4.9.0/../../../../msp430-elf/lib/crt0.o
uses MSP430
/home/ilya/msp430/msp430-elf-21092013-0/bin/../lib/gcc/msp430-elf/4.9.0/../../../../msp430-elf/bin/ld:
failed to merge target specific data of file /tmp/cc5edjEZ.o
collect2: error: ld returned 1 exit status


Checking this reviles a dull parameter parsing bug:

% msp430-elf-gcc -mmcu=msp430 test.c
-I/home/ilya/msp430/msp430-elf-21092013-0/msp430-elf/include/msp430 -c
% msp430-elf-objdump -x test.o | grep -i arch
architecture: msp:11, flags 0x0010:

% msp430-elf-gcc -mmcu=msp430x test.c
-I/home/ilya/msp430/msp430-elf-21092013-0/msp430-elf/include/msp430 -c
% msp430-elf-objdump -x test.o | grep -i arch
architecture: msp:430X, flags 0x0010:

% msp430-elf-gcc -mmcu=msp430fr5739 test.c
-I/home/ilya/msp430/msp430-elf-21092013-0/msp430-elf/include/msp430 -c
% msp430-elf-objdump -x test.o | grep -i arch
architecture: msp:430X, flags 0x0010:

Here are the revision ID's for your reference:

gcc 25bd6b06e5c81ff8c97d6671651442305a2cbbb2
newlib 090b27c6ed560767408293f185aa313eeef23d74
binutils e1926926db9154828b02a83c3d094ba6c39247e0
gdb 7.6.50.20130921
msp430mcu d5dd733e674dfd80781669a98ef85fd57526ce47
mspdebug 0.22

The compilation was done according to:
http://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:redhat

A x86 binary can be found here:
https://s3.amazonaws.com/com.xively.packages/msp430-elf-21092013-0.txz

[Bug target/58330] powerpc64 atomic store split in two

[amodra at gcc dot gnu.org]

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

--- Comment #5 from Alan Modra  ---
Author: amodra
Date: Mon Sep 23 14:27:06 2013
New Revision: 202829

URL: http://gcc.gnu.org/viewcvs?rev=202829&root=gcc&view=rev
Log:
PR target/58330
* config/rs6000/rs6000.md (bswapdi2_64bit): Disable for volatile mems.
gcc/testsuite/
* gcc.target/powerpc/pr58330.c: New.


Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug target/58330] powerpc64 atomic store split in two

[amodra at gcc dot gnu.org]

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

--- Comment #6 from Alan Modra  ---
Author: amodra
Date: Mon Sep 23 14:27:56 2013
New Revision: 202830

URL: http://gcc.gnu.org/viewcvs?rev=202830&root=gcc&view=rev
Log:
PR target/58330
* gcc.target/powerpc/pr58330.c: New.


Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr58330.c

[Bug target/58330] powerpc64 atomic store split in two

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Alan Modra  ---
Fixed

[Bug target/58330] powerpc64 atomic store split in two

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken

[eblake at redhat dot com]

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

--- Comment #3 from Eric Blake  ---
Since the engine is able to warn at -O0 when I _don't_ take the address, I
don't see why the warning is lost by the mere action of taking the address.

[Bug c/58488] -Wuninitialized is useless for a variable whose address is later taken

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
The warning machinery is only able to warn about vars in SSA form, vars which
must live in memory can't be warned on easily.  So, for such variables you only
get warnings if the compiler is able as part of some optimization make the var
non-addressable (e.g. inlining and propagation can help that, etc.), or scalar
replacement of aggregates is able to break appart larger aggregates and use SSA
form for those.  Thus, you get better warnings with optimizations.

[Bug tree-optimization/58508] New: Redundant vector load of "actual" loop invariant in loop body.

[congh at google dot com]

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

Bug ID: 58508
   Summary: Redundant vector load of "actual" loop invariant in
loop body.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: congh at google dot com

When GCC vectorizes the loop below, it will firstly do loop versioning with
aliasing check on a and b. Since a and b have different strides (1 and 0), the
check guarantees that there is no aliasing between a and b across all
iterations. Then with this precondition *b becomes a loop invariant so that it
can be loaded outside the loop during vectorization (Note that this
precondition always holds when the loop is being vectorized). This can save us
a load and a shuffle instruction in each iteration.


void foo (int* a, int* b, int n)
{
  for (int i = 0; i < n; ++i)
a[i] += *b;
}


I have a patch handling this case as an optimization. After loop versioning, I
detect all zero-strided data references and hoist the loads of them to the loop
header. The patch is shown below.


thanks,
Cong



Index: gcc/tree-vect-loop-manip.c
===
--- gcc/tree-vect-loop-manip.c(revision 202662)
+++ gcc/tree-vect-loop-manip.c(working copy)
@@ -2477,6 +2477,37 @@ vect_loop_versioning (loop_vec_info loop
   adjust_phi_and_debug_stmts (orig_phi, e, PHI_RESULT (new_phi));
 }

+  /* Extract load and store statements on pointers with zero-stride 
+ accesses.  */
+  if (LOOP_REQUIRES_VERSIONING_FOR_ALIAS (loop_vinfo))
+{
+
+  /* In the loop body, we iterate each statement to check if it is a load 
+ or store. Then we check the DR_STEP of the data reference.  If 
+ DR_STEP is zero, then we will hoist the load statement to the loop 
+ preheader, and move the store statement to the loop exit.  */
+
+  for (gimple_stmt_iterator si = gsi_start_bb (loop->header); 
+!gsi_end_p (si); )
+{
+  gimple stmt = gsi_stmt (si);
+  stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+  struct data_reference *dr = STMT_VINFO_DATA_REF (stmt_info);
+
+  if (dr && integer_zerop (DR_STEP (dr)))
+{
+  if (DR_IS_READ (dr))
+{
+  basic_block preheader = loop_preheader_edge (loop)->src;
+  gimple_stmt_iterator si_dst = gsi_last_bb (preheader);
+  gsi_move_after (&si, &si_dst);
+}
+}
+  else
+gsi_next (&si);
+}
+} 
+
   /* End loop-exit-fixes after versioning.  */

   if (cond_expr_stmt_list)

[Bug c++/58510] New: [4.9 regression] [c++0x] ICE with multiple non-static data initializations in union

[reichelt at gcc dot gnu.org]

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

Bug ID: 58510
   Summary: [4.9 regression] [c++0x] ICE with multiple non-static
data initializations in union
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with "-std=c++0x") triggers an ICE
on trunk:


void foo()
{
  union
  {
int i = 0;
char c = 0;
  };
}


bug.cc: In function 'void foo()':
bug.cc:4:3: error: multiple fields in union 'foo()::'
initialized
   {
   ^
bug.cc: In constructor 'constexpr foo()()':
bug.cc:4:3: error: initializations for multiple members of 'foo()::'
bug.cc: In function 'void foo()':
bug.cc:7:4: note: synthesized method 'constexpr foo()()' first required here 
   };
^
bug.cc:7:4: internal compiler error: in complete_ctor_at_level_p, at
expr.c:5650
0x89a301 complete_ctor_at_level_p(tree_node const*, long, tree_node const*)
../../gcc/gcc/expr.c:5650
0x89a68e categorize_ctor_elements_1
../../gcc/gcc/expr.c:5602
0x9684b6 gimplify_init_constructor
../../gcc/gcc/gimplify.c:3966
0x96993e gimplify_modify_expr_rhs
../../gcc/gcc/gimplify.c:4518
0x969cad gimplify_modify_expr
../../gcc/gcc/gimplify.c:4834
0x95e07b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7322
0x961ef6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5699
0x95f987 gimplify_and_add
../../gcc/gcc/gimplify.c:329
0x95f987 gimplify_decl_expr
../../gcc/gcc/gimplify.c:1472
0x95f987 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7489
0x961ef6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5699
0x95eccf gimplify_cleanup_point_expr
../../gcc/gcc/gimplify.c:5475
0x95eccf gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7659
0x961ef6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5699
0x962bb1 gimplify_bind_expr
../../gcc/gcc/gimplify.c:1213
0x95e73f gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**,
bool (*)(tree_node*), int)
../../gcc/gcc/gimplify.c:7493
0x961ef6 gimplify_stmt(tree_node**, gimple_statement_d**)
../../gcc/gcc/gimplify.c:5699
0x963541 gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:8356
0x9639f6 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:8488
0x7fa9d7 analyze_function
../../gcc/gcc/cgraphunit.c:636
Please submit a full bug report, [etc.]

[Bug bootstrap/58509] New: [4.9 regression] ICE in calc_dfs_tree, at dominance.c:397 breaks Ada bootstrap on sparc64-linux

[mikpe at it dot uu.se]

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

Bug ID: 58509
   Summary: [4.9 regression] ICE in calc_dfs_tree, at
dominance.c:397 breaks Ada bootstrap on sparc64-linux
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mikpe at it dot uu.se
  Host: sparc64-linux
Target: sparc-linux
 Build: sparc-linux

Attempting to bootstrap gcc-4.9-20130922 on sparc64-linux fails with:

/mnt/scratch/objdir49/./gcc/xgcc -B/mnt/scratch/objdir49/./gcc/
-B/mnt/scratch/install49/sparc-unknown-linux/bin/
-B/mnt/scratch/install49/sparc-unknown-linux/lib/ -isystem
/mnt/scratch/install49/sparc-unknown-linux/include -isystem
/mnt/scratch/install49/sparc-unknown-linux/sys-include-c -g -O2  -fPIC  -W
-Wall -gnatpg -nostdinc   g-awk.adb -o g-awk.o
+===GNAT BUG DETECTED==+
| 4.9.0 20130922 (experimental) (sparc-unknown-linux) GCC error:   |
| in calc_dfs_tree, at dominance.c:397 |
| Error detected around g-awk.adb:264:9|
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact gcc or gnatmake command that you entered.  |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files).   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

system.ads
g-awk.adb
g-awk.ads
gnat.ads
ada.ads
a-finali.ads
s-finroo.ads
g-regpat.ads
s-regpat.ads
a-except.ads
s-parame.ads
s-stalib.ads
a-unccon.ads
s-traent.ads
a-textio.ads
a-ioexce.ads
a-stream.ads
s-ficobl.ads
interfac.ads
i-cstrea.ads
s-crtl.ads
s-wchcon.ads
a-string.ads
a-strunb.ads
a-strmap.ads
a-charac.ads
a-chlat1.ads
a-strfix.ads
a-uncdea.ads
g-dirope.ads
g-dyntab.ads
g-os_lib.ads
s-os_lib.ads
s-string.ads
s-exctab.ads
a-tags.ads
s-stoele.ads
s-stoele.adb
s-soflin.ads
s-stache.ads
s-finmas.ads
s-stopoo.ads
s-pooglo.ads
s-unstyp.ads
s-stratt.ads
s-secsta.ads
s-stposu.ads
s-ststop.ads
s-imgint.ads
s-valint.ads
s-valrea.ads
g-dyntab.adb
g-hesorg.ads
s-memory.ads
g-hesorg.adb


raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:432
make[7]: *** [g-awk.o] Error 1
make[7]: Leaving directory `/mnt/scratch/objdir49/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2
make[6]: Leaving directory `/mnt/scratch/objdir49/gcc/ada'
make[5]: *** [gnatlib-shared-default] Error 2
make[5]: Leaving directory `/mnt/scratch/objdir49/gcc/ada'
make[4]: *** [gnatlib-shared-dual] Error 2
make[4]: Leaving directory `/mnt/scratch/objdir49/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory `/mnt/scratch/objdir49/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir49/sparc-unknown-linux/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir49'
make: *** [bootstrap] Error 2

The previous weekly snapshot, gcc-4.9-20130915, bootstrapped fine on this
machine.  I haven't seen this failure on x86_64 or powerpc64 (armv5tel is still
building).

Configuration options:
--prefix=/mnt/scratch/install48
--with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-5.1.2
--with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-3.1.2
--with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-1.0.1 --enable-multilib
--disable-plugin --disable-lto --disable-nls --enable-threads=posix
--enable-checking=release --disable-libmudflap
--enable-languages=c,c++,fortran,ada --build=sparc-unknown-linux
--target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all

[Bug tree-optimization/58005] missed optimization printf constant string

[daniel.santos at pobox dot com]

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

Daniel Santos  changed:

   What|Removed |Added

 CC||daniel.santos at pobox dot com

--- Comment #5 from Daniel Santos  ---
(In reply to jos...@codesourcery.com from comment #3)
> Such an optimization can increase code size (well, the total size of 
> string constants in the program) if the same format string is used with 
> many different arguments, so it may not always be a good idea (at least 
> with -Os).

Yeah, I agree.  Such a subtle optimization would be bad for many people who
intentionally reuse a format string to reduce the data size and then only to
have that thwarted by the compiler.  Typically, printfs don't reside in
performance sensitive sections of code.

[Bug c++/58511] New: [c++0x] ICE using static const member variable in constexpr

[reichelt at gcc dot gnu.org]

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

Bug ID: 58511
   Summary: [c++0x] ICE using static const member variable in
constexpr
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following invalid code snippet (compiled with "-std=c++0x") triggers an ICE
since GCC 4.8.0 (when inheriting constructors were introduced):


struct A
{
  constexpr A(int, int = i) {}
  static const int i;
};

struct B : A
{
  using A::A;
};

constexpr B b(0);


bug.cc:12:16: error: 'constexpr B::B(int)' called in a constant expression
 constexpr B b(0);
^
bug.cc:9:12: note: 'constexpr B::B(int)' is not usable as a constexpr function
because:
   using A::A;
^
bug.cc:9:12: internal compiler error: in synthesized_method_walk, at
cp/method.c:1218
0x675548 synthesized_method_walk
../../gcc-4.8.0/gcc/cp/method.c:1217
0x679692 explain_implicit_non_constexpr(tree_node*)
../../gcc-4.8.0/gcc/cp/method.c:1481
0x69f68b explain_invalid_constexpr_fn(tree_node*)
../../gcc-4.8.0/gcc/cp/semantics.c:6379
0x69faf6 cxx_eval_call_expression
../../gcc-4.8.0/gcc/cp/semantics.c:6751
0x6a1142 cxx_eval_constant_expression
../../gcc-4.8.0/gcc/cp/semantics.c:7814
0x6a14a9 cxx_eval_constant_expression
../../gcc-4.8.0/gcc/cp/semantics.c:7835
0x6a4426 cxx_eval_outermost_constant_expr
../../gcc-4.8.0/gcc/cp/semantics.c:8115
0x5bd69d store_init_value(tree_node*, tree_node*, vec**, int)
../../gcc-4.8.0/gcc/cp/typeck2.c:722
0x540b40 check_initializer
../../gcc-4.8.0/gcc/cp/decl.c:5711
0x5537b5 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc-4.8.0/gcc/cp/decl.c:6328
0x62afeb cp_parser_init_declarator
../../gcc-4.8.0/gcc/cp/parser.c:16038
0x62b85e cp_parser_simple_declaration
../../gcc-4.8.0/gcc/cp/parser.c:10567
0x62d630 cp_parser_block_declaration
../../gcc-4.8.0/gcc/cp/parser.c:10448
0x6361fb cp_parser_declaration
../../gcc-4.8.0/gcc/cp/parser.c:10345
0x634ecd cp_parser_declaration_seq_opt
../../gcc-4.8.0/gcc/cp/parser.c:10231
0x636772 cp_parser_translation_unit
../../gcc-4.8.0/gcc/cp/parser.c:3807
0x636772 c_parse_file()
../../gcc-4.8.0/gcc/cp/parser.c:28186
0x73e504 c_common_parse_file()
../../gcc-4.8.0/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

[Bug rtl-optimization/54585] stack space allocated but never used when calling functions that return structs in registers

[chip at pobox dot com]

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

--- Comment #3 from Chip Salzenberg  ---
It's worth it for cache reasons I believe.  The data cache works better you
don't spread out the stack data unnecessarily.  More concretely, if the stack
frame can entirely disappear then you also reduce the instruction count. 
That's fewer instructions to dispatch and less icache pressure.

[Bug driver/58512] New: [Feature request] -Wformat extensions to accomodate custom rules

[daniel.santos at pobox dot com]

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

Bug ID: 58512
   Summary: [Feature request] -Wformat extensions to accomodate
custom rules
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.santos at pobox dot com

I am working on a Linux kernel patch set to add a feature comprable to glibc's
%m format specifier.  However, glibc's extensions uses errno which, of course,
doesn't exist in the kernel.  Therefore, if I wanted to use %m, I would trigger
-Wformat warnings due to the unexpected argument(s).

The Linux kernel currently has many extensions to printf
(http://lxr.free-electrons.com/source/lib/vsprintf.c#L1466) which operate by
adding a suffix to an existing format specifier, preventing any breakage due to
-Wformat.  But it is also limiting because new format specifiers must be
implemented via suffixes, which consequently increase data size (be it ever so
slightly).  It would be helpful to have a mechanism to tell gcc that you are
extending the format rule checks in x fashion.  For example:

* Define new archetype named "linux_printf" extending "printf"
* Remove %m rule.
* Add %m rule, defined as .

Then in the __attribute__ printf declaration, one would simply use the
linux_printf for the archetype name.

[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44

[tammy at Cadence dot COM]

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

--- Comment #26 from Tammy Hsu  ---
Thanks a lot for the patch. It addresses the issue on the standalone test and
shows also in our real tool test results. With this patch, the major
degradations are gone. Compared to gcc445, there is a slight overall
improvement for this tool now.

Really appreciate all the comments and the creation of a patch in such a short
of time

[Bug tree-optimization/58513] New: *var and MEM[(const int &)var] (var has int* type) are not treated as the same data ref.

[congh at google dot com]

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

Bug ID: 58513
   Summary: *var and MEM[(const int &)var]  (var has int* type)
are not treated as the same data ref.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: congh at google dot com

First look at the code below:


int op (const int& x, const int& y) { return x + y; }

void foo(int* a)
{
 for (int i = 0; i < 10; ++i)
   a[i] = op(a[i], 1);
}


GCC will generate the following GIMPLE for this loop after inlining op():


  :
  # i_17 = PHI <0(2), i_23(4)>
  # ivtmp_13 = PHI <10(2), ivtmp_24(4)>
  _12 = (long unsigned int) i_17;
  _2 = _12 * 4;
  _1 = a_6(D) + _2;
  _20 = MEM[(const int &)_1];
  _19 = _20 + 1;
  *_1 = _19;
  i_23 = i_17 + 1;
  ivtmp_24 = ivtmp_13 - 1;
  if (ivtmp_24 != 0)
goto ;
  else
goto ;


Here each element of the array a is loaded by MEM[(const int &)_1] and stored
by *_1, which are the only two data refs in the loop body. The GCC vectorizer
needs to check the possible aliasing between data refs with potential data
dependence. Here those two data refs are actually the same one, but GCC could
not recognize this fact. As a result, the aliasing checking predicate will
always return false at runtime (GCC 4.9 could eliminate this generated branch
at the end of the vectorization pass). 

The reason why GCC thinks that MEM[(const int &)_1] and *_1 are two different
data refs is that there is a possible defect in the function operand_equal_p(),
which is used to compare two data refs. The current implementation uses == to
compare the types of the second argument of MEM_REF operator, which is too
strict. Using types_compatible_p() instead can fix the issue above. I have
produced a patch to fix it and the patch is shown below. Please give me the
comment on this patch. (bootstrapping and "make check" passed).


thanks,
Cong



Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 202662)
+++ gcc/fold-const.c(working copy)
@@ -2693,8 +2693,9 @@ operand_equal_p (const_tree arg0, const_
&& operand_equal_p (TYPE_SIZE (TREE_TYPE (arg0)),
TYPE_SIZE (TREE_TYPE (arg1)), flags)))
   && types_compatible_p (TREE_TYPE (arg0), TREE_TYPE (arg1))
-  && (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg0, 1)))
-  == TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg1, 1
+  && types_compatible_p (
+TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg0, 1))),
+TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (arg1, 1
   && OP_SAME (0) && OP_SAME (1));

 case ARRAY_REF:

[Bug libstdc++/58514] New: Undefined symbol in libstdc++.so starting with rev 202818

[pthaugen at gcc dot gnu.org]

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

Bug ID: 58514
   Summary: Undefined symbol in libstdc++.so starting with rev
202818
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
ppluzhnikov at google dot com
  Host: powerpc64-linux
Target: powerpc64-linux
 Build: powerpc64-linux

First noticed when cpu2000 benchmark 252.eon failed to build. Can reproduce
with simple Hello world. Only occurs for 32-bit compile. Bisected to r202818.


[pthaugen@igoo ~/temp]$ cat Hello.C
#include 
using namespace std;
int main()
{
  cout << "Hello World!" << endl;
  return 0;
}
[pthaugen@igoo ~/temp]$ ~/install/gcc/trunk_work/bin/g++ -m64 Hello.C
[pthaugen@igoo ~/temp]$ a.out
Hello World!
[pthaugen@igoo ~/temp]$ ~/install/gcc/trunk_work/bin/g++ -m32 Hello.C
/home/pthaugen/install/gcc/trunk_work/lib/gcc/powerpc64-linux/4.9.0/../../../../lib/libstdc++.so:
undefined reference to `int std::__int_to_char(char*,
unsigned int, char const*, std::_Ios_Fmtflags, bool)'
collect2: error: ld returned 1 exit status



The undefined symbol comes from the added file snprintf_lite.cc

[pthaugen@igoo c++11]$ pwd
/home/pthaugen/work/build/gcc/trunk_work/powerpc64-linux/32/libstdc++-v3/src/c++11
[pthaugen@igoo c++11]$ nm -u snprintf_lite.o | grep int_to_char
 U _ZSt13__int_to_charIcjEiPT_T0_PKS0_St13_Ios_Fmtflagsb


Configure flags for build:
Configured with: /home/pthaugen/src/gcc/trunk_work/gcc/configure
--prefix=/home/pthaugen/install/gcc/trunk_work --target=powerpc64-linux
--host=powerpc64-linux --build=powerpc64-linux --enable-secureplt
--enable-threads=posix --enable-shared --enable-__cxa_atexit
--with-long-double-128 --enable-decimal-float --disable-alsa --enable-checking
--with-lto --with-as=/home/bergner/binutils/install/binutils-power8/bin/as
--with-ld=/home/bergner/binutils/install/binutils-power8/bin/ld
--with-gmp=/home/pthaugen/install/gcc-host-libs
--with-mpfr=/home/pthaugen/install/gcc-host-libs
--with-mpc=/home/pthaugen/install/gcc-host-libs --without-ppl --without-cloog
--enable-languages=c,fortran,c++ --disable-bootstrap

[Bug libstdc++/58514] Undefined symbol in libstdc++.so starting with rev 202818

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Paolo Carlini  ---
Fixed today.

[Bug c/58515] New: Loop optimized away when it should not

[manus at eiffel dot com]

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

Bug ID: 58515
   Summary: Loop optimized away when it should not
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manus at eiffel dot com

Created attachment 30885
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30885&action=edit
To reproduce code generation issue

If you compile the attached code with -O3 the `slow' function becomes a no-op
which is incorrect. Older version of GCC I've tried generated proper code. I
could not try newer version.

To reproduce compile with -O3 the attached file.

I found this while fixing the warning that GCC raises when compiling the `fast'
function.

[Bug c/58515] Loop optimized away when it should not

[manus at eiffel dot com]

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

Emmanuel Stapf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Emmanuel Stapf  ---
Sorry the test code was not the proper one I intended to use since it seems
legitimate that gcc optimizes this away due to the absence of side effects.

[Bug c++/58516] New: ICE with __transaction_atomic

[reichelt at gcc dot gnu.org]

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

Bug ID: 58516
   Summary: ICE with __transaction_atomic
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following code snippet (compiled with "-std=c++0x -fgnu-tm") triggers an
ICE since GCC 4.7.0 (when transactional memory was introduced):

=
void foo()
{
  __transaction_atomic noexcept(false) {}
}
=

bug.cc: In function 'void foo()':
bug.cc:3:41: internal compiler error: tree check: expected class 'expression',
have 'exceptional' (statement_list) in finish_transaction_stmt, at
cp/semantics.c:5202
   __transaction_atomic noexcept(false) {}
 ^
0xcd2399 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9258
0x6b576b expr_check
../../gcc/gcc/tree.h:2773
0x6b576b finish_transaction_stmt(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/semantics.c:5202
0x635842 cp_parser_transaction
../../gcc/gcc/cp/parser.c:28482
0x635842 cp_parser_statement
../../gcc/gcc/cp/parser.c:9205
0x636dde cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:9552
0x636f26 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:9506
0x648323 cp_parser_function_body
../../gcc/gcc/cp/parser.c:18313
0x648323 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:18349
0x64935f cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:22333
0x64a079 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:22254
0x64a079 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16348
0x64a32f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10986
0x64c190 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x6551ae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x653f0d cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x6557e6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x6557e6 c_parse_file()
../../gcc/gcc/cp/parser.c:28893
0x768164 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

[Bug target/58517] New: [SH] wrong code with subc and movsicc (-mpretend-cmove) after ce2

[olegendo at gcc dot gnu.org]

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

Bug ID: 58517
   Summary: [SH] wrong code with subc and movsicc
(-mpretend-cmove) after ce2
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*

While working on something else, I've noticed the following sequence in the
CSiBE set in the file zlib-1.1.4/infblock.s, compiling with -m4-single -ml -O2
-mpretend-cmove (trunk rev 201978):

.L257:
sett! 1740sett[length = 2]
movr2,r13! 2180movsi_ie/2[length = 2]
subr5,r1! 1588*subsi3_internal[length = 2]
subcr5,r13! 1741*subc[length = 2]
bt0f! 1589*movsicc_t_false/1[length = 4]
movr1,r13
0:
tstr13,r13! 435cmpeqsi_t/1[length = 2]
bf.L67! 436*cbranch_t[length = 2]
bra.L124
nop! 2774jump_compact[length = 4]

The subc insn clobbers the T_REG and the following 'bt 0f' just looks wrong.
It seems that something goes wrong and the insn that does the test before
*movsicc_t_false gets eliminated because the sett-subc sequence is placed in
between.
After the combine pass the sequence looks like:

(note 422 421 423 45 [bb 45] NOTE_INSN_BASIC_BLOCK)
(insn 423 422 432 45 (set (reg:SI 147 t)
(gtu:SI (reg/f:SI 424 [ D.2926 ])
(reg/v/f:SI 189 [ q ]))) infblock.c:202 34 {cmpgtusi_t}
 (nil))
(insn 432 423 424 45 (set (reg/v:SI 190 [ n ])
(minus:SI (reg/v/f:SI 423 [ q ])
(reg/v/f:SI 189 [ q ]))) infblock.c:202 76 {*subsi3_internal}
 (expr_list:REG_DEAD (reg/v/f:SI 423 [ q ])
(nil)))
(jump_insn 424 432 425 45 (set (pc)
(if_then_else (eq (reg:SI 147 t)
(const_int 0 [0]))
(label_ref:SI 433)
(pc))) infblock.c:202 295 {*cbranch_t}
 (expr_list:REG_DEAD (reg:SI 147 t)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)))
 -> 433)
(note 425 424 426 46 [bb 46] NOTE_INSN_BASIC_BLOCK)
(note 426 425 427 46 NOTE_INSN_DELETED)
(insn 427 426 433 46 (parallel [
(set (reg/v:SI 190 [ n ])
(plus:SI (not:SI (reg/v/f:SI 189 [ q ]))
(reg/f:SI 424 [ D.2926 ])))
(clobber (reg:SI 147 t))
]) infblock.c:202 74 {*subc}
 (expr_list:REG_UNUSED (reg:SI 147 t)
(expr_list:REG_DEAD (reg/f:SI 424 [ D.2926 ])
(nil
(code_label 433 427 434 47 70 "" [1 uses])


After the following pass ce2 it becomes:

(note 422 421 423 45 [bb 45] NOTE_INSN_BASIC_BLOCK)
(insn 423 422 432 45 (set (reg:SI 147 t)
(gtu:SI (reg/f:SI 424 [ D.2926 ])
(reg/v/f:SI 189 [ q ]))) infblock.c:202 34 {cmpgtusi_t}
 (nil))
(insn 432 423 1587 45 (set (reg/v:SI 190 [ n ])
(minus:SI (reg/v/f:SI 423 [ q ])
(reg/v/f:SI 189 [ q ]))) infblock.c:202 76 {*subsi3_internal}
 (expr_list:REG_DEAD (reg/v/f:SI 423 [ q ])
(nil)))
(insn 1587 432 1588 45 (parallel [
(set (reg:SI 945)
(plus:SI (not:SI (reg/v/f:SI 189 [ q ]))
(reg/f:SI 424 [ D.2926 ])))
(clobber (reg:SI 147 t))
]) infblock.c:202 74 {*subc}
 (nil))
(insn 1588 1587 1589 45 (set (reg:SI 946)
(minus:SI (reg/v/f:SI 423 [ q ])
(reg/v/f:SI 189 [ q ]))) infblock.c:202 76 {*subsi3_internal}
 (nil))
(insn 1589 1588 435 45 (set (reg/v:SI 190 [ n ])
(if_then_else:SI (eq (reg:SI 147 t)
(const_int 0 [0]))
(reg:SI 946)
(reg:SI 945))) infblock.c:202 54 {*movsicc_t_false}
 (nil))
(insn 435 1589 436 45 (set (reg:SI 147 t)
(eq:SI (reg/v:SI 190 [ n ])
(const_int 0 [0]))) infblock.c:202 17 {cmpeqsi_t}
 (nil))
(jump_insn 436 435 1378 45 (set (pc)
(if_then_else (eq (reg:SI 147 t)
(const_int 0 [0]))
(label_ref 501)
(pc))) infblock.c:202 295 {*cbranch_t}
 (expr_list:REG_DEAD (reg:SI 147 t)
(expr_list:REG_BR_PROB (const_int 1 [0x2710])
(nil)))
 -> 501)

which is wrong.  I haven't checked whether it also happens on current trunk.

[Bug c/47781] warnings from custom printf format specifiers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-09-23
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
Confirmed.

[Bug driver/58512] [Feature request] -Wformat extensions to accomodate custom rules

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of older bug requesting a similar thing.

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

[Bug c/47781] warnings from custom printf format specifiers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||daniel.santos at pobox dot com

--- Comment #6 from Andrew Pinski  ---
*** Bug 58512 has been marked as a duplicate of this bug. ***

[Bug c/47781] warnings from custom printf format specifiers

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
Related to bug 15338.

[Bug c++/58518] New: [4.8/4.9 regression] ICE template specialization

[reichelt at gcc dot gnu.org]

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

Bug ID: 58518
   Summary: [4.8/4.9 regression] ICE template specialization
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org

The following valid code snippet triggers an ICE since GCC 4.8.0:


template struct A
{
  template struct B {};
  template struct B {};
};

A::B<0, 0> b;


bug.cc:7:17: internal compiler error: in tsubst, at cp/pt.c:11473
 A::B<0, 0> b;
 ^
0x5a63d5 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11473
0x5a92a2 convert_template_argument
../../gcc/gcc/cp/pt.c:6424
0x5a3135 coerce_template_parms
../../gcc/gcc/cp/pt.c:6827
0x5bf864 get_class_bindings
../../gcc/gcc/cp/pt.c:18177
0x5c0420 most_specialized_class
../../gcc/gcc/cp/pt.c:18398
0x5d0eb0 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:8687
0x5d0eb0 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9216
0x65cdcb complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:132
0x54da66 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4670
0x577851 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4633
0x649a5a cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16447
0x64a32f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10986
0x64c190 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x6551ae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x653f0d cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x6557e6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x6557e6 c_parse_file()
../../gcc/gcc/cp/parser.c:28893
0x768164 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]

A little longer testcase triggers an ICE in a different function:


template struct A
{
  typedef typename T::X U;

  template struct B {};
  template struct B {};
};

struct C
{
  typedef int X;
};

A::B<0, 0> b;


bug.cc:14:15: internal compiler error: in dependent_type_p, at cp/pt.c:19969
 A::B<0, 0> b;
   ^
0x588d28 dependent_type_p(tree_node*)
../../gcc/gcc/cp/pt.c:19969
0x589504 dependent_scope_p(tree_node*)
../../gcc/gcc/cp/pt.c:2
0x54aed7 make_typename_type(tree_node*, tree_node*, tag_types, int)
../../gcc/gcc/cp/decl.c:3331
0x5a5781 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11914
0x5a92a2 convert_template_argument
../../gcc/gcc/cp/pt.c:6424
0x5a3135 coerce_template_parms
../../gcc/gcc/cp/pt.c:6827
0x5bf864 get_class_bindings
../../gcc/gcc/cp/pt.c:18177
0x5c0420 most_specialized_class
../../gcc/gcc/cp/pt.c:18398
0x5d0eb0 instantiate_class_template_1
../../gcc/gcc/cp/pt.c:8687
0x5d0eb0 instantiate_class_template(tree_node*)
../../gcc/gcc/cp/pt.c:9216
0x65cdcb complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:132
0x54da66 start_decl_1(tree_node*, bool)
../../gcc/gcc/cp/decl.c:4670
0x577851 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4633
0x649a5a cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:16447
0x64a32f cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10986
0x64c190 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10867
0x6551ae cp_parser_declaration
../../gcc/gcc/cp/parser.c:10764
0x653f0d cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10650
0x6557e6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x6557e6 c_parse_file()
../../gcc/gcc/cp/parser.c:28893
Please submit a full bug report, [etc.]

[Bug libstdc++/58514] Undefined symbol in libstdc++.so starting with rev 202818

[ppluzhnikov at google dot com]

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

--- Comment #2 from Paul Pluzhnikov  ---
Fixed by r202832 and r202836.

Sorry about the breakage.

[Bug c++/58518] [4.8/4.9 regression] ICE with template specialization

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug c++/58500] [C++1y] Crash with auto in function parameter

[abutcher at gcc dot gnu.org]

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

--- Comment #2 from abutcher at gcc dot gnu.org ---
Author: abutcher
Date: Mon Sep 23 22:43:44 2013
New Revision: 202851

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

gcc/cp/
PR c++/58500
* type-utils.h (find_type_usage): Only traverse one type level into
member function pointers.

gcc/testsuite/
PR c++/58500
* g++.dg/cpp1y/pr58500.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/pr58500.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/type-utils.h
trunk/gcc/testsuite/ChangeLog

[Bug driver/58512] [Feature request] -Wformat extensions to accomodate custom rules

[daniel.santos at pobox dot com]

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

--- Comment #2 from Daniel Santos  ---
Ahh, thanks so much!  Sorry I failed to find the related bugs. :(

[Bug driver/58505] jv-convert fails to compile with gcj-4.8.2

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
I believe this was fixed on trunk by the following change:

2013-05-22  Matthias Klose  

* jvspec.c (jvgenmain_spec): Add %I to cc1 call.