[Bug c++/68073] free(): invalid pointer errors with short strings using _GLIBCXX_USE_CXX11_ABI=1

[nikola.kovacs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68073

--- Comment #2 from nikola.kovacs at gmail dot com ---
It's not my code, I'm just trying to make it work.

The problem is it creates a new string into data, which is
std::aligned_storage:

new (&data) target_type(std::forward(val));

If the string is long, it has to be freed, otherwise there's a memory leak.

The documentation for std::aligned_storage says it has to be destroyed with
explicit destructor calls:
http://en.cppreference.com/w/cpp/types/aligned_storage 

But it also says that only PODtypes can be used, and std::string isn't one. So
that's the problem, right?

[Bug c++/68073] free(): invalid pointer errors with short strings using _GLIBCXX_USE_CXX11_ABI=1

[nikola.kovacs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68073

--- Comment #3 from nikola.kovacs at gmail dot com ---
Never mind, I misread the documentation.

It looks like something else is causing the problem, since this works fine, and
it calls the destructor directly: (modified example from
http://en.cppreference.com/w/cpp/types/aligned_storage)

#include 
#include 
#include 

template
class static_holder
{
typename std::aligned_storage::type data;

bool allocated = false;

public:
template void put(Args&&... args)
{
if (allocated) {
reinterpret_cast(&data)->~T();
}
new(&data) T(std::forward(args)...);
allocated = true;
}

const T& get() const
{
return *reinterpret_cast(&data);
}

~static_holder()
{
reinterpret_cast(&data)->~T();
}
};

int main()
{
static_holder v1;
static_holder v2;
v1.put("foo");
v1.put("bar");
v2.put("foobarbazasdfdafsdfadasdfasdf");
v2.put("x");
std::cout << v1.get() << '\n';
std::cout << v2.get() << '\n';
}

[Bug fortran/66681] Wrong result in assigning this_image() to a complex coarray

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66681

--- Comment #6 from Dominique d'Humieres  ---
A patch has been submitted at
https://gcc.gnu.org/ml/fortran/2015-09/msg00024.html.

[Bug fortran/68076] New: f95i reports "out of memory" on simple testcase

[mar...@mpa-garching.mpg.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68076

Bug ID: 68076
   Summary: f95i reports "out of memory" on simple testcase
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 36572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36572&action=edit
test case

When compiling the following module, gfortran crashes with an "out of memory"
diagnostic:

martin@marvin ~/lsnew $ gfortran -v -std=f2003 -c testcase.f03 
Using built-in specs.
COLLECT_GCC=gfortran
Target: x86_64-pc-linux-gnu
Configured with: /home/martin/gcc/configure --disable-multilib --enable-gold
--enable-plugins --prefix=/home/martin/ugcc --enable-languages=c++,fortran
--enable-target=all --enable-checking=release --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=f2003' '-c' '-mtune=generic' '-march=x86-64'
 /home/martin/ugcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/f951 testcase.f03
-quiet -dumpbase testcase.f03 -mtune=generic -march=x86-64 -auxbase testcase
-std=f2003 -version -fintrinsic-modules-path
/home/martin/ugcc/lib/gcc/x86_64-pc-linux-gnu/6.0.0/finclude -o /tmp/ccaNNCfs.s
GNU Fortran (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2003 (GCC) version 6.0.0 20150923 (experimental) [trunk revision
3bf38a0:6620841:618c2dcced6864af8a34ed341525c556bb44b375] (x86_64-pc-linux-gnu)
compiled by GNU C version 4.8.4, GMP version 5.1.3, MPFR version
3.1.2-p3, MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

f951: out of memory allocating 30978549264 bytes after a total of 561152 bytes

[Bug fortran/68076] f951 reports "out of memory" on simple testcase

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68076

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-24
 Ever confirmed|0   |1

[Bug fortran/68076] f951 reports "out of memory" on simple testcase

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68076

--- Comment #1 from Dominique d'Humieres  ---
Up to revision r228467 (2015-10-05) I get the ICE

f951: internal compiler error: Segmentation fault: 11

At r228566 (2015-10-07) the test compiles without any problem, likely r228551
(pr65766).

[Bug c++/68073] free(): invalid pointer errors with short strings using _GLIBCXX_USE_CXX11_ABI=1

[nikola.kovacs at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68073

--- Comment #4 from nikola.kovacs at gmail dot com ---
(sorry for the triple post) I figured it out, it was caused by swap operating
on std::aligned_storage, so it didn't properly swap the string.

[Bug fortran/66681] Wrong result in assigning this_image() to a complex coarray

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66681

--- Comment #7 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #6)
> A patch has been submitted at
> https://gcc.gnu.org/ml/fortran/2015-09/msg00024.html.

Hi Dominique,

If you follow the correspondence, it ended with questions from me that were
never answered.

Paul

[Bug ipa/68057] [6 Regression] 450.soplex in SPEC CPU 2006 failed to build

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68057

--- Comment #6 from Markus Trippelsdorf  ---
BTW there is a big binary size increase for SPEC2000/2006 apps using flto,
see https://vmakarov.fedorapeople.org/spec/

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

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> Does the problem still exist?

The change occurred between revisions r217100 (2014-11-04) and r217500
(2014-11-13), likely r217383 for pr44054.

Note that there is probably still a latent bug, an least with trunk (6.0) for
which I see some random ICEs:

[book15] f90/bug% gfc -w pr52622.f90
pr52622.f90:130:2:

   function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result(   
&
  1
Error: Unclassifiable statement at (1)
f951: internal compiler error: Segmentation fault: 11
...
[book15] f90/bug% gfc -w pr52622.f90
pr52622.f90:130:2:

   function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result(   
&
  1
Error: Unclassifiable statement at (1)
pr52622.f90:103:8:

 if (b1) then
1
Error: IF clause at (1) requires a scalar LOGICAL expression
pr52622.f90:99:8:

 if (b) then
1
Error: IF clause at (1) requires a scalar LOGICAL expression
f951: internal compiler error: Segmentation fault: 11
...
[book15] f90/bug% gfcp -w pr52622.f90
pr52622.f90:130:2:

   function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result(   
&
  1
Error: Unclassifiable statement at (1)
(null):0: confused by earlier errors, bailing out
[book15] f90/bug% gfca -w pr52622.f90
pr52622.f90:130:2:

   function passeverywherefcomplex_impl(self, c1, c2, c3, exception) result(   
&
  1
Error: Unclassifiable statement at (1)
(null):0: confused by earlier errors, bailing out

gfc is r229284, gfcp is r229283 configured with --enable-checking=release, and
gfca is r229261 configured with --enable-checking=release.

[Bug fortran/68053] lower bound of implied shape array restricted too much

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68053

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-24
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0).

[Bug fortran/66681] Wrong result in assigning this_image() to a complex coarray

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66681

--- Comment #8 from Dominique d'Humieres  ---
> Hi Dominique,
>
> If you follow the correspondence, it ended with questions from me that
> were never answered.
>
> Paul

Indeed I have read https://gcc.gnu.org/ml/fortran/2015-09/msg00071.html! I have
the patch in my tree since some time and I prefer to have a pointer to it in
bugzilla rather than digging the fortran archives.

The problem is that Tobias reacts only if you close the PR as fixed.

[Bug c++/68077] New: Namespace having the same name as contained class should not compile

[vgheorgh at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68077

Bug ID: 68077
   Summary: Namespace having the same name as contained class
should not compile
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vgheorgh at gmail dot com
  Target Milestone: ---

According to [7.3.4/6 Using directive [namespace udir]] the following code is
ill-formed, and there is no "no diagnostic required":

template 
class Foo{};

namespace X
{
class X{};
}

using namespace X; // now both class X and namespace X are visible
Foo f()
{
return {};
}

int main() {}

Therefore I believe the code should not compile. Tested with both gcc5.2.x and
gcc6. More details: http://stackoverflow.com/q/33313853/3093378

[Bug fortran/56471] Program crashes when allocating a derived type with an allocatable component

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56471

Joost VandeVondele  changed:

   What|Removed |Added

   Last reconfirmed|2013-06-29 00:00:00 |2015-10-24
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
  Known to fail||6.0

--- Comment #2 from Joost VandeVondele  
---
yes, stack overflow also with trunk.

> gfortran -fsanitize=address -g PR56471.f90 && ./a.out
ASAN:DEADLYSIGNAL
=
==13127==ERROR: AddressSanitizer: stack-overflow on address 0x7ffe797483b8 (pc
0x00400b73 bp 0x7ffe7bd6ddd0 sp 0x7ffe797483b0 T0)
#0 0x400b72 in MAIN__ /data/vjoost/gnu/bugs/PR56471.f90:2
#1 0x400d0a in main /data/vjoost/gnu/bugs/PR56471.f90:10
#2 0x3ba4a1ed5c in __libc_start_main (/lib64/libc.so.6+0x3ba4a1ed5c)
#3 0x400a78  (/data/vjoost/gnu/bugs/a.out+0x400a78)

SUMMARY: AddressSanitizer: stack-overflow /data/vjoost/gnu/bugs/PR56471.f90:2
in MAIN__
==13127==ABORTING

[Bug fortran/68078] New: segfault with allocate and stat for derived types with default initialization

[Joost.VandeVondele at mat dot ethz.ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68078

Bug ID: 68078
   Summary: segfault with allocate and stat for derived types with
default initialization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
  Target Milestone: ---

The following testcase:

> cat test.f90
TYPE foo
  INTEGER, DIMENSION(1) :: data=42
END TYPE
TYPE(foo), POINTER :: fooptr

DO 
  ALLOCATE(fooptr,stat=istat)
  IF (istat.NE.0) EXIT
ENDDO
END

> ulimit -v 100
> gfortran -g test.f90 && ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Presumably the default initialization is attempted even if fooptr is null. In
case of a present istat, this should not happen. Ifort deals fine with the
case.

[Bug fortran/67805] ICE on array constructor with wrong character specification

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67805

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Oct 24 16:20:26 2015
New Revision: 229287

URL: https://gcc.gnu.org/viewcvs?rev=229287&root=gcc&view=rev
Log:
2015-10-24  Steven G. Kargl  

PR fortran/67805
* array.c (gfc_match_array_constructor): Check for error from type
spec matching.
* decl.c (char_len_param_value): Check for valid of charlen parameter.
Reap dead code dating to 2008.
match.c (gfc_match_type_spec): Special case the keyword use in REAL.

2015-10-24  Steven G. Kargl  

PR fortran/67805
* gfortran.dg/pr67805.f90: New testcase.
* gfortran.dg/array_constructor_26.f03: Update testcase.
* gfortran.dg/array_constructor_27.f03: Ditto.
* gfortran.dg/char_type_len_2.f90: Ditto.
* gfortran.dg/pr67802.f90: Ditto.
* gfortran.dg/used_before_typed_3.f90: Ditto.

Added:
trunk/gcc/testsuite/gfortran.dg/pr67805.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/decl.c
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03
trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03
trunk/gcc/testsuite/gfortran.dg/char_type_len_2.f90
trunk/gcc/testsuite/gfortran.dg/large_real_kind_3.F90
trunk/gcc/testsuite/gfortran.dg/pr67802.f90
trunk/gcc/testsuite/gfortran.dg/used_before_typed_3.f90

[Bug middle-end/63510] Wrong line number in Wstrict-overflow message

[gang.chen.5i5j at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63510

--- Comment #13 from Chen Gang  ---
gcc version 6.0.0 20151023 (experimental) (GCC) has no this issue (I guess, the
reason is that it calls gimple_simplify instead of fold_binary).

For me, this issue can be closed.

Thanks.

[Bug ipa/67600] [5/6 Regression] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3

[miyuki at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67600

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #6 from Mikhail Maltsev  ---
I wonder if the testcase could be reduced somehow...

$ ll -S gcc/testsuite/g++.dg/torture | head -n 7
total 2.2M
-rw-r--r-- 1 miyuki miyuki 664K  19:44  24.10.15 pr67600.C
-rw-r--r-- 1 miyuki miyuki  43K  10:56  10.07.15 Wsizeof-pointer-memaccess2.C
-rw-r--r-- 1 miyuki miyuki  43K  10:56  10.07.15 Wsizeof-pointer-memaccess1.C
-rw-r--r-- 1 miyuki miyuki  17K  10:56  10.07.15 pr31863.C
-rw-r--r-- 1 miyuki miyuki  12K  10:56  10.07.15 pr37922.C
-rw-r--r-- 1 miyuki miyuki  11K  06:08  04.08.15 pr46383.C

[Bug fortran/68055] ICE on using unsupported kinds in program without program statement

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68055

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Oct 24 17:09:35 2015
New Revision: 229288

URL: https://gcc.gnu.org/viewcvs?rev=229288&root=gcc&view=rev
Log:
2015-10-24  Steven G. Kargl  

PR fortran/68055
* decl.c (gfc_match_decl_type_spec): Check for valid kind in old-style
declarations.

2015-10-24  Steven G. Kargl  

PR fortran/68055
* gfortran.dg/pr68055.f90: New case.

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

[Bug ipa/67600] [5/6 Regression] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67600

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #7 from Markus Trippelsdorf  ---
(In reply to Mikhail Maltsev from comment #6)
> I wonder if the testcase could be reduced somehow...
> 
> $ ll -S gcc/testsuite/g++.dg/torture | head -n 7
> total 2.2M
> -rw-r--r-- 1 miyuki miyuki 664K  19:44  24.10.15 pr67600.C

Yeah, I was wondering about that too. 
Honza, why are not just using two #includes instead of all the preprocessed
standard headers?

[Bug middle-end/68079] New: hppa: pointers to method types need canonicalization before comparison

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68079

Bug ID: 68079
   Summary: hppa: pointers to method types need canonicalization
before comparison
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
CC: deller at gmx dot de
  Target Milestone: ---
  Host: hppa*-*-* (32-bit)
Target: hppa*-*-* (32-bit)
 Build: hppa*-*-* (32-bit)

Created attachment 36573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36573&action=edit
Test program.

On 32-bit hppa targets, pointers to functions need canonicalization prior
to comparison as they point to non unique function descriptors and not directly
to the functions themselves.

The attached testcase demonstrates the problem.  The test passes on x86
but fails on hppa.

A number of kde packages (e.g., kitemmodels) fail to build because of this bug.

Currently, we have the following code in dojump.c to canonicalize function
pointers:

  if (HAVE_canonicalize_funcptr_for_compare
  && TREE_CODE (TREE_TYPE (treeop0)) == POINTER_TYPE
  && TREE_CODE (TREE_TYPE (TREE_TYPE (treeop0)))
  == FUNCTION_TYPE
  && TREE_CODE (TREE_TYPE (treeop1)) == POINTER_TYPE
  && TREE_CODE (TREE_TYPE (TREE_TYPE (treeop1)))
  == FUNCTION_TYPE)
{

At this point, we have using the testcase:

1209  if (targetm.have_canonicalize_funcptr_for_compare ()
(gdb) p debug_tree (treeop0)

   SI
   size 
   unit size 
   align 32 symtab 0 alias set -1 canonical type 0xfb640b40 method
basetype 
   arg-types 
   chain >>
   pointer_to_this >
   public unsigned SI size  unit size

   align 32 symtab 0 alias set -1 canonical type 0xfb644180>
   visiteddef_stmt _6 = MEM[(struct _t *)func_5].__pfn;

   version 6>
$1 = void
(gdb) p debug_tree (treeop1)

   SI
   size 
   unit size 
   align 32 symtab 0 alias set -1 canonical type 0xfb640b40 method
basetype 
   arg-types 
   chain >>
   pointer_to_this >
   unsigned SI size  unit size 
   align 32 symtab 0 alias set -1 canonical type 0xfb644180>
   constant
   arg 0 
   addressable asm_written used public static decl_5 SI file testlib.cpp
line 5 col 5 align 32 context  initial

   full-name "int testlib::func1()"
   pending-inline-info 0xfc330a20
   (mem:SI (symbol_ref/v:SI ("@_ZN7testlib5func1Ev") [flags 0x1]
) [0  S4 A32])
   chain 
   public static decl_5 decl_6 SI file testlib.cpp line 10 col 6 align
32 context  initial  result

   full-name "static void testlib::findfunc(void**)"
   pending-inline-info 0xfb9fd3f0 arguments 
   struct-function 0xfbbf5d00>>>
$2 = void

A METHOD_TYPE is also a function and pointers to method types point at function
descriptors on hppa.  So, we also need to canonicalize pointers to methods.

The current code also fails to canonicalize REFERENCE_TYPEs that refer to
functions:

#define POINTER_TYPE_P(TYPE) \
  (TREE_CODE (TYPE) == POINTER_TYPE || TREE_CODE (TYPE) == REFERENCE_TYPE)

[Bug middle-end/68079] hppa: pointers to method types need canonicalization before comparison

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68079

--- Comment #2 from John David Anglin  ---
Created attachment 36575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36575&action=edit
Patch for gcc-5

[Bug middle-end/68079] hppa: pointers to method types need canonicalization before comparison

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68079

--- Comment #1 from John David Anglin  ---
Created attachment 36574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36574&action=edit
Patch for trunk

[Bug fortran/32151] Misleading compilation diagnostic

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32151

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |WONTFIX

--- Comment #2 from kargl at gcc dot gnu.org ---
gfortran gives a reasonable error for first issue.

% gfc6 -c -fmax-errors=1 q1.f90
q1.f90:5:47:

if ((Verbose) .and. (abs(Position - Anchor) le. Cut_off )) then
   1
Error: Expected a right parenthesis in expression at (1)

gfortran is clearly trying to and expression of the form
(abs(Position - Anchor)) where the last righthand parenthesis
is missing.  It is the programmer's job to look at the locus
of the error and make an appropriate fix.

The second error is simply a side effect of gfortran trying to
do its best to compile the mangled code.  Fix the first problem,
and the second problem goes away.

The error message for the second program is also reasonable.
Once the first error is fixed, then the others go away.

[Bug middle-end/68079] hppa: pointers to method types need canonicalization before comparison

[deller at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68079

--- Comment #3 from deller at gmx dot de ---
Hi Dave,

Thanks for creating this bug report.

On 24.10.2015 19:48, danglin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68079
> A number of kde packages (e.g., kitemmodels) fail to build because of this 
> bug.

Nitpick:
The bug/miscompilation is actually in kdebase, but it's true that it then shows
up in kitemmodels first.

Helge

[Bug gcov-profile/68080] New: gcov returns negative counts

[Pidgeot18 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080

Bug ID: 68080
   Summary: gcov returns negative counts
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Pidgeot18 at gmail dot com
  Target Milestone: ---

Created attachment 36576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36576&action=edit
File to run

(See also bug 67937 for bad things that happen when this occurs).

I finally minimized a test case that causes negative counts to happen. If you
name the attached file TestDeadlockDetector.cpp and run:
 rm -rf *.gcda && c++ --coverage -std=c++11 -pthread -Os
TestDeadlockDetector.cpp && ./a.out && gcov -a -b -p TestDeadlockDetector.gcda
&& grep -- '-[0-9][0-9]*:' TestDeadlockDetector.cpp.gcov

you should usually see ContentionNoDeadlock_thread have negative counts. The
exact count changes from each run (and sometimes, it's not negative).

The -Os is in the c++ command line is definitely required.

[Bug gcov-profile/68080] gcov returns negative counts

[Pidgeot18 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68080

--- Comment #1 from Joshua Cranmer  ---
For what it's worth:
jcranmer@huitzilopochtli /tmp/gcov-dir $ c++ -v
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 5.2.1-22'
--with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20151010 (Debian 5.2.1-22)

[Bug bootstrap/63827] parallel make in libjava broken at r217383

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63827

Jack Howarth  changed:

   What|Removed |Added

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

--- Comment #15 from Jack Howarth  ---
(In reply to Jack Howarth from comment #5)
> This is extremely reproducible at r217383 on darwin and no other breakage in
> the parallel make has been seen this week prior to this commit. The
> accumulated error messages in the failing build are...
> 
> make[3]: *** read jobs pipe: No such file or directory.  Stop.
> make[3]: *** Waiting for unfinished jobs
> ...
> ake[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory
> '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/
> libjava'
> Makefile:17122: recipe for target 'all-target-libjava' failed
> make[1]: *** [all-target-libjava] Error 2
> make[1]: Leaving directory
> '/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir'
> Makefile:20722: recipe for target 'bootstrap' failed
> make: *** [bootstrap] Error 2
> make: INTERNAL: Exiting with 1 jobserver tokens available; should be 16!
> 
> It looks like the failure occurs when the java classes are being compiled.
> Can we revert r217383 until the flaw in its handling of the parallel make is
> resolved? Having to build gcc serially is very painful.

This issue has reappeared OS X 10.11 for make 4.1 built with NLS support when
executed under the fink package manager using the system perl. The cause
appears to be the indirect linkage of the CoreFoundation framework via libintl.
The CoreFoundation frameworks sources don't contain any EINTR handling for
interruptible system calls like read(), etc so there will be potential race
conditions for programs using fork()/exec() like make.

radr://23248551 "The CoreFoundation framework and associated libraries aren't
fork()/exec() safe"

[Bug tree-optimization/68067] [4.9/5/6 Regression] Wrong constant folding

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68067

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #5 from Mikael Pettersson  ---
Started with r124217:

--- pr68067.s-r124216   2015-10-24 22:29:26.827234815 +0200
+++ pr68067.s-r124217   2015-10-24 22:24:24.287329237 +0200
@@ -5,8 +5,9 @@
.type   main, @function
 main:
 .LFB2:
-   xorl%eax, %eax
-   ret
+   subq$8, %rsp
+.LCFI0:
+   callabort
 .LFE2:
.size   main, .-main
.section.eh_frame,"a",@progbits

[Bug c/68081] New: Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[noloader at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081

Bug ID: 68081
   Summary: Cygwin GCC cannot compile program that uses
__builtin_ia32_rdseed64_step
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: noloader at gmail dot com
  Target Milestone: ---

I'm testing on Cygwin64. Cygwin64 provides the 5.2.0 compiler.

Attempting to compile the following results in an error:

  $ cat rdseed.c
  #include 

  int main()
  {
uint64_t val;
__builtin_ia32_rdseed64_step(&val);
return (int)val;
  }

The error is:

  $ gcc -mrdseed rdseed.c -o rdseed.exe
  ...
  rdseed.c:6:36: error: '__builtin_ia32_rdseed64_step' was not declared in this
scope.

The expected define appears to be defined:

  $ cpp -mrdseed -dM 

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
Why are you using the builtin directly?  You should be using the intrinsics
form instead.

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[noloader at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081

--- Comment #2 from Jeffrey Walton  ---
(In reply to Andrew Pinski from comment #1)
> Why are you using the builtin directly?  You should be using the intrinsics
> form instead.

Its a cross product of (1) that's what the docs tell me to use for RDRAND and
(2) lack of documentation for RDSEED.

The doc I am referring to is
http://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#x86-Built-in-Functions
lists. It tells me to use "__builtin_ia32_rdrand{16|32|64}_step" for RDRAND.
But it does not tell me what to use for RDSEED. I made the leap I should use
the *_rdseed variants for RDSEED.

(My apologies for the literal read. If I should be doing something different,
then I need to be told to do so :)

[Bug target/68081] Cygwin GCC cannot compile program that uses __builtin_ia32_rdseed64_step

[noloader at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68081

--- Comment #3 from Jeffrey Walton  ---
(In reply to Jeffrey Walton from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Why are you using the builtin directly?  You should be using the intrinsics
> > form instead.
> 
> Its a cross product of (1) that's what the docs tell me to use for RDRAND
> and (2) lack of documentation for RDSEED.
> 
> The doc I am referring to is
> http://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html#x86-Built-in-
> Functions lists. It tells me to use "__builtin_ia32_rdrand{16|32|64}_step"
> for RDRAND. But it does not tell me what to use for RDSEED. I made the leap
> I should use the *_rdseed variants for RDSEED.
> 
> (My apologies for the literal read. If I should be doing something
> different, then I need to be told to do so :)

By the way, I tried to find RDRAND and RDSEED intrinsic functions in the past:
http://www.google.com/search?q=RDRAND+intrinsic+site:gnu.org . The best I can
tell, they are undocumented.

I did find H.J. Lu's patches that provide __builtin_ia32_rdseed{X}_step, so I
used them instead. They are documented, so I used them.

Its very important (to me) to find provenance in vendor documentation.

[Bug middle-end/65947] Vectorizer misses conditional assignment of constant

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65947

--- Comment #6 from Andreas Schwab  ---
FAIL: gcc.dg/vect/pr65947-1.c (internal compiler error)
FAIL: gcc.dg/vect/pr65947-1.c (test for excess errors)
Excess errors:
/opt/gcc/gcc-20151024/gcc/testsuite/gcc.dg/vect/pr65947-1.c:10:1: error: bogus
comparison result type
vector(4) signed int
_35 = _44 == _34;
/opt/gcc/gcc-20151024/gcc/testsuite/gcc.dg/vect/pr65947-1.c:10:1: error: the
first argument of a VEC_COND_EXPR must be of a boolean vector type of the same
number of elements as the result
vector(4) int
vector(4) signed int
_36 = VEC_COND_EXPR <_35, vect_last_1.9_31, _32>;
/opt/gcc/gcc-20151024/gcc/testsuite/gcc.dg/vect/pr65947-1.c:10:1: internal
compiler error: verify_gimple failed
0xb27adf verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5093
0xa1d47f execute_function_todo
../../gcc/passes.c:1968
0xa1df1f execute_todo
../../gcc/passes.c:2025

[Bug libgcc/68082] New: issue on 64 bit shift

[angelo70 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082

Bug ID: 68082
   Summary: issue on 64 bit shift
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: angelo70 at gmail dot com
  Target Milestone: ---

Dear all,

testing gcc 4.9.0 toolchain for mcf5307 (coldfire) the code on target hangs
(loops) on a 64 bit shift opration (between 2 nop's i put).
I see that code (64 bit shift) is added from libgcc.

ffc0ee2e :
ffc0ee2e:   4e56 ffd0   linkw %fp,#-48
ffc0ee32:   48d7 3c7c   moveml %d2-%d6/%a2-%a5,%sp@
ffc0ee36:   2f2d 03d8   movel %a5@(984),%sp@-
ffc0ee3a:   4282clrl %d2
ffc0ee3c:   347c 003c   moveaw #60,%a2
ffc0ee40:   266d 0008   moveal %a5@(8),%a3
ffc0ee44:   4e93jsr %a3@
ffc0ee46:   588faddql #4,%sp
ffc0ee48:   262d 051c   movel %a5@(1308),%d3

ffc0ee4c:   4e71nop
ffc0ee4e:   2043moveal %d3,%a0
ffc0ee50:   2f0amovel %a2,%sp@-
ffc0ee52:   2f2e 000c   movel %fp@(12),%sp@-
ffc0ee56:   2f2e 0008   movel %fp@(8),%sp@-
ffc0ee5a:   4e90jsr %a0@
ffc0ee5c:   4fef 000c   lea %sp@(12),%sp
ffc0ee60:   2d40 fff8   movel %d0,%fp@(-8)
ffc0ee64:   2d41 fffc   movel %d1,%fp@(-4)
ffc0ee68:   4e71nop

ffc0ee6a:   2843moveal %d3,%a4
ffc0ee6c:   202e fff8   movel %fp@(-8),%d0
ffc0ee70:   222e fffc   movel %fp@(-4),%d1
ffc0ee74:   2800movel %d0,%d4
ffc0ee76:   8881orl %d1,%d4
ffc0ee78:   670abeqs ffc0ee84 
ffc0ee7a:   206d 03d0   moveal %a5@(976),%a0
ffc0ee7e:   1430 2800   moveb %a0@(,%d2:l),%d2

I don't see anything strange in the opcodes, anyway, execution stops somewhere
between the 2 nops.

[Bug libgcc/68082] issue on 64 bit shift

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68082

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-24
 Ever confirmed|0   |1

--- Comment #1 from Andreas Schwab  ---
Please read .

[Bug tree-optimization/68083] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68083

Bug ID: 68083
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes. 

This is a regression from 5.2.x.


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20151023 (experimental) [trunk revision 229251] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.2 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
Aborted (core dumped)
$ 





int a = 2, b = 1, c = 1;

int
fn1 ()
{
  int d;
  for (; a; a--)
{
  for (d = 0; d < 4; d++)
{
  int k;
  if (c < 1)
if (k)
  c = 0;
  if (b)
continue;
  return 0;
}
  b = !1;
}
  return 0;
}

int
main ()
{
  fn1 ();

  if (a != 1) 
__builtin_abort (); 

  return 0;
}

[Bug inline-asm/68084] New: Inverted conditions generated for x86 inline assembly "flag output constraints"

[richardpku at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68084

Bug ID: 68084
   Summary: Inverted conditions generated for x86 inline assembly
"flag output constraints"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richardpku at gmail dot com
  Target Milestone: ---

I have been trying out the new "flag output constraints" feature in inline
assembly ("=@ccCC"), and have found GCC sometimes incorrectly generates
inverted conditions in assembler code.

The minimal test case is as follows:


_Bool dec_ref(unsigned *p)
{
  _Bool r;
  asm ("cmp %2, %1" : "=@ccae"(r) : "m"(*p), "ri"(2));
  if (r)
return __atomic_sub_fetch(p, 1, __ATOMIC_RELEASE) == 0;
  return 1;
}


GCC (6.0.0 20151024) generates the following assembler code:


dec_ref:
cmp $2, (%rdi)
movl$1, %eax
jc  .L7
rep ret
.p2align 4,,10
.p2align 3
.L7:
lock subl   $1, (%rdi)
sete%al
ret


where "jc" is incorrect. It should be "jnc".

Interestingly, GCC generates the expected code if "=@ccae" is written as
"=@ccnb" (ae and nb are synonymous).

[Bug c++/68085] New: bug when using anonymous structs in function

[ryan.burn at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68085

Bug ID: 68085
   Summary: bug when using anonymous structs in function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The following code compiles fine with clang and EDG, but gives this error with
g++ -std=c++1z:

main.cpp: In function ‘auto make(int)’:
main.cpp:5:17: error: declaration of ‘int make(int)y’
[-fpermissive]
 decltype(y) y;
 ^
main.cpp:3:8: error: changes meaning of ‘y’ from ‘int y’ [-fpermissive]
   auto y = x;

//
auto make(int x) {  
  auto y = x;   
  struct {  
decltype(y) y;  
  } result{x};  
  return result;
}   

int main() {
  return 0; 
} 
//

[Bug c++/68085] bug when using anonymous structs in function

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68085

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
No GCC is correct.  C++ says no diagnostic is required for this case;  GCC
decided that it can diagnostic it.

Basically y needs to be referencing to the same decl before and after the
finish of the struct if used.

[Bug target/62109] __gthr_i486_lock_cmp_xchg missing clobber

[gccbugzilla at limegreensocks dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62109

David  changed:

   What|Removed |Added

  Attachment #33302|0   |1
is obsolete||

--- Comment #12 from David  ---
Created attachment 36577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36577&action=edit
Update patch per comment 11

Instead of just adding the clobber, this second patch removes the whole routine
that was only needed on win95.  It also removes the (no longer used) define for
__GTHREAD_I486_INLINE_LOCK_PRIMITIVES and updates the comment.

Note that I do not have commit privileges to svn, which is why I post this here
rather than to the patches ml.

[Bug c++/68070] Undefined reference to default constructor of member template class

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68070

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-25
 Ever confirmed|0   |1

[Bug c/68056] GCC do not compile failed with using keyword " _Atomic" as an identifier

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68056

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |c

--- Comment #2 from Jonathan Wakely  ---
Why is this categorised as C++?

[Bug c++/60976] Compilation with G++ 4.9.0 is 2-3 times slower than with 4.8.2

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60976

--- Comment #30 from Jonathan Wakely  ---
(In reply to Giuseppe Ottaviano from comment #19)
> At Facebook we experienced a similar regression, compilation times more than
> doubled for several large C++ files.
> We found that the regression was mostly caused by r207240, specifically to
> the changes in bits/alloc_traits.h. Just reverting that file brought back
> build times almost to previous levels.

Do you have a testcase showing this slowdown?

I tried a partial specialization and it doesn't make much difference to the
test file in comment 5, confirming that the Facebook issue is different from
the original bug report, which is caused by the constructor overloads that are
required by the standard.

[Bug rtl-optimization/68086] New: Expression explicitly defined outside the loop is moved inside the loop by the optimizer

[igusarov at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68086

Bug ID: 68086
   Summary: Expression explicitly defined outside the loop is
moved inside the loop by the optimizer
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: igusarov at mail dot ru
  Target Milestone: ---

Created attachment 36578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36578&action=edit
Single function to reproduce the results

Compileable C source in "ex324_core.c" does not include any header files. It
consists of a single function whose performance is spoiled by the optimizer.
Please read explanatory comments in that file.

"ex324.c" is a compileable test program build around the same core function. It
merely measures the amount of CPU clock ticks taken by that core function. It
includes system headers for printf and mmap, and is provided just for
convenience of testing.

The problem was first discovered in x86_64 gcc 5.2.0 compiler. Brief regression
research showed that 4.8.3 has this problem too. 4.7.4 seems to be good.

Problem in a nutshell. Let's start with this loop:

// Case 1
for (i = 0; i < size; ++i)
  accumulator += data[i];

and rewrite it in this equivalent form:

// Case 2
int*  rebased = data + size;
for (i = -size; i; ++i)
  accumulator += rebased[i];

It looks like the forward propagation pass decides not to allocate a register
for variable 'rebased', but rather compute its value every time it is used in
the loop. This results in assembly output which, if written in terms of C,
would look like this:

for (i = -size; i; ++i)
  accumulator += *(data + (size + i));

Extra operation inside the loop only slows the program down.
This happens at any optimization level above -O0.

Command line:
x86_64-unknown-freebsd9.0_5.2.0-gcc -O2 -S ex324_core.c

Compiler:
x86_64-unknown-freebsd9.0_5.2.0-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-freebsd9.0_5.2.0-gcc
COLLECT_LTO_WRAPPER=/usr/toolchain/x86_64-unknown-freebsd9.0_5.2.0/libexec/gcc/x86_64-unknown-freebsd9.0/5.2.0/lto-wrapper
Target: x86_64-unknown-freebsd9.0
Configured with:
/mnt/hdd/usr/home/toolbuilder/build_scripts/x86_64-unknown-freebsd9.0_5.2.0/build_scripts/../tools_build/x86_64-unknown-freebsd9.0_5.2.0/gcc-5.2.0/configure
--target=x86_64-unknown-freebsd9.0
--prefix=/usr/toolchain/x86_64-unknown-freebsd9.0_5.2.0
--with-local-prefix=/usr/local
--with-sysroot=/usr/toolchain/x86_64-unknown-freebsd9.0_5.2.0/sysroot
--program-prefix=x86_64-unknown-freebsd9.0_5.2.0- --with-gnu-as --with-gnu-ld
--with-as=/usr/toolchain/x86_64-unknown-freebsd9.0_5.2.0/bin/x86_64-unknown-freebsd9.0_5.2.0-as
--with-ld=/usr/toolchain/x86_64-unknown-freebsd9.0_5.2.0/bin/x86_64-unknown-freebsd9.0_5.2.0-ld
--with-nm=/usr/toolchain/x86_64-unknown-freebsd9.0_5.2.0/bin/x86_64-unknown-freebsd9.0_5.2.0-nm
--with-objdump=/usr/toolchain/x86_64-unknown-freebsd9.0_5.2.0/bin/x86_64-unknown-freebsd9.0_5.2.0-objdump
--with-gmp=/mnt/hdd/usr/home/toolbuilder/build_scripts/x86_64-unknown-freebsd9.0_5.2.0/build_scripts/../tools_build/x86_64-unknown-freebsd9.0_5.2.0/gmp-root
--with-mpfr=/mnt/hdd/usr/home/toolbuilder/build_scripts/x86_64-unknown-freebsd9.0_5.2.0/build_scripts/../tools_build/x86_64-unknown-freebsd9.0_5.2.0/mpfr-root
--with-mpc=/mnt/hdd/usr/home/toolbuilder/build_scripts/x86_64-unknown-freebsd9.0_5.2.0/build_scripts/../tools_build/x86_64-unknown-freebsd9.0_5.2.0/mpc-root
--disable-__cxa_atexit --enable-languages=c,c++ --disable-multilib
--disable-nls --enable-shared=libstdc++ --enable-static --enable-threads
Thread model: posix
gcc version 5.2.0 (GCC)

Operating system:
amd64 FreeBSD 9.0-RELEASE

CPU:
Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz (3500.10-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x206a7  Family = 6  Model = 2a Stepping = 7
Features=0xbfebfbff
Features2=0x179ae3bf
  AMD Features=0x28100800
  AMD Features2=0x1

[Bug rtl-optimization/68086] Expression explicitly defined outside the loop is moved inside the loop by the optimizer

[igusarov at mail dot ru]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68086

--- Comment #1 from Igor A. Goussarov  ---
Created attachment 36579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36579&action=edit
Performance test for the problem