[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
We are passing (unsupported on 32bit target) DImode to
expand_set_or_movmem_via_rep:

(gdb) bt
#0  expand_set_or_movmem_via_rep (destmem=0x2e8b8d68,
srcmem=0x2e8b8d80, destptr=0x2e8b8d98, srcptr=0x2e8b8dc8,
value=0x0, 
orig_value=0x0, count=0x2e7b06c0, mode=DImode, issetmem=false) at
/home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:23523
#1  0x010eb99b in ix86_expand_set_or_movmem (dst=0x2e8b8d68,
src=0x2e8b8d80, count_exp=0x2e7b06c0, val_exp=0x0, 
align_exp=0x2e7b04c0, expected_align_exp=0x2e7b04c0,
expected_size_exp=0x2e7b0470, min_size_exp=0x2e7b06c0, 
max_size_exp=0x2e7b06c0, probable_max_size_exp=0x2e7b06c0,
issetmem=false) at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:25114
#2  0x01259fc4 in gen_movmemsi (operand0=0x2e8b8d68,
operand1=0x2e8b8d80, operand2=0x2e7b06c0, operand3=0x2e7b04c0, 
operand4=0x2e7b04c0, operand5=0x2e7b0470, operand6=0x2e7b06c0,
operand7=0x2e7b06c0, operand8=0x2e7b06c0)
at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.md:15968

[Bug tree-optimization/66012] Sub-optimal 64bit load is generated instead of zero-extension

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
In GIMPLE that masking is generally useless though, you shift the bits away,
and without the extra BIT_AND_EXPR the expression is more canonical and
shorter.
So, supposedly during expansion or combine you could figure this from the left
shift with large shift count.

[Bug tree-optimization/66013] New: Missed optimization after inlining va_list parameter, -m32 case

[vries at gcc dot gnu.org]

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

Bug ID: 66013
   Summary: Missed optimization after inlining va_list parameter,
-m32 case
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ -m32 twin PR of PR66010 ]

Consider this test-case (based on gcc.dg/tree-ssa/stdarg-2.c, f15):
...
#include 

int
f1 (int i, ...)
{
  int res;
  va_list ap;

  va_start (ap, i);
  res = va_arg (ap, int);
  va_end (ap);

  return res;
}

inline int __attribute__((always_inline))
f2_1 (va_list ap)
{
  return va_arg (ap, int);
}

int
f2 (int i, ...)
{
  int res;
  va_list ap;

  va_start (ap, i);
  res = f2_1 (ap);
  va_end (ap);

  return res;
}
...

When compiling at -O2 with -m32, the optimized dump for f1 and f2 are very
similar:
...
   # .MEM_9 = VDEF <.MEM_1(D)>
   # USE = anything 
   # CLB = anything 
-  ap_8 = __builtin_next_argD.993 (0);
-  ap_6 = ap_8;
+  ap_11 = __builtin_next_argD.993 (0);
+  ap_6 = ap_11;
   # PT = nonlocal 
-  ap_7 = ap_6;
+  ap_3 = ap_6;
   # VUSE <.MEM_9>
-  res_4 = MEM[(intD.1 *)ap_7];
+  _7 = MEM[(intD.1 *)ap_3];
   GIMPLE_NOP
   # VUSE <.MEM_9>
-  return res_4;
+  return _7;
 ;;succ:   EXIT [100.0%] 
...

However, at pass_stdarg, we see on one hand:
...
f1: va_list escapes 0, needs to save 4 GPR units and all FPR units.
...

but OTOH:
...
f2: va_list escapes 1, needs to save all GPR units and all FPR units.
...

Still the .s code is identical for f1 and f2:
...
.cfi_startproc
movl8(%esp), %eax
ret
.cfi_endproc
...

This is because ix86_setup_incoming_varargs doesn't do anything for -m32:
...
static void
ix86_setup_incoming_varargs (cumulative_args_t cum_v, machine_mode mode,
 tree type, int *, int no_rtl)
{
  CUMULATIVE_ARGS *cum = get_cumulative_args (cum_v);
  CUMULATIVE_ARGS next_cum;
  tree fntype;

  /* This argument doesn't appear to be used anymore.  Which is good,
 because the old code here didn't suppress rtl generation.  */
  gcc_assert (!no_rtl);

  if (!TARGET_64BIT)
return;
...

[Bug tree-optimization/66013] Missed optimization after inlining va_list parameter, -m32 case

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Before pass_stdarg, we observe in f1 that va_start and va_arg use the same
argument:
...
  # .MEM_2 = VDEF <.MEM_1(D)>
  # USE = nonlocal escaped
  # CLB = nonlocal escaped { D.1806 } (escaped)
  __builtin_va_startD.1021 (&apD.1806, 0);

  # .MEM_3 = VDEF <.MEM_2>
  # USE = nonlocal null { D.1806 } (escaped)
  # CLB = nonlocal null { D.1806 } (escaped)
  res_4 = VA_ARG (&apD.1806, 0B);
...

Before pass_stdarg, we observe in f2 that va_start and va_arg do not use the
same argument:
...
  # .MEM_2 = VDEF <.MEM_1(D)>
  # USE = nonlocal escaped
  # CLB = nonlocal escaped { D.1814 }
  __builtin_va_startD.1021 (&apD.1814, 0);

  # VUSE <.MEM_2>
  # PT = nonlocal
  ap.0_3 = apD.1814;

  # .MEM_4 = VDEF <.MEM_2>
  apD.1830 = ap.0_3;

  # .MEM_8 = VDEF <.MEM_4>
  # USE = nonlocal null { D.1830 } (escaped)
  # CLB = nonlocal null { D.1830 } (escaped)
  _7 = VA_ARG (&apD.1830, 0B);
...

[Bug tree-optimization/66013] Missed optimization after inlining va_list parameter, -m32 case

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
And in the pass_stdarg dump, for f2 we see why the va_list escapes:
...
va_list escapes in # .MEM_4 = VDEF <.MEM_2>
apD.1830 = ap.0_3;
...

[Bug ipa/65873] [5/6 Regression] Failure to inline always_inline memcpy

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Honza, any progress on this?

[Bug tree-optimization/66013] Missed optimization after inlining va_list parameter, -m32 case

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Before postponing expansion of va_arg to pass_stdarg, we had at pass_stdarg:
...
f2: va_list escapes 0, needs to save 4 GPR units and all FPR units.
...

On one hand, the optimization in pass_stdarg has regressed. OTOH, that hasn't
brought a regression in code generation.

So I'm not sure if this should be marked as a '6 Regression', and/or tagged
with missing optimization.

[Bug tree-optimization/66010] [6 Regression] Missed optimization after inlining va_list parameter

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Investigated -m32 case in twin PR66013.

[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Proposed patch:

--cut here--
Index: i386.c
===
--- i386.c  (revision 222796)
+++ i386.c  (working copy)
@@ -2988,6 +2988,17 @@ ix86_parse_stringop_strategy_string (char *strateg
   return;
 }

+  if ((stringop_alg) i == rep_prefix_8_byte
+ && !TARGET_64BIT)
+   {
+ /* rep; movq isn't available in 32-bit code.  */
+ error ("stringop strategy name %s specified for option %s "
+"not supported for 32-bit code",
+ alg_name,
+ is_memset ? "-mmemset_strategy=" : "-mmemcpy_strategy=");
+ return;
+   }
+
   input_ranges[n].max = maxs;
   input_ranges[n].alg = (stringop_alg) i;
   if (!strcmp (align, "align"))
--cut here--

[Bug libstdc++/66011] [6 Regression] call to '__open_missing_mode' declared with attribute error

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||redi at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
CloseFD out = { ::open(to.c_str(), O_WRONLY|O_CREAT) };
indeed looks like a bug to me, for O_CREAT one needs to use 3 argument ::open,
to specify mode.  It is true that there is later on a fchmodat or chmod, but
that still leaves the permissions in between the open and chmod as random.
Either it should be ::open(to.c_str(), O_WRONLY|O_CREAT, from_st->st_mode) ,
or perhaps say from_st->st_mode & S_IRWXU, etc. so that you don't expose the
file content while it is still incomplete to other users, or just S_IWUSR so
that owner can write and nothing else.

[Bug lto/66014] New: 5.1 mingw64 fails to perform slim bootstrap-lto: ccEt8YNj.ltrans4.ltrans.o::(.text+0x628): undefined reference to `stpcpy'

[breedlove.matt at gmail dot com]

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

Bug ID: 66014
   Summary: 5.1 mingw64 fails to perform slim bootstrap-lto:
ccEt8YNj.ltrans4.ltrans.o::(.text+0x628):
undefined reference to `stpcpy'
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: breedlove.matt at gmail dot com
  Target Milestone: ---

Created attachment 35461
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35461&action=edit
save-temps and object files for pex-win32 and stpcpy

Following the fix in PR 65559 (though LTO didn't work at all previously), GCC
on mingw64 is unable to perform a slim bootstrap, dying when building
liblto_plugin-0.dll.  Normal -ffat-lto-object builds unaffected.

/bin/sh ./libtool --tag=CC --tag=disable-static  --mode=link
/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/xgcc
-B/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/
-B/mingw64/x86_64-w64-mingw32/bin/ -L/mingw64/x86_64-w64-mingw32/lib
-L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/
-B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include
-isystem /mingw64/x86_64-w64-mingw32/sys-include-Wall -O2 -march=x86-64
-mtune=native -flto=jobserver -frandom-seed=1 -Wc,-static-libgcc -no-undefined
-bindir "/mingw64/bin/gcc-5.1.0" -module -bindir
/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0  -Wc,../libiberty/libiberty.a 
-Xcompiler '-static-libstdc++' -Xcompiler '-static-libgcc'
'-Wl,--stack,12582912' -o liblto_plugin.la -rpath
/mingw64/lib/gcc/x86_64-w64-mingw32/5.1.0 lto-plugin.lo
libtool: link: 
/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/xgcc
-B/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/./prev-gcc/
-B/mingw64/x86_64-w64-mingw32/bin/ -L/mingw64/x86_64-w64-mingw32/lib
-L/mingw64/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/include -B/mingw64/x86_64-w64-mingw32/bin/
-B/mingw64/x86_64-w64-mingw32/lib/ -isystem /mingw64/x86_64-w64-mingw32/include
-isystem /mingw64/x86_64-w64-mingw32/sys-include-shared  .libs/lto-plugin.o
  -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib  -march=x86-64 -mtune=native
-static-libgcc ../libiberty/libiberty.a -static-libstdc++ -static-libgcc
-Wl,--stack -Wl,12582912   -o .libs/liblto_plugin-0.dll
-Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker
.libs/liblto_plugin.dll.a
M:\mingw64\tmp\cc5tPjOg.ltrans4.ltrans.o::(.text+0x628): undefined
reference to `stpcpy'
collect2.exe: error: ld returned 1 exit status
Makefile:351: recipe for target 'liblto_plugin.la' failed
make[1]: *** [liblto_plugin.la] Error 1
make[1]: Leaving directory
'/build/staging/mingw-w64-x86_64-gcc5/src/build-x86_64-w64-mingw32/lto-plugin'
Makefile:264: recipe for target 'all' failed
make: *** [all] Error 2


This is following the fix to GCC by including specific object files in archives
rather than the entire library.  The following shows that no symbols appear
within the slim objects for the (should be defined) stpcpy in stpcpy.o as well
as the undefined symbol in pex-win32.o

$ nm --plugin prev-lto-plugin/.libs/liblto_plugin-0.dll libiberty/pex-win32.o
 U _close
 U _dup
 U _errno
 U _get_osfhandle
 U _open
 U _pipe
 U _read
 U CloseHandle
 U CreateFileA
 U CreateProcessA
 U fdopen
 T funcs
 U getenv
 U GetExitCodeProcess
 U GetVersionExA
 T pex_init
 U pex_init_common
 U qsort
 U SetHandleInformation
 U WaitForSingleObject
 U xmalloc

$ nm -a libiberty/pex-win32.o

 b .bss
 d .data
 r .gnu.lto_.decls.1
 r .gnu.lto_.inline.1
 r .gnu.lto_.opts
 r .gnu.lto_.refs.1
 r .gnu.lto_.symbol_nodes.1
 r .gnu.lto_.symtab.1
 r .gnu.lto_argv_to_argc.1
 r .gnu.lto_argv_to_cmdline.1
 r .gnu.lto_backslashify.1
 r .gnu.lto_env_compare.1
 r .gnu.lto_find_executable.1
 r .gnu.lto_funcs.1
 r .gnu.lto_pex_init.1
 r .gnu.lto_pex_win32_close.1
 r .gnu.lto_pex_win32_exec_child.1
 r .gnu.lto_pex_win32_fdopenr.1
 r .gnu.lto_pex_win32_fdopenw.1
 r .gnu.lto_pex_win32_open_read.1
 r .gnu.lto_pex_win32_open_write.1
 r .gnu.lto_pex_win32_pipe.1
 r .gnu.lto_pex_win32_wait.1
 r .gnu.lto_spawn_script.1
 r .gnu.lto_std_suffixes.1
 r .gnu.lto_win32_spawn.1

[Bug c/16351] NULL dereference warnings

[tim.ruehsen at gmx dot de]

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

Tim Ruehsen  changed:

   What|Removed |Added

 CC||tim.ruehsen at gmx dot de

--- Comment #23 from Tim Ruehsen  ---
*PLEASE* put this on higher priority.

In 25 years of C development I saw thousands of crashes due to NULL pointer
dereferences. Many of them could have been avoided by simply printing a
warning.

You really save lifes ! And millions of working hours searching for obvious
bugs.

The requested warning is an absolutely must-have (enabled by default).
Seeing this bug open since 2004 is... well ... I have no words.

(Don't get me wrong: I make a deep kneefall for gcc and it's developers)

[Bug rtl-optimization/65932] [5 Regression] Linux-3.10.75 on arm926ej-s does not boot due to wrong code generation

[christian.eggers at kathrein dot de]

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

--- Comment #5 from Christian Eggers  ---
(In reply to Richard Earnshaw from comment #2)
> code built with
> -fno-ipa-sra appears to be ok on a visual inspection.

linux-3.10.25 boots fine if globally compiled with additional -fno-ipa-sra

The affected linux system is a arm926ej-s. Is this bug also relevant for my
Cortex-M boards?

[Bug fortran/59678] [F03] Segfault on equalizing variables of a complex derived type

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #18 from vehre at gcc dot gnu.org ---
Resolved with commit r222477. No objections so far, closing.

[Bug fortran/65841] Seg fault on intrinsic assignment to allocatable derived type with allocatable component

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #6 from vehre at gcc dot gnu.org ---
Fixed with r222477. No complaints so far, closing.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #11)
> Unfortunately, the gcc.dg/tree-ssa/stdarg-2.c part of the patch is wrong:
> the test
> now FAILs on i686-unknown-linux-gnu, i686-apple-darwin, and i386-pc-solaris
> with
> -m64: both dumps (i.e. -m32 and -m64) contain
> 
> m32/stdarg-2.c.084t.stdarg:f15: va_list escapes 1, needs to save all GPR
> units and all FPR units.
> m64/stdarg-2.c.084t.stdarg:f15: va_list escapes 1, needs to save all GPR
> units and all FPR units.
> 
>   Rainer

Proposed patch: https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00294.html

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #35 from Jürgen Reuter  ---
What are u waiting for?^^ already confirmed in comment #34 that rverything in
our code works with the patch

[Bug libgomp/65993] [6 Regression] Numerous libgomp.oacc failures seen in r222712

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue May  5 09:39:29 2015
New Revision: 222799

URL: https://gcc.gnu.org/viewcvs?rev=222799&root=gcc&view=rev
Log:
[PR testsuite/65205, libgomp/65993] Fix dg-shouldfail usage in OpenACC libgomp
tests

In dg-output, don't expect "0x" prefix for "%p" format specifier, don't expect
"(nil)" for NULL pointer.

PR testsuite/65205
PR libgomp/65993
libgomp/
* testsuite/libgomp.oacc-c-c++-common/clauses-2.c: In dg-output,
don't expect "0x" prefix for "%p" format specifier, don't expect
"(nil)" for NULL pointer.
* testsuite/libgomp.oacc-c-c++-common/lib-16.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-17.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-18.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-20.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-21.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-22.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-23.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-25.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-26.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-27.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-28.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-29.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-30.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-34.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-35.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-36.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-39.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-40.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-42.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-43.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-44.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-47.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-48.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-52.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-53.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-54.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-57.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-58.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/data-already-1.c: More
accurately specify what we're looking for.
* testsuite/libgomp.oacc-c-c++-common/data-already-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/data-already-8.c: Likewise.
* testsuite/libgomp.oacc-fortran/data-already-1.f: Likewise.
* testsuite/libgomp.oacc-fortran/data-already-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/data-already-8.f: Likewise.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-8.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-16.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-20.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-23.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-25.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-26.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-27.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-34.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-35.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-36.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-39.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-40.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-42.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-44.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-48.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-52.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-53.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-54.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-c

[Bug testsuite/65205] Wrong dg-shouldfail usage in OpenACC libgomp tests

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge  ---
Author: tschwinge
Date: Tue May  5 09:39:29 2015
New Revision: 222799

URL: https://gcc.gnu.org/viewcvs?rev=222799&root=gcc&view=rev
Log:
[PR testsuite/65205, libgomp/65993] Fix dg-shouldfail usage in OpenACC libgomp
tests

In dg-output, don't expect "0x" prefix for "%p" format specifier, don't expect
"(nil)" for NULL pointer.

PR testsuite/65205
PR libgomp/65993
libgomp/
* testsuite/libgomp.oacc-c-c++-common/clauses-2.c: In dg-output,
don't expect "0x" prefix for "%p" format specifier, don't expect
"(nil)" for NULL pointer.
* testsuite/libgomp.oacc-c-c++-common/lib-16.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-17.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-18.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-20.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-21.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-22.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-23.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-25.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-26.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-27.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-28.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-29.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-30.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-34.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-35.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-36.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-39.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-40.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-42.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-43.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-44.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-47.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-48.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-52.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-53.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-54.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-57.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/lib-58.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/data-already-1.c: More
accurately specify what we're looking for.
* testsuite/libgomp.oacc-c-c++-common/data-already-2.c: Likewise.
* testsuite/libgomp.oacc-c-c++-common/data-already-8.c: Likewise.
* testsuite/libgomp.oacc-fortran/data-already-1.f: Likewise.
* testsuite/libgomp.oacc-fortran/data-already-2.f: Likewise.
* testsuite/libgomp.oacc-fortran/data-already-8.f: Likewise.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-1.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-2.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-8.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-16.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-20.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-23.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-25.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-26.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-27.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-34.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-35.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-36.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-39.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-40.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-42.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-44.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-48.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-52.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-53.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-54.c
trunk/libgomp/testsuite/libgomp.oacc-c-c++-c

[Bug libgomp/65993] [6 Regression] Numerous libgomp.oacc failures seen in r222712

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Schwinge  ---
Patch applied in r222799.

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[chefmax at gcc dot gnu.org]

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

Maxim Ostapenko  changed:

   What|Removed |Added

 Target|arm |arm-linux-gnueabi
 CC||chefmax at gcc dot gnu.org,
   ||ygribov at gcc dot gnu.org
   Host||x86_64-pc-linux-gnu
  Known to fail||6.0

--- Comment #7 from Maxim Ostapenko  ---
I've ran to the exactly the same issue on armv7-a (cortex-A8) target with trunk
compiler and pr55073.C testcase:

$ ~/install/gcc-trunk-arm/armv7l-tizen/bin/armv7l-tizen-linux-gnueabi-gcc 
~/workspace/downloads/gcc/gcc/testsuite/gcc.target/arm/pr55073.C -O2
-mcpu=cortex-a8 -lm -o ./pr55073.exe

$ ~/install/gcc-5.0-arm/armv7l-tizen/bin/armv7l-tizen-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/max/install/gcc-trunk-arm/armv7l-tizen/bin/armv7l-tizen-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/max/install/gcc-trunk-arm/armv7l-tizen/libexec/gcc/armv7l-tizen-linux-gnueabi/6.0.0/lto-wrapper
Target: armv7l-tizen-linux-gnueabi
Configured with: /home/max/build/v6/sources/gcc_1/configure 
--build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu
--target=armv7l-tizen-linux-gnueabi
--prefix=/home/max/install/gcc-trunk-arm/armv7l-tizen
--with-sysroot=/home/max/install/gcc-trunk-arm/armv7l-tizen/armv7l-tizen-linux-gnueabi/sys-root
--disable-libmudflap
--enable-libssp
--disable-nls
--disable-libstdcxx-pch
--disable-multilib
--disable-gnu-unique-object
--enable-linker-build-id
--with-mode=arm
--with-fpu=neon-vfpv4
--with-arch=armv7-a
--with-tune=cortex-a15.cortex-a7
--with-float=softfp
--enable-libgomp
--enable-poison-system-directories
--enable-long-long
--enable-threads
--enable-languages=c,c++,fortran
--enable-shared
--enable-lto
--enable-symvers=gnu
--enable-__cxa_atexit
--with-gnu-as
--with-gnu-ld
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --
Thread model: posix
gcc version 6.0.0 20150505 (experimental)

Looking to gdb output:

Breakpoint 1, 0x8608 in test_func() ()
(gdb) disas
Dump of assembler code for function _Z9test_funcv:
   0x85b4 <+0>: movwr3, #34480  ; 0x86b0
   0x85b8 <+4>: movtr3, #0
   0x85bc <+8>: add r2, r3, #16
   0x85c0 <+12>:vld1.8  {d20-d21}, [r3 :128]
   0x85c4 <+16>:vld1.8  {d16-d17}, [r2 :128]
   0x85c8 <+20>:vorrd17, d20, d20
   0x85cc <+24>:vorrd18, d16, d16
   0x85d0 <+28>:vzip.8  d16, d20
   0x85d4 <+32>:vzip.8  d17, d18
   0x85d8 <+36>:vorrd20, d16, d16
   0x85dc <+40>:vorrd18, d17, d17
   0x85e0 <+44>:vorrd22, d16, d16
   0x85e4 <+48>:vzip.8  d20, d18
   0x85e8 <+52>:vzip.8  d17, d22
   0x85ec <+56>:vorrd18, d20, d20
   0x85f0 <+60>:vmov.i16q12, #2 ; 0x0002
   0x85f4 <+64>:vmovl.s8q10, d17
   0x85f8 <+68>:vmovl.s8q9, d18
   0x85fc <+72>:vsub.i16q10, q10, q12
   0x8600 <+76>:vsub.i16q8, q9, q12
   0x8604 <+80>:vadd.i16q8, q10, q8
=> 0x8608 <+84>:vst1.64 {d16-d17}, [r0 :128]
   0x860c <+88>:bx  lr
End of assembler dump.
r0 0xbe3ffc58   3191864408
(gdb) 

vst1.64 wants r0 to be 128-bit aligned, but it's only 64-bit aligned here.

Documentation from ARM info center (http://infocenter.arm.com/help/index.jsp?
topic=/com.arm.doc.ddi0344c/Cihejdic.html) points here for cortex-a8:

"If an alignment qualifier is specified, a check is made for strict alignment
based on the qualifier, independent of the A-bit setting." So, bus error seems
to be expected here.

On cortex-a15.cortex-a7 the same code executed without errors. So, I wonder, if
it's a testcase problem and it should be disabled for CA8? Or maybe it is a
compiler bug?

[Bug target/65951] [AArch64] Will not vectorize 64bit integer multiplication

[alalaw01 at gcc dot gnu.org]

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

--- Comment #5 from alalaw01 at gcc dot gnu.org ---
I believe the definitive algorithm for converting multiply-by-constant into
adds+shifts(+etc.) lives in expmed.c. I don't at present have a plan for how to
reuse that, but if we could do so _in_some_form_ then that would be the ideal??

[Bug lto/65950] Loop is not vectorized with lto.

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
The function containing given loop is marked as:

foo/24 (foo) @0x7f39f4b84620
  Type: function definition analyzed
  Visibility: prevailing_def_ironly
  References: 
  Referring: 
  Read from file: /tmp/ccKAP5Mo.o
  Availability: local
  First run: 0
  Function flags: local nonfreeing_fn unlikely_executed
  Called by: main/23

[Bug target/65955] [arm] ICE during movcond_addsi split

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to ktkachov from comment #5)
> Created attachment 35434 [details]
> Proposed fix
> 
> Could you please give this patch a try?
> Unfortunately I don't have ada on my arm system so I can't try it out at the
> moment.

I managed to complete a bootstrap using the patch.

I'm now doing a nobootstrap build and test with and without the patch.

[Bug target/65955] [arm] ICE during movcond_addsi split

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to vries from comment #6)
> I'm now doing a nobootstrap build and test with and without the patch.

I have reproduced the failure using the nobootstrap build:
...
build/gcc/testsuite/gfortran/../../gfortran
-Bbuild/gcc/testsuite/gfortran/../../
-Bbuild/arm-linux-gnueabihf/./libgfortran/
src/gcc/testsuite/gfortran.dg/pr43984.f90 -fno-diagnostics-show-caret
-fdiagnostics-color=never -O -O2 -fno-tree-dominator-opts -fdump-tree-pre -S -o
pr43984.s
src/gcc/testsuite/gfortran.dg/pr43984.f90:49:0: internal compiler error: RTL
check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1710
0x886fd5 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int,
char const*)
src/gcc/rtl.c:731
0xcd9c25 rhs_regno
src/gcc/rtl.h:1710
0xd0f6bb gen_split_2634(rtx_insn*, rtx_def**)
src/gcc/config/arm/arm.md:9341
0x110a23d split_7
src/gcc/config/arm/arm.md:9326
0x1118f0f split_12
src/gcc/config/arm/neon.md:4372
0x111fd37 split_insns(rtx_def*, rtx_def*)
src/gcc/config/arm/sync.md:379
0x4f0d59 try_split(rtx_def*, rtx_def*, int)
src/gcc/emit-rtl.c:3664
0x81e53b split_insn
src/gcc/recog.c:2919
0x81e925 split_all_insns()
src/gcc/recog.c:3009
0x8215e1 rest_of_handle_split_after_reload
src/gcc/recog.c:3956
0x821625 execute
src/gcc/recog.c:3985
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

FAIL: gfortran.dg/pr43984.f90   -O  (internal compiler error)
FAIL: gfortran.dg/pr43984.f90   -O  (test for excess errors)
...

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

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

--- Comment #36 from vehre at gcc dot gnu.org ---
I am waiting for an official review of the patch, to be allowed to commit to
trunk. So I am not waiting on you. :-)

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

--- Comment #8 from ktkachov at gcc dot gnu.org ---
(In reply to vries from comment #7)
> (In reply to vries from comment #6)
> > I'm now doing a nobootstrap build and test with and without the patch.
> 
> I have reproduced the failure using the nobootstrap build:



> 
> FAIL: gfortran.dg/pr43984.f90   -O  (internal compiler error)
> FAIL: gfortran.dg/pr43984.f90   -O  (test for excess errors)
> ...

You mean without my patch, right? (hopefully ;))
I can't reproduce it on my cross build with
-mthumb/-march=armv7-a/-mfloat-abi=hard/-mfpu=vfpv3-d16 unfortunately

[Bug target/65955] [arm] ICE during movcond_addsi split

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
(In reply to ktkachov from comment #8)
> (In reply to vries from comment #7)
> > (In reply to vries from comment #6)
> > > I'm now doing a nobootstrap build and test with and without the patch.
> > 
> > I have reproduced the failure using the nobootstrap build:
> 
> 
> 
> > 
> > FAIL: gfortran.dg/pr43984.f90   -O  (internal compiler error)
> > FAIL: gfortran.dg/pr43984.f90   -O  (test for excess errors)
> > ...
> 
> You mean without my patch, right? (hopefully ;))

Yes :)

> I can't reproduce it on my cross build with
> -mthumb/-march=armv7-a/-mfloat-abi=hard/-mfpu=vfpv3-d16 unfortunately

with checking=yes,rtl?

[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg

[vries at gcc dot gnu.org]

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

--- Comment #13 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue May  5 10:32:28 2015
New Revision: 222802

URL: https://gcc.gnu.org/viewcvs?rev=222802&root=gcc&view=rev
Log:
Xfail gcc.dg/tree-ssa/stdarg-2.c f15 scans

2015-05-05  Tom de Vries  

* gcc.dg/tree-ssa/stdarg-2.c: Xfail f15 scans which test for presence
of
'va_list escapes 0'.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/stdarg-2.c

[Bug target/66015] New: align directives not propagated after __attribute__ ((__optimize__ ("O2")))

[chrbr at gcc dot gnu.org]

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

Bug ID: 66015
   Summary: align directives not propagated after __attribute__
((__optimize__ ("O2")))
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrbr at gcc dot gnu.org
  Target Milestone: ---

When attribute optimize is used, the alignment flags are not reevaluated.

Consequently, the functions are not aligned as if they were with the same
global flag

for example:
__attribute__ ((__optimize__ ("O2")))
void
hooray ()
{
}

is not aligned 

The second consequence is that can_inline_edge_p fails because opts_for_fn
(caller->decl) != opts_for_fn (callee->decl)) even-though they are compiled
with the same optimization level.

[Bug tree-optimization/64950] postpone expanding va_arg till pass_stdarg

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #14 from vries at gcc dot gnu.org ---
patch committed adding xfails in stdarg-2.c.

xfails tracked in spin-off PRs:
- PR66010 '[6 Regression] Missed optimization after inlining va_list parameter'
- PR66013 'Missed optimization after inlining va_list parameter, -m32 case'

Re-marking resolved, fixed.

[Bug target/41089] [4.8/4.9/5/6 Regression] stdarg pass produces wrong code

[vries at gcc dot gnu.org]

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

Bug 64950 Summary: postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug other/51153] OpenACC implementation

[vries at gcc dot gnu.org]

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

Bug 64950 Summary: postpone expanding va_arg till pass_stdarg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64950

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug go/66016] New: Accessing nil Func's name results in crash

[jcajka at redhat dot com]

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

Bug ID: 66016
   Summary: Accessing nil Func's name results in crash
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: jcajka at redhat dot com
CC: cmang at google dot com
  Target Milestone: ---

Created attachment 35462
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35462&action=edit
patch

Follow up to bug 65798 and
https://bugzilla.redhat.com/show_bug.cgi?id=1212472#c2.


Comment #4 from RHBZ:

Hm..., it doesn't fix it. I have messed it up a bit..., problem might not be
the runtime.Caller...( as the rejected function name part was working around
the problem). I have prepare small program triggering the crash outside docker.

package main

import "runtime"
import "fmt"

func main() {
for i := 1;i <= 5;i++ {
pc, fname, line,ok := runtime.Caller(i)
fmt.Printf("%x",pc)
fmt.Print(" ",fname," ",line," ",ok,"\n")
fn := runtime.FuncForPC(pc)
fmt.Print(fn.Name(),"\n\n")
}
}

Crashes with gcc-go:

7fefdc22b2c6 ../../../libgo/runtime/proc.c 550 true
runtime_main

7fefdc228f8b ../../../libgo/runtime/proc.c 235 true
kickoff

7fefdb20  0 true
panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x0]

goroutine 16 [running]:
main.main
/root/test.go:12

goroutine 18 [finalizer wait]:
created by runtime_createfing
../../../libgo/runtime/mgc0.c:2572

but works fine with golang(built with --ldflags "-linkmode external"):
./test

4125e3 /usr/lib/golang/src/runtime/proc.go 63 true
runtime.main

4377e1 /usr/lib/golang/src/runtime/asm_amd64.s 2232 true
runtime.goexit

0  0 false


0  0 false


0  0 false

There is difference(probably expected?, this confused me...), in number of
callers. But also libgo seems to behave differently than golang when accessing
nil Func's Name, as ommiting/replacing the fn.Name() with just fn yields with
gcc-go:

7feb8a48e2c6 ../../../libgo/runtime/proc.c 550 true
&{{}}

7feb8a48bf8b ../../../libgo/runtime/proc.c 235 true
&{{}}

7feb89472fff  0 true


0  0 false


0  0 false


(Also tried just fn := runtime.FuncForPC(0)
 fmt.Print(fn.Name(),"\n\n")
 which works with golang, but fails with gcc-go)

I have checked golang's code and indeed it does checking for nil.

(symtab.go)
func cfuncname(f *_func) *byte {
if f == nil || f.nameoff == 0 {
return nil
}
datap := findmoduledatap(f.entry) // inefficient
return (*byte)(unsafe.Pointer(&datap.pclntable[f.nameoff]))
}

but libgo doesn't:
(caller.c)
String
runtime_funcname_go (Func *f)
{
  return f->name;
}

changing it:

@@ -231,7 +231,13 @@ String runtime_funcname_go (Func *f)
 String
 runtime_funcname_go (Func *f)
 {
-  return f->name;
+  String str;
+  if (!f)
+  {
+runtime_memclr (&str, sizeof str);
+return str;
+  }
+  else return f->name;
 }

seems to fix the crash(tested on x86, will do ppc). Also it seems that Entry()
is not protected in both golang and libgo. I would expect same behavior as in
Name(). Will open golang ticket. I hope now it is finally correct fix(or at
least at right spot)... Patch in attachment.

[Bug go/66016] Accessing nil Func's name results in crash

[jcajka at redhat dot com]

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

--- Comment #1 from Jakub Čajka  ---
Golang upstream ticket:

https://github.com/golang/go/issues/10696

[Bug c++/57271] ARM: gcc generates insufficient alignment for memory passed as extra argument for function return large composite type

[tetra2005 at gmail dot com]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #8 from Yuri Gribov  ---
> So, I wonder, if it's a testcase problem and
> it should be disabled for CA8?

Perhaps add CA8 check in check_effective_target_arm_vect_no_misalign in
gcc/testsuite/lib/target-supports.exp?

[Bug target/65955] [arm] ICE during movcond_addsi split

[ktkachov at gcc dot gnu.org]

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

--- Comment #10 from ktkachov at gcc dot gnu.org ---

> > I can't reproduce it on my cross build with
> > -mthumb/-march=armv7-a/-mfloat-abi=hard/-mfpu=vfpv3-d16 unfortunately
> 
> with checking=yes,rtl?

Ah yes, with --enable-checking=yes,rtl I can reproduce it, and confirm that it
goes away with the patch.
I have posted the patch at
 https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00284.html

Thanks for investigating!

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

[alalaw01 at gcc dot gnu.org]

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

--- Comment #3 from alalaw01 at gcc dot gnu.org ---
Yeah, you're right, it's not commutative, but then, it doesn't need to be.

If f(x,y) is "(a[x] ? 7 : y)", then f(0, f(1, ...)) = f(1, f(0, ...))
(associative but not commutative), which is all we need to reorder the
iterations of the loop?

So if at the end of the loop we have a vector

v_tmp_result = { f(8, f(4, f(0, ))), f(9, f(5, f(1, ))), f(10, f(6,
f(2, ))), f(11, f(7, f(3, ))) }

obtained by standard technique for reductions, we then need to reduce the
vector to a scalar, which could be

(a) if any of the vector elements are equal to the constant 7, then return the
constant 7, else the initial value:

cond_expr (vec_reduc_or (vec_equals (v_tmp_result, 7)), 7, )

indeed you might just vectorize to get the predicates

v_tmp2 = { a[8] | a[4] | a[0], a[9] | a[5] | a[1], a[10] | a[6] | a[2], a[11] |
a[7] | a[3] }

and then reduce to scalar with cond_expr (vec_reduc_or (v_tmp2), 7, 3)

(b) alternatively one could exploit the initial value (3) also being a constant
and choose an appropriate operator from {max, min, or, and}, e.g. for 3 and 7
either reduc_max_expr(3,7) or reduc_or_expr(3,7) would work.

[Bug tree-optimization/46029] -ftree-loop-if-convert-stores causes FAIL: libstdc++-v3/testsuite/ext/pb_ds/example/tree_intervals.cc

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||alalaw01 at gcc dot gnu.org

--- Comment #4 from alalaw01 at gcc dot gnu.org ---
I'm still seeing this problem with -ftree-loop-if-convert-stores, introducing
faults by converting conditional to unconditional loads. It doesn't look as if
Sebastian Pop's patches went in (after being approved,
https://gcc.gnu.org/ml/gcc-patches/2010-11/msg01670.html). Can anyone shed any
light on this?

[Bug libstdc++/66017] New: Undefined behaviour in std::set

[public at hansmi dot ch]

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

Bug ID: 66017
   Summary: Undefined behaviour in std::set
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: public at hansmi dot ch
  Target Milestone: ---

Created attachment 35463
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35463&action=edit
Test program and output after building with Clang 3.6 (using GCC toolchain
5.1.0)

When building for Linux x86 (Debian 8 (Jessie), 32 bit) using `long long' as
std::set's value type causes UBSan as included in Clang 3.5 and 3.6 to report
an downcast/upcast of a misaligned address at runtime and ASan to report
undefined behaviour, all of them in _Rb_tree.

The simplest example I could find:

---
#include 

int main(int, char **)
{
  std::set foo {1LL};
}
---

std::set::begin, std::set::end, set::set::empty cause reports too.

This is not reproducible when compiling with GCC 5.1.0 (with the same options
sans those specific to Clang) and neither when building for x86-64 with either
compiler.

Reproduced using:

- Clang 3.5 w/ GCC toolchain 4.9
- Clang 3.6 w/ GCC toolchain 4.9
- Clang 3.6 w/ GCC toolchain 5.1.0

Shorter value types for std::set, e.g. `long' or `char', work. Packaging the
`long long' in another type, e.g. a struct, works too. The issue does not occur
with libc++.

Bug 60734 reported something similar, though there seem to be more issues. I'm
uncertain as to whether it's an issue in _Rb_tree, __aligned_buffer or another
place altogether.

Original report at LLVM/Clang: https://llvm.org/bugs/show_bug.cgi?id=23413

[Bug libstdc++/66017] Undefined behaviour in std::set

[public at hansmi dot ch]

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

--- Comment #1 from M. Hanselmann  ---
Forgot to add that A. Bougacha has analyzed the issue. According to him it's a
cast (or casts) invoking undefined behaviour.

https://llvm.org/bugs/show_bug.cgi?id=23413#c2

[Bug libstdc++/66017] Undefined behaviour in std::set

[public at hansmi dot ch]

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

--- Comment #2 from M. Hanselmann  ---
This may be related to bug 63345.

[Bug lto/52159] ICE when building qemu with GCC 4.7 trunk: cannot read LTO decls

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #6 from Markus Trippelsdorf  ---
dup

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

[Bug lto/59000] lto can't merge user-defined weak builtin functions

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||matt at use dot net

--- Comment #4 from Markus Trippelsdorf  ---
*** Bug 52159 has been marked as a duplicate of this bug. ***

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

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

--- Comment #37 from Jürgen Reuter  ---
(In reply to vehre from comment #36)
> I am waiting for an official review of the patch, to be allowed to commit to
> trunk. So I am not waiting on you. :-)

I see. Got it. :D

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

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

--- Comment #24 from Manuel López-Ibáñez  ---
(In reply to Tim Ruehsen from comment #23)

> The requested warning is an absolutely must-have (enabled by default).
> Seeing this bug open since 2004 is... well ... I have no words.

GCC needs lots of more developers. Not "experts" or "hackers", but simply
people with some patience and curiosity and basic knowledge about C/C++ and
compiling and debugging code in GNU/Linux. We need people that can focus on
things like this for a couple of hours every week for months and get it done
from start to finish.

Paid developers are paid to work on other things (targets, optimizations,
extensions) and rarely have the time and focus necessary to get projects like
this finished. Volunteers are few and we already have our hands very full with
our own little projects.

I can give you many examples of old "must-have" bugs that are "easy" to fix,
but simply there is no one with enough time and motivation to get them done.

[Bug libstdc++/66018] New: opendir configure test not working when GCC_NO_EXECUTABLES

[green at moxielogic dot com]

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

Bug ID: 66018
   Summary: opendir configure test not working when
GCC_NO_EXECUTABLES
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: green at moxielogic dot com
  Target Milestone: ---

I'm building a moxie-elf toolchain, which defines GCC_NO_EXECUTABLES during
part of the build process.

The new filesystem-ts code forces an opendir configure test that fails when
GCC_NO_EXECUTABLES is defined.

[Bug target/66019] New: Corrupt libstdc++ on AIX 6.1

[joerg.rich...@pdv-fs.de]

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

Bug ID: 66019
   Summary: Corrupt libstdc++ on AIX 6.1
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joerg.rich...@pdv-fs.de
  Target Milestone: ---
  Host: powerpc-ibm-aix6.1.0.0
Target: powerpc-ibm-aix6.1.0.0
 Build: powerpc-ibm-aix6.1.0.0

I am building GCC 4.9.2 on AIX 6.1 with the same script I used for AIX 5.3.

$ configure --enable-languages=c,c++ --disable-bootstrap --disable-nls
--with-local-prefix=/not_existing_directory --enable-frame-pointer
--with-ld=/bin/ld --with-as=/bin/as --prefix=/tools/pkg/gcc/4.9.2

make && make install

During build of GCC are a lot of warnings like this:

ld: 0711-768 WARNING: Object
../src/c++98/.libs/libc++98convenience.a[locale-inst.o], section 1, function
.std::istreambuf_iterator >::_M_get() const:
The branch at address 0x15534 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x8D3C0001.

There are 3728 ld 0711-768 warnings.  On AIX 5.3 there are no warnings using
the same script.

Nevertheless GCC builds without errors.

But when compiling and running application code that calles
std::istreambuf_iterator::_M_get() 
the process termines with SIGSEGV or SIGILL.

Here is a gdb/bt of a crashed process:

#0  0x090002edc554 in std::istreambuf_iterator
>::_M_get ()
   from libstdc++.a(libstdc++.so.6)
#1  0x090002e6dce4 in std::istreambuf_iterator
> std::num_get >
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const [clone
.localalias.77] () from libstdc++.a(libstdc++.so.6)
#2  0x090002e6db6c in std::num_get > >::do_get(std::istreambuf_iterator >, std::istreambuf_iterator
>, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const [clone
.localalias.236] ()
   from libstdc++.a(libstdc++.so.6)
#3  0x090002e92658 in std::istream& std::istream::_M_extract(unsigned int&) [clone .localalias.69] ()
   from libstdc++.a(libstdc++.so.6)

Searching for ld: 0711-768 seem to indicate that this warnings should not be
ignored.

The error might be related to some missing GNU-tool.  The 6.1 machine is not
using the same 
GNU tools like the 5.3 maschine.  I know that GCC does not build with
AIX-sed/awk.  Might 
be that I missed another GNU tool that will fix this problem.  But I have no
idea what it can be.

[Bug target/65456] powerpc64le autovectorized copy loop missed optimization

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #24 from Bill Schmidt  ---
> No, I don't think so.  The same change was made in GCC 4.9, and it didn't 
> cause
> it to XPASS there (looking at gcc-testresults).  Also, my change restricted 
> the
> number of cases for which a test is expected to fail, rather than adding 
> cases,
> so if it XPASSes now, it should have XPASSed prior to the change.
>
> Have you bisected to see which revision corresponds to the regression?

Not yet: those sparc boxes are slow, and it will take ages.  I'll check
if I can reproduce in a cross compiler.

Rainer

[Bug c/16351] NULL dereference warnings

[pmatos at gcc dot gnu.org]

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

pmatos at gcc dot gnu.org changed:

   What|Removed |Added

 CC||pmatos at gcc dot gnu.org

--- Comment #25 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #24)
> I can give you many examples of old "must-have" bugs that are "easy" to fix,
> but simply there is no one with enough time and motivation to get them done.

It would be interesting to have that list. Or just those on the top of your
head. I might not necessarily look at them now but I know I will have some time
in the near future to work on a few of these, so it would be interesting to
have this list so I can look at them.

Thanks.

[Bug libstdc++/66011] [6 Regression] call to '__open_missing_mode' declared with attribute error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-05-05
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Jonathan Wakely  ---
I'll fix this ASAP. In the meanwhile, you can configure with
--disable-libstdcxx-filesystem-ts

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

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

--- Comment #26 from Manuel López-Ibáñez  ---
(In reply to pmatos from comment #25)
> (In reply to Manuel López-Ibáñez from comment #24)
> > I can give you many examples of old "must-have" bugs that are "easy" to fix,
> > but simply there is no one with enough time and motivation to get them done.
> 
> It would be interesting to have that list. Or just those on the top of your
> head. I might not necessarily look at them now but I know I will have some
> time in the near future to work on a few of these, so it would be
> interesting to have this list so I can look at them.

A good place to start is
https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=easyhack&list_id=116934&order=bug_id&query_format=advanced

In particular, PR19808 should be fairly easy and there is some work already
done. It is also a prerequisite for PR2972. 

PR7652 has an initial patch.
PR23087 is very straightforward. 
PR17896 has a patch already.
PR99 is the oldest bug in my list and it is still a mystery. It needs proper
debugging to understand what goes wrong.

Of course, there are also quite a few very old bugs where the fix is not so
straight-forward but the impact would be very high: PR19430 (do the warning in
the FE?) and PR18501 (the most common Wuninitialized bug).

[Bug c/16351] NULL dereference warnings

[pmatos at gcc dot gnu.org]

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

--- Comment #27 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #26)
> A good place to start is
> https://gcc.gnu.org/bugzilla/buglist.
> cgi?keywords=easyhack&list_id=116934&order=bug_id&query_format=advanced
> 

Thanks for the input. I will take a look.

[Bug target/64579] __TM_end __builtin_tend failed to return transactional state

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
Author: bergner
Date: Tue May  5 14:22:33 2015
New Revision: 222807

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

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* config/rs6000/htm.md: Remove all define_expands.
(UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC,
UNSPECV_HTM_TABORTWCI): Remove.
(UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New.
(tabort_internal, tbegin_internal, tcheck_internal, tend_internal,
trechkpt_internal, treclaim_internal, tsr_internal): Rename from
this...
(tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this.
(tabortdc_internal, tabortdci_internal, tabortwc_internal,
tabortwci_internal): Remove define_insns.
(tabortc, tabortci): New define_insns.
(tabort): Use gpc_reg_operand.
(tcheck): Remove operand.
(htm_mfspr_, htm_mtspr_): Use GPR mode macro.
* config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as
expected value.
* config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove.
(BU_HTM_SPR1): Rename to BU_HTM_V1.  Remove use of RS6000_BTC_SPR.
(tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin,
tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend,
tsr, ttest): Pass in the RS6000_BTC_CR attribute.
(get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr,
get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute.
(tcheck): Remove builtin argument.
* config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64
not TARGET_64BIT.
(htm_expand_builtin): Fix usage of expandedp.  Disallow usage of the
tabortdc and tabortdci builtins when not in 64-bit mode.
Modify code to handle the loss of the HTM define_expands.
Emit code to copy the CR register to TARGET.
(htm_init_builtins): Modify code to handle the loss of the HTM
define_expands.
* config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete.
(RS6000_BTC_64BIT): Likewise.
(RS6000_BTC_CR): New macro.
* doc/extend.texi: Update documentation for htm builtins.

gcc/testsuite/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* gcc.target/powerpc/htm-1.c: New test.
* gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test
on 64-bit compiles.
(__builtin_tabortdci): Likewise.
(__builtin_tcheck): Remove operand.
* lib/target-supports.exp (check_htm_hw_available): New function.

Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/htm-1.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/rs6000/htm.md
branches/gcc-5-branch/gcc/config/rs6000/htmxlintrin.h
branches/gcc-5-branch/gcc/config/rs6000/rs6000-builtin.def
branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
branches/gcc-5-branch/gcc/config/rs6000/rs6000.h
branches/gcc-5-branch/gcc/doc/extend.texi
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c
branches/gcc-5-branch/gcc/testsuite/lib/target-supports.exp

[Bug c/16351] NULL dereference warnings

[tim.ruehsen at gmx dot de]

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

--- Comment #28 from Tim Ruehsen  ---
I far as I can read, not a patch is missing. A review + commit is missing.
How can you ask for more developers (=patches) when the work is ignored ?
Don't get me wrong, I just try to understand how this should work.

[Bug target/64579] __TM_end __builtin_tend failed to return transactional state

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
Author: bergner
Date: Tue May  5 14:25:35 2015
New Revision: 222808

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

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* config/rs6000/htm.md: Remove all define_expands.
(UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC,
UNSPECV_HTM_TABORTWCI): Remove.
(UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New.
(tabort_internal, tbegin_internal, tcheck_internal, tend_internal,
trechkpt_internal, treclaim_internal, tsr_internal): Rename from
this...
(tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this.
(tabortdc_internal, tabortdci_internal, tabortwc_internal,
tabortwci_internal): Remove define_insns.
(tabortc, tabortci): New define_insns.
(tabort): Use gpc_reg_operand.
(tcheck): Remove operand.
(htm_mfspr_, htm_mtspr_): Use GPR mode macro.
* config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as
expected value.
* config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove.
(BU_HTM_SPR1): Rename to BU_HTM_V1.  Remove use of RS6000_BTC_SPR.
(tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin,
tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend,
tsr, ttest): Pass in the RS6000_BTC_CR attribute.
(get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr,
get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute.
(tcheck): Remove builtin argument.
* config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64
not TARGET_64BIT.
(htm_expand_builtin): Fix usage of expandedp.  Disallow usage of the
tabortdc and tabortdci builtins when not in 64-bit mode.
Modify code to handle the loss of the HTM define_expands.
Emit code to copy the CR register to TARGET.
(htm_init_builtins): Modify code to handle the loss of the HTM
define_expands.
* config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete.
(RS6000_BTC_64BIT): Likewise.
(RS6000_BTC_CR): New macro.
* doc/extend.texi: Update documentation for htm builtins.

gcc/testsuite/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* gcc.target/powerpc/htm-1.c: New test.
* gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test
on 64-bit compiles.
(__builtin_tabortdci): Likewise.
(__builtin_tcheck): Remove operand.
* lib/target-supports.exp (check_htm_hw_available): New function.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/htm-1.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/rs6000/htm.md
branches/gcc-4_9-branch/gcc/config/rs6000/htmxlintrin.h
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000-builtin.def
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_9-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_9-branch/gcc/doc/extend.texi
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c
branches/gcc-4_9-branch/gcc/testsuite/lib/target-supports.exp

[Bug target/64579] __TM_end __builtin_tend failed to return transactional state

[bergner at gcc dot gnu.org]

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

--- Comment #5 from Peter Bergner  ---
Author: bergner
Date: Tue May  5 14:27:30 2015
New Revision: 222809

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

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* config/rs6000/htm.md: Remove all define_expands.
(UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC,
UNSPECV_HTM_TABORTWCI): Remove.
(UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New.
(tabort_internal, tbegin_internal, tcheck_internal, tend_internal,
trechkpt_internal, treclaim_internal, tsr_internal): Rename from
this...
(tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this.
(tabortdc_internal, tabortdci_internal, tabortwc_internal,
tabortwci_internal): Remove define_insns.
(tabortc, tabortci): New define_insns.
(tabort): Use gpc_reg_operand.
(tcheck): Remove operand.
(htm_mfspr_, htm_mtspr_): Use GPR mode macro.
* config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as
expected value.
* config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove.
(BU_HTM_SPR1): Rename to BU_HTM_V1.  Remove use of RS6000_BTC_SPR.
(tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin,
tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend,
tsr, ttest): Pass in the RS6000_BTC_CR attribute.
(get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr,
get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute.
(tcheck): Remove builtin argument.
* config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64
not TARGET_64BIT.
(htm_expand_builtin): Fix usage of expandedp.  Disallow usage of the
tabortdc and tabortdci builtins when not in 64-bit mode.
Modify code to handle the loss of the HTM define_expands.
Emit code to copy the CR register to TARGET.
(htm_init_builtins): Modify code to handle the loss of the HTM
define_expands.
* config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete.
(RS6000_BTC_64BIT): Likewise.
(RS6000_BTC_CR): New macro.
* doc/extend.texi: Update documentation for htm builtins.

gcc/testsuite/

Backport from mainline.
2015-04-27  Peter Bergner  

PR target/64579
* gcc.target/powerpc/htm-1.c: New test.
* gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test
on 64-bit compiles.
(__builtin_tabortdci): Likewise.
(__builtin_tcheck): Remove operand.
* lib/target-supports.exp (check_htm_hw_available): New function.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/htm-1.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/rs6000/htm.md
branches/gcc-4_8-branch/gcc/config/rs6000/htmxlintrin.h
branches/gcc-4_8-branch/gcc/config/rs6000/rs6000-builtin.def
branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.c
branches/gcc-4_8-branch/gcc/config/rs6000/rs6000.h
branches/gcc-4_8-branch/gcc/doc/extend.texi
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c
branches/gcc-4_8-branch/gcc/testsuite/lib/target-supports.exp

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #23 from Thiago Macieira  ---
$ pmap `pidof qtcreator` | perl -ne '@_ = split / +/; if ($_[6] eq "r-xp" &&
$_[7] !~ /\[/) { $_[1] =~ s/K//; $total += $_[1]; $bin = $_[1] unless $bin; }
END { print "$bin $total\n"; }'
72 166164

That is, the size of the binary's text segment is 72k and the size of all the
library's text segments is 162 MB (granted, this includes .rodata sections).

My assertion is that keeping copy relocations is optimising for 0.05% of the
codebase.

I am asking that we begin reversing that decision. We can do it by opt-in, like
Qt 5 tried to do: some large libraries, when they do their next binary
incompatible release, enable the feature, causing the applications to stop
doing copy relocations. I'd also like ld to refuse to link if copy relocations
are required and the symbol comes from a library that used
-fvisibility=protected -fsymbolic -Wl,-Bsymbolic (isn't that what DF_SYMBOLIC
is for?)

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[hjl.tools at gmail dot com]

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

--- Comment #24 from H.J. Lu  ---
(In reply to Thiago Macieira from comment #23)
> $ pmap `pidof qtcreator` | perl -ne '@_ = split / +/; if ($_[6] eq "r-xp" &&
> $_[7] !~ /\[/) { $_[1] =~ s/K//; $total += $_[1]; $bin = $_[1] unless $bin;
> } END { print "$bin $total\n"; }'
> 72 166164
> 
> That is, the size of the binary's text segment is 72k and the size of all
> the library's text segments is 162 MB (granted, this includes .rodata
> sections).
> 
> My assertion is that keeping copy relocations is optimising for 0.05% of the
> codebase.

Copy relocation is the part of the psABI.  What you did violates the psABI,
as it is incompatible with the normal executable.

> I am asking that we begin reversing that decision. We can do it by opt-in,
> like Qt 5 tried to do: some large libraries, when they do their next binary
> incompatible release, enable the feature, causing the applications to stop
> doing copy relocations. I'd also like ld to refuse to link if copy
> relocations are required and the symbol comes from a library that used
> -fvisibility=protected -fsymbolic -Wl,-Bsymbolic (isn't that what
> DF_SYMBOLIC is for?)

Link-time library != run-time library.  You can't enforce run-time behavior
at link-tome.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek  ---
(In reply to Thiago Macieira from comment #23)
> $ pmap `pidof qtcreator` | perl -ne '@_ = split / +/; if ($_[6] eq "r-xp" &&
> $_[7] !~ /\[/) { $_[1] =~ s/K//; $total += $_[1]; $bin = $_[1] unless $bin;
> } END { print "$bin $total\n"; }'
> 72 166164
> 
> That is, the size of the binary's text segment is 72k and the size of all
> the library's text segments is 162 MB (granted, this includes .rodata
> sections).
> 
> My assertion is that keeping copy relocations is optimising for 0.05% of the
> codebase.

You can't judge everything from these numbers, just because KDE for some reason
decides to use very small binaries.  Many programs have much larger binaries,
especially if they care about performance.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek  ---
Plus, if KDE uses so small binaries, why don't just compile them with -fPIC
then?
You can then link them as normal executables or PIEs, depending on what you
prefer, and still it supposedly wouldn't use copy relocations, as all
references to externals would be through .got.

[Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available

[ktkachov at gcc dot gnu.org]

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

--- Comment #26 from ktkachov at gcc dot gnu.org ---
So, out of interest, what is needed to make this work properly with target
attributes?

What hooks do we need to implement?
Looking at
https://gcc.gnu.org/onlinedocs/gccint/Target-Attributes.html#Target-Attributes

I think it should be TARGET_OPTION_SAVE and TARGET_OPTION_RESTORE and also the
builtin initialisation hook should be changed, but I can't figure out how
TARGET_OPTION_{SAVE, RESTORE} are used (are they even relevant?)

[Bug c++/65854] [c++-concepts] Type constraint satisfaction error for type aliases; regression from r211591

[tom at honermann dot net]

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

Tom Honermann  changed:

   What|Removed |Added

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

--- Comment #3 from Tom Honermann  ---
Thank you!  I confirmed that this is corrected with r222769.  Changing status
to resolved/fixed.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

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

--- Comment #29 from Manuel López-Ibáñez  ---
(In reply to Tim Ruehsen from comment #28)
> I far as I can read, not a patch is missing. A review + commit is missing.
> How can you ask for more developers (=patches) when the work is ignored ?
> Don't get me wrong, I just try to understand how this should work.

I'm actually not asking for more patches. As you can see, many of those PRs
already have patches. People send patches all the time. Sometimes very large
ones, and many times they never get committed, because they do not ping them,
or they do not address the reviewers' comments, or simply they get bored and
move to something else. 

What we need is people that are "patient and motivated" to get their code
committed to the upstream repository.

Unfortunately, getting reviews is hard because there are few developers and
they are busy, and new developers often fail to insist because they feel their
work is being ignored or they do not have time to follow-up and do the changes
asked by the reviewers. It is a vicious circle that I do not know how to solve.

As a volunteer, I know a patch of mine may take weeks/months to get reviewed. I
simply keep pinging (see https://gcc.gnu.org/wiki/Community for tips on how to
do this effectively). If I have free time, I work on something else; if not,
well, then it doesn't matter that it did not get reviewed yet. I am not in a
hurry. I don't have a deadline or a boss to present results. It is better that
it gets fixed in a year or two than never. 

For example, it took many years to get something as simple as coloured output
for diagnostics, but it finally happened. This was not because the core GCC
devs had a meeting and said "Oh, Clang is kicking our ass with their colors,
let's make this a priority". No, it took one volunteer insisting during many
months, revisions of patches and compromises. It did not actually take a lot of
coding time in total, but it was a process spread across many months.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #27 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #26)
> Plus, if KDE uses so small binaries, why don't just compile them with -fPIC
> then?
> You can then link them as normal executables or PIEs, depending on what you
> prefer, and still it supposedly wouldn't use copy relocations, as all
> references to externals would be through .got.

Can you guarantee that the linker won't generate copy relocs for -fPIC?

Anyway, I know I am generalising from a sample of 1, but in my experience as a
desktop developer, the mass of library code is much bigger and more complex
than the application code. This is probably not true in large single-instance
applications -- for example, mysqld's text segment is of comparable size to the
total size of the libraries it uses.

Still, if this were solved properly, relocations that resolved back into the
executable itself would still be bound locally, even position-dependently if
that's how the binary were built. I am asking that it stop doing copy
relocations, which only applies to symbols the linker *did* detect came from
elsewhere.

I've also said I'll gladly tag each of those symbols with an __attribute__ so
that GCC also knows it comes from elsewhere and generate the proper indirect
load sequence via the GOT.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[hjl.tools at gmail dot com]

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

--- Comment #28 from H.J. Lu  ---
(In reply to Thiago Macieira from comment #27)
> (In reply to Jakub Jelinek from comment #26)
> > Plus, if KDE uses so small binaries, why don't just compile them with -fPIC
> > then?
> > You can then link them as normal executables or PIEs, depending on what you
> > prefer, and still it supposedly wouldn't use copy relocations, as all
> > references to externals would be through .got.
> 
> Can you guarantee that the linker won't generate copy relocs for -fPIC?

Yes.

[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[tocarip at gcc dot gnu.org]

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

--- Comment #4 from tocarip at gcc dot gnu.org ---
Author: tocarip
Date: Tue May  5 15:43:13 2015
New Revision: 222811

URL: https://gcc.gnu.org/viewcvs?rev=222811&root=gcc&view=rev
Log:
PR target/65915
* config/i386/i386.md (vector convert to float spltiter): Check for
xmm16+, when splitting scalar float conversion.
* config/i386/sse.md (sse2_cvtsi2sd): Support EVEX version.

testsuite/ChangeLog:

PR target/65915
* gcc.target/i386/pr65915.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65915.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
(In reply to Thiago Macieira from comment #27)
> Still, if this were solved properly, relocations that resolved back into the
> executable itself would still be bound locally, even position-dependently if
> that's how the binary were built. I am asking that it stop doing copy
> relocations, which only applies to symbols the linker *did* detect came from
> elsewhere.

You are missing the point of copy relocations.  Consider:
int a = 1;
extern int b, c;
int foo (void)
{
  return a + b + c;
}
compiled with -fno-pic or -fpie.  a is known to be defined in the executable,
but b and c are externals.  Without copy relocations you'd need to emit
significantly slower code (extra .got reference or similar) for all the
accesses to the externals, with copy relocations you can optimistically assume
they will likely be defined in the executable (usual case for larger programs,
at least for C shared libraries people avoid exporting variables from shared
libraries if easily possible), and if not, the linker will create copy
relocations.

Only with whole program (LTO or similar) compilation, when you can talk to the
linker, you could find out if the externals from some TU are defined within the
executable or not.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #30 from Thiago Macieira  ---
(In reply to H.J. Lu from comment #28)
> (In reply to Thiago Macieira from comment #27)
> > (In reply to Jakub Jelinek from comment #26)
> > Can you guarantee that the linker won't generate copy relocs for -fPIC?
> 
> Yes.

Thanks. We'll start requiring -fPIC as of Qt 5.4.2 and we'll advise Linux
distributions to backport the patch if they also upgrade GCC from 4.9.

For reference: https://codereview.qt-project.org/111787

Please treat this bug report now as a feature suggestion.

[Bug target/64304] AArch64 miscompilation with -mgeneral-regs-only

[fyang at gcc dot gnu.org]

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

--- Comment #7 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Tue May  5 15:50:18 2015
New Revision: 222812

URL: https://gcc.gnu.org/viewcvs?rev=222812&root=gcc&view=rev
Log:
Backported from mainline
2015-01-19  Jiong Wang  
Andrew Pinski  

PR target/64304
* config/aarch64/aarch64.md (define_insn "*ashl3_insn"): Deleted.
(ashl3): Don't expand if operands[2] is not constant.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/pr64304.c
Modified:
branches/gcc-4_9-branch/gcc/ChangeLog
branches/gcc-4_9-branch/gcc/config/aarch64/aarch64.md
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #31 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #29)
> You are missing the point of copy relocations.  Consider:
> int a = 1;
> extern int b, c;
> int foo (void)
> {
>   return a + b + c;
> }
> compiled with -fno-pic or -fpie.  a is known to be defined in the
> executable, but b and c are externals.  Without copy relocations you'd need
> to emit significantly slower code (extra .got reference or similar) for all
> the accesses to the externals, with copy relocations you can optimistically
> assume they will likely be defined in the executable (usual case for larger
> programs, at least for C shared libraries people avoid exporting variables
> from shared libraries if easily possible), and if not, the linker will
> create copy relocations.

That is true.

But if you place the same code in a library, then now all accesses must be
indirect, even for a. My assertion isn't about the usefulness of copy
relocations, it's that they are optimising for the wrong thing. The size and
complexity of libraries and plugins in desktop applications is orders of
magnitude above that of the application codebases.

> Only with whole program (LTO or similar) compilation, when you can talk to
> the linker, you could find out if the externals from some TU are defined
> within the executable or not.

Or if we tag them appropriately.

int a = 1;
extern int b;
__attribute__((dllimport)) extern int c;
int foo(void)
{
return a + b + c;
}

Now the compiler knows that a is in the local executable and it can assume that
b is too, but it  also knows that c isn't and must be accessed indirectly. This
did not require LTO.

Modern libraries already all have a macro preceding all the function and
variable declarations meant to be used by other DSOs, ever since Ulrich
Drepper's "dso-howto" manual. The macro tags are required so that we have a
proper __attribute__((visibility("default"))) when the library is compiled with
-fvisibility=hidden. Moreover, the same tag expands to __declspec(dllexport) or
__declspec(dllimport) on Windows if the library is cross-platform. So the
precedent is there and modern libraries are mostly ready to make use of the
feature.

[Bug target/64304] AArch64 miscompilation with -mgeneral-regs-only

[fyang at gcc dot gnu.org]

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

--- Comment #8 from fyang at gcc dot gnu.org ---
Author: fyang
Date: Tue May  5 15:59:12 2015
New Revision: 222814

URL: https://gcc.gnu.org/viewcvs?rev=222814&root=gcc&view=rev
Log:
Backported from mainline
2015-01-19  Jiong Wang  
Andrew Pinski  

PR target/64304
* config/aarch64/aarch64.md (define_insn "*ashl3_insn"): Deleted.
(ashl3): Don't expand if operands[2] is not constant.

Added:
branches/gcc-4_8-branch/gcc/testsuite/gcc.target/aarch64/pr64304.c
Modified:
branches/gcc-4_8-branch/gcc/ChangeLog
branches/gcc-4_8-branch/gcc/config/aarch64/aarch64.md
branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug go/66016] Accessing nil Func's name results in crash

[ian at gcc dot gnu.org]

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

--- Comment #2 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue May  5 16:38:45 2015
New Revision: 222815

URL: https://gcc.gnu.org/viewcvs?rev=222815&root=gcc&view=rev
Log:
PR go/66016
runtime: Don't crash in Func.Name if the Func is nil.

Related to Go issue 10696

Modified:
branches/gcc-4_9-branch/libgo/runtime/go-caller.c

[Bug go/66016] Accessing nil Func's name results in crash

[ian at gcc dot gnu.org]

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

--- Comment #3 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue May  5 16:38:57 2015
New Revision: 222816

URL: https://gcc.gnu.org/viewcvs?rev=222816&root=gcc&view=rev
Log:
PR go/66016
runtime: Don't crash in Func.Name if the Func is nil.

Related to Go issue 10696

Modified:
trunk/libgo/runtime/go-caller.c

[Bug go/66016] Accessing nil Func's name results in crash

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Fixed.  Thanks for reporting it.

[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May  5 16:53:27 2015
New Revision: 222817

URL: https://gcc.gnu.org/viewcvs?rev=222817&root=gcc&view=rev
Log:
PR target/65990
* config/i386/i386.c (ix86_parse_stringop_strategy_string): Error out
if rep_8byte stringop strategy was specified for 32-bit target.

testsuite/ChangeLog:

PR target/65990
* gcc.target/i386/pr65990.c: New test.


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

[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

[Bug target/65983] [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618) with -fsanitize=thread -mavx512ifma -march=barcelona

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Depends on|65915   |
 Resolution|--- |DUPLICATE

--- Comment #3 from Uroš Bizjak  ---
Confirmed dup of PR65915.

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


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65915
[Bug 65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c
(internal compiler error)

[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Blocks|65983   |

--- Comment #5 from Uroš Bizjak  ---
*** Bug 65983 has been marked as a duplicate of this bug. ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65983
[Bug 65983] [6 Regression] ICE: SIGSEGV in mark_label_nuses (emit-rtl.c:3618)
with -fsanitize=thread -mavx512ifma -march=barcelona

[Bug target/65915] [6 Regression] FAIL: gcc.target/i386/avx512f-vrndscalepd-2.c (internal compiler error)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed.

[Bug target/66020] [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test

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

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/66020] New: [6.0 regression] FAIL: gcc.target/powerpc/ppc64-abi-2.c execution test

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

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

Bug ID: 66020
   Summary: [6.0 regression] FAIL:
gcc.target/powerpc/ppc64-abi-2.c execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: powerpc64-*-*

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c -O2
-fprofile -mprofile-kernel -maltivec -mabi=altivec -lm -m64 -o
./ppc64-abi-2.exe
$ ./ppc64-abi-2.exe
Segmentation fault
(gdb) bt
#0  0x in ?? ()
#1  0x3fffb7d24dcc in generic_start_main (
main=@0x10012190: 0x15d0 , argc=, 
argv=0x3fffef48, auxvec=0x3220, init=, 
rtld_fini=, stack_end=, fini=)
at ../csu/libc-start.c:269
#2  0x3fffb7d24fd4 in __libc_start_main (argc=, 
argv=, ev=, auxvec=, 
rtld_fini=, stinfo=, 
stack_on_entry=)
at ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:80
#3  0x in ?? ()


Breakpoint 3, fcvi (s=0x100011e0 "vv", v=..., i=2)
at ../gcc/testsuite/gcc.target/powerpc/ppc64-abi-2.c:138
138   reg_parms_t lparms = gparms;
(gdb) disass
Dump of assembler code for function fcvi:
   0x1900 <+0>: mflrr0
   0x1904 <+4>: bl  0x1820 
   0x1908 <+8>: mflrr0
=> 0x190c <+12>:nop
   0x1910 <+16>:li  r8,176
   0x1914 <+20>:ld  r10,-32744(r2)
   0x1918 <+24>:std r0,16(r1)
   0x191c <+28>:stdur1,-112(r1)
   0x1920 <+32>:ld  r9,0(r10)
   0x1924 <+36>:ld  r6,32(r10)
   0x1928 <+40>:cmpdcr7,r3,r9
   0x192c <+44>:lvx v0,r10,r8
   0x1930 <+48>:bne-cr7,0x1954 
   0x1934 <+52>:vcmpequw. v2,v2,v0
   0x1938 <+56>:bge-cr6,0x1954 
   0x193c <+60>:cmpdcr7,r7,r6
   0x1940 <+64>:bne-cr7,0x1954 
   0x1944 <+68>:addir1,r1,112
   0x1948 <+72>:ld  r0,16(r1)
   0x194c <+76>:mtlrr0
   0x1950 <+80>:blr
   0x1954 <+84>:bl  0x15bc
<0044.plt_call.abort@@GLIBC_2.3>
   0x1958 <+88>:ld  r2,40(r1)
   0x195c <+92>:.long 0x0
   0x1960 <+96>:.long 0x1
   0x1964 <+100>:   lwz r0,0(0)
End of assembler dump.
(gdb) i reg r0
r0 0x0  0

[Bug target/65990] ICE: in extract_insn, at recog.c:2341 (unrecognizable insn) with -mmemcpy-strategy=rep_8byte:-1:noalign -m32 -mtune=btver2

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.3

[Bug middle-end/66021] New: GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

Bug ID: 66021
   Summary: GCC miscompiles Z3
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nunoplopes at sapo dot pt
  Target Milestone: ---

GCC 4.92 miscompiles Z3. I've tried Cygwin and Linux, 32 and 64 bits, and all
miscompile.

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #35407|0   |1
is obsolete||

--- Comment #12 from vehre at gcc dot gnu.org ---
Created attachment 35464
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35464&action=edit
Follow-up patch fixing latest regression.

With this patch all code samples and the code in the tar-archive compile and
execute well. This patch will need most of my previous patches. The total set
of all of my patches is available on the gitmirror in the branch
vehre/head_cosmo

[Bug middle-end/66021] GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

--- Comment #1 from Nuno Lopes  ---
Sorry, a bit more information the problem:

On function void
reduce_args_tactic::imp::populate_decl2args_proc::operator()(app * n), when
compiled with -O0 no call to memory::deallocate(void* p) is made, while with
-O2 memory::deallocate is called with p == 0, which cannot happen (since it's
called through dealloc_svect, which bails out if the pointer is null).

Apologies for not being able to reduce the test case; I don't have much
experience with the gcc internals.

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

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

--- Comment #3 from Daniel Starke  ---
I have yet to bootstrap the current trunk (r222810). It currently fails with
/usr/new-gcc/bin32/./prev-gcc/xg++ -B/usr/new-gcc/bin32/./prev-gcc/
-B/mingw/mingw32/bin/ -nostdinc++
-B/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/src/.libs
-B/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/libsupc++/.libs 
-I/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32 
-I/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/include 
-I/usr/new-gcc/src/gcc-trunk/libstdc++-v3/libsupc++
-L/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/src/.libs
-L/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/libsupc++/.libs -c   -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc-trunk/gcc
-I../../src/gcc-trunk/gcc/build -I../../src/gcc-trunk/gcc/../include 
-I../../src/gcc-trunk/gcc/../libcpp/include -DPTW32_STATIC_LIB \
-o build/genmddeps.o ../../src/gcc-trunk/gcc/genmddeps.c
In file included from ../../src/gcc-trunk/gcc/genmddeps.c:19:0:
../../src/gcc-trunk/gcc/system.h:1024:0: error: "CONST_CAST2" redefined
[-Werror]
 #define CONST_CAST2(TOTYPE,FROMTYPE,X) (const_cast (X))
 ^
In file included from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32/bits/gthr.h:148:0,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/ext/atomicity.h:35,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/bits/basic_string.h:39,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/string:52,
 from ../../src/gcc-trunk/gcc/system.h:201,
 from ../../src/gcc-trunk/gcc/genmddeps.c:19:
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32/bits/gthr-default.h:33:0:
note: this is the location of the previous definition
 #define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q;
TOTYPE _nq;})(X))._nq)
 ^
cc1plus.exe: all warnings being treated as errors

I will try to compile the trunk without bootstrap.

[Bug middle-end/66021] GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

--- Comment #2 from Nuno Lopes  ---
Created attachment 35465
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35465&action=edit
test case

[Bug bootstrap/66022] New: 4.8.4 build fails with stage 2 and 3 comparison error

[jrm at exa dot com]

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

Bug ID: 66022
   Summary: 4.8.4 build fails with stage 2 and 3 comparison error
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrm at exa dot com
  Target Milestone: ---

Created attachment 35466
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35466&action=edit
Shell script used to extract tar ball, obtain pre-reqs, configure and run gcc
build

Attempting as non-clever a build of 4.8.4 as possible.  Same behavior with
binutils 2.19.1 or 2.25.   Prerequisites obtained w/"download_prerequisites"
script (MPFR 2.4.2, GMP 4.3.2 and MPC 0.8.1).   Ordinary linux machine:

plasma:/opt/SRC-gcc-4.8.4/gcc-4.8.4% cat /etc/issue
CentOS release 5.9 (Final)
Kernel \r on an \m

plasma:/opt/SRC-gcc-4.8.4/gcc-4.8.4% uname -a
Linux plasma 2.6.18-348.12.1.el5 #1 SMP Wed Jul 10 05:28:41 EDT 2013 x86_64
x86_64 x86_64 GNU/Linux


Last bits of the build log showing failure:

gmake[3]: Entering directory `/opt/BUILD-gcc-4.8.4'
rm -f stage_current
gmake[3]: Leaving directory `/opt/BUILD-gcc-4.8.4'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Bootstrap comparison failure!
gcc/coverage.o differs
gcc/asan.o differs
gcc/sel-sched-ir.o differs
gcc/passes.o differs
gcc/sel-sched.o differs
gcc/value-prof.o differs
gcc/cfg.o differs
gcc/dse.o differs
gcc/tree-ssa-pre.o differs
gcc/haifa-sched.o differs
gcc/sched-deps.o differs
gcc/tree-ssa-tail-merge.o differs
gcc/cp/class.o differs
gcc/cp/semantics.o differs
gcc/alloc-pool.o differs
gcc/tree-ssa-threadupdate.o differs
gmake[2]: *** [compare] Error 1
gmake[2]: Leaving directory `/opt/BUILD-gcc-4.8.4'

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[juergen.reuter at desy dot de]

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

--- Comment #13 from Jürgen Reuter  ---
I will give it a try as soon as possible. Any idea how long propagation into
the trunk might last?

[Bug go/66016] Accessing nil Func's name results in crash

[ian at gcc dot gnu.org]

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

--- Comment #5 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue May  5 17:46:31 2015
New Revision: 222820

URL: https://gcc.gnu.org/viewcvs?rev=222820&root=gcc&view=rev
Log:
PR go/66016
runtime: Don't crash in Func.Name if the Func is nil.

Related to Go issue 10696

Modified:
branches/gcc-5-branch/libgo/runtime/go-caller.c

[Bug fortran/65894] [6 Regression] severe regression in gfortran 6.0.0

[vehre at gcc dot gnu.org]

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

--- Comment #14 from vehre at gcc dot gnu.org ---
That solely depends on the availability of reviews. At the moment getting a
review is quite difficult.

Btw, when you can use docker, then there is docker image available at:

https://registry.hub.docker.com/u/cmbant/docker-gcc-build/

But this also needs to compile first. Check the "Build Details" tab, whether it
succeeded. I do not maintain this docker file, just for info.

[Bug middle-end/66021] GCC miscompiles Z3

[nunoplopes at sapo dot pt]

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

--- Comment #3 from Nuno Lopes  ---
Created attachment 35467
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35467&action=edit
reduced test case

[Bug target/66023] New: Investigate and fix IBM z Systems `guality' testsuite failures

[krebbel at gcc dot gnu.org]

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

Bug ID: 66023
   Summary: Investigate and fix IBM z Systems `guality' testsuite
failures
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Running the GCC guality testsuite on z currently shows many
fails. These fails need to be investigated, classified, and fixed.

The goal is to fix as many as possible guality testsuite fails on
-march level z196 with GDB 7.9.  For all remaining fails a detailled
description of the problem is required which either points out why
this is a fundamental problem in GCC or why the problem does not lie
within the scope of GCC.

[Bug target/66023] Investigate and fix IBM z Systems `guality' testsuite failures

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/66024] New: Implement AddressSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Bug ID: 66024
   Summary: Implement AddressSanitizer support for IBM z Systems
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Enable the AddressSanitizer in GCC for IBM z Systems.  The goal is to pass the
AddressSanitizer testsuite on a z machine.

[Bug target/66024] Implement AddressSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/66025] Implement ThreadSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/66025] New: Implement ThreadSanitizer support for IBM z Systems

[krebbel at gcc dot gnu.org]

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

Bug ID: 66025
   Summary: Implement ThreadSanitizer support for IBM z Systems
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Enable the ThreadSanitizer in GCC for IBM z Systems.  The goal is to pass the
ThreadSanitizer testsuite on a z machine.