[Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu

[chefmax at gcc dot gnu.org]

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

--- Comment #14 from Maxim Ostapenko  ---
Author: chefmax
Date: Wed Oct 21 07:44:35 2015
New Revision: 229113

URL: https://gcc.gnu.org/viewcvs?rev=229113&root=gcc&view=rev
Log:
libsanitizer/

PR sanitizer/63958
Reapply:
2014-10-14  David S. Miller  

* sanitizer_common/sanitizer_platform_limits_linux.cc (time_t):
Define at __kernel_time_t, as needed for sparc.
(struct __old_kernel_stat): Don't check if __sparc__ is defined.
* libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
(__sanitizer): Define struct___old_kernel_stat_sz,
struct_kernel_stat_sz, and struct_kernel_stat64_sz for sparc.
(__sanitizer_ipc_perm): Adjust for sparc targets.
(__sanitizer_shmid_ds): Likewsie.
(__sanitizer_sigaction): Likewise.
(IOC_SIZE): Likewsie.

Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc
trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h

[Bug bootstrap/63888] [5 Regression] bootstrap failed when configured with -with-build-config=bootstrap-asan --disable-werror

[chefmax at gcc dot gnu.org]

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

--- Comment #41 from Maxim Ostapenko  ---
Author: chefmax
Date: Wed Oct 21 07:47:54 2015
New Revision: 229114

URL: https://gcc.gnu.org/viewcvs?rev=229114&root=gcc&view=rev
Log:
libsanitizer/

PR bootstrap/63888
Reapply:
2015-02-20  Jakub Jelinek  

* asan/asan_globals.cc (RegisterGlobal): Disable detect_odr_violation
support until it is rewritten upstream.

* c-c++-common/asan/pr63888.c: New test.


Modified:
trunk/libsanitizer/ChangeLog
trunk/libsanitizer/asan/asan_globals.cc

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak  ---
The runtime version of the test still fails:

--cut here--
#include 

__m128d reg = { 2.0, 4.0 };

void
__attribute__((noinline))
set_lower (double b)
{
  double v[2];
  _mm_store_pd(v, reg);
  v[0] = b;
  reg = _mm_load_pd(v);
}

int
main ()
{
  set_lower (6.0);

  if (reg[1] != 4.0)
abort ();

  return 0;
}
--cut here--

gcc -O2 -pr67609.c

$ ./a.out
Aborted

set_lower:
.LFB518:
movdqa  reg(%rip), %xmm1# 6 *movti_internal/4
>>  movapd  %xmm0, %xmm1# 7 *movdf_internal/14
movaps  %xmm1, reg(%rip)# 8 *movv2df_internal/3
ret # 14simple_return_internal

Marked insn moves the whole register and clobbers the high word of the xmm1.

[Bug c++/67904] g++ crashes and asks for bugreport

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||nickc at redhat dot com,
   ||ramana.radhakrishnan at arm 
dot co
   ||m, richard.earnshaw at arm dot 
com
   Severity|critical|normal

--- Comment #2 from Paolo Carlini  ---
I can't either, with -m32. Let's add arm maintainers in CC.

[Bug tree-optimization/68026] [6 Regression] Regression in GCC-6.0.0's optimizer

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 21 07:56:54 2015
New Revision: 229117

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

PR tree-optimization/68026
* tree-ssa-ccp.c (get_value_for_expr): Zero-extend mask for
unsigned VARYING values.

* gcc.dg/tree-ssa/ssa-ccp-39.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-ccp-39.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug tree-optimization/68026] [6 Regression] Regression in GCC-6.0.0's optimizer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68031] [6 Regression] cc1 crashes when compiling newlib / mktm_r.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/68031] [6 Regression] cc1 crashes when compiling newlib / mktm_r.c

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 21 08:08:05 2015
New Revision: 229118

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

PR middle-end/68031
* fold-const.c: Include tree-ssa-operands.h and tree-into-ssa.h.
(tree_ssa_name_nonnegative_warnv_p): Fold into ...
(tree_single_nonnegative_warnv_p): ... here.  For SSA names
make sure they are not registered for update.

* gcc.dg/torture/pr68031.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr68031.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/68036] [6 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-21
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on valid code at -Os|[6 Regression] ICE on valid
   |and above on|code at -Os and above on
   |x86_64-linux-gnu|x86_64-linux-gnu
 Ever confirmed|0   |1

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

[Bug ipa/68035] ipa performance issue when no procedures are present

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||mliska at suse dot cz

--- Comment #1 from Richard Biener  ---
We try to remove equivalent static const globals (thus unify them).  But we
should quickly arrive to the conclusion they are not equal, sth that doesn't
work here.  Eventually the hashing is also bad.

[Bug ipa/68035] [5/6 Regression] ipa performance issue when no procedures are present

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||compile-time-hog
   Target Milestone|--- |5.3
Summary|ipa performance issue when  |[5/6 Regression] ipa
   |no procedures are present   |performance issue when no
   ||procedures are present

[Bug c++/67904] g++ crashes and asks for bugreport

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 CC||ramana at gcc dot gnu.org

--- Comment #3 from Ramana Radhakrishnan  ---
Created attachment 36554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36554&action=edit
compressed testcase.

I'm unable to reproduce the failure with the following options on a cross
compiler built from the FSF-5 branch around the 1st of October which has
roughly similar configury to what the reporter has put in.

5.2.1 20151001

$GCC -c -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb
-mtls-dialect=gnu -Wall -Wtype-limits -Wignored-qualifiers -Winit-self
-Wpointer-arith -Wnon-virtual-dtor -Wno-invalid-offsetof -Wstrict-null-sentinel
-fno-strict-aliasing -fsigned-char -ftemplate-depth=1024 -fno-builtin-malloc
-fno-builtin-calloc -fno-builtin-realloc -fno-builtin-free -O2 pr67904.ii 

I've attached a compressed version of the testcase for others to play with...

I'm traveling this week so it won't be Monday till when I can be really
productive with this by trying a few versions. So if someone else can play with
this, please be my guest.

Can you also post the messages or a backtrace from the compiler that it may
have printed when aborting so that people can try and reproduce the issue. The
log attached just contains the log of the "pre-processing" step.

[Bug target/68018] [6 Regression] ICE: in ix86_compute_frame_layout, at config/i386/i386.c:11308 with -mstackrealign

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Oct 21 08:43:44 2015
New Revision: 229120

URL: https://gcc.gnu.org/viewcvs?rev=229120&root=gcc&view=rev
Log:
PR target/68018
* config/i386/i386.c (ix86_compute_frame_layout): Realign the stack
for 64-bit MS_ABI targets also when default incoming stack boundary
is overriden.

testsuite/ChangeLog:

PR target/68018
* gcc.target/i386/pr68018.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr68018.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67904] g++ crashes and asks for bugreport

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
I can't get a crash with current trunk or GCC 5 using an
arm-none-linux-gnueabihf cross-compiler.

Also, I don't see what the crash message is supposed to be.
Seeing as the testcase is pretty large, could it be just that the compiler runs
out of memory on your machine?

[Bug c++/66583] incorrect implicitly-defined move constructor for class with anonymous union and NSDMI

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Oct 21 09:27:18 2015
New Revision: 229122

URL: https://gcc.gnu.org/viewcvs?rev=229122&root=gcc&view=rev
Log:
PR c++/66583

* init.c (innermost_aggr_scope): New.
(sort_mem_initializers): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/anon-union1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/init.c

[Bug c++/67557] [4.9/5/6 regression] Calling copy constructor of base class in constructor of derived class produces crashing code

[jason at gcc dot gnu.org]

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

--- Comment #15 from Jason Merrill  ---
Author: jason
Date: Wed Oct 21 09:27:12 2015
New Revision: 229121

URL: https://gcc.gnu.org/viewcvs?rev=229121&root=gcc&view=rev
Log:
PR c++/67557

* call.c (is_base_field_ref): New.
(unsafe_copy_elision_p): New.
(build_over_call): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/init/elide3.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/call.c

[Bug c++/66583] incorrect implicitly-defined move constructor for class with anonymous union and NSDMI

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.3

--- Comment #4 from Jason Merrill  ---
Fixed for 5.3/6.

[Bug tree-optimization/68031] [6 Regression] cc1 crashes when compiling newlib / mktm_r.c

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #6 from Marek Polacek  ---
*** Bug 68036 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/68036] [6 Regression] ICE on valid code at -Os and above on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Marek Polacek  ---
Wait, this should be already fixed.

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

[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
Indeed, there is an issue with outer-loop unswitching - it should not be
performed for infinite loops. But if we slightly modify test if finite
outer-loop we will get the same error: 
char a;
void fn1(char *p1, int p2, int p3) {
  int i, x;
  for (i = 0; i < 10; i++) {
for (x = 0; x < p3; x++) {
  *p1 = a;
  p1--;
}
p1 += p2;
  }
}

I assume that  sccp is responsible for it.

[Bug tree-optimization/68031] [6 Regression] cc1 crashes when compiling newlib / mktm_r.c

[mihail.popa at gmail dot com]

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

Mihail Popa  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #7 from Mihail Popa  ---
Thanks for the fast resolution

[Bug fortran/68040] New: [5/6 Regression] Internal compiler error: Error reporting routines re-entered.

[dominiq at lps dot ens.fr]

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

Bug ID: 68040
   Summary: [5/6 Regression] Internal compiler error: Error
reporting routines re-entered.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
  Target Milestone: ---

On x86_64-apple-darwin14 compiling the following test (second test in pr47030)

module m
   real :: x
   common /mydata/ x
   !GCC$ attributes dllexport :: mydata
end module

with -Wall gives

f951: Warning: 'dllexport' attribute directive ignored [-Wattributes]

up to revision r217100 (2014-11-04), but gives the ICE

'
in pp_format, at pretty-print.c:617

Internal compiler error: Error reporting routines re-entered.
gfortran: internal compiler error: Abort trap: 6 (program f951)
Abort

for revisions after r217653 (2014-11-17).

backtrace

#0  0x7fff8c312286 in __pthread_kill () from
/usr/lib/system/libsystem_kernel.dylib
#1  0x7fff90d429f9 in pthread_kill () from
/usr/lib/system/libsystem_pthread.dylib
#2  0x7fff960809b3 in abort () from /usr/lib/system/libsystem_c.dylib
#3  0x000100d2e761 in uw_init_context_1 (context=0x6,
outer_cfa=0x7fff5fbfea00, outer_ra=0x100c879e9 )
at ../../../_clean/libgcc/unwind-dw2.c:1563
#4  0x000100d2f1c8 in _Unwind_Backtrace (trace=0x100c878f0 ,
trace_argument=0x7fff7a2f8300) at ../../../_clean/libgcc/unwind.inc:283
#5  0x000100c879e9 in backtrace_full (state=0x1420f5000, skip=, callback=, error_callback=, 
data=) at ../../_clean/libbacktrace/backtrace.c:127
#6  0x000100c4c743 in diagnostic_action_after_output (context=0x1415a7ac0,
diag_kind=) at ../../_clean/gcc/diagnostic.c:450
#7  0x000100c4c97e in diagnostic_report_diagnostic (context=0x1415a7ac0,
diagnostic=0x7fff5fbfeaf0) at ../../_clean/gcc/diagnostic.c:788
#8  0x000100c4d7d5 in internal_error (gmsgid=) at
../../_clean/gcc/diagnostic.c:1141
#9  0x000100c4c256 in fancy_abort (file=, line=, function=) at ../../_clean/gcc/diagnostic.c:1209
#10 0x000100c502e9 in pp_format (pp=0x1422013a0, text=0x7fff5fbfee50) at
../../_clean/gcc/pretty-print.c:614
#11 0x000100c4c951 in diagnostic_report_diagnostic (context=0x1415a7ac0,
diagnostic=0x7fff5fbfee50) at ../../_clean/gcc/diagnostic.c:784
#12 0x000100c4cf74 in warning (opt=177, gmsgid=) at
../../_clean/gcc/diagnostic.c:948
#13 0x000100ca61f1 in decl_attributes (node=,
attributes=, flags=) at
../../_clean/gcc/attribs.c:446
#14 0x0001000f6ae2 in gfc_get_symbol_decl (sym=) at
../../_clean/gcc/fortran/trans-decl.c:1557
#15 0x0001000f9339 in gfc_create_module_variable (sym=) at
../../_clean/gcc/fortran/trans-decl.c:4567
#16 0x0001000bf0dc in do_traverse_symtree (st=,
st_func=, sym_func=)
at ../../_clean/gcc/fortran/symbol.c:3719
#17 0x0001000fc82e in gfc_generate_module_vars (ns=) at
../../_clean/gcc/fortran/trans-decl.c:5004
#18 0x0001000d8949 in gfc_generate_module_code (ns=) at
../../_clean/gcc/fortran/trans.c:1988
#19 0x00010008bfbf in gfc_parse_file () at
../../_clean/gcc/fortran/parse.c:5533
#20 0x0001000d22a6 in gfc_be_parse_file () at
../../_clean/gcc/fortran/f95-lang.c:209
#21 0x000100947d9a in compile_file () at ../../_clean/gcc/toplev.c:483
#22 0x000100d333fc in ?? ()
#23 0x000100d34db9 in main (argc=3, argv=0x7fff5fbff308) at
../../_clean/gcc/main.c:39

[Bug c++/66999] Missing comma in lambda capture causes internal compiler error

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-21
 Ever confirmed|0   |1

[Bug c++/66897] ICE when using remove_reference with type tagged with __may_alias__

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|apfokin at gmail dot com   |
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #1 from Paolo Carlini  ---
Fixed in trunk.

[Bug c++/66892] [DR355] Fix of core language defect 355 has status c++11 but is not implemented yet

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

   Severity|enhancement |normal

[Bug fortran/55207] [F08] Variables declared in the main program should implicitly get the SAVE attribute

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #19 from Janne Blomqvist  ---
As was mentioned recently on comp.lang.fortran, this affects OpenMP. Consider

program teste_paralelo
  use omp_lib
  real :: v1(12,60,60,60,2)
  !$omp parallel do
  do kk=2,60
 v1(5,2,2,kk,1)=0
  enddo
  !$omp end parallel do
  !$omp parallel
  print *, 'Hello World!'
  !$omp end parallel
end program teste_paralelo

Compiling without OpenMP and checking the binary with size, the array v1 is
allocated statically in the bss section:

$ gfortran -g teste_paralelo.f90 -o test-serial
$ size test-serial 
   textdata bss dec hex filename
   2147 608 207360322073878713c72e3 test-serial

Enabling openmp, the array suddenly goes on the stack:

$ gfortran -g -fopenmp teste_paralelo.f90 -o test
$ size test
   textdata bss dec hex filename
   2822 656   83486 d9e test


If one manually makes v1 saved, it naturally goes into the bss with openmp too:

$ gfortran -g -fopenmp teste_paralelo.f90 -o test-save 
$ size test-save 
   textdata bss dec hex filename
   2790 656 207360322073947813c7596 test-save

[Bug fortran/67171] [6 regression] sourced allocation

[mikael at gcc dot gnu.org]

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #7 from Mikael Morin  ---
(In reply to Andre Vehreschild from comment #4)
> Hi Paul,
> 
> please compare:
> 
> https://gcc.gnu.org/ml/fortran/2015-10/msg00033.html
> 
> to your fix. Sounds like we are doing the same.
> 

(In reply to Andre Vehreschild from comment #6)
> Hi Paul,
> 
> No it's not, but the patch for the other pr addresses a lot of things in the
> allocate. Mostly about functions returning class objects, but I remember to
> have changed some of the things your patch might address . I just wanted to
> point you to similar work.
> 
Andre, the patch linked above doesn't seem to address that many things,
especially allocate-related.
Maybe you were referring to the following patch instead? It's also one of
yours, and still awaiting review.

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02208.html

[Bug bootstrap/68041] New: [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[dominiq at lps dot ens.fr]

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

Bug ID: 68041
   Summary: [6 Regression] Bootstrap broken on
x86_64-apple-darwin14 at revision r229119
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: chefmax at gcc dot gnu.org, iains at gcc dot gnu.org,
rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin14
Target: x86_64-apple-darwin14
 Build: x86_64-apple-darwin14

Bootstrap broken on x86_64-apple-darwin14 at revision r229119 (likely r229111):

...
libtool: link:  /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/bin/
-B/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/lib/ -isystem
/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/include -isystem
/opt/gcc/gcc6w/x86_64-apple-darwin14.5.0/sys-include-dynamiclib
-Wl,-undefined -Wl,dynamic_lookup -o .libs/libasan.3.dylib 
.libs/asan_activation.o .libs/asan_allocator.o .libs/asan_debugging.o
.libs/asan_fake_stack.o .libs/asan_flags.o .libs/asan_globals.o
.libs/asan_interceptors.o .libs/asan_linux.o .libs/asan_mac.o
.libs/asan_malloc_linux.o .libs/asan_malloc_mac.o .libs/asan_malloc_win.o
.libs/asan_new_delete.o .libs/asan_poisoning.o .libs/asan_posix.o
.libs/asan_report.o .libs/asan_rtl.o .libs/asan_stack.o .libs/asan_stats.o
.libs/asan_suppressions.o .libs/asan_thread.o .libs/asan_win.o
.libs/asan_win_dll_thunk.o .libs/asan_win_dynamic_runtime_thunk.o  
-Wl,-force_load,../sanitizer_common/.libs/libsanitizer_common.a
-Wl,-force_load,../lsan/.libs/libsanitizer_lsan.a 
-L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/src/.libs
-L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/src
-L/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libstdc++-v3/libsupc++/.libs -lrt
-lpthread -ldl ../../libstdc++-v3/src/.libs/libstdc++.dylib -lm   
-install_name  /opt/gcc/gcc6w/lib/libasan.3.dylib -compatibility_version 4
-current_version 4.0 -Wl,-single_module
ld: library not found for -lrt
collect2: error: ld returned 1 exit status
Makefile:446: recipe for target 'libasan.la' failed
make[4]: *** [libasan.la] Error 1
make[4]: Leaving directory
'/opt/gcc/build_w/x86_64-apple-darwin14.5.0/libsanitizer/asan'
...

[Bug c++/66781] "confused by earlier errors, bailing out" with wrong enum within class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-21
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
 Ever confirmed|0   |1

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[chefmax at gcc dot gnu.org]

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

--- Comment #1 from Maxim Ostapenko  ---
Yes, this is mine.

[Bug fortran/67171] [6 regression] sourced allocation

[vehre at gcc dot gnu.org]

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Hi Mikael,

yes, you are absolutely right. I mixed those two up, sorry. My head is in CUDA
programming currently and that's keeping it quite busy. Feel free to review
though :-)

Regards,
   Andre

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[chefmax at gcc dot gnu.org]

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

--- Comment #2 from Maxim Ostapenko  ---
Created attachment 36555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36555&action=edit
First version of the fix.

Dominique, I'm sorry about that. Could you please try attached patch? There may
be other errors for Darwin in libsanitizer build (I didn't make proper testing
because of lack of target) and it would be great to fix them here too.

[Bug target/66326] Floating point exception with -mfpmath=387 and -fcilkplus.

[ryan.burn at gmail dot com]

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

ryan.burn at gmail dot com changed:

   What|Removed |Added

 CC||ryan.burn at gmail dot com

--- Comment #4 from ryan.burn at gmail dot com ---
I'm getting a similar problem testing with 6.0. Only the flags -mfpmath doesn't
seem to make a difference for the case I'm testing. But it runs successfully
with -O1 or above but fails with -O0. Not sure which particular option is
causing the problem.

Here's the code I'm testing with

///
#include 
#include 
#include 

template 
void do_not_optimize_away(T&& x) {
  asm volatile("" : "+r"(x));
}

const int N = 1'000'000;

auto compute() {
  std::vector v(N);
  auto rng = std::mt19937{std::random_device{}()};
  std::uniform_real_distribution dist(0, 1);
  for (int i = 0; i < N; ++i) v[i] = std::log(std::sqrt(dist(rng)));
  return v;
}

int main() {
  std::vector v1, v2, v3;
  cilk_spawn [&] { v1 = compute(); }();
  cilk_spawn [&] { v2 = compute(); }();
  v3 = compute();
  do_not_optimize_away(v1.data());
  do_not_optimize_away(v2.data());
  do_not_optimize_away(v3.data());
  return 0;
}
///

// O1 level - good
rnburn@localhost ~/test/gcc_cilk $ /home/rnburn/local/bin/g++ -std=c++1z -O1
-fcilkplus -std=c++14   -march=haswell t2.cpp 
rnburn@localhost ~/test/gcc_cilk $ ./a.out 

// O0 level - fails
rnburn@localhost ~/test/gcc_cilk $ /home/rnburn/local/bin/g++ -std=c++1z -O0
-fcilkplus -std=c++14   -march=haswell t2.cpp 
rnburn@localhost ~/test/gcc_cilk $ ./a.out 
Floating point exception

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
> Created attachment 36555 [details]
> First version of the fix.
>
> Dominique, I'm sorry about that. Could you please try attached patch?
> There may be other errors for Darwin in libsanitizer build (I didn't
> make proper testing because of lack of target) and it would be great
> to fix them here too.

Thanks for the quick answer. Bootstrap with the patch in progress, allow for ~2
hours.

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug fortran/68040] [5/6 Regression] Internal compiler error: Error reporting routines re-entered.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |5.3

[Bug tree-optimization/68021] [6 Regression] ice in rewrite_use_nonlinear_expr with -O3

[ysrumyan at gmail dot com]

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

--- Comment #5 from Yuri Rumyantsev  ---
Hi HJ

I added my evaluation to bug. It looks like my changes are not
responsible for ICE.

2015-10-20 13:20 GMT+03:00 hjl.tools at gmail dot com
:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68021
>
> H.J. Lu  changed:
>
>What|Removed |Added
> 
>  CC||ysrumyan at gmail dot com
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Compiling the first test with -Wall gives the warning

 !GCC$ attributes dllexport :: mydata
1
Warning: Unused variable 'mydata' declared at (1) [-Wunused-variable]

for 5.2.0 and 6.0, without ' [-Wunused-variable]' for 4.8 and 4.9.

Compiling the second test gives

f951: warning: 'dllexport' attribute directive ignored [-Wattributes]

for 4.8 and 4.9 and an ICE for 5.2.0 and 6.0 (pr68040).

I don't get any warning for the third test for 4.8 up to trunk (6.0).

[Bug fortran/47879] wrong-debug issue with multiple USE-assoc of variables of other translation units

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> From Bug #47839 comment 6
> > The ICE is fixed.  The wrong-debug issue remains as soon as two USE
> > associations for the same variable exist.

Is is still an issue. If yes, would it be possible to have a better test case?

[Bug sanitizer/68016] ASan doesn't catch overflow in globals when COPY relocation is involved.

[chefmax at gcc dot gnu.org]

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

--- Comment #2 from Maxim Ostapenko  ---
Ok, I guess won't fix here.

[Bug rtl-optimization/67635] [SH] ifcvt missed optimization

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
(In reply to ktkachov from comment #2)
> 
> Perhaps we can consider teaching cse to not transform these kinds of
> expressions (c ? x : x + a) if the target has a store_flag/addcc instruction
> of the appropriate mode?

Sounds a bit shaky.  These sequences could also be introduced by other things
than the CSE pass.  I guess a more "stable" solution would be to make ifcvt
realize that in one path x must be zero and effectively un-CSE it, then proceed
as usual.

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
With the patch in comment 2, bootstrap completed without any problem.

Preliminary tests for g++ and asan

=== g++ Summary for unix/-m64 ===

# of expected passes1007
# of unexpected failures14
# of unsupported tests  179

=== g++ Summary ===

# of expected passes2021
# of unexpected failures21
# of unsupported tests  358

the failures are

FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -Os  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2 -flto
-flto-partition=none  output pattern test
FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2 -flto  output pattern
test

for both -m32 and -m64, and

FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O1  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O3 -g  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -Os  output pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto -flto-partition=none  output
pattern test
FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto  output pattern test

for -m64 only.

How many lines of the output do you need to adjust the regexps?

Further tests for ubsan and gcc in progress.

[Bug target/68028] Compilation error "lto1: error: target attribute or pragma changes single precision floating point", with "-flto" on different variant of powerpc like -mcpu=e6500, 8540, 8548, e500m

[ranjan.amit8 at gmail dot com]

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

--- Comment #2 from martin  ---
Hi Richard,

 You mean to say that there is no issue with LTO, the error is only due to
addition flags for particular -mcpu.

I am only getting this issue when I passs -flto option with -mcpu=e6500.
Without -flto there is no issue as

 $ ./powerpc-windriver-linux-gcc test.c -mcpu=e6500

It means with particular -mcpu with -flto option switches additional flags
which is resulting in this error during compilation. While those additional
flags came into picture after gcc-5.1.0 release.

$ ./powerpc-windriver-linux-gcc test.c -mcpu=e6500 -flto
In function âmainâ:
lto1: warning: compilation : main_target_opt = 1
lto1: error: target attribute or pragma changes single precision floating point
lto1: error: target attribute or pragma changes double precision floating point
lto-wrapper: fatal error: ./powerpc-windriver-linux-gcc returned 1 exit status
compilation terminated.
/opt/2cross/lib/gcc/powerpc-windriver-linux/5.2.0/../../../../powerpc-windriver-linux/bin/ld:
lto-wrapper failed
collect2: error: ld returned 1 exit status

Can you guide me further.

Thanks,
Martin

[Bug c++/67991] Pointer to function with internal linkage not being allowed, when it should be

[nacitar at ubercpp dot com]

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

--- Comment #7 from Jacob McIntosh  ---
Per a thread on the isocpp group(linked in the OP), N4268's wording was
incorporated shortly before C++14's ratification, so it's unclear to me why
this is a C++1z feature and not a C++14 feature.

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[chefmax at gcc dot gnu.org]

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

--- Comment #5 from Maxim Ostapenko  ---
(In reply to Dominique d'Humieres from comment #4)
> With the patch in comment 2, bootstrap completed without any problem.
> 
> Preliminary tests for g++ and asan
> 
>   === g++ Summary for unix/-m64 ===
> 
> # of expected passes  1007
> # of unexpected failures  14
> # of unsupported tests179
> 
>   === g++ Summary ===
> 
> # of expected passes  2021
> # of unexpected failures  21
> # of unsupported tests358
> 
> the failures are
> 
> FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O0  output pattern test
> FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O1  output pattern test
> FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2  output pattern test
> FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O3 -g  output pattern test
> FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -Os  output pattern test
> FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2 -flto
> -flto-partition=none  output pattern test
> FAIL: c-c++-common/asan/sanity-check-pure-c-1.c   -O2 -flto  output pattern
> test
> 
> for both -m32 and -m64, and
> 
> FAIL: c-c++-common/asan/memcmp-1.c   -O0  output pattern test
> FAIL: c-c++-common/asan/memcmp-1.c   -O1  output pattern test
> FAIL: c-c++-common/asan/memcmp-1.c   -O2  output pattern test
> FAIL: c-c++-common/asan/memcmp-1.c   -O3 -g  output pattern test
> FAIL: c-c++-common/asan/memcmp-1.c   -Os  output pattern test
> FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto -flto-partition=none  output
> pattern test
> FAIL: c-c++-common/asan/memcmp-1.c   -O2 -flto  output pattern test
> 
> for -m64 only.
> 
> How many lines of the output do you need to adjust the regexps?

Thanks! These tests passed before, right? So, could you share more details
about these tests output (perhaps open a new bug with sanitizer label)?

> 
> Further tests for ubsan and gcc in progress.

[Bug target/68028] Compilation error "lto1: error: target attribute or pragma changes single precision floating point", with "-flto" on different variant of powerpc like -mcpu=e6500, 8540, 8548, e500m

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
I was saying that LTO now makes it appear like it uses target attributes to
change this kind of property and this is because the rs6000.opt file tells
it that it can do this.  But then when it does things fail.

I think the code still passes on -mcpu=e6500 to the link stage thus you
get

int __attribute__((target("cpu=e6500"))) main()
{
}

compiled by

$ ./powerpc-pc-linux-gcc test.c -mcpu=e6500

does that work? (without LTO?)


Note I have in my local tree

Index: gcc/lto-opts.c
===
--- gcc/lto-opts.c  (revision 229119)
+++ gcc/lto-opts.c  (working copy)
@@ -201,6 +201,12 @@ lto_write_options (void)
  && lto_stream_offload_p)
continue;

+  /* Do not store target-specific options if we target a
+ SWITCHABLE_TARGET target.  */
+  if ((cl_options[option->opt_index].flags & CL_TARGET)
+ && SWITCHABLE_TARGET)
+   continue;
+
   /* Drop options created from the gcc driver that will be rejected
 when passed on to the driver again.  */
   if (cl_options[option->opt_index].cl_reject_driver)

which would stop us from passing the target options seen at compile-time
as the "default global state" to the link command.

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres  ---
> Further tests for ubsan and gcc in progress.

g++/ubsan

=== g++ Summary for unix/-m64 ===

# of expected passes2950
# of expected failures  49
# of unsupported tests  175

=== g++ Summary ===

# of expected passes5837
# of expected failures  98
# of unsupported tests  371

gcc/asan (same failures as for g++/asan)

=== gcc Summary for unix/-m64 ===

# of expected passes904
# of unexpected failures14
# of unsupported tests  156

=== gcc Summary ===

# of expected passes1815
# of unexpected failures21
# of unsupported tests  312

gcc/ubsan

=== gcc Summary for unix/-m64 ===

# of expected passes2346
# of unsupported tests  157

=== gcc Summary ===

# of expected passes4629
# of unsupported tests  335

> Thanks! These tests passed before, right? So, could you share more
> details about these tests output (perhaps open a new bug with sanitizer
> label)?

I'll do that later today.

[Bug target/68028] Compilation error "lto1: error: target attribute or pragma changes single precision floating point", with "-flto" on different variant of powerpc like -mcpu=e6500, 8540, 8548, e500m

[ranjan.amit8 at gmail dot com]

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

--- Comment #4 from martin  ---
$ ./powerpc-pc-linux-gcc test.c -mcpu=e6500

does that work? (without LTO?)

Yes, It works without -flto.

[Bug c++/55986] RHS of logical operators may render LHS unevaluated in constant-expression

[yaghmour.shafik at gmail dot com]

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

--- Comment #5 from Shafik Yaghmour  ---
It looks like this case from this Stackoverflow question
http://stackoverflow.com/q/32920229/1708801 is possibly related:

int main(int argc, char**)
{
constexpr int a = argc * 0;
}

gcc treats `argc * 0` as a constant expression a comment indicates this is due
to constant folding and it seems possible that gcc is constant folding `i ||
true` as well.

[Bug sanitizer/68042] New: [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[dominiq at lps dot ens.fr]

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

Bug ID: 68042
   Summary: [6 Regression]
c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c)
failures on x86_64-apple-darwin14 after r229111
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dominiq at lps dot ens.fr
CC: chefmax at gcc dot gnu.org, dodji at gcc dot gnu.org,
dvyukov at gcc dot gnu.org, iains at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin14
Target: x86_64-apple-darwin14
 Build: x86_64-apple-darwin14

As reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68041 the test
c-c++-common/asan/sanity-check-pure-c-1.c fails with -m32 and -m64, while the
test c-c++-common/asan/memcmp-1.c fails with -m64 only (gcc or g++).

With r229078 the output for memcmp-1.c is

==78782==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff52f1c2a4 at pc 0x00010ccf9d99 bp 0x7fff52f1c260 sp 0x7fff52f1ba10
READ of size 6 at 0x7fff52f1c2a4 thread T0
#0 0x10ccf9d98  (/opt/gcc/gcc6a/lib/libasan.2.dylib+0xed98)
#1 0x10cce3db4 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10db4)
#2 0x7fff8d6885c8  (/usr/lib/system/libdyld.dylib+0x35c8)
#3 0x0  ()

Address 0x7fff52f1c2a4 is located in stack of thread T0 at offset 36 in frame
#0 0x10cce3cdb 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10cdb)

  This frame has 2 object(s):
[32, 36) 'a1' <== Memory access at offset 36 overflows this variable
[96, 100) 'a2'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 ??
...

with r229123 the output is

==78732==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fff5b7c82a4 at pc 0x000104486c10 bp 0x7fff5b7c8260 sp 0x7fff5b7c7a10
READ of size 6 at 0x7fff5b7c82a4 thread T0
#0 0x104486c0f in wrap_memcmp.part.128
sanitizer_common_interceptors.inc:414
#1 0x104437da1 in main (a.out+0x10da1)
#2 0x7fff8d6885c8 in start (libdyld.dylib+0x35c8)
#3 0x0  ()

Address 0x7fff5b7c82a4 is located in stack of thread T0 at offset 36 in frame
#0 0x104437cc6 in main (a.out+0x10cc6)

  This frame has 2 object(s):
[32, 36) 'a1' <== Memory access at offset 36 overflows this variable
[96, 100) 'a2'
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism or swapcontext
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
sanitizer_common_interceptors.inc:414 in wrap_memcmp.part.128
...

The corresponding outputs for sanity-check-pure-c-1.c are

==79126==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020e095
at pc 0x00010624ff15 bp 0x7fff599b0320 sp 0x7fff599b0318
READ of size 1 at 0x6020e095 thread T0
#0 0x10624ff14 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10f14)
#1 0x7fff8d6885c8  (/usr/lib/system/libdyld.dylib+0x35c8)
#2 0x0  ()

0x6020e095 is located 5 bytes inside of 10-byte region
[0x6020e090,0x6020e09a)
freed by thread T0 here:
#0 0x1062872c9  (/opt/gcc/gcc6a/lib/libasan.2.dylib+0x322c9)
#1 0x10624fed2 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10ed2)
#2 0x7fff8d6885c8  (/usr/lib/system/libdyld.dylib+0x35c8)
#3 0x0  ()

previously allocated by thread T0 here:
#0 0x10628711a  (/opt/gcc/gcc6a/lib/libasan.2.dylib+0x3211a)
#1 0x10624fec2 
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x10ec2)
#2 0x7fff8d6885c8  (/usr/lib/system/libdyld.dylib+0x35c8)
#3 0x0  ()

SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??
...

and

==79057==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020e095
at pc 0x00010880befe bp 0x7fff573f4320 sp 0x7fff573f4318
READ of size 1 at 0x6020e095 thread T0
#0 0x10880befd in main (a.out+0x10efd)
#1 0x7fff8d6885c8 in start (libdyld.dylib+0x35c8)
#2 0x0  ()

0x6020e095 is located 5 bytes inside of 10-byte region
[0x6020e090,0x6020e09a)
freed by thread T0 here:
#0 0x1088615d0 in wrap_free.part.0 asan_malloc_mac.cc:112
#1 0x10880bebb in main (a.out+0x10ebb)
#2 0x7fff8d6885c8 in start (libdyld.dylib+0x35c8)
#3 0x0  ()

previously allocated by thread T0 here:
#0 0x1088602a7 in wrap_malloc asan_malloc_mac.cc:104
#1 0x10880beab in main (a.out+0x10eab)
#2 0x7fff8d6885c8 in start (libdyld.dylib+0x35c8)
#3 0x0  ()

SUMMARY: AddressSanitizer: heap-use-after-free (a.out+0x10efd) in main

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
> I'll do that later today.

pr68042.

[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[chefmax at gcc dot gnu.org]

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

--- Comment #1 from Maxim Ostapenko  ---
I wonder if the fix would be just output patterns adjustment (just like here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63939)?

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[chefmax at gcc dot gnu.org]

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

--- Comment #8 from Maxim Ostapenko  ---
Created attachment 36556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36556&action=edit
The patch I've posted to gcc-patches ML for review.

[Bug bootstrap/68041] [6 Regression] Bootstrap broken on x86_64-apple-darwin14 at revision r229119

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> Created attachment 36556 [details]
> The patch I've posted to gcc-patches ML for review.

I have not tested the part "removes -lc++abi flag for UBSan on Darwin" (later
tonight).
Comment from Iain Sandoe on IRC:

  we don't use libc++ anyway on GCC, so academic
  i.e. "it seems the right thing to do"

[Bug sanitizer/68042] [6 Regression] c-c++-common/asan/(memcmp-1.c|sanity-check-pure-c-1.c) failures on x86_64-apple-darwin14 after r229111

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> I wonder if the fix would be just output patterns adjustment (just like here:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63939)?

Indeed, however the regexprs are quite unfriendly and I probably won't have the
time to look at them before the end of the week.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[vmakarov at gcc dot gnu.org]

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

--- Comment #14 from Vladimir Makarov  ---
(In reply to Uroš Bizjak from comment #13)
> The runtime version of the test still fails:
> 
> 
> gcc -O2 -pr67609.c
> 
> $ ./a.out
> Aborted
> 
> set_lower:
> .LFB518:
> movdqa  reg(%rip), %xmm1# 6 *movti_internal/4
> >>  movapd  %xmm0, %xmm1# 7 *movdf_internal/14
> movaps  %xmm1, reg(%rip)# 8 *movv2df_internal/3
> ret # 14simple_return_internal
> 
> Marked insn moves the whole register and clobbers the high word of the xmm1.

Yes, right.  The bug is not fixed yet.  Although it is not RA problem anymore,
I believe.

Before final we have

(insn:TI 7 6 8 2 (set (subreg:DF (reg/v:TI 22 xmm1 [orig:89 v ] [89]) 0)
(reg/v:DF 21 xmm0 [orig:90 b ] [90])) b3.c:7 126 {*movdf_internal}
 (expr_list:REG_DEAD (reg/v:DF 21 xmm0 [orig:90 b ] [90])
(nil)))

How can the final pass use movapd for this?  RTL semantics say high part of
xmm1 should be not changed.

I only can guess.  That final pass removes the subreg first as it was done in
LRA earlier.

I see two solutions.  Prevent the final remove the subreg first and generate
corresponding insn (most probably needs some additions to i386.md).  Or prevent
use movapd in *movdf_internal using movlpd instead (by the way it will also
solve other bugs like 67124).

The first solution is less safe as it may affect all targets.  Although it
could be implemented in a safe way: remove the subreg only if there is no insn
definition with subreg.  But I am not a specialist in writing md files to be
sure (e.g. how to treat insn as *movdf_internal on all passes and only as insn
with subreg on the final pass).

[Bug c/68024] Diagnose variadic functions defined without prototypes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c/68024] Diagnose variadic functions defined without prototypes

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct 21 17:30:20 2015
New Revision: 229131

URL: https://gcc.gnu.org/viewcvs?rev=229131&root=gcc&view=rev
Log:
PR c/68024
* c-decl.c (start_function): Warn about vararg functions without
a prototype.

* gcc.dg/pr68024.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr68024.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug c/68024] Diagnose variadic functions defined without prototypes

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #15 from Uroš Bizjak  ---
(In reply to Vladimir Makarov from comment #14)

> The first solution is less safe as it may affect all targets.  Although it
> could be implemented in a safe way: remove the subreg only if there is no
> insn definition with subreg.  But I am not a specialist in writing md files
> to be sure (e.g. how to treat insn as *movdf_internal on all passes and only
> as insn with subreg on the final pass).

I think that RTL infrastructure should be fixed/enhanced first to allow proper
handling of subregs through all passes in a consistent way. There is no point
in a special workaround, applicable to only one target, as the same problem
will trigger also for other targets.

Adding Jeff to CC.

[Bug go/67968] go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[gong_su at hotmail dot com]

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

--- Comment #2 from gong_su at hotmail dot com ---
Hi Dominik, the command that failed with go1 internal error has a lot of .go
files specified so I don't know which one actually caused the problem. So
instead I can send you the entire Ethereum build tree so that you should be
able to reproduce the problem by simply unpacking the tar.bz2 file somewhere
and doing a "make geth". I can't attach the build tree here since it's 64MB and
the limit for attachment is 1MB. Let me know if you want me to email you the
build tree. Thanks.

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[hubicka at gcc dot gnu.org]

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

--- Comment #11 from Jan Hubicka  ---
Author: hubicka
Date: Wed Oct 21 18:00:30 2015
New Revision: 229132

URL: https://gcc.gnu.org/viewcvs?rev=229132&root=gcc&view=rev
Log:

PR middle-end/67966
* tree.c (verify_type): Verify that TYPE_MODE match
between TYPE_CANONICAL and type.
* expr.c (store_expr_with_bounds): Revert my previous change.
* expmed.c (store_bit_field_1): Revert prevoius change.
* gimple-expr.c (useless_type_conversion_p): Require TYPE_MODE
to match for all types.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/expmed.c
trunk/gcc/expr.c
trunk/gcc/gimple-expr.c
trunk/gcc/tree.c

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #16 from Jeffrey A. Law  ---
reload has traditionally removed subregs of hardregs and passes after reload
have depended on that behaviour.  Doing something similar in lra is obviously
necessary.  In fact, subregs of multi-word hard regs isn't ever supposed to
appear in the except during allocation & reloading.

I'm not sure why final has another call to cleanup_subreg_operands.  While git
blame blames me, I was just refactoring existing code code back in '98.

Does that shed any light on what the right behaviour for LRA ought to be?

[Bug rtl-optimization/67609] [5/6 Regression] Generates wrong code for SSE2 _mm_load_pd

[vmakarov at gcc dot gnu.org]

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

--- Comment #17 from Vladimir Makarov  ---
(In reply to Jeffrey A. Law from comment #16)
> reload has traditionally removed subregs of hardregs and passes after reload
> have depended on that behaviour.  Doing something similar in lra is
> obviously necessary.  In fact, subregs of multi-word hard regs isn't ever
> supposed to appear in the except during allocation & reloading.
> 
> I'm not sure why final has another call to cleanup_subreg_operands.  While
> git blame blames me, I was just refactoring existing code code back in '98.
> 
> Does that shed any light on what the right behaviour for LRA ought to be?

LRA before the patch did the same as reload.  This case shows that still some
subregs should stay after reload otherwise we have wrong transformations (as
making insn setting high part of the register a dead insn).

Of course, some optimizations can not deal with subregs of multi-regs.  The
patch avoids keeping such subregs.  I also found x86 reg-stack pass can not
deal with any subregisters of stack fp regs.

In any case I spent a lot of time for this small patch which works for at least
5 tested targets.

I guess what we need more is to make final pass (at least for x86-64) to deal
with the rest of subregs in a right way.

[Bug fortran/57360] Implement a warning for implied save

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
I have a quite common "counter example", where a subroutine
is initialized on first invocation:

subroutine foo ()
  logical :: first = .true.
  write(6,*) first
  if (first) then
first = .false.
! Do initialization
  end if
end subroutine foo

call foo ()
call foo ()
end

Should this one also get a warning?

[Bug fortran/67939] ICE on using data with negative substring range

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
I'm testing a patch.

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

[ott at fb dot com]

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

--- Comment #26 from Giuseppe Ottaviano  ---
(In reply to Jonathan Wakely from comment #25)
> There was a G++ bug (now fixed) that made void_t not work, try this
> alternative version:
> 
> template< class... > struct __voider { using type = void; };
> template< class... _T0toN > using __void_t = typename
> __voider<_T0toN...>::type;

Thanks, I finally got it to work! I also had to hack back __alloctr_rebind
because hashtable.h depended on it.

I can confirm that, on my test files, the trailing return approach is not
slower than enable_if on return. 
Since std::allocator is pretty much the only used allocator, I also tried to
add a partial specialization allocator_traits> so that no SFINAE
has to be performed, and there is a non-negligible speedup:

enable_if on return type: 100% (baseline)
_Require/enable_if on extra template argument: 225%
detected_or_t/trailing return type: 100%
partial specialization for allocator<>: 89%

This is all with GCC 4.9.2 with no optimization flags. GCC 5.2 gives similar
times.

Do you use partial specializations as performance optimizations (thus
equivalent to the general case) in libstdc++?

[Bug target/68018] [6 Regression] ICE: in ix86_compute_frame_layout, at config/i386/i386.c:11308 with -mstackrealign

[zsojka at seznam dot cz]

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

--- Comment #5 from Zdenek Sojka  ---
I did a test run with r229094 + the patch applied, and there are no ICEs. All
the ICEs archived from older runs are gone, and no new ones are introduced (eg.
everything that failed in the past now compiles fine). I can only test for
ICEs, not for exec failures.

[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250

[gcc at magfr dot user.lysator.liu.se]

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

--- Comment #16 from Magnus Fromreide  ---
Should the importance of this bug be raised?
It is a bit embarrasing that the program

#include 

ice's

[Bug debug/68010] internal compiler error: in tree_to_shwi, at tree.h:3661

[ghoort1 at gmail dot com]

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

--- Comment #6 from Andrey Chistyakov  ---
I simplified the Marcus' code:

Ghoort@blade /cygdrive/c/Projects/bug
$ cat c2.cpp
namespace boost {}

template 
struct C {
};

template  class StructDecoder : C {
public:
  StructDecoder()  {
namespace bs = boost;
using namespace bs;
  }
};

void NFGParserparse() {
  StructDecoder q_syslog_desc;
}

Ghoort@blade /cygdrive/c/Projects/bug
$ g++ -c -g c2.cpp

c2.cpp: In constructor «StructDecoder::StructDecoder() [with Skipper =
int]»:
c2.cpp:12:3: internal compiler error: в tree_to_shwi, в tree.h:3661
   }
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug driver/68043] New: many undocumented options, missing punctuation

[msebor at gcc dot gnu.org]

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

Bug ID: 68043
   Summary: many undocumented options, missing punctuation
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As discussed in the thread at the link below, gcc's online help (the output of
gcc --help -v) includes a large number of undocumented options (197 in 5.1.0). 
For  example, the section listing language-related options starts with the
following and 44 or so more undocumented options:

  The following options are language-related:
--all-warnings   This switch lacks documentation
--ansi   This switch lacks documentation
--assert This switch lacks documentation
...

All of the options in the section above and a good number of others are
synonyms for other options that are, in fact, documented.  This bug tracks an
enhancement to use this "aliasing" knowledge to avoid printing "This switch
lacks documentation" for such options and improve the experience using the
compiler.  In addition, as was also noted in the mailing list discussion, many
of the one-sentence descriptions of the options are not properly ended with a
period, making printing additional (generated) sentences difficult.  To make
that possible, the other aspect of this bug is to track fixing the sources of
the descriptions (i.e., the various .opt files) to properly terminate each
sentence.

https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01395.html

[Bug driver/68043] many undocumented options, missing punctuation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[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 #27 from Jonathan Wakely  ---
(In reply to Giuseppe Ottaviano from comment #26)
> Do you use partial specializations as performance optimizations (thus
> equivalent to the general case) in libstdc++?

No, but doing so for std::allocator_traits> might make sense.

[Bug target/67871] LTO falis for ARM big-endian

[jonathan at codesourcery dot com]

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

--- Comment #8 from Jonathan Roelofs  ---
Created attachment 36557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36557&action=edit
fix implementation (gcc)

I've implemented the fix you described in the binutils thread, and it does in
fact clear up the issue I was originally seeing.

I'd like to see this committed upstream if possible.

[Bug target/67871] LTO falis for ARM big-endian

[jonathan at codesourcery dot com]

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

--- Comment #9 from Jonathan Roelofs  ---
Created attachment 36558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36558&action=edit
fix implementation (binutils)

[Bug ipa/67056] [5/6 regression] Wrong code generated

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
Author: hubicka
Date: Wed Oct 21 21:14:06 2015
New Revision: 229148

URL: https://gcc.gnu.org/viewcvs?rev=229148&root=gcc&view=rev
Log:
PR ipa/67056
* ipa-polymorphic-call.c (possible_placement_new): If cur_offset
is negative we don't know the type.
(check_stmt_for_type_change): Skip constructors of non-polymorphic
types as those won't help devirutalization.
* g++.dg/ipa/pr67056.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/ipa/pr67056.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-polymorphic-call.c
trunk/gcc/testsuite/ChangeLog

[Bug target/67871] LTO falis for ARM big-endian

[jonathan at codesourcery dot com]

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

--- Comment #10 from Jonathan Roelofs  ---
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02177.html

[Bug c++/61259] Spurious "ISO C++ forbids zero-size array" warning with -pedantic

[ilja.j.honkonen at nasa dot gov]

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

ilja.j.honkonen at nasa dot gov changed:

   What|Removed |Added

 CC||ilja.j.honkonen at nasa dot gov

--- Comment #2 from ilja.j.honkonen at nasa dot gov ---
I'm seeing this also, when I create an ofstream with () instead of {} I get a
complaint from gcc-4.4 to gcc-5:

#include "vector"
#include "string"
#include "fstream"
#include "boost/filesystem.hpp"
int main() {
std::vector input_files{"a.out"};
std::ofstream str(
//std::ofstream str{
boost::filesystem::path(input_files[0])
.parent_path()
.append("b")
.generic_string()
);
//};
}

g++-mp-4.9 gcc.cpp -I $HOME/include -L $HOME/lib -lboost_filesystem
-lboost_system -std=c++0x -W -Wall -Wextra -pedantic -O3
gcc.cpp: In function 'int main()':
gcc.cpp:9:41: warning: ISO C++ forbids zero-size array 'input_files'
[-Wpedantic]
   boost::filesystem::path(input_files[0])
 ^

g++-mp-4.4 gcc.cpp -I $HOME/include -L $HOME/lib -lboost_filesystem
-lboost_system -std=c++0x -W -Wall -Wextra -pedantic -O3
gcc.cpp: In function 'int main()':
gcc.cpp:9: warning: ISO C++ forbids zero-size array 'input_files'

[Bug fortran/67939] ICE on using data with negative substring range

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Wed Oct 21 21:40:05 2015
New Revision: 229153

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

PR fortran/67939
* data.c (create_character_initializer): Deal with zero length string.


2015-10-21  Steven G. Kargl  

PR fortran/67939
* gfortran.dg/pr67939.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr67939.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/data.c
trunk/gcc/testsuite/ChangeLog

[Bug c/68044] New: ceil() with -O3 and -masm=intel fails to compile

[janisozaur+gcc at gmail dot com]

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

Bug ID: 68044
   Summary: ceil() with -O3 and -masm=intel fails to compile
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janisozaur+gcc at gmail dot com
  Target Milestone: ---

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

on Arch Linux with gcc 5.2.0, glibc 2.22-3

Test case to be compiled with:
gcc test.c -o test -m32 -O3 -masm=intel

the ceil() function is taken from /usr/include/bits/mathinline.h, verbatim
provided here:

__inline_mathcodeNP (ceil, __x, \
  register long double __value;   \
  register int __ignore;  \
  unsigned short int __cw;\
  unsigned short int __cwtmp; \
  __asm __volatile ("fnstcw %3\n\t"   \
"movzwl %3, %1\n\t"   \
"andl $0xf3ff, %1\n\t"\
"orl $0x0800, %1\n\t"   /* rounding up */ \
"movw %w1, %2\n\t"\
"fldcw %2\n\t"\
"frndint\n\t" \
"fldcw %3"\
: "=t" (__value), "=&q" (__ignore), "=m" (__cwtmp),   \
  "=m" (__cw) \
: "0" (__x)); \
  return __value)

This works fine without -masm=intel

[Bug c/68044] ceil() with -O3 and -masm=intel fails to compile

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
This is a bug in the glibc headers for not supporting the alternative
inline-Asm. Please report it to them.

[Bug c++/68045] New: [concepts] segfault in contains_struct_check ../../gcc/gcc/tree.h:2971

[ryan.burn at gmail dot com]

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

Bug ID: 68045
   Summary: [concepts] segfault in contains_struct_check
../../gcc/gcc/tree.h:2971
   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: ---

Created attachment 36560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36560&action=edit
preprocessed code

The attached code gives this stack trace:

rnburn@localhost ~/bugs/contains_struct_check_segfault $ c++17
contains_struct_check_segfault.cpp 
In file included from
/home/rnburn/proj/echo/parallel/include/echo/parallel/invoke_create.h:3:0,
 from
/home/rnburn/proj/echo/parallel/unittest/invoke_create.cpp:1:
/home/rnburn/proj/echo/parallel/include/echo/parallel/concept.h: In function
‘void C_A_T_C_HT_E_S_T6()’:
/home/rnburn/proj/echo/parallel/include/echo/parallel/concept.h:63:61: internal
compiler error: Segmentation fault
 uncvref_t>()...>();
 ^
0xcacfef crash_signal
../../gcc/gcc/toplev.c:352
0x67833e contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:2971
0x67833e tsubst_copy
../../gcc/gcc/cp/pt.c:13490
0x67f202 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16238
0x6813f8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15712
0x661a6c tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13138
0x67cd12 tsubst_template_args
../../gcc/gcc/cp/pt.c:10839
0x6621c1 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12829
0x6623bf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12452
0x67cd12 tsubst_template_args
../../gcc/gcc/cp/pt.c:10839
0x67fafb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15230
0x6813f8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15712
0x66aad1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15044
0x67a71e tsubst_pack_expansion(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:10675
0x67d04a tsubst_template_args
../../gcc/gcc/cp/pt.c:10803
0x67fafb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15230
0x6813f8 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15712
0x66aad1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15044
0x823207 satisfy_predicate_constraint
../../gcc/gcc/cp/constraint.cc:1694
0x823207 satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1898
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug driver/68043] many undocumented options, missing punctuation

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Author: msebor
Date: Wed Oct 21 22:24:41 2015
New Revision: 229155

URL: https://gcc.gnu.org/viewcvs?rev=229155&root=gcc&view=rev
Log:
Improve --help output to generate references to option aliases.

gcc/
PR driver/68043
* opts.c (undocumented_msg, use_diagnosed_msg): New globals.
(print_filtered_help): Reference aliased option's name and encourage
readers to use it in preference to the alias if the former is not
documented.  Mention when using an option is diagnosed.
* gcc.c (display_help): End each sentence with a period.

* ada/gcc-interface/lang.opt: End each sentence that describes
an option with a period.
* c-family/c.opt: Same.
* common.opt: Same.
* config/aarch64/aarch64.opt: Same.
* config/alpha/alpha.opt: Same.
* config/arc/arc.opt: Same.
* config/arm/arm.opt: Same.
* config/avr/avr.opt: Same.
* config/bfin/bfin.opt: Same.
* config/c6x/c6x.opt: Same.
* config/cr16/cr16.opt: Same.
* config/cris/cris.opt: Same.
* config/cris/linux.opt: Same.
* config/darwin.opt: Same.
* config/epiphany/epiphany.opt: Same.
* config/fr30/fr30.opt: Same.
* config/frv/frv.opt: Same.
* config/ft32/ft32.opt: Same.
* config/g.opt: Same.
* config/h8300/h8300.opt: Same.
* config/i386/cygming.opt: Same.
* config/i386/djgpp.opt: Same.
* config/i386/i386.opt: Same.
* config/i386/interix.opt: Same.
* config/i386/mingw-w64.opt: Same.
* config/i386/mingw.opt: Same.
* config/ia64/ia64.opt: Same.
* config/ia64/ilp32.opt: Same.
* config/iq2000/iq2000.opt: Same.
* config/linux.opt: Same.
* config/lm32/lm32.opt: Same.
* config/lynx.opt: Same.
* config/m32c/m32c.opt: Same.
* config/m32r/m32r.opt: Same.
* config/m68k/ieee.opt: Same.
* config/m68k/m68k.opt: Same.
* config/mcore/mcore.opt: Same.
* config/mep/mep.opt: Same.
* config/microblaze/microblaze.opt: Same.
* config/mips/mips.opt: Same.
* config/mmix/mmix.opt: Same.
* config/mn10300/mn10300.opt: Same.
* config/moxie/moxie.opt: Same.
* config/msp430/msp430.opt: Same.
* config/nios2/elf.opt: Same.
* config/nios2/nios2.opt: Same.
* config/nvptx/nvptx.opt: Same.
* config/pa/pa-hpux.opt: Same.
* config/pa/pa-hpux1010.opt: Same.
* config/pa/pa-hpux.opt: Same.
* config/pa/pa-hpux1131.opt: Same.
* config/pa/pa.opt: Same.
* config/pa/pa64-hpux.opt: Same.
* config/pdp11/pdp11.opt: Same.
* config/rl78/rl78.opt: Same.
* config/rs6000/476.opt: Same.
* config/rs6000/aix64.opt: Same.
* config/rs6000/darwin.opt: Same.
* config/rs6000/linux64.opt: Same.
* config/rs6000/rs6000.opt: Same.
* config/rs6000/sysv4.opt: Same.
* config/s390/s390.opt: Same.
* config/s390/tpf.opt: Same.
* config/sh/sh.opt: Same.
* config/sol2.opt: Same.
* config/sparc/long-double-switch.opt: Same.
* config/sparc/sparc.opt: Same.
* config/spu/spu.opt: Same.
* config/stormy16/stormy16.opt: Same.
* config/tilegx/tilegx.opt: Same.
* config/tilepro/tilepro.opt: Same.
* config/v850/v850.opt: Same.
* config/vax/vax.opt: Same.
* config/visium/visium.opt: Same.
* config/vms/vms.opt: Same.
* config/vxworks.opt: Same.
* config/xtensa/xtensa.opt: Same.
* fortran/lang.opt: Same.

testsuite/
PR driver/68043
* gcc.misc-tests/help.exp: Adjust.
* lib/options.exp (check_for_options): Add detail to output.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ada/gcc-interface/lang.opt
trunk/gcc/c-family/c.opt
trunk/gcc/common.opt
trunk/gcc/config/aarch64/aarch64.opt
trunk/gcc/config/alpha/alpha.opt
trunk/gcc/config/arc/arc.opt
trunk/gcc/config/arm/arm.opt
trunk/gcc/config/avr/avr.opt
trunk/gcc/config/bfin/bfin.opt
trunk/gcc/config/c6x/c6x.opt
trunk/gcc/config/cr16/cr16.opt
trunk/gcc/config/cris/cris.opt
trunk/gcc/config/cris/linux.opt
trunk/gcc/config/darwin.opt
trunk/gcc/config/epiphany/epiphany.opt
trunk/gcc/config/fr30/fr30.opt
trunk/gcc/config/frv/frv.opt
trunk/gcc/config/ft32/ft32.opt
trunk/gcc/config/g.opt
trunk/gcc/config/h8300/h8300.opt
trunk/gcc/config/i386/cygming.opt
trunk/gcc/config/i386/djgpp.opt
trunk/gcc/config/i386/i386.opt
trunk/gcc/config/i386/interix.opt
trunk/gcc/config/i386/mingw-w64.opt
trunk/gcc/config/i386/mingw.opt
trunk/gcc/config/ia64/ia64.opt
trunk/gcc/config/ia64/ilp32.opt
trunk/gcc/config/iq2000/iq2000.opt
trunk/gcc/conf

[Bug middle-end/67966] [6 regression] ICE in convert_move, at expr.c:282

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #12 from Eric Botcazou  ---
Fixed by Jan's patch.

[Bug driver/68043] many undocumented options, missing punctuation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Committed to trunk.

[Bug c/68046] New: -ftrapv doesn't catch leaq-based overflows on x86-64

[eggert at gnu dot org]

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

Bug ID: 68046
   Summary: -ftrapv doesn't catch leaq-based overflows on x86-64
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eggert at gnu dot org
  Target Milestone: ---

On x86-64 for this program:

long i = 0x7fffL;
int main (void)
{
  return i + 1 < i;
}

gcc -ftrapv -O2 -S generates this code:

main:
movqi(%rip), %rax
leaq1(%rax), %rdx
cmpq%rdx, %rax
setg%al
movzbl  %al, %eax
ret

which does not trap, even though the addition overflows.

[Bug c/64955] RFE: have -Wformat suggest the correct format string to use

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
FWIW, if printing a new note is a concern, perhaps simply enhancing the
existing warning to mention the appropriate format specifier for the type along
the following lines might be less nannying:

warning: format ‘%i’ expects argument of type ‘int’, but argument 2 has type
‘long long int’ which requires ’%lli’ [-Wformat=]

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
-fsantize=undefined is more recommended for Linux and recent versions of gcc
instead of -ftrapv.

[Bug c++/66781] "confused by earlier errors, bailing out" with wrong enum within class

[paolo at gcc dot gnu.org]

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

--- Comment #1 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Oct 21 22:52:45 2015
New Revision: 229156

URL: https://gcc.gnu.org/viewcvs?rev=229156&root=gcc&view=rev
Log:
/cp
2015-10-21  Paolo Carlini  

PR c++/66781
* parser.c (cp_parser_enum_specifier): Upon error_at set
nested_name_specifier to error_mark_node; improve error message.

/testsuite
2015-10-21  Paolo Carlini  

PR c++/66781
* g++.dg/parse/enum13.C: New.

/cp
2015-10-21  Paolo Carlini  

PR c++/67847
* parser.c (cp_parser_enum_specifier): Reject a nested_name_specifier
which doesn't name a class or namespace.

/testsuite
2015-10-21  Paolo Carlini  

PR c++/67847
* g++.dg/parse/enum12.C: New.


Added:
trunk/gcc/testsuite/g++.dg/parse/enum12.C
trunk/gcc/testsuite/g++.dg/parse/enum13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67847] ICE on (invalid) nested enum declaration on x86_64-linux-gnu in is_ancestor, at cp/name-lookup.c:2771

[paolo at gcc dot gnu.org]

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

--- Comment #2 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Wed Oct 21 22:52:45 2015
New Revision: 229156

URL: https://gcc.gnu.org/viewcvs?rev=229156&root=gcc&view=rev
Log:
/cp
2015-10-21  Paolo Carlini  

PR c++/66781
* parser.c (cp_parser_enum_specifier): Upon error_at set
nested_name_specifier to error_mark_node; improve error message.

/testsuite
2015-10-21  Paolo Carlini  

PR c++/66781
* g++.dg/parse/enum13.C: New.

/cp
2015-10-21  Paolo Carlini  

PR c++/67847
* parser.c (cp_parser_enum_specifier): Reject a nested_name_specifier
which doesn't name a class or namespace.

/testsuite
2015-10-21  Paolo Carlini  

PR c++/67847
* g++.dg/parse/enum12.C: New.


Added:
trunk/gcc/testsuite/g++.dg/parse/enum12.C
trunk/gcc/testsuite/g++.dg/parse/enum13.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67847] ICE on (invalid) nested enum declaration on x86_64-linux-gnu in is_ancestor, at cp/name-lookup.c:2771

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #3 from Paolo Carlini  ---
Fixed.

[Bug c++/66781] "confused by earlier errors, bailing out" with wrong enum within class

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Paolo Carlini  ---
Fixed.

[Bug middle-end/65315] incorrect alignment of local variable with aligned attribute

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

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

--- Comment #4 from Steve Ellcey  ---
A patch for this was checked in before 5.0 branched.

[Bug c/68044] ceil() with -O3 and -masm=intel fails to compile

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I don't think use of -masm=intel is within the scope of what glibc wants 
to support for inline asm in its headers.  Rather, GCC should be made to 
inline the relevant function if it doesn't already, and then the glibc 
macro disabled for recent-enough GCC.

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com  ---
I wonder if it would be possible to map -ftrapv to something like 
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error 
(whatever is most closely equivalent to -ftrapv and doesn't require 
libubsan).  Then we could get rid of the separate -ftrapv code paths, 
which never worked well (while keeping the shared libgcc functions for 
compatibility, of course).

[Bug c++/68047] New: diagnose placement new with misaligned buffer

[msebor at gcc dot gnu.org]

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

Bug ID: 68047
   Summary: diagnose placement new with misaligned buffer
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Related to bug 67942 and bug 36159, using C++ placement new to construct an
object in a inappropriately aligned buffer is undefined and can lead to crashes
as shown in the test case below.  When the placement new expression is being
used with a plain character buffer that isn't guaranteed to be aligned on the
same boundary as the object being constructed, GCC could and arguably should
issue a diagnostic suggesting to align the buffer as necessary.  Since
depending on the alignment, there may be decent chance that the character
buffer just happens to be aligned or the misaligned access is tolerated on the
target hardware, the warning should probably be explicitly requested (i.e., not
be included in -Wall).

This bug tracks the proposed implementation of this diagnostic.

$ cat t.cpp && g++ -Wall -Wextra -Wpedantic -O2 -g t.cpp && gdb -batch -q -ex
'r' -ex 'bt' -ex 'disas' ./a.out
typedef __typeof__ (sizeof 0) size_t;

void* operator new (size_t, void *p) { return p; }
void* operator new[] (size_t, void *p) { return p; }

typedef int v4si __attribute__ ((vector_size (16)));

struct S { v4si v; };

S __attribute__ ((weak)) foo (S *p, v4si x)
{
p->v = x;
return *p;
}

S __attribute__ ((weak)) f (v4si x)
{
char a [sizeof (S) * 2];

S *p = new (a + 1) S ();

return foo (p, x);
}

int main  ()
{
v4si x = { 1, 2, 3, 4 };

f (x);
}


Program received signal SIGSEGV, Segmentation fault.
foo(S*, int __vector(4)) (p=p@entry=0x7fffded1, x=...) at t.cpp:12
12  p->v = x;
#0  foo(S*, int __vector(4)) (p=p@entry=0x7fffded1, x=...) at t.cpp:12
#1  0x00400667 in f(int __vector(4)) (x=...) at t.cpp:22
#2  0x004004c1 in main () at t.cpp:29
Dump of assembler code for function foo(S*, int __vector(4)):
=> 0x00400640 <+0>: movaps %xmm0,(%rdi)
   0x00400643 <+3>: retq   
End of assembler dump.
$

[Bug c++/68047] diagnose placement new with misaligned buffer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-22
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug bootstrap/68048] New: Unable to compile ./host-x86_64-pc-linux-gnu/gcc/version.c! Can't pass preprocessor strings!

[ghasemi.arash at gmail dot com]

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

Bug ID: 68048
   Summary: Unable to compile
./host-x86_64-pc-linux-gnu/gcc/version.c! Can't pass
preprocessor strings!
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ghasemi.arash at gmail dot com
  Target Milestone: ---

Summary:

I checkout the latest svn trunk and "configure" is successful with the
following string:
==
./configure --prefix=/home/me/gcc-cerberus/install_dir_cerberus/
--with-gmp=/home/me/gcc-trunk/gmp-6.0.0/install_dir/
--with-mpfr=/home/me/gcc-trunk/mpfr-3.1.3/install_dir/
--with-mpc=/home/me/gcc-trunk/mpc-1.0.3/install_dir/
--enable-languages=c,c++,fortran --disable-multilib
==

But "make" failed when it reaches to compile "version.c". Please see the
following message:

==
g++ -std=gnu++98 -c   -g -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild
-I../.././gcc -I../.././gcc/build -I../.././gcc/../include 
-I../.././gcc/../libcpp/include  \
-DBASEVER="\"6.0.0\"" -DDATESTAMP="\" 20151022\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\" (experimental)\"" -DPKGVERSION="\"(GCC) \"" \
-DBUGURL="\"\"" -o build/version.o
../.././gcc/version.c
g++.orig: error: 20151022": No such file or directory
g++.orig: error: (experimental)": No such file or directory
g++.orig: error: ": No such file or directory
make[3]: *** [build/version.o] Error 1
make[3]: Leaving directory `/home/me/gcc-cerberus/host-x86_64-pc-linux-gnu/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/home/me/gcc-cerberus'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/home/me/gcc-cerberus'
make: *** [all] Error 2
==

Some possibilities:

   I think I successfully compiled and installed mpc, mpfr, and gmp libraries
and the "configure" stage of GCC recognizes them. So I suspected to
adding/removing the other options, i.e --enable-languages=c,c++,fortran and
--disable-multilib, and in either case I get exactly same error.

   Please note that either shell or GNU make on my system think that
-DDATESTAMP="\" 20151022\"" is a file and it doesn't know that it is the
preprocessor input for compilation! So where is the problem? Please help me
ASAP. Thanks!

[Bug ipa/67056] [5 regression] Wrong code generated

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|UNCONFIRMED
Summary|[5/6 regression] Wrong code |[5 regression] Wrong code
   |generated   |generated
 Ever confirmed|1   |0

--- Comment #18 from Jan Hubicka  ---
Fixed on trunk so far; fix is backportable.

[Bug target/63304] Aarch64 pc-relative load offset out of range

[ramana at gcc dot gnu.org]

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

--- Comment #29 from Ramana Radhakrishnan  ---
Author: ramana
Date: Thu Oct 22 04:26:50 2015
New Revision: 229160

URL: https://gcc.gnu.org/viewcvs?rev=229160&root=gcc&view=rev
Log:
[Patch AArch64 63304] Fix issue with global state.


Jiong pointed out privately that there was a thinko
in the way in which the global state was being
set and reset. I don't like adding such
global state but 


2015-10-22  Ramana Radhakrishnan  

PR target/63304
* config/aarch64/aarch64.c (aarch64_nopcrelative_literal_loads): New.
(aarch64_expand_mov_immediate): Use aarch64_nopcrelative_literal_loads.
(aarch64_classify_address): Likewise.
(aarch64_secondary_reload): Likewise.
(aarch64_override_options_after_change_1): Adjust.
* config/aarch64/aarch64.md
(aarch64_reload_movcp):
Use aarch64_nopcrelative_literal_loads.
(aarch64_reload_movcp): Likewise.
* config/aarch64/aarch64-protos.h (aarch64_nopcrelative_literal_loads): 
Declare

2015-10-22  Jiong Wang  
Ramana Radhakrishnan  

PR target/63304
* gcc.target/aarch64/pr63304_1.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr63304_1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.md
trunk/gcc/testsuite/ChangeLog