[Bug c++/67302] New: copy elision in return (expression)

[osensei80 at gmail dot com]

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

Bug ID: 67302
   Summary: copy elision in return (expression)
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: osensei80 at gmail dot com
  Target Milestone: ---

Consider:

struct A
{
  A() { std::cout << "default ctor\n"; }
  A(const A&) { std::cout << "copy ctor\n"; }
  A(A&&) { std::cout << "move ctor\n"; }
};

A bar()
{
  A a;
  return( a );
}

int main()
{
  bar();
}

Compiling with option -std=c++11 the output is "default ctor". But compiling
with -std=c++14 or -std=c++1z the output is

default ctor
move ctor

Why get's the move not elided?

[Bug libgomp/67303] New: libgomp: ThreadSanitizer: data race in libgomp

[Joost.VandeVondele at mat dot ethz.ch]

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

Bug ID: 67303
   Summary: libgomp: ThreadSanitizer: data race in libgomp
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Joost.VandeVondele at mat dot ethz.ch
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

After compiling libgomp with -fsanitize=thread, the following testcase triggers
a warning, which might indicate a problem in libgomp/iter.c:304

> cat test.f90
SUBROUTINE foo()
END SUBROUTINE

!$OMP PARALLEL DO SCHEDULE(guided)
DO i=1,1000
   CALL foo()
ENDDO
END

> gfortran -fsanitize=thread -fopenmp -g test.f90

> OMP_NUM_THREADS=4 ./a.out

==
WARNING: ThreadSanitizer: data race (pid=5740)
  Read of size 8 at 0x7d740001eb48 by thread T2:
#0 gomp_iter_guided_next
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/iter.c:304
(libgomp.so.1+0xc123)
#1 gomp_loop_guided_next
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:328
(libgomp.so.1+0xdf00)
#2 MAIN__._omp_fn.0 /data/vjoost/gnu/bugs/test.f90:4 (a.out+0x00400ad5)
#3 gomp_thread_start
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/team.c:118
(libgomp.so.1+0x000177a8)

  Previous atomic write of size 8 at 0x7d740001eb48 by thread T3:
#0 __tsan_atomic64_compare_exchange_weak
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libsanitizer/tsan/tsan_interface_atomic.cc:814
(libtsan.so.0+0x0005d3e3)
#1 gomp_iter_guided_next
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/iter.c:327
(libgomp.so.1+0xc1d4)
#2 gomp_loop_guided_next
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:328
(libgomp.so.1+0xdf00)
#3 MAIN__._omp_fn.0 /data/vjoost/gnu/bugs/test.f90:4 (a.out+0x00400ad5)
#4 gomp_thread_start
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/team.c:118
(libgomp.so.1+0x000177a8)

  Location is heap block of size 2080 at 0x7d740001ea00 allocated by main
thread:
#0 malloc
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libsanitizer/tsan/tsan_interceptors.cc:491
(libtsan.so.0+0x000250a3)
#1 gomp_malloc
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/alloc.c:37
(libgomp.so.1+0xabba)
#2 gomp_new_team
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/team.c:149
(libgomp.so.1+0x0001780a)
#3 gomp_parallel_loop_start
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:448
(libgomp.so.1+0xcdfc)
#4 GOMP_parallel_loop_guided
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:519
(libgomp.so.1+0xe6eb)
#5 MAIN__ /data/vjoost/gnu/bugs/test.f90:4 (a.out+0x00400a49)
#6 main /data/vjoost/gnu/bugs/test.f90:8 (a.out+0x00400a96)

  Thread T2 (tid=5743, running) created by main thread at:
#0 pthread_create
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libsanitizer/tsan/tsan_interceptors.cc:895
(libtsan.so.0+0x00026c94)
#1 gomp_team_start
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/team.c:796
(libgomp.so.1+0x00017fee)
#2 gomp_parallel_loop_start
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:450
(libgomp.so.1+0xce95)
#3 GOMP_parallel_loop_guided
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:519
(libgomp.so.1+0xe6eb)
#4 MAIN__ /data/vjoost/gnu/bugs/test.f90:4 (a.out+0x00400a49)
#5 main /data/vjoost/gnu/bugs/test.f90:8 (a.out+0x00400a96)

  Thread T3 (tid=5744, running) created by main thread at:
#0 pthread_create
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libsanitizer/tsan/tsan_interceptors.cc:895
(libtsan.so.0+0x00026c94)
#1 gomp_team_start
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/team.c:796
(libgomp.so.1+0x00017fee)
#2 gomp_parallel_loop_start
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:450
(libgomp.so.1+0xce95)
#3 GOMP_parallel_loop_guided
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/loop.c:519
(libgomp.so.1+0xe6eb)
#4 MAIN__ /data/vjoost/gnu/bugs/test.f90:4 (a.out+0x00400a49)
#5 main /data/vjoost/gnu/bugs/test.f90:8 (a.out+0x00400a96)

SUMMARY: ThreadSanitizer: data race
/data/vjoost/toolchain-tsan/build/gcc-5.1.0/libgomp/iter.c:304
gomp_iter_guided_next
==

[Bug tree-optimization/67284] [6 regression] libgo fails to build on trunk r227015 / *-linux-gnu

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

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

Andreas Schwab  changed:

   What|Removed |Added

 Target|powerpc64le-linux-gnu,  |powerpc64le-linux-gnu,
   |x64_64-pc-linux-gnu |x64_64-pc-linux-gnu,
   ||aarch64-*
Version|5.2.1   |6.0
 Blocks||67133
   Target Milestone|--- |6.0
Summary|libgo fails to build on |[6 regression] libgo fails
   |trunk r227015 / *-linux-gnu |to build on trunk r227015 /
   ||*-linux-gnu


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67133
[Bug 67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in
gimple_op, at gimple.h:2274

[Bug libgomp/67303] libgomp: ThreadSanitizer: data race in libgomp

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is a partly false negative.  In the sense the load from ws->start just
needs to be __atomic_load(&ws->start, RELAX) to be correct.  This in it of
itself is the same as what it is correctly doing.  Just removes the error from
the thread santitizer.

The main reason why I say this is because we are doing a compare and swap loop
to check if ws->start has changed when doing the lock-less popping off the
stack.

[Bug middle-end/67285] ICE with (rdiv (POW:s @0 REAL_CST@1) @0)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/67285] ICE with (rdiv (POW:s @0 REAL_CST@1) @0)

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Fri Aug 21 08:06:20 2015
New Revision: 227053

URL: https://gcc.gnu.org/viewcvs?rev=227053&root=gcc&view=rev
Log:
2015-08-21  Richard Biener  

PR middle-end/67285
* gimple-fold.c (replace_stmt_with_simplification): Assert
seq is empty when replacing a call with itself but different
arguments.
* gimple-match-head.c (maybe_push_res_to_seq): When pushing
a call require that it is const.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/gimple-match-head.c

[Bug rtl-optimization/67227] [6 regression] comparison failure in ada/par.o

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-21
  Component|tree-optimization   |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |aoliva at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Alexandre Oliva  ---
Mine.  Patch posted at https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01275.html

[Bug tree-optimization/67284] [6 regression] libgo fails to build on trunk r227015 / *-linux-gnu

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Looks like

--- a/gcc/gimple-ssa-isolate-paths.c
+++ b/gcc/gimple-ssa-isolate-paths.c
@@ -115,7 +115,8 @@ insert_trap (gimple_stmt_iterator *si_p, tree op)
   else
 gsi_insert_before (si_p, seq, GSI_NEW_STMT);

-  split_block (gimple_bb (new_stmt), new_stmt);
+  edge e = split_block (gimple_bb (new_stmt), new_stmt);
+  remove_edge (e);
   *si_p = gsi_for_stmt (stmt);
 }

fixes it.

[Bug tree-optimization/67284] [6 regression] libgo fails to build on trunk r227015 / *-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org

[Bug inline-asm/67301] Unable to compile program using extended assembly and asmSymbolicName

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||documentation
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-21
  Component|driver  |inline-asm
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
Confirmed as documentation issue.

[Bug middle-end/67298] [6 Regression] 254.gap in SPEC CPU 2000 is miscompiled

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |6.0

[Bug other/67304] New: Allow front-ends to share command-line options with different behaviours

[ibuclaw at gdcproject dot org]

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

Bug ID: 67304
   Summary: Allow front-ends to share command-line options with
different behaviours
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Marking as enhancement, as I'm sure that my situation is pretty unique (also
coming from a frontend maintained outside of gcc).

There are a couple of compiler-provided features in my frontend's frontend that
does the following for any provided source code to the compiler:
- Generate documentation.
- Generate 'header' sources.

Both come with independent options to set either the output file or directory.

Because they are 'generator' features, and do not have any effect on the
compilation process or codegen (unlike, for instance -fno-bounds-check), I'm a
bit wary of using an -fxxx option for them.

The upstream reference compiler uses the following options:

---
-D generate documentation
-Dd write documentation file to directory
-Df  write documentation file to filename
-H generate 'header' file
-Hd write 'header' file to directory
-Hf  write 'header' file to filename
---

Whilst it may seem natural to use the same options (also a win for existing
build tools), alas this is no good because C/C++ claims both -D and -H as
theirs and theirs only.  This seems overtly restricted.

For me, it makes more sense if the generated options.[ch] files had two levels
for handling front-end provided options.
1. To determine if the language handles -X
2. To forward -X to the language specific handler for processing/help/errors.

However I am not too familiar with the awk files used in the process, so I'm
not sure how much of an undertaking this will be.


N.B.  There's been a -J option in my frontend for some 12 years now, I'm not
sure if this precedes Fortran (long before my time when I picked up the
compiler), but Fortran claims it as theirs.  However I use it for something
completely different, and I guess it's only pure chance that we share identical
command-line usage. ;)

[Bug tree-optimization/67305] New: [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[jiwang at gcc dot gnu.org]

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

Bug ID: 67305
   Summary: [6 Regression] gcc.c-torture/compile/20121027-1.c ICE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jiwang at gcc dot gnu.org
CC: vmakarov at redhat dot com
  Target Milestone: ---
Target: arm-none-eabi

since r226850, seen on arm-none-eabi only currently.

it can be easily reproduced by the following command. -mfpu and -mfloat are
necessary.

./cc1 -O3 -nostdinc 20121027-1.c  -march=armv8-a -mthumb
-mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard

cross cc1 is generated from
   ../gcc/configure --target=arm-none-eabi --enable-languages=c,c++


t.c:13:1: internal compiler error: in decompose_normal_address, at 
rtlanal.c:6090
 }
 ^
0xc94a37 decompose_normal_address
/space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6090
0xc94d25 decompose_address(address_info*, rtx_def**, machine_mode, 
unsigned char, rtx_code)
/space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6167
0xc94dc3 decompose_mem_address(address_info*, rtx_def*)
/space/rguenther/tramp3d/trunk/gcc/rtlanal.c:6187
0xb61149 process_address_1
/space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:2867
0xb61c4e process_address
/space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:3124
0xb62607 curr_insn_transform
/space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:3419
0xb65250 lra_constraints(bool)
/space/rguenther/tramp3d/trunk/gcc/lra-constraints.c:4421

Richard's initial comments

that looks like a latent issue to me in an area of GCC I am not
familiar with.  I suggest to open a bugreport and CC Vladimir.

The r226850 change caused us to eliminate an induction variable
early (I suspect IVOPTs would have done this later anyway, but
I did not verify that):

Replaced redundant PHI node defining bl_2 with c_1
Replaced c_1 + 1 with bl_15 in all uses of c_16 = c_1 + 1;
Removing dead stmt c_16 = c_1 + 1;
Removing dead stmt bl_2 = PHI <0(2), bl_15(3)>

[Bug rtl-optimization/67305] [6 Regression] gcc.c-torture/compile/20121027-1.c ICE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-21
  Component|tree-optimization   |rtl-optimization
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

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

[Bug c++/67302] copy elision in return (expression)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-21
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The useless parentheses on the return expression disable elision, but that's a
bug.

[Bug tree-optimization/67306] New: Patterns ICEs when moved using "simplify and match"

[hs.naveen2u at gmail dot com]

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

Bug ID: 67306
   Summary: Patterns ICEs when moved using "simplify and match"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hs.naveen2u at gmail dot com
  Target Milestone: ---

Created attachment 36232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36232&action=edit
Testcase to reproduce the issue

Hi,

I am trying to move some patterns using simplify and match.
Moved some patterns and observed that some patterns ICEs for
Long Double and Float patterns.

The patterns which does the operations are:-

 /* Simplify sqrt(x) * sqrt(y) -> sqrt(x*y).  */
(for root (SQRT CBRT)
 (simplify
  (mult (root:s @0) (root:s @1))
  (root (mult @0 @1

 /* Simplify pow(x,y) * pow(x,z) -> pow(x,y+z). */
 (simplify
  (mult (POW:s @0 @1) (POW:s @0 @2))
(POW @0 (plus @1 @2)))

 /* Simplify expN(x) * expN(y) -> expN(x+y). */
(for expss (EXP EXP2 EXP10 POW10)
 (simplify
  (mult (exps:s @0) (exps:s @1))
   (exps (plus @0 @1

/* Simplify x / expN(y) into x*expN(-y). */
(for expss (EXP EXP2 EXP10 POW10)
 (simplify
  (rdiv @0 (exps:s @1))
   (mult @0 (exps (negate @1)


All the operations in the attached testcase results in SEG FAULT:-
aarch64-thunder-elf-gcc simlify-2.c -O2 -funsafe-math-optimizations -lm

[Bug c++/67302] [C++14] copy elision in return (expression)

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|copy elision in return  |[C++14] copy elision in
   |(expression)|return (expression)

--- Comment #2 from Jonathan Wakely  ---
Possibly started with the introduction of force_paren_expr in r197248

The fix for Bug 63437 allows it to compile, but didn't re-enable elision.

[Bug c++/66957] [4.9/5/6 Regression] incorrect "is protected within this context" error

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #7 from Ville Voutilainen  ---
For what it's worth, this patch looked like it might also fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972, and it
does.

[Bug other/67304] Allow front-ends to share command-line options with different behaviours

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
On Fri, 21 Aug 2015, ibuclaw at gdcproject dot org wrote:

> -D generate documentation

The driver needs to know what's an option and what's an option argument, 
so that it can identify input files and know what front end or front ends 
to run.  How would you expect it to distinguish your front end's -D (an 
option on its own) from the C "-D foo" (option with separate argument)?  
Or are you only interested in these options for a language-specific driver 
program, not with the generic "gcc" driver?

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||paolo.carlini at oracle dot com

--- Comment #2 from Ville Voutilainen  ---
Looks like the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957
may have fixed this. Paolo, would you like to clean this up with a testcase?

[Bug c++/58972] Lambda can't access private members

[ville.voutilainen at gmail dot com]

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

--- Comment #13 from Ville Voutilainen  ---
Looks like the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66957
may have fixed this one, too.

[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c

[zeccav at gmail dot com]

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

--- Comment #6 from Vittorio Zecca  ---
A shorter source file displaying the same bug:

// from pr42049.c
// gcc -funroll-loops -O
// ../../gcc-5.2.0/gcc/loop-iv.c:2670:14: runtime error: 
// signed integer overflow: 7 - -9223372036854775808 cannot be represented in
type 'long int'
// loop-iv.c source line "max = (uint64_t) (up - down) / inc + 1;"
// Target: x86_64-unknown-linux-gnu
// COLLECT_GCC_OPTIONS='-funroll-loops' '-O' '-mtune=generic' '-march=x86-64'
void
foo (void)
{
 long int i;
 for (i = 1; i  && i < 8; i++);
}

[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-21
   Assignee|unassigned at gcc dot gnu.org  |trippels at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #7 from Markus Trippelsdorf  ---
Hmm, git blame of /* source line "max = (uint64_t) (up - down) / inc + 1;" */
points to me.
I will take a look.

[Bug ipa/67307] New: FE considers 'inline int foo ()' as always-inline, inlining not disabled via -fno-early-inlining

[rguenth at gcc dot gnu.org]

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

Bug ID: 67307
   Summary: FE considers 'inline int foo ()' as always-inline,
inlining not disabled via -fno-early-inlining
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, jsm28 at gcc dot gnu.org
  Target Milestone: ---

inline int foo (int i) { return i; }

runs into c-decl.c

  /* For GNU C extern inline functions disregard inline limits.  */
  if (DECL_EXTERNAL (fndecl)
  && DECL_DECLARED_INLINE_P (fndecl))
DECL_DISREGARD_INLINE_LIMITS (fndecl) = 1;


but not with -std=gnu89, only with -std=gnu99.  This means it is considered
"always-inline" by inline_always_inline_functions which means it is still
inlined early even with -fno-early-inlining.

Not sure if the FE behavior is desired - we have DECL_DECLARED_INLINE_P
to guide general inlining.  DECL_DISREGARD_INLINE_LIMITS should really
be only used if "always-inline" semantics are to be wanted by the FE.

[Bug ipa/67307] FE considers 'inline int foo ()' as always-inline, inlining not disabled via -fno-early-inlining

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
I don't see an obvious reason to disregard limits here, but haven't 
checked the history of the code.  C99 inline functions must always have an 
extern version provided somewhere in the program in case they aren't 
inlined.

[Bug other/67304] Allow front-ends to share command-line options with different behaviours

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #2 from Manuel López-Ibáñez  ---
(In reply to Iain Buclaw from comment #0)
> However I am not too familiar with the awk files used in the process, so I'm
> not sure how much of an undertaking this will be.

>From my own experience, being familiar with awk is not really needed. You just
need to figure out what C++ code you want to generate (options.c, options.h)
and how it will interact with the rest of GCC. I will suggest that you actually
prototype your changes directly hacking options.c and options.h, then you
modify the awk scripts to generate that code. Modifying the scripts is not that
complex, just printing the right things at the right place (probably our awk
scripts can be very much cleaned up and optimized but it hasn't been an issue
so far).

[Bug tree-optimization/67306] Patterns ICEs when moved using "simplify and match"

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-21
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Ah, indeed.  Mine.

[Bug tree-optimization/67306] Patterns ICEs when moved using "simplify and match"

[rguenth at gcc dot gnu.org]

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

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

Patch I am testing

[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c

[zeccav at gmail dot com]

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

--- Comment #8 from Vittorio Zecca  ---
Maybe the easiest way to reproduce the issue is as in the following;

gdb ~/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1
GNU gdb (GDB) Fedora 7.8.2-39.fc21
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
/home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1...done.
(gdb) break ../../gcc-5.2.0/gcc/loop-iv.c:2671
Breakpoint 1 at 0x153209e: file ../../gcc-5.2.0/gcc/loop-iv.c, line 2671.
(gdb) run gccerr14.c -O -quiet -funroll-loops
Starting program:
/home/vitti/local/gcc-5.2.0-sanitized/libexec/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1
gccerr14.c -O -quiet -funroll-loops
Missing separate debuginfos, use: debuginfo-install glibc-2.20-8.fc21.x86_64
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, iv_number_of_iterations (loop=0x2aaab633f360,
insn=0x2aaab635e400, condition=0x2aaab6362d98, 
desc=0x7fffa810) at ../../gcc-5.2.0/gcc/loop-iv.c:2671
2671  max = (uint64_t) (up - down) / inc + 1;
Missing separate debuginfos, use: debuginfo-install gmp-6.0.0-9.fc21.x86_64
libmpc-1.0.2-3.fc21.x86_64 mpfr-3.1.2-8.fc21.x86_64
(gdb) print up
$1 = 7
(gdb) print down
$2 = -9223372036854775808

But you need an unoptimized version of cc1

[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
Patch posted: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01308.html

[Bug other/67304] Allow front-ends to share command-line options with different behaviours

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw  ---
(In reply to jos...@codesourcery.com from comment #1)
> On Fri, 21 Aug 2015, ibuclaw at gdcproject dot org wrote:
> 
> > -D generate documentation
> 
> The driver needs to know what's an option and what's an option argument, 
> so that it can identify input files and know what front end or front ends 
> to run.  How would you expect it to distinguish your front end's -D (an 
> option on its own) from the C "-D foo" (option with separate argument)?  
> Or are you only interested in these options for a language-specific driver 
> program, not with the generic "gcc" driver?

If I were to assume that the driver for each language (g++, gfortran, gcj)
would be considered part of the generic "gcc" driver, then it would be the
latter rather than the former.

If it is indeed the former, then you might ignore the next comment, which is by
and large just me thinking out loud with not a good deal of understanding this
particular component of gcc.

The desired behaviour I've got in mind, is that from knowing which
language-specific options each front-end uses (by collecting all options from
lang.opt), the decoding process becomes:

if (option->flags & lang_specific_mask)
  lang_specific[lang]->decode(argv + i, &opt_array[num_decoded_options]);

Where:
 - lang_specific_mask: Starts off being whatever language the driver defaults
to compiling for (CL_CXX for g++, etc...), but is overridden given the -Xlang
option.
 - lang_specific[lang]->decode: Calls an auto generated function from the
language-specific lang.opt input files (options-cxx.c)

However this would, in trying to consider all angles, add some extra bloat with
the duplications of "shared-but-not-common" handlers, unless some clever
merging is done.  I guess it would also mean that the entire command-line
decoding process may need to be rolled back and restarted if an -Xnew-lang
option is encountered.

[Bug sanitizer/67308] New: FATAL: ThreadSanitizer: unexpected memory mapping

[doko at gcc dot gnu.org]

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

Bug ID: 67308
   Summary: FATAL: ThreadSanitizer: unexpected memory mapping
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/796246]

seen on the gcc-5-branch.

$ uname -r
4.1.0-3-generic
$ echo 'void main(void){}' | gcc -pie -fPIE -fsanitize=thread -xc - -ltsan &&
./a.out
FATAL: ThreadSanitizer: unexpected memory mapping 0x555caf24a000-0x555caf24b000

"""
There was an intentional change in the kernel that causes PIEs to be
loaded in a different address range:

https://git.kernel.org/linus/d1fd836dcf00d2028c700c7e44d2c23404062c90

I think ThreadSanitizer is just going to have to learn about this.
"""

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini  ---
Hi Ville. Unfortunately it still fails for me, in the same way. Are you using
the complete testcase, including the line outside namespace std?

[Bug c++/64816] gcc claims that constructor is private when it should be accessible

[ville.voutilainen at gmail dot com]

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

--- Comment #4 from Ville Voutilainen  ---
Sorry for the noise, I managed to drop out that last line, bummer. So no, this
hasn't been fixed yet.

[Bug c++/58972] Lambda can't access private members

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|jason at redhat dot com|jason at gcc dot gnu.org
   Target Milestone|--- |6.0

--- Comment #14 from Jason Merrill  ---
Yep, fixed for GCC 6.

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367
Bug 54367 depends on bug 58972, which changed state.

Bug 58972 Summary: Lambda can't access private members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58972

   What|Removed |Added

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

[Bug c++/67309] New: Error compiling with -std=c++11 and -fsingle-precision-constant

[dflogeras2 at gmail dot com]

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

Bug ID: 67309
   Summary: Error compiling with -std=c++11 and
-fsingle-precision-constant
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dflogeras2 at gmail dot com
  Target Milestone: ---

The ARM people recommend using -fsingle-precision-constant for targeting their
microcontrollers, such as the Cortex M4.  I am experimenting with using parts
of modern C++ on my uC projects.

If I compile the following (not just with arm cross compilers, even my native
linux compiler):

#include 
int main() {}

with:
gcc test.cpp -fsingle-precision-constant -std=c++11 -c

It fails, since c++11 templating will not promote float types, and there is an
ambiguous 6.0 floating point constant in the bowels of the STL, which ends up
with a call to std::max( float, double ) which is illegal.

Not sure what the proper fix is, and I'm also not sure why this used to compile
for me (same flags, gcc-4.7.3), but no longer does.

[Bug target/67310] New: [PATCH] gcc 4.8.4 fails to compile with -march=native on VIA nano CPU

[jol_indien at yahoo dot fr]

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

Bug ID: 67310
   Summary: [PATCH] gcc 4.8.4 fails to compile with -march=native
on VIA nano CPU
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jol_indien at yahoo dot fr
  Target Milestone: ---

Created attachment 36234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36234&action=edit
patch to properly detect VIA nano CPU

GCC 4.8.4 detects VIA nano CPU as a "core2" one and thus fails to compile any
executable when called with "-march=native":
echo 'int main(){return 0;}' > test.c && gcc -march=native  -O2   test.c -o
test && rm test.c test
test.c:1:0: error: CPU you selected does not support x86-64 instruction set
 int main(){return 0;}
 ^

The attached patch properly detects the VIA nano CPU and sets up the proper
compile flags, ie:
 -march=x86-64 -mcx16 -msahf -mno-movbe -mno-aes
 -mno-pclmul -mno-popcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop
 -mno-bmi -mno-bmi2 -mno-tbm -mno-avx -mno-avx2 -msse3 -mssse3 -mno-sse4.2
 -mno-sse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c
 -mno-fsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mno-xsave
 -mno-xsaveopt --param l1-cache-size=64 --param l1-cache-line-size=64
 --param l2-cache-size=1024 -mtune=generic
which enables:  -mcx16 -mfxsr -mmmx -msahf -msse -msse2 -msse3 -mssse3

Of course, this does not give a full support of this CPU family but allows to
compile properly for it.

Tested with:
vendor_id   : CentaurHauls
cpu family  : 6
model   : 15
model name  : VIA Nano processor U2250 (1.6GHz Capable)
stepping: 3

Please consider to apply this patch.

[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Author: trippels
Date: Fri Aug 21 16:44:30 2015
New Revision: 227075

URL: https://gcc.gnu.org/viewcvs?rev=227075&root=gcc&view=rev
Log:
Fix PR61657 (undefined behavior in loop-iv.c)

bootstrap-ubsan shows:
 loop-iv.c:2626:14: runtime error: signed integer overflow: 9223372036854775806
- -9223372036854775808 cannot be represented in type 'long int'

Fixed by moving the variables in question from signed to unsigned.

PR rtl-optimization/61657
* loop-iv.c (iv_number_of_iterations): Declare up and down as
unsigned. Remove superflous uint64_t cast.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/loop-iv.c

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 61657, which changed state.

Bug 61657 Summary: Undefined behavior in loop-iv.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61657

   What|Removed |Added

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

[Bug rtl-optimization/61657] Undefined behavior in loop-iv.c

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #11 from Markus Trippelsdorf  ---
Fixed on trunk.

[Bug fortran/67311] New: ICE calling subroutine with derived type as argument within OpenMP parallel region

[acreman at astro dot ex.ac.uk]

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

Bug ID: 67311
   Summary: ICE calling subroutine with derived type as argument
within OpenMP parallel region
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acreman at astro dot ex.ac.uk
  Target Milestone: ---

The following test case produces an internal compiler error with recent
gfortran versions:

! == Begin test case ==
subroutine test
  call openmp_sub
end subroutine test

subroutine openmp_sub

  implicit none

  TYPE myType
TYPE(myType), DIMENSION(:), POINTER :: x
  END TYPE myType

  type(myType) :: argument
!$OMP PARALLEL DEFAULT(NONE) PRIVATE(argument)
  call foo(argument)
!$OMP END PARALLEL

end subroutine openmp_sub
! == End test case ==

The command line used to build was:  gfortran -c -fopenmp test.f90
I see an ICE at versions 4.9.3 and 5.2 on SLES and gfortran 4.9.2 on Mac OS. 
The test case compiles OK with version 4.6.3 (SLES) and 4.8.2 (Ubuntu)

The output from gfortran 4.9.3 is: 

> gfortran -c -fopenmp test.f90
gfortran: internal compiler error: Segmentation fault (program f951)
0x40d14c execute
../../gcc-4.9.3/gcc/gcc.c:2854
0x40d514 do_spec_1
../../gcc-4.9.3/gcc/gcc.c:4658
0x40fdd6 process_brace_body
../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
../../gcc-4.9.3/gcc/gcc.c:5312
0x40fdd6 process_brace_body
../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
../../gcc-4.9.3/gcc/gcc.c:5312
0x40e0f3 do_spec_1
../../gcc-4.9.3/gcc/gcc.c:5427
0x40fdd6 process_brace_body
../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
../../gcc-4.9.3/gcc/gcc.c:5312
0x40fdd6 process_brace_body
../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
../../gcc-4.9.3/gcc/gcc.c:5312
0x40eea6 do_spec_2
../../gcc-4.9.3/gcc/gcc.c:4359
0x4104b8 do_spec(char const*)
../../gcc-4.9.3/gcc/gcc.c:4326
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-21
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Thanks for the nice testcase. There are a few such constants in the library,
and we *really* do want them to be double precision because we are passing them
to std::min or std::max, so they're meant to be doubles and so
-fsingle-precision-constant buys you nothing here. I suppose we can add an
explicit template argument list to the calls to force promotion to double.

[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
N.B. it fails for me even before GCC 4.7.3, possibly since  was first
added and included by .

[Bug c++/67240] [concepts] Implicit conversion constraints are not respected

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/67240] [concepts] Implicit conversion constraints are not respected

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Fri Aug 21 18:33:07 2015
New Revision: 227081

URL: https://gcc.gnu.org/viewcvs?rev=227081&root=gcc&view=rev
Log:
PR c++/67240
* constraint.cc (satisfy_implicit_conversion_constraint): Also
check for NULL_TREE.

Added:
trunk/gcc/testsuite/g++.dg/concepts/iconv1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constraint.cc

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-21
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
The ICE appeared between revisions r211105 (2014-05-31, no ICE) and r211652
(2014-06-13, ICE) for 5.0. The change has been back ported to 4.9.

[Bug tree-optimization/67312] New: [6 Regression] ICE: SIGSEGV in expand_expr_real_1 (expr.c:9561) with -ftree-coalesce-vars

[zsojka at seznam dot cz]

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

Bug ID: 67312
   Summary: [6 Regression] ICE: SIGSEGV in expand_expr_real_1
(expr.c:9561) with -ftree-coalesce-vars
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36235&action=edit
reduced testcase

Compiler output:
$ gcc -ftree-coalesce-vars testcase.c -wrapper valgrind,-q
==23677== Invalid read of size 2
==23677==at 0x81C88A: expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) (expr.c:9561)
==23677==by 0x82FA16: expand_expr (expr.h:255)
==23677==by 0x82FA16: expand_assignment(tree_node*, tree_node*, bool)
(expr.c:5101)
==23677==by 0x706988: expand_gimple_stmt_1 (cfgexpand.c:3599)
==23677==by 0x706988: expand_gimple_stmt(gimple_statement_base*)
(cfgexpand.c:3695)
==23677==by 0x708C88: expand_gimple_basic_block(basic_block_def*, bool)
(cfgexpand.c:5698)
==23677==by 0x70F5A6: (anonymous
namespace)::pass_expand::execute(function*) (cfgexpand.c:6284)
==23677==by 0xA3D491: execute_one_pass(opt_pass*) (passes.c:2319)
==23677==by 0xA3D955: execute_pass_list_1(opt_pass*) [clone .constprop.79]
(passes.c:2372)
==23677==by 0xA3D9A8: execute_pass_list(function*, opt_pass*)
(passes.c:2383)
==23677==by 0x743AC7: cgraph_node::expand() (cgraphunit.c:1920)
==23677==by 0x7449F2: output_in_order(bool) (cgraphunit.c:2158)
==23677==by 0x744DDB: symbol_table::compile() [clone .part.50]
(cgraphunit.c:2403)
==23677==by 0x747597: compile (cgraphunit.c:2473)
==23677==by 0x747597: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2496)
==23677==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23677== 
testcase.c: In function 'foo':
testcase.c:3:7: internal compiler error: Segmentation fault
 y = x;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Tested revisions:
r227052 - ICE
5 branch r225803 - OK

[Bug c++/67313] New: [6 Regression] ICE: in vague_linkage_p, at cp/decl2.c:1878 with -fno-weak and variadic template

[zsojka at seznam dot cz]

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

Bug ID: 67313
   Summary: [6 Regression] ICE: in vague_linkage_p, at
cp/decl2.c:1878 with -fno-weak and variadic template
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---

Created attachment 36236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36236&action=edit
reduced testcase

Compiler output:
$ gcc -fno-weak testcase.C
testcase.C: In function 'void f() [with  = {}]':
testcase.C:2:1: internal compiler error: in vague_linkage_p, at cp/decl2.c:1878
 f ()
 ^
0x6ba472 vague_linkage_p(tree_node*)
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:1878
0x6ba5bb generate_mangling_alias
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4361
0xf87820 decl_assembler_name(tree_node*)
/mnt/svn/gcc-trunk/gcc/tree.c:658
0xfab7a7 assign_assembler_name_if_neeeded(tree_node*)
/mnt/svn/gcc-trunk/gcc/tree.c:5829
0x915158 cgraph_node::analyze()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:629
0x918533 analyze_functions
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:1028
0x919050 symbol_table::finalize_compilation_unit()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:2477
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Tested revisions:
r227052 - ICE
5 branch r225803 - OK

[Bug middle-end/67295] [ARM][6 Regression] FAIL: gcc.target/arm/builtin-bswap-1.c scan-assembler-times revshne\\t 1

[aoliva at gcc dot gnu.org]

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

--- Comment #1 from Alexandre Oliva  ---
I get exactly the same code with r226900, before the copyrename patch:

cmp r1, #0
rev16ne r0, r0
uxthne  r0, r0
.L2:
sxthr0, r0
b   foos16

Did you use any other configuration flags or compiler options or assembler
version or something to get you the better-optimized code?

[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant

[dflogeras2 at gmail dot com]

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

--- Comment #3 from Dave Flogeras  ---
That is what is weird to me, it definitely used to compile for me with GCC
4.7.3 and 4.8.3 (with the same build system flags).

Is there anything that is conditional when compiling GCC that maybe the Gentoo
crossdev folks have changed over time, which could mask this behaviour?  I
don't imagine they were patching those headers.  However, when I rebuild my
cross GCC 4.7.3 with crossdev, it now fails, as you've noted.

I am happy to test patchsets, and or even come up with them if you think this
is something worth delegating.  I have no experience in GCC's tree, but I can
follow orders :)

[Bug rtl-optimization/67227] [6 regression] comparison failure in ada/par.o

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Aug 21 20:03:14 2015
New Revision: 227085

URL: https://gcc.gnu.org/viewcvs?rev=227085&root=gcc&view=rev
Log:
fix sched compare regression

for  gcc/ChangeLog

PR rtl-optimization/64164
PR rtl-optimization/67227
* alias.c (memrefs_conflict_p): Handle VALUEs in PLUS better.
(nonoverlapping_memrefs_p): Test offsets and sizes when given
identical gimple_reg exprs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c

[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level

[aoliva at gcc dot gnu.org]

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

--- Comment #53 from Alexandre Oliva  ---
Author: aoliva
Date: Fri Aug 21 20:03:14 2015
New Revision: 227085

URL: https://gcc.gnu.org/viewcvs?rev=227085&root=gcc&view=rev
Log:
fix sched compare regression

for  gcc/ChangeLog

PR rtl-optimization/64164
PR rtl-optimization/67227
* alias.c (memrefs_conflict_p): Handle VALUEs in PLUS better.
(nonoverlapping_memrefs_p): Test offsets and sizes when given
identical gimple_reg exprs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/alias.c

[Bug rtl-optimization/67227] [6 regression] comparison failure in ada/par.o

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
Fixed

[Bug bootstrap/66978] [6 Regression] bootstrap failure with --with-multilib-list=m32,m64,mx32

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66978
Bug 66978 depends on bug 67227, which changed state.

Bug 67227 Summary: [6 regression] comparison failure in ada/par.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227

   What|Removed |Added

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

[Bug rtl-optimization/64164] [4.9/5/6 Regression] one more stack slot used due to one less inlining level

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64164
Bug 64164 depends on bug 67227, which changed state.

Bug 67227 Summary: [6 regression] comparison failure in ada/par.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227

   What|Removed |Added

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

[Bug rtl-optimization/67000] [6 Regression] ICE in split_complex_args, at function.c:2325 on ppc64le

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67000
Bug 67000 depends on bug 67227, which changed state.

Bug 67227 Summary: [6 regression] comparison failure in ada/par.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227

   What|Removed |Added

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

[Bug middle-end/66983] [6 Regression] Many testsuite regressions

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66983
Bug 66983 depends on bug 67227, which changed state.

Bug 67227 Summary: [6 regression] comparison failure in ada/par.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227

   What|Removed |Added

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

[Bug middle-end/67035] [6 Regression] FAIL: gcc.c-torture/compile/pr54713-3.c

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67035
Bug 67035 depends on bug 67227, which changed state.

Bug 67227 Summary: [6 regression] comparison failure in ada/par.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227

   What|Removed |Added

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

[Bug middle-end/67034] [6 Regression] FAIL: gcc.c-torture/compile/pr39928-1.c

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67034
Bug 67034 depends on bug 67227, which changed state.

Bug 67227 Summary: [6 regression] comparison failure in ada/par.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67227

   What|Removed |Added

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

[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Are you site you were always using -std=c++11?

The algorithm header won't include the random header without that.

[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant

[dflogeras2 at gmail dot com]

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

--- Comment #5 from Dave Flogeras  ---
Definitely, this project is my testbed for playing with new C++ features on a
STM32F4 micro.  I also checked the ChibiOS (the RTOS I use) and it has always
had -fsingle-precision-constant defined (well for all versions I have used in
the past year).

Certainly mysterious, maybe Gentoo was patching it.. I mean it has to be
deterministic after all.

[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant

[dflogeras2 at gmail dot com]

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

--- Comment #6 from Dave Flogeras  ---
Created attachment 36237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36237&action=edit
Patch for random.tcc

This patch made the test case presented compile cleanly for myself.  It is from
GCC-4.8.4's tree because that is what I had kicking around.

[Bug c/67314] New: No warning on assigning an out-of-range integer to an enum

[chengniansun at gmail dot com]

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

Bug ID: 67314
   Summary: No warning on assigning an out-of-range integer to an
enum
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chengniansun at gmail dot com
  Target Milestone: ---

$: cat t.c
enum E {e} ee = 99;
$: gcc-trunk -Wall -Wextra -c t.c
$: clang-trunk  -c t.c
$: cat t.c
enum E {e} ee = 99;
$: gcc-trunk -Wall -Wextra -c t.c
$: clang-trunk  -Wassign-enum -c t.c
t.c:1:17: warning: integer constant not in range of enumerated type 'enum E'
[-Wassign-enum]
enum E {e} ee = 99;
^
1 warning generated.

[Bug c/67314] No warning on assigning an out-of-range integer to an enum

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This warning is only useful for c++. C defines the full range of the underlying
type of the enum for the enum while c++ has different rules. 

Also I think this warning would be too noisy for c code and clang is wrong to
implement it for c.

[Bug c++/67315] New: Strange 'this' pointer behavior when calling virtual function with different optimization attributes.

[waseemsarwar103 at yahoo dot com]

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

Bug ID: 67315
   Summary: Strange 'this' pointer behavior when calling virtual
function with different optimization attributes.
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: waseemsarwar103 at yahoo dot com
  Target Milestone: ---

Created attachment 36238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36238&action=edit
preprocessed file of the code in bug

The issue below only get produced on x86 (32 bit) system.

Compiler Version: gcc 4.9.0 (Target: i686-pc-linux-gnu)

System Type:  ubuntu 14.04.02
(Linux dev-virtual-machine 3.16.0-30-generic #40~14.04.1-Ubuntu SMP Thu Jan 15
17:45:15 UTC 2015 i686 i686 i686 GNU/Linux)

GCC Compilation Options: 
Configured with: ../gcc-4.9.0/configure --prefix=/home/was/gcc/gcc_install/
--with-gmp=/home/was/gcc/gcc_install/gcc_pre/
--with-mpfr=/home/was/gcc/gcc_install/gcc_pre/ --enable-shared
--with-system-zlib --enable-threads=posix
--with-mpc='/home/was/gcc/gcc_install/gcc_pre/1~'

Compilation command: 
g++- -ggdb -O3 -Wall -Werror -fstrict-aliasing -Wstrict-aliasing=2 -Wcast-align
-fPIC -fno-exceptions -fno-rtti -funsigned-char -DNOTLS -D__STDC_LIMIT_MACROS
-D__STDC_FORMAT_MACROS  -o incorrect_this.o test_incorrect_this.cpp

Comiler Output: Clean compilation. No error or warnings.

Description:
When following code is compiled with '-O3' but certain functions in the derived
class uses specific function attribute '(__attribute__((optimize("O0"' to
not apply global optimization to those functions, then calling the virtual
function from within those function causes 'this' pointer to be garbage and is
way off than the actual 'this' pointer.

If I compile the whole code with 'O0', the problem goes away. It seems like the
compiler is producing incompatible code when the function has optimization
level of 'O0' and calling a virtual function that was compiled with "O3". 

I have the following code that reproduces the problem with compiler version gcc
4.9.0, 4.9.2 and 4.9.3 on x86 systems. Observe 'this' pointer behavior in
virtual functions calls. 

Code: 
#include 

class ITest1
{
public:
virtual void test11(void) = 0;
};

class ITest2
{
public:
virtual void test21(void)
{
printf("Calling test21 %p\n", this);
}
};

#define OPTIMIZE_SIZE __attribute__((optimize("O0")))

class Test : public ITest1, public ITest2
{
public:
Test() : m_test(0)
{ }

OPTIMIZE_SIZE void init()
{
m_test = 4;
printf("Init %p \n", this);
printf("m_test = %d\n", m_test);

// All following functions have strange 'this' pointer value.
test11();
test21();
}


void test11(void)
{
printf("Calling test11 %p\n", this);
//printf("m_test = %d \n", m_test);
}

void test12(void)
{
printf("Calling test12 %p\n", this);
}


private:
int m_test;
};

int main()
{
Test *test = new Test();
test->init();
}

Output:

root@dev-virtual-machine:/home/dev/framework/test_incorrect_this#
./incorrect_this.o
Init 0x96d9a10
m_test = 4
Calling test11 0xc
Calling test21 0xc

Observe that this pointer has changed to completely different value pointing to
garbage. 

Please help me understand the problem and potential fix to avoid this kind of
scenario. Thanks.

[Bug c/67314] No warning on assigning an out-of-range integer to an enum

[chengniansun at gmail dot com]

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

--- Comment #2 from Chengnian Sun  ---
(In reply to Andrew Pinski from comment #1)
> This warning is only useful for c++. C defines the full range of the
> underlying type of the enum for the enum while c++ has different rules. 
> 
> Also I think this warning would be too noisy for c code and clang is wrong
> to implement it for c.

Thanks for your reply. So in C, if I understand correctly, the enum construct
is mainly to define a set of integer constants. It is not like the enumerations
in other languages, such as Java, to define a set of categorical values.

[Bug c/67314] No warning on assigning an out-of-range integer to an enum

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
In fact, this is warned by -Wc++-compat. since this is invalid in C++. I think
a patch that moves this warning under a new flag -Wassign-enum which is enabled
by -Wc++-compat may be accepted, but you need to try. I doubt anyone else is
going to implement this for you.

[Bug c/67316] New: Address local variable returned as 0x0

[llandwerlin at gmail dot com]

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

Bug ID: 67316
   Summary: Address local variable returned as 0x0
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: llandwerlin at gmail dot com
  Target Milestone: ---

Playing with a project using Hans Boehm's GC (http://www.hboehm.info/gc/), and
getting a crash with gcc 5.2.1,  I nailed down the difference to the following
program :

--

#include 

typedef char* ptr_t;
typedef unsigned long word;

ptr_t GC_approx_sp1(void)
{
volatile word dummy;
dummy = 42;
return((ptr_t)&dummy);
}

ptr_t GC_approx_sp2(void)
{
volatile word dummy;
dummy = 42;
ptr_t ret = (ptr_t)&dummy;
return ret;
}

int
main(int argc, char* argv[]) {
  printf("sp1=%p, sp2=%p\n", GC_approx_sp1(), GC_approx_sp2());
  return 0;
}

--

GCC 4.8/4.9 will print something like this : sp1=0x7ffc8fa4ce98,
sp2=0x7ffc8fa4ce90
GCC 5.2.1 will print this  : sp1=(nil), sp2=0x7ffcb650d550

I may be missing something obvious here, but if this is a programming error, I
find it weird this thing never got caught before.

For info the function from hboehm's GC is GC_approx_sp().

Thanks!

[Bug c/67316] Address local variable returned as 0x0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is undefined behavior.  Returning the address of a local variable is
undefined.
If you want to trick the compiler though here is a better solution (than just
moving the address taking out of the return):
ptr_t GC_approx_sp2(void)
{
volatile word dummy;
dummy = 42;
ptr_t ret = (ptr_t)&dummy;
asm("":"+r"(ret));
return ret;
}

[Bug inline-asm/67317] New: [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[myriachan at gmail dot com]

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

Bug ID: 67317
   Summary: [x86] Silly code generation for
_addcarry_u32/_addcarry_u64
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: myriachan at gmail dot com
  Target Milestone: ---

x86 intrinsics _addcarry_u32 and _addcarry_u64 generate silly code.  For
example, the following function to get the result of a 64-bit addition (the XOR
is to the output clearer):

u64 testcarry(u64 a, u64 b, u64 c, u64 d)
{
u64 result0, result1;
_addcarry_u64(_addcarry_u64(0, a, c, &result0), b, d,
&result1);
return result0 ^ result1;
}

This is the code generated with -O1, -O2 and -O3:

xor r8d, r8d
add r8b, -1
adc rdx, rdi
setcr8b
mov rax, rdx
add r8b, -1
adc rcx, rsi
xor rax, rcx
ret

The first sillyness is that _addcarry_u64 does not optimize a compile-time
constant 0 being the first carry parameter.  Instead of "adc", it should just
use "add".

The second sillyness is with the use of r8b to store the carry flag, then using
"add r8b, -1" to put the result back into carry.

Instead, the code should be something like this:

add rdx, rdi
mov rax, rdx
adc rcx, rsi
xor rax, rcx
ret

Naturally, for something this simple, I'd use unsigned __int128, but this came
up in large number math.

[Bug inline-asm/67317] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Can you provide the full preprocessed source?