[Bug other/56811] [4.8/4.9 Regression] libbacktrace causes undefined symbol "_Unwind_GetIPInfo" on ia64-hpux

[misty at brew dot sh]

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

--- Comment #7 from Misty De Meo  ---
Checking the GCC database, I noticed a similar issue regarding GCC 4.4.3:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47609

Checking the symbol list in libgcc_s and libstdc++, I can see that it's true
that OS X 10.4's GCC C++ stdlib doesn't include that symbol; the OS only
shipped with GCC 4.0.1. I assume GCC 4.4's libgcc_s/libstdc++ includes it, so
perhaps the problem is that the GCC 4.8 build is pulling in the wrong library.

Unfortunately I don't have the machine available for testing until next week.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

[rguenth at gcc dot gnu.org]

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

--- Comment #19 from Richard Biener  ---
Barking up wrong trees.  Hacky fix looks like:

Index: gcc/expr.c
===
--- gcc/expr.c  (revision 202043)
+++ gcc/expr.c  (working copy)
@@ -4753,6 +4753,9 @@ expand_assignment (tree to, tree from, b
{
  enum machine_mode address_mode;
  rtx offset_rtx;
+ rtx saved_to_rtx = to_rtx;
+ if (misalignp)
+   to_rtx = mem;

  if (!MEM_P (to_rtx))
{
@@ -4785,6 +4788,11 @@ expand_assignment (tree to, tree from, b
  to_rtx = offset_address (to_rtx, offset_rtx,
   highest_pow2_factor_for_target (to,
   offset));
+ if (misalignp)
+   {
+ mem = to_rtx;
+ to_rtx = saved_to_rtx;
+   }
}

   /* No action is needed if the target is not a memory and the field


volatile bitfield case to be audited as well:

  /* If the bitfield is volatile, we want to access it in the
 field's mode, not the computed mode.
 If a MEM has VOIDmode (external with incomplete type),
 use BLKmode for it instead.  */
  if (MEM_P (to_rtx))
{
  if (volatilep && flag_strict_volatile_bitfields > 0)
to_rtx = adjust_address (to_rtx, mode1, 0);
  else if (GET_MODE (to_rtx) == VOIDmode)
to_rtx = adjust_address (to_rtx, BLKmode, 0);
}

checks the wrong RTX if it got the movmisalign path.  Or rather,
-fstrict-volatile bitfields doesn't seem to work properly for
misaligned accesses?

[Bug middle-end/31279] Uninitialized warning for call-by-reference arguments with known intent(in)

[rguenth at gcc dot gnu.org]

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

Bug 31279 depends on bug 31094, which changed state.

Bug 31094 Summary: Support annotating function parameters as read-only and/or 
non-escaping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug c/31893] Please provide an "inout" attribute for function parameters.

[rguenth at gcc dot gnu.org]

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

Bug 31893 depends on bug 31094, which changed state.

Bug 31094 Summary: Support annotating function parameters as read-only and/or 
non-escaping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/31094] Support annotating function parameters as read-only and/or non-escaping

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Richard Biener  ---
Not sure - the middle-end now has the 'fn spec' attribute, so middle-end
support
is ready.  The revision in question only marks IO library calls properly,
not as requested user functions with INTENT(IN)/INTENT(OUT) (?)

So, closing the middle-end part as fixed (this was a middle-end bug).

Eventually a Fortran bug still needs to be opened.

[Bug fortran/31593] Invariant DO loop variables and subroutines

[rguenth at gcc dot gnu.org]

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

Bug 31593 depends on bug 31094, which changed state.

Bug 31094 Summary: Support annotating function parameters as read-only and/or 
non-escaping
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31094

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/56977] gcc -Og incorrectly warns about 'constant zero length parameter'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||4.8.2
 Resolution|--- |FIXED
  Known to fail||4.8.1

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Wed Aug 28 08:29:48 2013
New Revision: 202046

URL: http://gcc.gnu.org/viewcvs?rev=202046&root=gcc&view=rev
Log:
2013-08-28  Richard Biener  

Backport from mainline
2013-06-24  Richard Biener  

PR middle-end/56977
* passes.c (init_optimization_passes): Move pass_fold_builtins
and pass_dce earlier with -Og.

* gcc.dg/pr56977.c: New testcase.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr56977.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/passes.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.

[rguenther at suse dot de]

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

--- Comment #16 from rguenther at suse dot de  ---
On Fri, 16 Aug 2013, pinskia at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50955
> 
> --- Comment #15 from Andrew Pinski  ---
> (In reply to Andrew Pinski from comment #14)
> > I am running into a similar situation with a modified 4.7 on
> > mips64-linux-gnu (configured to use the Octeon2 instructions which has a
> > load instruction which does base+index [or rather reg+reg]).
> 
> Before IV-OPTS I have this use:
>   i.17_13 = (sizetype) i_52;
>   D.13668_14 = i.17_13 + -1;
>   D.13669_15 = D.13668_14 * 4;
>   D.13670_16 = D.13666_12 + D.13669_15;
>   att_17 = *D.13670_16;
> 
> But we decided that it was not used as an address here though.  We have:
> (gdb) p *use->iv
> $15 = {base = 0x777e1c60, base_object = 0x0, step = 0x777e1c60,
> ssa_name = 0x0, biv_p = 0 '\000', 
>   have_use_for = 1 '\001', use_id = 0}
> (gdb) p *use
> $16 = {id = 3, type = USE_NONLINEAR_EXPR, iv = 0x1376bb0, stmt =
> 0x7727c780, op_p = 0x0, related_cands = 0x0, 
>   n_map_members = 10, cost_map = 0x13de580, selected = 0x0}

The original fix was supposed to be as small as possible (late in
the release cycle).  So it intentionally wasn't trying to be complete.

If you can provide a reproducer on trunk I'll gladly have a look
again (please open a new bugreport)

[Bug middle-end/57287] [4.9 Regression] Bogous uninitialized warning with abnormal control flow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|REOPENED|NEW
 CC|rguenther at suse dot de   |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |4.9.0
Summary|GCC 4.9.0 fails to build|[4.9 Regression] Bogous
   |GDB on Ubuntu 12.04 |uninitialized warning with
   ||abnormal control flow

--- Comment #15 from Richard Biener  ---
Confirmed.  David, can you have a look here?  I had a hard time following what
exactly to do with the dataflow in the uninit pass for abnormal control flow
(abnormal control flow should be considered receiving an initialized value).

Thanks.

[Bug target/57927] -march=core-avx2 different than -march=native on INTEL Haswell (i7-4700K)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-08/msg01602.htm
   ||l
   Target Milestone|--- |4.8.2

--- Comment #9 from Uroš Bizjak  ---
Also backported to 4.8 (and in part to 4.7) branch.

[Bug middle-end/58106] ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
Created attachment 30708
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30708&action=edit
Patch

The problem is that the rdesc chain creation mechanism cannot handle
the case where indirect inlining creates its master_clone and we are
thus "normally" cloning an inline tree.  Fixed with this (fully
tested) patch.  I forgot to add the testcase, will do that before
submitting.  I would also like to measure the chain lengths on at
least a few benchmarks first too.

[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array

[bernd.edlinger at hotmail dot de]

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

--- Comment #20 from Bernd Edlinger  ---
(In reply to Richard Biener from comment #19)
> volatile bitfield case to be audited as well:
> 
>   /* If the bitfield is volatile, we want to access it in the
>  field's mode, not the computed mode.
>  If a MEM has VOIDmode (external with incomplete type),
>  use BLKmode for it instead.  */
>   if (MEM_P (to_rtx))
> {
>   if (volatilep && flag_strict_volatile_bitfields > 0)
> to_rtx = adjust_address (to_rtx, mode1, 0);
>   else if (GET_MODE (to_rtx) == VOIDmode)
> to_rtx = adjust_address (to_rtx, BLKmode, 0);
> }
> 
> checks the wrong RTX if it got the movmisalign path.  Or rather,
> -fstrict-volatile bitfields doesn't seem to work properly for
> misaligned accesses?

Definitely. -fstrict-volatile-bitfields does not work at all.
Especially not fo misaligned accesses, or packed structures.
That's what Sanda Loosemore's patch is trying to fix.
As I repeatedly told. Please have a look at it if you can.

If flag_struct_volatile_bitfilds > 0 the
mode1 is diffent here than without.

[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug libstdc++/58148] [4.9 Regression] Fails to insert iterator range into sequence container with -D_GLIBCXX_DEBUG when conversion is needed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug rtl-optimization/57422] [4.9 Regression] ICE: SIGSEGV in dominated_by_p with custom flags

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug middle-end/58024] [4.9 Regression] segfault with -fopenmp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/58121] [4.9 regression] FAIL: cc1224a

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug c++/57945] [4.9 Regression] ICE: in varpool_get_node, at cgraph.h:840

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug bootstrap/58242] [4.9 regression] linux-android.c:40:7: error: 'OPTION_BIONIC' was not declared in this scope breaks bootstrap on powerpc64-linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/58026] [4.9 Regression] [OOP] ICE in generate_finalization_wrapper, at fortran/class.c:1521

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug regression/58221] [4.9 Regression]: Immense amount of execution regressions and increased test-time for cris-elf

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug ada/58239] [4.9 regression] pretty-print.c:789: undefined reference to `operator delete(void*)'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug middle-end/58094] [4.9 Regression] IPA devirt testsuite errors

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug tree-optimization/57732] [4.8/4.9 Regression] ICE (segfault in libisl) building drizzle on 32bit targets (at least arm-linux and i586-linux)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2
Summary|[4.8 / 4.9 Regression] ICE  |[4.8/4.9 Regression] ICE
   |(segfault in libisl)|(segfault in libisl)
   |building drizzle on 32bit   |building drizzle on 32bit
   |targets (at least arm-linux |targets (at least arm-linux
   |and i586-linux) |and i586-linux)

[Bug middle-end/57955] [4.7/4.8/4.9 Regression] Uniquization of constants reduces alignment of initializers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4
Summary|[4.6/4.7/4.8/4.9|[4.7/4.8/4.9 Regression]
   |Regression] Uniquization of |Uniquization of constants
   |constants reduces alignment |reduces alignment of
   |of initializers |initializers

[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectorized loops only for N== 1 and N >2 but not for N==2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2
Summary|[4.8/4.9 Regression]|[4.8/4.9 Regression]
   |-ftree-vectorizer-verbose=< |-ftree-vectorizer-verbose=<
   |n> shows vectroiyed loops   |n> shows vectorized loops
   |only for N== 1 and N >2 but |only for N== 1 and N >2 but
   |not for N==2|not for N==2

[Bug c++/58207] [4.8/4.9 Regression] ICE in sort_constexpr_mem_initializers due to out of bounds vector access

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.8.2

[Bug rtl-optimization/57967] [4.7 regresssion] Incorrect code generated on ARM with -fexpensive-optimizations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.7.4

[Bug gcov-profile/58250] -fprofile-use causes: "warning: -fprefetch-loop-arrays is not supported with -Os"

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
(In reply to Markus Trippelsdorf from comment #0)
> Just noticed this issue during a PGO/LTO Firefox build.
> During the -fprofile-use phase I always get the following warning:
>  warning: -fprefetch-loop-arrays is not supported with -Os [enabled by
> default]
> 
> This is caused by rev.193135:
>/* Enable sw prefetching at -O3 for CPUS that prefetching is helpful.  */
>if (flag_prefetch_loop_arrays < 0
>&& HAVE_prefetch
> -  && optimize >= 3
> +  && (optimize >= 3 || flag_profile_use)
>&& TARGET_SOFTWARE_PREFETCHING_BENEFICIAL)
>  flag_prefetch_loop_arrays = 1;
> 
> 
> Does the following patch look OK?
> 
> diff --git a/gcc/toplev.c b/gcc/toplev.c
> index 53f53fd..9955ed4 100644
> --- a/gcc/toplev.c
> +++ b/gcc/toplev.c
> @@ -1506,7 +1506,7 @@ process_options (void)
>  
>/* This combination of options isn't handled for i386 targets and doesn't
>   make much sense anyway, so don't allow it.  */
> -  if (flag_prefetch_loop_arrays > 0 && optimize_size)
> +  if (flag_prefetch_loop_arrays > 0 && optimize_size && !flag_profile_use)
>  {
>warning (0, "-fprefetch-loop-arrays is not supported with -Os");
>flag_prefetch_loop_arrays = 0;

Hmm, I rather question this hunk - where does it come from?  Why is
prefetching "unsupported" at -Os?

[Bug gcov-profile/58250] -fprofile-use causes: "warning: -fprefetch-loop-arrays is not supported with -Os"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Prefetching generally increases code size, so I think we shouldn't do it, at
least not by default.  So I'd say for !optimize_size -fprofile-use should just
not add -fprefetch-loop-arrays.

[Bug middle-end/58257] New: [4.8/4.9 Regression] Bogus warning with OpenMP collapsed loops

[jakub at gcc dot gnu.org]

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

Bug ID: 58257
   Summary: [4.8/4.9 Regression] Bogus warning with OpenMP
collapsed loops
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: jakub at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

/* { dg-do compile } */
/* { dg-options "-O2 -fopenmp -Wall" } */

int
foo (int n)
{
  int a[10][10];
  int x, y;
#pragma omp parallel for collapse(2)
  for (x = 0; x < n; x++)/* { dg-bogus "may be used uninitialized in this
function" } */
for (y = 0; y < n; y++)
  a[x][y] = x + y * y;
  return a[0][0];
}

yields:
rh999674.c: In function ‘’:
rh999674.c:10:3: warning: ‘.count.6’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
rh999674.c:10:3: note: ‘.count.6’ was declared here
rh999674.c:10:3: warning: ‘.count.7’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
rh999674.c:10:3: note: ‘.count.7’ was declared here

[Bug middle-end/58257] [4.8/4.9 Regression] Bogus warning with OpenMP collapsed loops

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-28
 CC||mpolacek at gcc dot gnu.org
  Known to work||4.7.3
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.0

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug middle-end/58257] [4.8/4.9 Regression] Bogus warning with OpenMP collapsed loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Target Milestone|--- |4.8.2

[Bug middle-end/58257] [4.8/4.9 Regression] Bogus warning with OpenMP collapsed loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Aug 28 10:08:59 2013
New Revision: 202049

URL: http://gcc.gnu.org/viewcvs?rev=202049&root=gcc&view=rev
Log:
PR middle-end/58257
* omp-low.c (copy_var_decl): Copy over TREE_NO_WARNING flag.

* c-c++-common/gomp/pr58257.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/gomp/pr58257.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/testsuite/ChangeLog

Author: jakub
Date: Wed Aug 28 10:10:43 2013
New Revision: 202050

URL: http://gcc.gnu.org/viewcvs?rev=202050&root=gcc&view=rev
Log:
PR middle-end/58257
* omp-low.c (copy_var_decl): Copy over TREE_NO_WARNING flag.

* c-c++-common/gomp/pr58257.c: New test.

Added:
branches/gcc-4_8-branch/gcc/testsuite/c-c++-common/gomp/pr58257.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/omp-low.c
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug c++/58255] [C++11] explicit delegating constructor with no arguments wrongly rejected

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-08-28
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
Seems easy.

[Bug c++/58255] [C++11] explicit delegating constructor with no arguments wrongly rejected

[paolo.carlini at oracle dot com]

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

--- Comment #2 from Paolo Carlini  ---
I'm finishing testing this:

Index: init.c
===
--- init.c(revision 202020)
+++ init.c(working copy)
@@ -1465,6 +1465,7 @@ build_aggr_init (tree exp, tree init, int flags, t
   TREE_THIS_VOLATILE (exp) = 0;

   if (init && TREE_CODE (init) != TREE_LIST
+  && init != void_type_node
   && !(TREE_CODE (init) == TARGET_EXPR
&& TARGET_EXPR_DIRECT_INIT_P (init))
   && !(BRACE_ENCLOSED_INITIALIZER_P (init)

[Bug c++/58258] New: cp_tree_equal and unknown symbol take up 70% of (astronomical) build time

[geoffers+gccbug at gmail dot com]

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

Bug ID: 58258
   Summary: cp_tree_equal and unknown symbol take up 70% of
(astronomical) build time
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: geoffers+gccbug at gmail dot com

Created attachment 30709
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30709&action=edit
Slow compiling file

With the attached file (sorry about the size — I'm going away on holiday and
have run out of time to reduce it and would likely forget about it — though it
is an improvement on the 2.3MB preprocessed source file it started off as!),
g++ takes ~90s to compile, whereas clang++ takes ~3s. (On the original,
non-reduced testcase, g++ took ~2h, clang++ took ~20s — a 400x difference.)
This, somewhat obviously, isn't acceptable to me as an end-user.

Notably expensive, from `perf record g++ -c -O0 -Wfatal-errors -std=c++11
-fpreprocessed -w -S -o /dev/null testcase.i`:

 44.89%  cc1plus  cc1plus[.] 0x0065a167
 14.73%  cc1plus  cc1plus[.] cp_tree_equal(tree_node*, tree_node*)
  8.05%  cc1plus  cc1plus[.] dependent_name(tree_node*)
  5.29%  cc1plus  cc1plus[.] operand_equal_p(tree_node const*,
tree_node const*, unsigned int)
  5.05%  cc1plus  cc1plus[.] ggc_internal_alloc_stat(unsigned long)

To contrast with a limited sample of the original (I'm not recording the
two-hour compilation, the perf.data file would be huge!):

+  54.76%  cc1plus  cc1plus[.] 0x006482d9   
+  20.42%  cc1plus  cc1plus[.] cp_tree_equal(tree_node*,
tree_node*)
+  13.97%  cc1plus  cc1plus[.] dependent_name(tree_node*)

I'm using the ArchLinux packaged GCC/Clang, i.e.,

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20130725/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--disable-install-libiberty --disable-multilib --disable-libssp
--disable-werror --enable-checking=release
Thread model: posix
gcc version 4.8.1 20130725 (prerelease) (GCC)

[Bug target/58259] New: PowerPC: Atomic flag test and set generates NULL pointer read and write

[sebastian.hu...@embedded-brains.de]

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

Bug ID: 58259
   Summary: PowerPC: Atomic flag test and set generates NULL
pointer read and write
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de

The GCC C compiler generates a NULL pointer read and write for the atomic flag
test and set method in GCC 4.7, 4.8 and 4.9.  The GCC C++ compiler doesn't have
this problem.

C test case:

#include 

_Bool test_and_set(atomic_flag *flag)
{
  return atomic_flag_test_and_set_explicit(flag, memory_order_acquire);
}

C++ test case:

#include 

bool test_and_set(std::atomic_flag &flag)
{
  return flag.test_and_set(std::memory_order_acquire);
}

GCC assembler output:

powerpc-eabi-gcc-4.7.0 -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.file   "test.c"
.section".text"
.align 2
.globl test_and_set
.type   test_and_set, @function
test_and_set:
li 10,0
rlwinm 9,3,3,27,28
lbz 5,0(10) <--- HERE IS THE NULL POINTER READ
xori 9,9,24
li 7,255
li 6,1
rlwinm 3,3,0,0,29
slw 7,7,9
slw 5,5,9
slw 6,6,9
.L2:
lwarx 10,0,3
and 8,10,7
cmpw 0,8,5
andc 8,10,7
or 8,8,6
bne- 0,.L3
stwcx. 8,0,3
bne- 0,.L2
.L3:
isync
srw 10,10,9
li 9,0
mfcr 3
rlwinm 3,3,3,1
stb 10,0(9) <--- HERE IS THE NULL POINTER WRITE
blr
.size   test_and_set, .-test_and_set
.ident  "GCC: (GNU) 4.7.0 20120202 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

powerpc-eabi-gcc -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.file   "test.c"
.section".text"
.align 2
.globl test_and_set
.type   test_and_set, @function
test_and_set:
li 9,0
li 7,255
lbz 5,0(9)
rlwinm 9,3,3,27,28
xori 9,9,24
li 6,1
rlwinm 3,3,0,0,29
slw 7,7,9
slw 5,5,9
slw 6,6,9
.L2:
lwarx 10,0,3
and 4,10,7
andc 8,10,7
cmpw 0,4,5
or 8,8,6
bne- 0,.L3
stwcx. 8,0,3
bne- 0,.L2
.L3:
isync
srw 10,10,9
li 9,0
stb 10,0(9)
mfcr 3
rlwinm 3,3,3,1
blr
    .size   test_and_set, .-test_and_set
.ident  "GCC: (GNU) 4.9.0 20130828 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

powerpc-eabi-g++ -std=c++11 -Wall -Wextra -O2 -S test.cc && cat test.s
.file   "test.cc"
.section".text"
.align 2
.globl _Z12test_and_setRSt11atomic_flag
.type   _Z12test_and_setRSt11atomic_flag, @function
_Z12test_and_setRSt11atomic_flag:
.LFB326:
.cfi_startproc
rlwinm 9,3,3,27,28
li 6,255
xori 9,9,24
li 7,1
rlwinm 8,3,0,0,29
slw 6,6,9
slw 7,7,9
.L2:
lwarx 3,0,8
andc 10,3,6
or 10,10,7
stwcx. 10,0,8
bne- 0,.L2
isync
srw 3,3,9
rlwinm 3,3,0,0xff
blr
.cfi_endproc
.LFE326:
.size   _Z12test_and_setRSt11atomic_flag,
.-_Z12test_and_setRSt11atomic_flag
.ident  "GCC: (GNU) 4.9.0 20130828 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

The ARMv7 architecture has a very similar atomic model and GCC generates valid
code:

arm-eabi-gcc -march=armv7-a -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.arch armv7-a
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file   "test.c"
.text
.align  2
.global test_and_set
.type   test_and_set, %function
test_and_set:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #0
mov r1, #1
ldrbr2, [r3]@ zero_extendqisi2
.L2:
ldrexb  r3, [r0]
cmp r3, r2
bne .L3
strexb  ip, r1, [r0]
cmp ip, #0
bne .L2
.L3:
mov r2, #0
dmb sy
movne   r0, #0
moveq   r0, #1
strbr3, [r2]
bx  lr
.size   test_and_set, .-test_and_set
.ident  "GCC

[Bug target/58259] ARM, PowerPC: Atomic flag test and set generates NULL pointer read and write

[sebastian.hu...@embedded-brains.de]

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

Sebastian Huber  changed:

   What|Removed |Added

 Target|powerpc-eabi|powerpc-eabi, arm-eabi
Summary|PowerPC: Atomic flag test   |ARM, PowerPC: Atomic flag
   |and set generates NULL  |test and set generates NULL
   |pointer read and write  |pointer read and write

--- Comment #1 from Sebastian Huber  ---
Sorry, also the ARMv7 has the NULL pointer read and write problem:

arm-eabi-gcc -march=armv7-a -std=c11 -Wall -Wextra -O2 -S test.c && cat test.s
.arch armv7-a
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 1
.eabi_attribute 30, 2
.eabi_attribute 34, 1
.eabi_attribute 18, 4
.file   "test.c"
.text
.align  2
.global test_and_set
.type   test_and_set, %function
test_and_set:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, #0
mov r1, #1
ldrbr2, [r3]@ zero_extendqisi2 <-- NULL POINTER READ
.L2:
ldrexb  r3, [r0]
cmp r3, r2
bne .L3
strexb  ip, r1, [r0]
cmp ip, #0
bne .L2
.L3:
mov r2, #0
dmb sy
moveq   r0, #1
strbr3, [r2] <-- NULL POINTER WRITE
movne   r0, r2
bx  lr
.size   test_and_set, .-test_and_set
.ident  "GCC: (GNU) 4.9.0 20130828 (experimental) [master revision
022fc2d:bffd767:fd457cef14f3bc6673e90a2de80005feea743ab7]"

[Bug libgcc/58260] New: configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[anand.karanam at tcs dot com]

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

Bug ID: 58260
   Summary: configure: error: cannot compute suffix of object
files: cannot compile See `config.log' for more
details. gmake[1]: *** [configure-target-libgcc] Error
1
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anand.karanam at tcs dot com

Created attachment 30710
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30710&action=edit
configuration file

While preparing cross compiler from Solaris10 to Linux problem seem during the
build of we observe the error 

checking for i686-pc-linux-gnu-gcc...
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/./gcc/xgcc
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/./gcc/
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/bin/
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/lib/
-isystem
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/include
-isystem
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/sys-include
 
checking for suffix of object files... configure: error: in
`/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/i686-pc-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
gmake[1]: *** [configure-target-libgcc] Error 1
gmake[1]: Leaving directory
`/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu'
make: *** [all] Error 2


Compiler is installed ( problem with libgcc and libstdcc++ builds)
but can't be used.





Environment variables

CLEARCASE_ROOT=/view/ekarana_solaris_to_linux
CLEARCASE_CMDLINE=setview ekarana_solaris_to_linux
USER=ekarana
LOGNAME=ekarana
HOME=/home/ekarana
PATH=/app/texinfo/4.0/bin:/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/bin:/app/openssl/1.0.0/bin:/vobs/cello/cade_struct/SunOS/sparc/bin/jdk1.4:/vobs/cello/cade_struct/SunOS/sparc/bin:/vobs/cello/cade_struct/bin:/usr/atria/bin:/home/ekarana/bin:/proj/swdi/tools/bin:/vobs/axeste/fwsime/eriemu/bin/ERIemu-FW/bin:/app/git/1.7.2.2/LMWP3/bin:/app/git/1.7.2.2/LMWP3/libexec/git-core:/local/Apstools/4.5/lib/tcl/bin:/opt/rational/clearcase/sun5/bin:/vobs/wds/otd/Developer/bin:/app/emake/sekisparc/bin:/app/git/1.8.3.3/bin:/app/git/1.8.3.3/libexec/git-core:/app/jdk/1.6.0_16/bin:/app/nedit/5.5.1/bin:/app/emacs/23.2/bin:/app/nxclient/3.4.0.7/bin:/app/vim/7.3.021/bin:/app/xemacs/21.5.29/bin:/app/thunderbird/3.1.6:/app/thunderbird/3.1.6/bin:/app/openoffice/3.2.1/bin:/app/j2re/1.6.0_22/bin:/app/ica/client/8.63:/app/acroread/8.1.7/Adobe/Reader8/bin:/app/firefox/3.6.12:/home/ekarana/.afs/0/rbin:/home/ekarana/.afs/0/pbin:/env/seki/bin:/home/ekarana/.afs/0/ibin:/usr/afsws/bin:/u
 
sr/bin:/bin:/usr/sbin:/sbin:/opt/quest/bin:/usr/openwin/bin:/usr/dt/bin:/usr/ccs/bin:/app/arc/0/bin:/usr/ucb:/vobs/cello/cade_struct/tools/coverity/SunOS/sparc/cov-analysis/bin:.
MAIL=/var/mail//ekarana
SHELL=/bin/tcsh
TZ=MET
SSH_CLIENT=147.214.14.232 48272 22
SSH_CONNECTION=147.214.14.232 48272 147.214.15.85 22
SSH_TTY=/dev/pts/452
TERM=xterm
DISPLAY=localhost:20.0

HOSTTYPE=sun4
VENDOR=sun
OSTYPE=solaris
MACHTYPE=sparc
SHLVL=2
PWD=/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu
GROUP=cello
HOST=esekits1047
REMOTEHOST=esekilxxen1309.rnd.ericsson.se
SITE=seki
ARC_ENV=seki
ARC_RELEASE=0
_system_path=/usr/bin:/bin:/usr/sbin:/sbin:/opt/quest/bin
MODULEPATH=/vobs/cello/cade_struct/modules:/app/modules/0/modulefiles:/home/ekarana/.afs/0/rmodules:/home/ekarana/.afs/0/pmodules:/env/seki/modules:/home/ekarana/.afs/0/imodules:/env/common/modules
LOADEDMODULES=firefox/3.6.12:acroread/8.1.7:flashplayer/10.1:ica/8.63:j2re/1.6.0_22:openoffice/3.2.1:thunderbird/3.1.6:xemacs/21.5.29:vim/7.3.021:nxclient/3.4.0.7:emacs/23.2:isit_modules:nedit/5.5.1:j2sdk/1.6.0_16:git/1.8.3.3:emake/sekisparc:coverity:openssl/1.0.0:texinfo/4.0
PROJ_NR=0
CCHOME=/usr/atria
MAGIC_PATH=/usr/atria/config/magic
LANG=en_US
LC_TIME=C
LC_MESSAGES=C
LC_COLLATE=C
_MODULESBEGINENV_=/home/ekarana/.modulesbeginenv
_LMFILES_=/env/common/modules/firefox/3.6.12:/env/common/modules/acroread/8.1.7:/env/common/modules/flashplayer/10.1:/env/common/modules/ica/8.63:/env/common/modules/j2re/1.6.0_22:/env/common/modules/openoffice/3.2.1:/env/common/modules/thunderbird/3.1.6:/env/common/modules/xemacs/21.5.29:/env/common/modules/vim/7.3.021:/env/common/modules/nxclient/3.4.0.7:/en

[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[mikpe at it dot uu.se]

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

--- Comment #1 from Mikael Pettersson  ---
(In reply to anand.karanam from comment #0)
> checking for suffix of object files... configure: error: in
> `/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/
> sparc-sun-solaris2.10-i686-pc-linux-gnu/i686-pc-linux-gnu/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> gmake[1]: *** [configure-target-libgcc] Error 1
> gmake[1]: Leaving directory
> `/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/
> sparc-sun-solaris2.10-i686-pc-linux-gnu'
> make: *** [all] Error 2

You need to look in that config.log file to see what the error was.  There are
several config.log files in the build tree, it should be in a `libgcc'
sub-directory.  I usually do 'find . -name config.log | xargs ls -tl | head' to
find the most recent one (which will be the one with the final hard error).

[Bug tree-optimization/57685] [4.8/4.9 Regression] GCC stuck in an infinite loop

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Hmm, it's register_edge_assert_for_1 not limiting its recursion and not
avoiding duplicate visits.  Which in this case leads to exponential
compile-time behavior.
We can mitigate the latter by only considering single-use defs.

[Bug middle-end/58245] -fstack-protector[-all] does not protect functions that call noreturn functions

[rose.garcia-eggl2fk at yopmail dot com]

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

Rose Garcia  changed:

   What|Removed |Added

 CC||rose.garcia-eggl2fk@yopmail
   ||.com

--- Comment #4 from Rose Garcia  ---
the place to get only the GCC patches for musl is
https://github.com/GregorR/musl-gcc-patches though.


btw, some debugging has shown that
stack_protect_prologue() and
stack_protect_epilogue() are both called, so it looks as if it's a later pass
that decides to eliminate the "dead" code of the epilogue, but not the one of
the prologue.

any hints where in the code this could happen is appreciated.

[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
   Severity|major   |normal

--- Comment #2 from Jonathan Wakely  ---
Please read http://gcc.gnu.org/wiki/FAQ#configure_suffix and then read
http://gcc.gnu.org/wiki/InstallingGCC

[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[anand.karanam at tcs dot com]

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

anand.karanam at tcs dot com changed:

   What|Removed |Added

 CC||anand.karanam at tcs dot com

--- Comment #3 from anand.karanam at tcs dot com ---
Created attachment 30711
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30711&action=edit
libgcc configuratrion informatoin

Added the config.log of libgcc

[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
The relevant part of the file is:

configure:3055:
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/./gcc/xgcc
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/./gcc/
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/bin/
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/lib/
-isystem
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/include
-isystem
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/sys-include
   -o conftest -g -Os   conftest.c  >&5
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: Bus Error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3058: $? = 1
configure:3246: checking for suffix of object files
configure:3268:
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/./gcc/xgcc
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/./gcc/
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/bin/
-B/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/lib/
-isystem
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/include
-isystem
/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/SunOS/sparc/i686-pc-linux-gnu/sys-include
   -c -g -Os  conftest.c >&5
conftest.c: In function 'main':
conftest.c:16:1: internal compiler error: Bus Error
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
configure:3272: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/";
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3286: error: in
`/home/ekarana/ekarana_2013/GCC463_OSE5.6/Solaris_to_Linux/INSTALL/build-gcc/sparc-sun-solaris2.10-i686-pc-linux-gnu/i686-pc-linux-gnu/libgcc':
configure:3289: error: cannot compute suffix of object files: cannot compile


I still suggest you follow the instructions at
http://gcc.gnu.org/wiki/InstallingGCC instead of installing gmp, mpfr and mpc
separately.

[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[mikpe at it dot uu.se]

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

--- Comment #4 from Mikael Pettersson  ---
You got several 'conftest.c:16:1: internal compiler error: Bus Error' from the
newly built compiler.

You should try one of those compilation attempts manually, in gdb, to see where
the SIGBUS is coming from.

I see that you configured with --with-{gmp,mpfr,mpc} pointing into a private
install.  That's OK, but unless you built those libraries with --disable-shared
you also have to set up LD_LIBRARY_PATH so that they can be found by the
dynamic linker.  Otherwise it might load incompatible versions installed
elsewhere.

(I always build gmp/mpfr/mpc with --disable-shared exactly to avoid such
issues.)

[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Mikael Pettersson from comment #4)
> (I always build gmp/mpfr/mpc with --disable-shared exactly to avoid such
> issues.)

Why not just build them in tree and avoid all problems?

[Bug fortran/58100] Spurious "DO loop at (1) will be executed zero times" warning

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #6 from Thomas Koenig  ---
So, let's close this as WONTFIX (because moving dead code
elimination into the front end will not happen anytime
soon - unless somebody volunteers, of course ;-)

[Bug c/48885] missed optimization with restrict qualifier?

[pa...@matos-sorge.com]

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

Paulo J. Matos  changed:

   What|Removed |Added

 CC||pa...@matos-sorge.com

--- Comment #3 from Paulo J. Matos  ---
My understanding is that for restrict optimization to take effect, variable a
has also to be restrict. Otherwise in the first assignment *a = *v;, a could
point to the same memory as v and therefore overwrite it, rendering the value
of *v in *b = *v; invalid. I think gcc is now doing the right thing.

[Bug tree-optimization/57511] [4.8/4.9 Regression] Missing SCEV final value replacement

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||spop at gcc dot gnu.org
 Blocks||5

--- Comment #3 from Richard Biener  ---
analyze_scalar_evolution_in_loop fails for a_4 in

  :
  # i_11 = PHI 
  # a_12 = PHI 
  _3 = i_11 + 16711935;
  a_4 = _3 + a_12;
  i_5 = i_11 + 1;
  if (i_5 != 10)
goto ;
  else
goto ;

  :
  # a_6 = PHI 
  return a_6;

the evolution is {16711935, +, _3 + 1}_1 but the evolution of _3
is { 16711935, +, 1 }_1 and { 16711935, +, { 16711935, +, 1 }_1 + 1}_1
isn't a valid evolution.  Even though 4.7 computed:

(chrec_apply
  (varying_loop = 1
)
  (chrec = {16711935, +, {16711936, +, 1}_1}_1)
  (x = 9)
  (res = 167119395))

this is probably caused by the fix for PR5.

I will experiment with relaxing it a bit tomorrow.  But the question
remains(?), is

  { 16711935, +, { 16711935, +, 1 }_1 + 1}_1

a valid scalar evolution?

[Bug spam/58261] New: Test bug 1

[jakub at gcc dot gnu.org]

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

Bug ID: 58261
   Summary: Test bug 1
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: spam
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

Testing svnmailer.

[Bug spam/58262] New: Test bug 2

[jakub at gcc dot gnu.org]

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

Bug ID: 58262
   Summary: Test bug 2
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: spam
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org

Testing svnmailer.

[Bug spam/58262] Test bug 2

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed Aug 28 14:41:27 2013
New Revision: 202051

URL: http://gcc.gnu.org/viewcvs?rev=202051&root=gcc&view=rev
Log:
PR spam/58261
PR spam/58262
Fix up ChangeLog entry whitespace.

Modified:
trunk/gcc/ChangeLog

[Bug spam/58261] Test bug 1

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Wed Aug 28 14:41:27 2013
New Revision: 202051

URL: http://gcc.gnu.org/viewcvs?rev=202051&root=gcc&view=rev
Log:
PR spam/58261
PR spam/58262
Fix up ChangeLog entry whitespace.

Modified:
trunk/gcc/ChangeLog

[Bug c++/58263] New: [feature request] friend class $UndefinedClass

[vova7890 at mail dot ru]

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

Bug ID: 58263
   Summary: [feature request] friend class $UndefinedClass
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vova7890 at mail dot ru

Idea is in:

class MyClass1
{
   friend class MyClas2; // trivial stupid human issue with MyClas2 -> MyClass2
private:
   void help();
};


class MyClass2
{
public:
   void need(MyClass1 *cl) {
  cl->help();   // error: is private!!
   }
};


Maybe need to check, have we declaration or not. If not - got a warning about
missing declaration.

[Bug c++/58263] [feature request] friend class $UndefinedClass

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Severity|trivial |enhancement

--- Comment #1 from Jonathan Wakely  ---
(In reply to vova7890 from comment #0)
> Maybe need to check, have we declaration or not. If not - got a warning
> about missing declaration.

That can't work, consider:

// A.h
class A {
  A();
  friend class B;
};

// B.h
#include "A.h"
class B { };

// A.cc
#include "A.h"
A::A() {}

Do we warn in A.cc that B is not defined? It is defined in another header, but
that isn't included by A.cc because it isn't needed.

[Bug ipa/58106] ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

URL||http://gcc.gnu.org/ml/gcc-p
   ||atches/2013-08/msg01701.htm
   ||l

--- Comment #4 from Martin Jambor  ---
I have submitted the patch to the mailing list for approval:

http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01701.html

[Bug spam/58261] Test bug 1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Hopefully fixed.

[Bug spam/58262] Test bug 2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Hopefully fixed.

[Bug spam/58262] Test bug 2

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Hoorah! Thanks, Jakub

[Bug target/58259] ARM, PowerPC: Atomic flag test and set generates NULL pointer read and write

[sebastian.hu...@embedded-brains.de]

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

Sebastian Huber  changed:

   What|Removed |Added

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

--- Comment #2 from Sebastian Huber  ---
Sorry for the noise, this was due to a broken FreeBSD  header
file.

[Bug tree-optimization/56933] [4.9 Regression] Vectorizer missing read-write dependency for interleaved accesses

[bernd.edlinger at hotmail dot de]

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

--- Comment #7 from Bernd Edlinger  ---
Created attachment 30712
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30712&action=edit
fixed test case

Looking deeper into the matter it seems like this an example
where vectorisation is not supposed to happen.
But this is still vectorized and causes the crash here:

   for (i = 0; i < 2*1024; i++)
 d[i] = 1.;


So this is my proposed fix for the test case:
- added check_vect() to prevent invalid instruction as Jakub suggested
- addeded scan-tree-dump to detect the READ_WRITE depencency
  to make sure that the vectorization in foo() did not happen
  for the right reason.

[Bug libgcc/58260] configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[1]: *** [configure-target-libgcc] Error 1

[mikpe at it dot uu.se]

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

--- Comment #7 from Mikael Pettersson  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Mikael Pettersson from comment #4)
> > (I always build gmp/mpfr/mpc with --disable-shared exactly to avoid such
> > issues.)
> 
> Why not just build them in tree and avoid all problems?

Because
1. building those libraries with --disable-shared and pointing gcc's configure
to them (--with-gmp= etc) is trivial and also avoids the problems,
2. I build gcc a lot (several branches x several architectures), I really don't
want to waste time and electricity rebuilding those libraries again and again,
3. I want precise control over which versions of those libraries I'm testing,
4. as a matter of principle I think pre-requisites should be strictly external
to the gcc build process, otherwise were do we stop? should we download and
build make, bash, coreutils, gdb, expect, glibc, ... just because the build
needs them? special-casing gmp/mpfr/mpc is completely unnecessary

[Bug ada/58264] New: Incorrect 'First when assigning function-call.all (of access String;) to an indefinite String object

[hans.buhrer at lmco dot com]

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

Bug ID: 58264
   Summary: Incorrect 'First when assigning function-call.all (of
access String;) to an indefinite String object
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hans.buhrer at lmco dot com

Created attachment 30713
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30713&action=edit
Minimal Ada source to reproduce the problem

In the source below, the function Peek returns a pointer to a
(formally)unconstrained String. The actual lower bound of the dynamically
allocated String object is 1.
When Peek.all is assigned to an indefinite String variable, the dope vector is
apparently not copied, but the dynamically allocated dope vector is reused.
When the dynamically allocated object is then Free'd (including its dope
vector) the 'First of the indefinite string object turns to garbage (0).
This only seems to happen for pointer-to-String that are returned by a function
call.
--
with Ada.Text_Io;
with Ada.Unchecked_Deallocation;
procedure Failure is

  type String_Ptr_T is access String;
  procedure Free is new Ada.Unchecked_Deallocation (String, String_Ptr_T);
  String_Data : String_Ptr_T := new String'("Hello World");

  function Peek return String_Ptr_T is
  begin
return String_Data;
  end Peek;

begin
  declare
Corrupted_String : String := Peek.all; -- Fails
--Corrupted_String : String := String_Data.all;  -- Works
  begin
Ada.Text_Io.Put_Line(Integer'Image(Corrupted_String'First));
Free(String_Data);
Ada.Text_Io.Put_Line(Integer'Image(Corrupted_String'First));
  end;
end Failure;
--

elvm1>gnatmake -O0 -g failure.adb -cargs -v -save-temps -Wall -Wextra
gcc-4.6 -c -O0 -g -v -save-temps -Wall -Wextra failure.adb
Using built-in specs.
COLLECT_GCC=/usr//bin/gcc-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 
COLLECT_GCC_OPTIONS='-gnatea' '-c' '-O0' '-g' '-v' '-save-temps' '-Wall'
'-Wextra' '-gnatez' '-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.6/gnat1 -gnatwa -quiet -dumpbase failure.adb
-auxbase failure -O0 -Wall -Wextra -gnatez -gnatea -g -gnatez -mtune=generic
-march=i686 failure.adb -o failure.s
failure.adb:16:05: warning: "Corrupted_String" is not modified, could be
declared constant
COLLECT_GCC_OPTIONS='-gnatea' '-c' '-O0' '-g' '-v' '-save-temps' '-Wall'
'-Wextra' '-gnatez' '-mtune=generic' '-march=i686'
 as --32 -o failure.o failure.s
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.6/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-gnatea' '-c' '-O0' '-g' '-v' '-save-temps' '-Wall'
'-Wextra' '-gnatez' '-mtune=generic' '-march=i686'
gnatbind -x failure.ali
gnatlink failure.ali -O0 -g
elvm1>./failure
 1
 0

As a work around, using 

Corrupted_String : String := Peek.all & ""; 

helps.

[Bug c++/58263] [feature request] friend class $UndefinedClass

[vova7890 at mail dot ru]

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

--- Comment #2 from vova7890  ---
(In reply to Jonathan Wakely from comment #1)
> Do we warn in A.cc that B is not defined? It is defined in another header,
> but that isn't included by A.cc because it isn't needed.



We warn about implicit friend class MyClas2. For example, we wrong writed class
name(as in example MyClas2 -> MyClass2, missed the letter "s" in the word
Class), try to compile that and see:

[vova7890@localhost tmp]$ g++ -O2 main.cpp
main.cpp: In member function 'void MyClass2::need(MyClass1*)':
main.cpp:10:9: error: 'void MyClass1::help()' is private
void help();
 ^
main.cpp:18:16: error: within this context
   cl->help();   // error: is private!!


But, we don`t understand why it`s private, because we think that we correctly
writed class name(friend class MyClass2), and do not see where is the bug
exactly. But, if compiler say as, about implicit friend class MyClas2, like
this:

[vova7890@localhost tmp]$ g++ -O2 main.cpp
main.cpp:8:12: warning: implicit declaration of friend 'MyClas2'
friend class MyClas2;
 ^
main.cpp: In member function 'void MyClass2::need(MyClass1*)':
main.cpp:10:9: error: 'void MyClass1::help()' is private
void help();
 ^
main.cpp:18:16: error: within this context
   cl->help();   // error: is private!!


we see where is exactly issue, and just correct that stupid typo.

[Bug target/58067] ICE in GFortran recog.c:2158

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Wed Aug 28 16:31:41 2013
New Revision: 202055

URL: http://gcc.gnu.org/viewcvs?rev=202055&root=gcc&view=rev
Log:
PR target/58067
* config/i386/i386.md (*tls_global_dynamic_64_largepic): New insn.
(*tls_local_dynamic_base_64_largepic): Likewise.
(tls_global_dynamic_64_, tls_local_dynamic_base_64_):
Remove predicate from call operand.
* config/i386/i386.c (ix86_tls_get_addr): For -mcmodel=large -fpic
return sum of pic_offset_table_rtx and UNSPEC_PLTOFF of the symbol.

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

[Bug middle-end/57287] [4.9 Regression] Bogous uninitialized warning with abnormal control flow

[xinliangli at gmail dot com]

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

--- Comment #16 from davidxl  ---
(In reply to Richard Biener from comment #15)
> Confirmed.  David, can you have a look here?  I had a hard time following
> what
> exactly to do with the dataflow in the uninit pass for abnormal control flow
> (abnormal control flow should be considered receiving an initialized value).
> 
> Thanks.


I looked at it a little. The warning is not from the predicated uninit analysis
which checks uses of phi defs.  The warning is emitted from tree-ssa.c:1644 in
function warn_uninitialized_vars. It warns about the 'definitely' uninitialized
variable that may be executed. In this case it is use of 'buf_16(ab)' in BB3. 
Not sure where this statement comes from:

buf_24 = buf_16(ab);

The dot file is attached.

digraph "uninit.c.131t.uninit1" {
overlap=false;
subgraph "baz" {
color="black";
label="baz";
fn_11_basic_block_0
[shape=Mdiamond,style=filled,fillcolor=white,label="ENTRY"];

fn_11_basic_block_1
[shape=Mdiamond,style=filled,fillcolor=white,label="EXIT"];

fn_11_basic_block_2 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:1 |\:\l\
|varseen_11(ab)\ =\ 0;\l\
|_14\ =\ head\ ();\l\
}"];

fn_11_basic_block_3 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:7100 |\:\l\
|list\ =\ _14;\l\
|buf_24\ =\ buf_16(ab);\l\
|if\ (_14\ !=\ 0B)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_11_basic_block_4 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:8500 |\:\l\
|#\ varseen_3(ab)\ =\ PHI\ \<1(3),\ 1(6)\>\l\
|#\ n_26(ab)\ =\ PHI\ \<_14(3),\ n_2(ab)(6)\>\l\
|#\ buf_27(ab)\ =\ PHI\ \\l\
|buf_21\ =\ bar\ ();\l\
}"];

fn_11_basic_block_5 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:4250 |\:\l\
}"];

fn_11_basic_block_6 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:2900 |\:\l\
|#\ n_1(ab)\ =\ PHI\ \\l\
|#\ varseen_4(ab)\ =\ PHI\ \\l\
|#\ buf_6(ab)\ =\ PHI\ \\l\
|__sigsetjmp\ (buf_6(ab),\ 1);\l\
|n_19\ =\ n_1(ab)-\>next;\l\
|n_2(ab)\ =\ n_19;\l\
|varseen_5\ =\ varseen_4(ab);\l\
|buf_7(ab)\ =\ buf_6(ab);\l\
|if\ (n_2(ab)\ !=\ 0B)\l\
\ \ goto\ \;\l\
else\l\
\ \ goto\ \;\l\
}"];

fn_11_basic_block_7 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:1500 |\:\l\
|_25\ =\ varseen_5;\l\
}"];

fn_11_basic_block_8 [shape=record,style=filled,fillcolor=lightgrey,label="{
FREQ:1500 |\:\l\
|#\ _8\ =\ PHI\ \<_25(7),\ 0(3)\>\l\
|return\ _8;\l\
}"];

fn_11_basic_block_0:s -> fn_11_basic_block_2:n
[style="solid,bold",color=blue,weight=100,constraint=true, label="[100%]"];
fn_11_basic_block_2:s -> fn_11_basic_block_6:n
[style="solid,bold",color=red,weight=10,constraint=true, label="[29%]"];
fn_11_basic_block_2:s -> fn_11_basic_block_3:n
[style="solid,bold",color=blue,weight=100,constraint=true, label="[71%]"];
fn_11_basic_block_3:s -> fn_11_basic_block_4:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[85%]"];
fn_11_basic_block_3:s -> fn_11_basic_block_8:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[15%]"];
fn_11_basic_block_4:s -> fn_11_basic_block_6:n
[style="dotted,bold",color=red,weight=10,constraint=false, label="[50%]"];
fn_11_basic_block_4:s -> fn_11_basic_block_5:n
[style="solid,bold",color=blue,weight=100,constraint=true, label="[50%]"];
fn_11_basic_block_5:s -> fn_11_basic_block_6:n
[style="dotted,bold",color=blue,weight=10,constraint=false, label="[100%]"];
fn_11_basic_block_6:s -> fn_11_basic_block_4:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[85%]"];
fn_11_basic_block_6:s -> fn_11_basic_block_7:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[15%]"];
fn_11_basic_block_7:s -> fn_11_basic_block_8:n
[style="solid,bold",color=blue,weight=100,constraint=true, label="[100%]"];
fn_11_basic_block_8:s -> fn_11_basic_block_1:n
[style="solid,bold",color=black,weight=10,constraint=true, label="[100%]"];
fn_11_basic_block_0:s -> fn_11_basic_block_1:n
[style="invis",constraint=true];
}
}

[Bug c++/58263] [feature request] friend class $UndefinedClass

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
But that will warn about valid code, where you didn't spell the name wrong.

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

[eraman at google dot com]

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

--- Comment #27 from Easwaran Raman  ---
These two test cases pass for me (compiles with -O3) with the attached patch
(http://gcc.gnu.org/bugzilla/attachment.cgi?id=30690). 
gcc --version returns:

gcc (GCC) 4.9.0 20130821 (experimental)

At what revision are you still getting the ICEs? The patch attached to this bug
subsumes the one posted in
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01584.html .

(In reply to Joost VandeVondele from comment #24)
> Also the other 'dup' PRs still fail (gcc -O3) . Collecting testcases here:
> 
> > cat  PR58018.c
> 
> int a, b, c, d, e;
> 
> void bar (int p)
> {
>   int f = b;
>   e &= p <= (f ^= 0);
> }
> 
> void foo ()
> {
>   for (; d; d++)
> {
>   bar (a && c);
>   bar (0);
>   bar (1);
> }
> }
> 
> 
> > cat PR58131.c
> 
> short a;
> int b, c;
> int d[1][4][2];
> 
> void foo ()
> {
>   int *e;
>   for (b = 1;; b--)
> {
>   if (*e)
>   break;
>   for (c = 2; c >= 0; c--)
> {
> *e |= d[0][3][b] != a;
> int *f = &d[0][3][b];
> *f = 0;
> }
> }
> }

[Bug c++/58263] [feature request] friend class $UndefinedClass

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
How about looking into the MyClass1 to see if there is a friend class and have
a quick heuristic about the spelling mistake when doing the error message?

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

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #28 from Joost VandeVondele  
---
(In reply to Easwaran Raman from comment #27)
> These two test cases pass for me (compiles with -O3) with the attached patch
> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=30690). 
> gcc --version returns:

OK, with only the patch mentioned above applied all testcases now pass. I think
this patch should be posted to gcc-patches for review, if you haven't done yet.
Thanks!

[Bug c++/58263] [feature request] friend class $UndefinedClass

[vova7890 at mail dot ru]

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

--- Comment #5 from vova7890  ---
(In reply to Jonathan Wakely from comment #3)
> But that will warn about valid code, where you didn't spell the name wrong.

Yes, but it can be not in one file, as in example. If it in one file, and
friend class is below the main class, can avoid warning by this:

class MyClass2;

class MyClass1
{
   friend class MyClass2; // trivial stupid human issue with MyClas2 ->
MyClass2
private:
   void help();
};

class MyClass2
{
public:
   void need(MyClass1 *cl) {
  cl->help();   // error: is private!!
   }
};

Also, maybe can use it on paranoid level warnings, for example.

[Bug c++/58263] [feature request] friend class $UndefinedClass

[vova7890 at mail dot ru]

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

--- Comment #6 from vova7890  ---
(In reply to Andrew Pinski from comment #4)
> How about looking into the MyClass1 to see if there is a friend class and
> have a quick heuristic about the spelling mistake when doing the error
> message?

Good idea. Can lookup for class name in visible fields, and also in curent
source, including fields after friend-contained class.

[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-08-28
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.6.0, 4.7.0, 4.8.0

[Bug tree-optimization/58228] [4.7/4.8/4.9 Regression] wrong code (with vectorization?) at -O3 on x86_64-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
This is nested vectorization, where the step in the inner loop is 0, while in
the outer loop is bigger than that, and for inv_p we look at the step in the
outer loop in that case, while we perhaps should look at the inner one. 
Richard?

[Bug fortran/52243] Avoid reallocation for: array1 = array1 / scalar for performance

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-08-28
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
I have a patch.

[Bug libstdc++/58265] New: std::string move assignment should be noexcept

[f.heckenb...@fh-soft.de]

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

Bug ID: 58265
   Summary: std::string move assignment should be noexcept
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de

According to http://www.cplusplus.com/reference/string/string/operator=/,
the std::string move assignment operator should be noexcept.

#include 
static_assert (std::is_nothrow_move_assignable ::value, "failed");

[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

[skunk at iskunk dot org]

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

Daniel Richard G.  changed:

   What|Removed |Added

 CC||skunk at iskunk dot org

--- Comment #5 from Daniel Richard G.  ---
I get this same error building on an old Debian woody system:

/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In
function 'void __sanitizer::internal__exit(int)':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:142:11:
error: '__NR_exit_group' was not declared in this scope
   syscall(__NR_exit_group, exitcode);
   ^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Lock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:529:13:
error: '__NR_futex' was not declared in this scope
 syscall(__NR_futex, m, FUTEX_WAIT, MtxSleeping, 0, 0, 0);
 ^
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc: In member
function 'void __sanitizer::BlockingMutex::Unlock()':
/home/src/gcc-4.8.1/libsanitizer/sanitizer_common/sanitizer_linux.cc:537:13:
error: '__NR_futex' was not declared in this scope
 syscall(__NR_futex, m, FUTEX_WAKE, 1, 0, 0, 0);
 ^
gmake[4]: *** [sanitizer_linux.lo] Error 1


Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
pthread_mutex_*() be sensible here?

[Bug tree-optimization/58143] [4.8/4.9 regression] wrong code at -O3

[bernd.edlinger at hotmail dot de]

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

--- Comment #15 from Bernd Edlinger  ---
This patch was posted at:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01733.html

[Bug libstdc++/58265] std::string move assignment should be noexcept

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2013-08-28
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
   Target Milestone|--- |4.9.0
 Ever confirmed|0   |1

--- Comment #1 from Paolo Carlini  ---
I'll fix this asap, very simple to do, but note that until we break the ABI
basic_string will remain nonconforming in many serious ways.

[Bug libstdc++/58265] std::string move assignment should be noexcept

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Target Milestone|4.9.0   |---

--- Comment #2 from Paolo Carlini  ---
As a matter of fact, isn't, in our current implementation, because std::swap
itself isn't in case the allocators are not equal.

I can preliminarily adjust it for ext/vstring.h (a preview of the future c++11
conforming basic_string) but it still needs work as regards the C++11 memory
allocation model.

Is this a bug: -mregparm=0 doesn't work with -O3?

[Wei Li]

Hi,

I am trying to disable pass arguments by register in my project. I
suppose -mregparm=0 can do this but unfortunately it doesn't work with
-O3. The arguments  are still through registers even I specified
-mregparm=0.

I am not sure if this intentional or a bug?  -mregparm is a specific
option.  In general the priority should be higher than  -O3 which is a
group option, right?

Thanks,
Wei

Re: Is this a bug: -mregparm=0 doesn't work with -O3?

[pinskia]

Sent from my iPad

On Aug 28, 2013, at 2:57 PM, Wei Li  wrote:

> Hi,
> 
> I am trying to disable pass arguments by register in my project. I
> suppose -mregparm=0 can do this but unfortunately it doesn't work with
> -O3. The arguments  are still through registers even I specified
> -mregparm=0.
> 
> I am not sure if this intentional or a bug?  -mregparm is a specific
> option.  In general the priority should be higher than  -O3 which is a
> group option, right?

Is this a static local only function?
If so then there Is code which changes the abi to use the registers. Also is 
this 32 or 64 bit x86?

Thanks,
Andrew Pinski

> 
> Thanks,
> Wei

Re: Is this a bug: -mregparm=0 doesn't work with -O3?

[Wei Li]

It's a static function. 32bit x86. I tried both gcc4.5.2 and gcc4.7.2,
the behavior is same.

On Wed, Aug 28, 2013 at 3:00 PM,   wrote:
>
>
> Sent from my iPad
>
> On Aug 28, 2013, at 2:57 PM, Wei Li  wrote:
>
>> Hi,
>>
>> I am trying to disable pass arguments by register in my project. I
>> suppose -mregparm=0 can do this but unfortunately it doesn't work with
>> -O3. The arguments  are still through registers even I specified
>> -mregparm=0.
>>
>> I am not sure if this intentional or a bug?  -mregparm is a specific
>> option.  In general the priority should be higher than  -O3 which is a
>> group option, right?
>
> Is this a static local only function?
> If so then there Is code which changes the abi to use the registers. Also is 
> this 32 or 64 bit x86?
>
> Thanks,
> Andrew Pinski
>
>>
>> Thanks,
>> Wei

Re: Is this a bug: -mregparm=0 doesn't work with -O3?

[pinskia]

On Aug 28, 2013, at 3:02 PM, Wei Li  wrote:

> It's a static function. 32bit x86. I tried both gcc4.5.2 and gcc4.7.2,
> the behavior is same.

Then this is not a bug.  Why would you care about the abi?  Are you using some 
inline asm also?

Andrew




> 
> On Wed, Aug 28, 2013 at 3:00 PM,   wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> On Aug 28, 2013, at 2:57 PM, Wei Li  wrote:
>> 
>>> Hi,
>>> 
>>> I am trying to disable pass arguments by register in my project. I
>>> suppose -mregparm=0 can do this but unfortunately it doesn't work with
>>> -O3. The arguments  are still through registers even I specified
>>> -mregparm=0.
>>> 
>>> I am not sure if this intentional or a bug?  -mregparm is a specific
>>> option.  In general the priority should be higher than  -O3 which is a
>>> group option, right?
>> 
>> Is this a static local only function?
>> If so then there Is code which changes the abi to use the registers. Also is 
>> this 32 or 64 bit x86?
>> 
>> Thanks,
>> Andrew Pinski
>> 
>>> 
>>> Thanks,
>>> Wei

Re: Is this a bug: -mregparm=0 doesn't work with -O3?

[Wei Li]

I am actually doing some instrumentation on the binary code generated
by gcc. I did it successfully for class methods and external functions
but failed on the static functions.

On Wed, Aug 28, 2013 at 3:12 PM,   wrote:
>
> On Aug 28, 2013, at 3:02 PM, Wei Li  wrote:
>
>> It's a static function. 32bit x86. I tried both gcc4.5.2 and gcc4.7.2,
>> the behavior is same.
>
> Then this is not a bug.  Why would you care about the abi?  Are you using 
> some inline asm also?
>
> Andrew
>
>
>
>
>>
>> On Wed, Aug 28, 2013 at 3:00 PM,   wrote:
>>>
>>>
>>> Sent from my iPad
>>>
>>> On Aug 28, 2013, at 2:57 PM, Wei Li  wrote:
>>>
 Hi,

 I am trying to disable pass arguments by register in my project. I
 suppose -mregparm=0 can do this but unfortunately it doesn't work with
 -O3. The arguments  are still through registers even I specified
 -mregparm=0.

 I am not sure if this intentional or a bug?  -mregparm is a specific
 option.  In general the priority should be higher than  -O3 which is a
 group option, right?
>>>
>>> Is this a static local only function?
>>> If so then there Is code which changes the abi to use the registers. Also 
>>> is this 32 or 64 bit x86?
>>>
>>> Thanks,
>>> Andrew Pinski
>>>

 Thanks,
 Wei

[Bug fortran/51976] [F2003] Support deferred-length character components of derived types (allocatable string length)

[w6ws at earthlink dot net]

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

Walter Spector  changed:

   What|Removed |Added

 CC||w6ws at earthlink dot net

--- Comment #12 from Walter Spector  ---
Adding myself (Walter Spector) to the cc list.  My contribution is a simple
little test case that works with current versions of Intel (with -assume
realloc_lhs option) and NAG.  As of todays gfortran snapshot (20130828), I get
a lot of 'Deferred-length character component 'city' at (1) is not yet
supported' errors.


program city_names
  implicit none

  type city_entry_t
character(:), allocatable :: city
character(:), allocatable :: state
  end type

  type(city_entry_t), allocatable :: cities(:)

  integer :: i

  cities = (/  &
city_entry_t ("San Francisco", "California"),  &
city_entry_t ("Portland", "Oregon"),  &
city_entry_t ("Seattle", "Washington"),  &
city_entry_t ("Salt Lake City", "Utah"),  &
city_entry_t ("Reno", "Nevada"),  &
city_entry_t ("Tucson", "Arizona"),  &
city_entry_t ("Denver", "Colorado"),  &
city_entry_t ("Kansas City","Kansas"),  &
city_entry_t ("Tulsa", "Oklahoma"),  &
city_entry_t ("Houston", "Texas")  &
  /)

  print '(5a)', (">",cities(i)%city, ", ", cities(i)%state,"<", i=1,size
(cities))

end program

[Bug c++/58255] [C++11] explicit delegating constructor with no arguments wrongly rejected

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #4 from Paolo Carlini  ---
Fixed for 4.9.0.

Re: Is this a bug: -mregparm=0 doesn't work with -O3?

[pinskia]

Sent from my iPad

On Aug 28, 2013, at 3:15 PM, Wei Li  wrote:

> I am actually doing some instrumentation on the binary code generated
> by gcc. I did it successfully for class methods and external functions
> but failed on the static functions.

Well that is not supported and is undefined.



> 
> On Wed, Aug 28, 2013 at 3:12 PM,   wrote:
>> 
>> On Aug 28, 2013, at 3:02 PM, Wei Li  wrote:
>> 
>>> It's a static function. 32bit x86. I tried both gcc4.5.2 and gcc4.7.2,
>>> the behavior is same.
>> 
>> Then this is not a bug.  Why would you care about the abi?  Are you using 
>> some inline asm also?
>> 
>> Andrew
>> 
>> 
>> 
>> 
>>> 
>>> On Wed, Aug 28, 2013 at 3:00 PM,   wrote:
 
 
 Sent from my iPad
 
 On Aug 28, 2013, at 2:57 PM, Wei Li  wrote:
 
> Hi,
> 
> I am trying to disable pass arguments by register in my project. I
> suppose -mregparm=0 can do this but unfortunately it doesn't work with
> -O3. The arguments  are still through registers even I specified
> -mregparm=0.
> 
> I am not sure if this intentional or a bug?  -mregparm is a specific
> option.  In general the priority should be higher than  -O3 which is a
> group option, right?
 
 Is this a static local only function?
 If so then there Is code which changes the abi to use the registers. Also 
 is this 32 or 64 bit x86?
 
 Thanks,
 Andrew Pinski
 
> 
> Thanks,
> Wei

[Bug c++/58255] [C++11] explicit delegating constructor with no arguments wrongly rejected

[paolo at gcc dot gnu.org]

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

--- Comment #3 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Aug 28 22:40:34 2013
New Revision: 202061

URL: http://gcc.gnu.org/viewcvs?rev=202061&root=gcc&view=rev
Log:
/cp
2013-08-28  Paolo Carlini  

PR c++/58255
* init.c (build_aggr_init): When init == void_type_node do not
set LOOKUP_ONLYCONVERTING.

/testsuite
2013-08-28  Paolo Carlini  

PR c++/58255
* g++.dg/cpp0x/dc7.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/dc7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug target/58208] deque 32-bit "-O3" bug

[tammy at Cadence dot COM]

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

--- Comment #12 from Tammy Hsu  ---
I installed the required i686 rpms on the Fedora 19 system, and the testcase
works without crash (using the /bin/g++).

I then built gcc481 on the Fedora 19 system, the testcase also works fine when
I compile/link it with my own build gcc481.

So it may really be a glibc compatibility issue (as Mikael said in comment 7).
>From Mikael and I have done:

Not working if build gcc481 on:
RHEL 5.5 - glibc 2.5
CentOS 5.8 - glibc 2.5 (done by Mikael)
RHEL 6.3 - glibc 2.12

Working if build gcc481 on
Fedora 17 - glibc 2.15 (done by Mikael)
Fedora 19 - glibc-2.17

Also if I use the gcc481 built on RHEL 5.5 or RHEL 6.3, and run on Fedora 19,
the testcase works also. So something changed between gcc4.7.3 and gcc 4.8.1
that causes "-ftree-vectorize" optimization not work well (32bit only) with
older glibc.

[Bug libgcc/58266] New: gcc-4.7.3: memleaks reported by valgrind

[mmokrejs at fold dot natur.cuni.cz]

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

Bug ID: 58266
   Summary: gcc-4.7.3: memleaks reported by valgrind
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mmokrejs at fold dot natur.cuni.cz

Created attachment 30714
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30714&action=edit
gcc-4.7.3.valgrind.txt

I ran valgrind because something in my computer overwrites memory regions of a
python interpreter. Here are those which relate to gcc. No idea how this
relates to e.g. bug #54173.



==5435== 28 bytes in 1 blocks are possibly lost in loss record 569 of 1,915
==5435==at 0x4C2C067: operator new(unsigned long) (vg_replace_malloc.c:298)
==5435==by 0xDC70B6C: std::string::_Rep::_S_create(unsigned long, unsigned
long, std::allocator const&) (in
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6.0.17)
==5435==by 0xDC7321C: char* std::string::_S_construct(char
const*, char const*, std::allocator const&, std::forward_iterator_tag)
(in /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6.0.17)
==5435==by 0xDC73322: std::basic_string,
std::allocator >::basic_string(char const*, std::allocator const&)
(in /usr/lib64/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6.0.17)
==5435==by 0x10A12934: Py::ExtensionModuleBase::ExtensionModuleBase(char
const*) (in /usr/lib64/python2.7/site-packages/matplotlib/_tri.so)
==5435==by 0x109FEEC3: TriModule::TriModule() (in
/usr/lib64/python2.7/site-packages/matplotlib/_tri.so)
==5435==by 0x109FF10F: init_tri (in
/usr/lib64/python2.7/site-packages/matplotlib/_tri.so)
==5435==by 0x4FB3FD9: _PyImport_LoadDynamicModule (importdl.c:53)
==5435==by 0x4FAFDDB: load_module (import.c:1915)
==5435==by 0x4FB21A4: import_submodule (import.c:2700)
==5435==by 0x4FB16C1: load_next (import.c:2515)
==5435==by 0x4FB0829: import_module_level (import.c:2232)

[Bug middle-end/58134] [4.8/4.9 Regression] -ftree-vectorizer-verbose= shows vectorized loops only for N== 1 and N >2 but not for N==2

[singhai at gcc dot gnu.org]

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

--- Comment #4 from Sharad Singhai  ---
I think perhaps it would be better if I remove this deprecated option
-ftree-vectorizer-verbose= completely. It is confusing in its current form and
the equivalent functionality is already available via -fopt-info-xxx option.

Any opinions?

Thanks,
Sharad

[Bug c/58267] New: Alignment specifier allowed within array declarator;

[rohan at rohanlean dot de]

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

Bug ID: 58267
   Summary: Alignment specifier allowed within array declarator;
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rohan at rohanlean dot de

“char s[_Alignas (int) 7];” is accepted without warnings in strict C11 mode.  I
cannot construct that declaration using the grammar in appendix A.2 of the
standard.

[Bug sanitizer/57316] [4.8/4.9 regression] build failure in libsanitizer

[kcc at gcc dot gnu.org]

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

--- Comment #6 from Kostya Serebryany  ---
> Would a fallback implementation of BlockingMutex::{Lock,Unlock}() that uses
> pthread_mutex_*() be sensible here?

That would be non-trivial. We intercept the pthread_ functions so we can't 
call them directly. We'll at least need to bypass our own interceptors. 
And as I mentioned before, older kernels will likely not work anyway for 
a few other reasons.