[Bug tree-optimization/63406] -Warray-bounds false positive with -O3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Marek Polacek  ---
No supported version of GCC warns on the testcase with -O3 -Warray-bounds ->
closing.

[Bug bootstrap/69506] check-in 232454 seems to cause problems with cygwin builds

[rogero at howzatt dot demon.co.uk]

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

--- Comment #1 from Roger Orr  ---
See also http://permalink.gmane.org/gmane.os.cygwin/156987

[Bug bootstrap/69506] New: check-in 232454 seems to cause problems with cygwin builds

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 69506
   Summary: check-in 232454 seems to cause problems with cygwin
builds
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

A complete build of gcc on cygwin, with change 232071 backed out (see pr66655),
works with revision 232453 but fails with revision 232454.

The stage-1 build of libstdc++-v3 fails with undefined symbols:
'_ITM_RU1'
'transaction clone for operator new[](unsigned long)'
'_ITM_memcpyRnWt'
'_ITM_RU8'

--

Using cygwin, with bison 2.7 installed:

This completes stage1, stage2 and stage3 of the build:

svn co -r 232453 svn://gcc.gnu.org/svn/gcc/trunk gcc-trunk-232453
cd gcc-trunk-232453
# see pr66655
svn up -r 232070 gcc/config/i386/cygming.h
./contrib/download_prerequisites
mkdir ../build-232453
cd ../build-232453
../gcc-trunk-232453/configure --enable-languages=c,c++
--prefix=/usr/share/gcc-trunk
make -j4

Changing the revision from 232453 to 232454 the make command fails.

Failing command:

libtool: link:  /cygdrive/c/projects/gcc/build-232454/./gcc/xgcc -shared-libgcc
-B/cygdrive/c/projects/gcc/build-232454/./gcc -nostdinc++
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-B/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/bin/
-B/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/lib/ -isystem
/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/include -isystem
/usr/share/gcc-trunk-232454/x86_64-unknown-cygwin/sys-include-shared
-nostdlib /cygdrive/c/projects/gcc/build-232454/./gcc/crtbeginS.o 
.libs/compatibility.o .libs/compatibility-debug_list.o
.libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o  -Wl,--whole-archive
../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a -Wl,--no-whole-archive 
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/libsupc++/.libs
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src
-L/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/.libs
-L/usr/lib/w32api -L/cygdrive/c/projects/gcc/build-232454/./gcc -L/lib/../lib
-L/usr/lib/../lib -lgcc_s -lgcc -lcygwin -ladvapi32 -lshell32 -luser32
-lkernel32 -lgcc_s -lgcc /cygdrive/c/projects/gcc/build-232454/./gcc/crtend.o 
-Wl,-O1 -Wl,--gc-sections -Wl,--version-script=libstdc++-symbols.ver   -o
.libs/cygstdc++-6.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
-Xlinker .libs/libstdc++.dll.a

Errors reported:

../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function
`_txnal_cow_string_C1_for_exceptions(void*, char const*, void*)':
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:242:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:254:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x39):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`transaction clone for operator new[](unsigned long)'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:273:(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x5d):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol
`_ITM_memcpyRtWn'
../src/c++11/.libs/libc++11convenience.a(cow-stdexcept.o): In function
`txnal_read_ptr':
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:284:(.text$_Z23_txnal_cow_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:284:(.text$_Z23_txnal_sso_string_c_strPKv+0x1):
relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
/cygdrive/c/projects/gcc/build-232454/x86_64-unknown-cygwin/libstdc++-v3/src/c++11/../../../../../gcc-trunk-232454/libstdc++-v3/src/c++11/cow-stdexcept.cc:284:(.text$_Z20_txnal_c

[Bug c/69507] New: bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

Bug ID: 69507
   Summary: bogus warning: ISO C does not allow ‘__alignof__
(expression)’
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The __alignof__  operator is a GCC extension to the C language whose documented
purpose is

  "to inquire about how an object is aligned, or the minimum alignment usually
required by a type."

While C11 provides the similar alignof operator that can be applied to types
(but not objects), prior versions of the C standard have no such feature.

Thus, the __alignof__  operator provides useful functionality not available in
any version of C.  Yet, when it's used with an object as an operand, GCC issues
the following warning in pedantic mode.  Not only is the warning unhelpful
(there is no other available feature that could be used instead), it's also
incorrect (ISO C says nothing about __alignof__).

As a data point, none of the three GCC-compatible compilers I've tested issues
a warning for this construct even in the strictest mode.

$ cat t.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic t.c
int a;
int i = __alignof__ (a);
t.c:2:9: warning: ISO C does not allow ‘__alignof__ (expression)’ [-Wpedantic]
 int i = __alignof__ (a);
 ^~~

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Severity|normal  |minor

[Bug target/69503] SIGFPE raised when mixing std::async with cilk

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-*-darwin
  Component|other   |target

--- Comment #1 from Andrew Pinski  ---
Works for me on the trunk (GCC 6) on x86_64 linux without a crash.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I don't think this is a bogus warning.  -pedantic turns off all of GCC
extensions including __attribute__ and asm support IIRC.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The manual says this about -Wpedantic:

  -Wpedantic does not cause warning messages for use of the alternate keywords
whose names begin and end with '__'.

GCC accepts without a warning many extensions in pedantic mode, including
__attribute__((aligned)), __const__, and __inline__, all of which have
corresponding similar features in C, as well as __typeof__ which doesn't:

$ cat z.c && /home/msebor/build/gcc-trunk-git/gcc/xgcc
-B/home/msebor/build/gcc-trunk-git/gcc -S -Wall -Wextra -Wpedantic -std=c11 z.c
__const__ int a __attribute__ ((aligned));
__typeof__ (a) b;
__inline__ void f (void) { }

[Bug sanitizer/69508] New: Undefined Behavior Sanitizer __ubsan_handle_load_invalid_value reports invalid load with wrong value

[chris.bainbridge at gmail dot com]

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

Bug ID: 69508
   Summary: Undefined Behavior Sanitizer
__ubsan_handle_load_invalid_value reports invalid load
with wrong value
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chris.bainbridge at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37482&action=edit
rx.o.objdump gcc-5.3.0

UBS on Linux kernel 4.5.0-rc1 gave an error:

[7.976500] UBSAN: Undefined behaviour in net/mac80211/rx.c:925:18
[7.976502] load of value 2 is not a valid value for type '_Bool'
[7.976505] CPU: 3 PID: 1134 Comm: kworker/u16:7 Not tainted 4.5.0-rc1+ #265
[7.976507] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843,
BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015
[7.976510] Workqueue: phy0 rt2x00usb_work_rxdone
[7.976513]  0004 880254a7ba50 8181d866
0007
[7.976517]  880254a7ba78 880254a7ba68 8188422d
8379b520
[7.976521]  880254a7bab8 81884747 0202
880248620032
[7.976525] Call Trace:
[7.976528]  [] dump_stack+0x45/0x5f
[7.976532]  [] ubsan_epilogue+0xd/0x40
[7.976537]  []
__ubsan_handle_load_invalid_value+0x67/0x70
[7.976541]  []
ieee80211_sta_reorder_release.isra.16+0x54d/0x730
[7.976545]  []
ieee80211_prepare_and_rx_handle+0xd04/0x1c00
[7.976549]  [] ? usb_hcd_map_urb_for_dma+0x65e/0x960
[7.976554]  [] __ieee80211_rx_handle_packet+0x1f3/0x750
[7.976557]  [] ieee80211_rx_napi+0x447/0x990
[7.976561]  [] rt2x00lib_rxdone+0x305/0xbd0
[7.976564]  [] ? dequeue_task_fair+0x64f/0x1de0
[7.976568]  [] ? sched_clock_cpu+0xe6/0x150
[7.976573]  [] rt2x00usb_work_rxdone+0x7c/0x140
[7.976577]  [] process_one_work+0x226/0x860
[7.976580]  [] worker_thread+0x5c/0x680
[7.976584]  [] ? process_one_work+0x860/0x860
[7.976588]  [] kthread+0xf6/0x150
[7.976591]  [] ? kthread_worker_fn+0x310/0x310
[7.976595]  [] ret_from_fork+0x3f/0x70
[7.976598]  [] ? kthread_worker_fn+0x310/0x310
[7.976601]


Patch to print the offending value:

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bc081850ac0e..3f85ac34 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -921,6 +921,7 @@ static void ieee80211_sta_reorder_release(struct
ieee80211_sub_if_data *sdata,

  set_release_timer:

+   printk("1 %d\n", tid_agg_rx->removed);
if (!tid_agg_rx->removed)
mod_timer(&tid_agg_rx->reorder_timer,
  tid_agg_rx->reorder_time[j] + 1 +
@@ -928,6 +929,7 @@ static void ieee80211_sta_reorder_release(struct
ieee80211_sub_if_data *sdata,
} else {
del_timer(&tid_agg_rx->reorder_timer);
}
+   printk("2 %d\n", tid_agg_rx->removed);
 }

 /*

UBS is reporting that bool tid_agg_rx->removed has value 2 but printk prints
value 0.

Tested with gcc-4.9.2, gcc-4.9.3, gcc-5.3.0

objdump -dr net/mac80211/rx.o attached
function ieee80211_sta_reorder_release.isra.16 is where the printk and
__ubsan_handle_load_invalid_value are called

If I move the printk call to a function call and pass in tid_agg_rx as an
argument and call that function in exactly the same place as the current
printk, then the invalid load error is *not* reported, even though the code
flow is identical.

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[townsend at astro dot wisc.edu]

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

--- Comment #3 from Rich Townsend  ---
Proposed patch appears to work in the real-world case I'm focused on. Thanks!

[Bug sanitizer/69508] Undefined Behavior Sanitizer __ubsan_handle_load_invalid_value reports invalid load with wrong value

[pinskia at gcc dot gnu.org]

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

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

[Bug target/69299] [6 Regression] -mavx performance degradation with r232088

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #3)
> Maybe we really need to have two types of memory
> constraints, ones which can be worst case always satisfied by reloading
> their address into an address register and another ones which can be worst
> case always satisfied by loading the memory into a temporary register (for
> loads) or storing it from a temporary register.
> 
> Or consider the constraint as CT_MEMORY only if the operand satisfies the
> constraint predicate and as CT_FIXED_FORM (or whatever is the default)
> otherwise?  Only normal CT_MEMORY, for Bm as long as it satisfies
> memory_operand, the exact address form doesn't really matters, but what
> matters is something inherent in the memory (and ISA flags).

I think it is a good idea.  We need memory constraint which prevents memory
address reloading.  So I've started to implement the new type of constraint.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-01-27
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.1.0, 6.0

--- Comment #3 from Martin Sebor  ---
This seems like a simple matter of a missed conditional in the parser.  The
following change suppresses the warning.  Let me add a test and post it for
review.

Index: gcc/c/c-parser.c
===
--- gcc/c/c-parser.c(revision 232841)
+++ gcc/c/c-parser.c(working copy)
@@ -7019,9 +7019,10 @@ c_parser_alignof_expression (c_parser *p
   mark_exp_read (expr.value);
   c_inhibit_evaluation_warnings--;
   in_alignof--;
-  pedwarn (start_loc,
-  OPT_Wpedantic, "ISO C does not allow %<%E (expression)%>",
-  alignof_spelling);
+  if (is_c11_alignof)
+   pedwarn (start_loc,
+OPT_Wpedantic, "ISO C does not allow %<%E (expression)%>",
+alignof_spelling);
   ret.value = c_alignof_expr (start_loc, expr.value);
   ret.original_code = ERROR_MARK;
   ret.original_type = NULL;

[Bug tree-optimization/69466] [6 Regression] ICE: Invalid PHI argument after vectorization (on -O2)

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #4 from Alexandre Oliva  ---
On it

[Bug c++/69509] New: infinite loop compiling a VLA in a recursive constexpr function

[msebor at gcc dot gnu.org]

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

Bug ID: 69509
   Summary: infinite loop compiling a VLA in a recursive constexpr
function
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Current GCC trunk (6.0) as well as 5.1.0 loops indefinitely compiling the
following quasi-legal C++ 11 code (loosely based on bug 69496).  Clang rejects
the code because it doesn't accept initialized VLAs.

The same code compiles successfully with -Dconstexpr=''.

$ (cat t.c && ulimit -t 10 && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc -S -Wall -Wextra -Wpedantic -std=c++14
-xc++ t.c)
constexpr int foo (int n)
{
int a [n] = { 0 };

int z = a [0] + (n ? foo (n - 1) : 0);

return z;
}

constexpr int i = foo (3);
t.c: In function ‘constexpr int foo(int)’:
t.c:3:13: warning: ISO C++ forbids variable length array ‘a’ [-Wvla]
 int a [n] = { 0 };
 ^
xgcc: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug rtl-optimization/69447] [5/6 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

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

Richard Henderson  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #8 from Richard Henderson  ---
Further archaeology suggests that PR 66424 is related,
and had an incomplete fix applied.

The fix for PR 66424 prevents an insn being moved if
it contains a subreg of a multi-word pseudo.  But the
same problem exists if one moves a complete multi-word
pseudo if any of its subregs have ever been accessed.

[Bug c/69507] bogus warning: ISO C does not allow ‘__alignof__ (expression)’

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Created attachment 37483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37483&action=edit
Proposed patch.

Attaching a proposed patch tested on x86_64-linux.  Since GCC is in stage 4
(regression fixes only) and this is no a regression it will probably have to
wait until after the 6.0 release.

[Bug rtl-optimization/69447] [5/6 Regression] wrong code with -O2 -fno-schedule-insns and mixed 8/16/32/64bit arithmetics @ armv7a

[rth at gcc dot gnu.org]

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

--- Comment #9 from Richard Henderson  ---
Created attachment 37484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37484&action=edit
proposed patch

Fixes the test case, in that it prevents the remat.

Starting overnight bootstraps for armv7hf, i686, and x86_64...

[Bug fortran/69484] [5/6 Regression] documentation issue: -Wtabs and -Wall

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug tree-optimization/69399] [5/6 Regression] wrong code with -O and int128

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|WAITING |NEW
   Target Milestone|--- |5.4

[Bug tree-optimization/57315] LTO and/or vectorizer performance regression on salsa20 core, 4.7->4.8

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Fixed so closing.

[Bug c++/69510] New: segfault in write_template_prefix while compiling C++ template code

[vapier at gcc dot gnu.org]

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

Bug ID: 69510
   Summary: segfault in write_template_prefix while compiling C++
template code
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vapier at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu

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

the attached test case (by Philippe Marti) crashes g++ starting with 4.9 (and
including 5.3).  4.8 and older work.


$ g++ -c test.ii -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/g++
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-5.3.0/work/gcc-5.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/include/g++-v5
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.3.0/python
--enable-languages=c,c++,java,go,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 5.3.0 p1.0, pie-0.6.5' --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=mx32,m32,m64
--disable-altivec --disable-fixed-point --with-abi=m64 --enable-targets=all
--enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts
--enable-lto --with-isl --disable-isl-version-check --enable-libsanitizer
Thread model: posix
gcc version 5.3.0 (Gentoo 5.3.0 p1.0, pie-0.6.5) 
COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'test.o' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1plus -fpreprocessed test.ii
-quiet -dumpbase test.ii -mtune=generic -march=x86-64 -auxbase-strip test.o
-version -fstack-protector-strong -o /tmp/ccxZdwTF.s
GNU C++ (Gentoo 5.3.0 p1.0, pie-0.6.5) version 5.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Gentoo 5.3.0 p1.0, pie-0.6.5) version 5.3.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version
3.1.3-p4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 542af32c761d4d0725ea4eab192ccd39

test.ii: In instantiation of 'void Test::func(typename TClass::Type)
[with TClass = A; int TID = 1; typename TClass::Type = double]':

test.ii:2:54: internal compiler error: Segmentation fault
  public: template  class TClass> void func(typename
TClass::Type x) {};
  ^
Please submit a full bug report,
with preprocessed source if appropriate.


here's the gdb output:
$ gdb --args g++ test.ii 
Reading symbols from /usr/bin/g++...(no debugging symbols found)...done.
(gdb) set follow-fork-mode child 
(gdb) r
Starting program: /usr/bin/g++ test.ii
process 4832 is executing new program:
/usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/x86_64-pc-linux-gnu-g++
[New process 4836]
process 4836 is executing new program:
/usr/libexec/gcc/x86_64-pc-linux-gnu/5.3.0/cc1plus

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 4836]
write_template_prefix (node=node@entry=0x765a6be0) at
.../gcc-5.3.0/gcc/cp/mangle.c:1163
1163.../gcc-5.3.0/gcc/cp/mangle.c: No such file or directory.
(gdb) bt
#0  write_template_prefix (node=node@entry=0x765a6be0) at
.../gcc-5.3.0/gcc/cp/mangle.c:1163
#1  0x006e6f0c in write_prefix (node=0x765acb28) at
.../gcc-5.3.0/gcc/cp/mangle.c:1078
#2  0x006e7171 in write_nested_name (decl=0x765a6c78) at
.../gcc-5.3.0/gcc/cp/mangle.c:1009
#3  0x006e37c9 in write_type (type=0x765acbd0) at
.../gcc-5.3.0/gcc/cp/mangle.c:2017
#4  0x006e5c72 in write_method_parms (parm_types=0x765a3a00,
method_p=, decl=) at
.../gcc-5.3.0/gcc/cp/mangle.c:2540
#5  0x006e5d8d in write_bare_function_type (type=0x765acd20,
include_return_type_p=0x1, decl=) at
.../gcc-5.3.0/gcc/cp/mangle.c:2482
#6  0x006e8acc in mangle_decl_string (decl=decl@entry=0x765ad510)
at .../gcc-5.3.0/gcc/cp/mangle.c:3449
#7  0x006e8c37 in get_mangled_id (decl=0x765ad510) at
.../gcc-5.3.0/gcc/c

[Bug c++/69510] segfault in write_template_prefix while compiling C++ template code

[vapier at gcc dot gnu.org]

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

Mike Frysinger  changed:

   What|Removed |Added

  Known to work||4.7.4, 4.8.5
Version|unknown |4.9.3
   Target Milestone|--- |4.9.4
  Known to fail||4.9.3, 5.1.0, 5.2.0, 5.3.0

[Bug tree-optimization/69336] Constant value not detected

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #10 from Dominik Vogt  ---
The new test fails on s390x; what should I do about it?
(see https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01359.html )

[Bug tree-optimization/69347] [6 regression] excessive compile time with -O2

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #17 from Jeffrey A. Law  ---
Per c#16.

[Bug c++/69510] segfault in write_template_prefix while compiling C++ template code

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||trippels at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Markus Trippelsdorf  ---
dup. Already fixed.

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

[Bug c++/67337] [4.9/5 Regression] Segmentation fault on a template class

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||vapier at gcc dot gnu.org

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

[Bug rtl-optimization/69482] Writing through pointers to volatile not always preserved

[wipedout at yandex dot ru]

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

--- Comment #4 from wipedout at yandex dot ru ---
Okay, suppose we have the following scenario. There's a third party library
with an encryption function like this:

void encrypt( void* data, void* key );

That function is compiled into as a static library and we cannot recompile it.
We know that the function copies the key onto the stack and fails to overwrite
it.

So we want to overwrite the stack after that function. Here's what we could do:


 void overwrite()
 {
  char array[SIZE];
  memset_s( array, SIZE );
 }

 void usefulFunction()
 {
 encrypt( something, key );
 overwrite();
 }

This would work the following way: first, `encrypt()` runs and leaves data on
the stack. Then `overwrite()` runs, allocates an array which very likely
overlaps with the area where `encrypt()` left the data and overwrites that
array.

This "array is not used" optimization heuristic equally applies to the array in
overwrite() and a later version of gcc may decide that no matter how the array
is allocated it's not used and therefore no need to overwrite it.

Yes, I know that the trick relies on undefined behavior in the first place.

[Bug target/60818] ICE in validate_condition_mode on powerpc-e500v2-linux-gnuspe

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 Target|powerpc-e500v2-linux-gnuspe |powerpc-e500v2-linux-gnuspe
   ||, powerpc-e300c3-linux-gnu
  Known to fail|4.9.0, 5.1.0, 5.2.0 |4.9.3, 5.3.0, 6.0

--- Comment #4 from Arseny Solokha  ---
The state of things is currently as follows:

1. Snippets from comment 0 and comment 1 cannot be reproduced anymore w/ gcc
5.3.0 and 6.0.0-alpha20160110.

2. Snippet from comment 3 can be further reduced to

unsigned int vz, tr, c, fr;

void
gi(void)
{
  if (vz < 1)
vz = ((fr < tr) >= (fr > tr));
}

and fails w/ 4.8.5, 4.9.3, 5.3.0 at -Os, -O2, -O3, and -Ofast.

3. The following snippet fails w/ 5.3.0 and 6.0.0-alpha20160110 at -O1, -O2,
-O3, -Ofast, and -Og:

unsigned int ou;

int
jv(void)
{
  unsigned int rg;
  return rg < ou;
}

[Bug lto/69408] LD crashes with LTO

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||ubizjak at gmail dot com

--- Comment #5 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> Waiting for a testcase.  See https://gcc.gnu.org/bugs.html

I *think* I have seen this problem recently on x86_64 Fedora 23 when testsuite
was run with RUNTESTFLAGS="--target_board=unix/-fno-use-linker-plugin"

I'll re-run the testsuite and report here.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rai...@emrich-ebersheim.de]

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

--- Comment #25 from Rainer Emrich  ---
I'm testing rev. 232815, proposed patch applied, on x86_64-w64-mingw32 atm.
Will take some time.

[Bug tree-optimization/69483] New: gcc ICE on x86_64-linux-gnu with "expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p"

[helloqirun at gmail dot com]

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

Bug ID: 69483
   Summary: gcc ICE on x86_64-linux-gnu with "expected class
'type', have 'exceptional' (error_mark) in
useless_type_conversion_p"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helloqirun at gmail dot com
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk on
x86_64-linux-gnu in both 32-bit and 64-bit modes. 

$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/home/absozero/trunk/root-gcc/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/home/absozero/trunk/root-gcc
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20160125 (experimental) [trunk revision 232792] (GCC)


$ gcc-trunk abc.c
abc.c:4:13: error: storage size of 'b' isn't known
 struct str1 b;
 ^

cc1: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:83
0xdd9de7 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/gcc/tree.c:9656
0x8cbe60 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/gcc/tree.h:3129
0x8cbe60 useless_type_conversion_p(tree_node*, tree_node*)
../../gcc/gcc/gimple-expr.c:83
0x8d2255 canonicalize_constructor_val(tree_node*, tree_node*)
../../gcc/gcc/gimple-fold.c:211
0x7807ca record_reference
../../gcc/gcc/cgraphbuild.c:54
0xdfcfd2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/gcc/tree.c:11498
0xdfd4b7 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../../gcc/gcc/tree.c:11575
0x781b04 record_references_in_initializer(tree_node*, bool)
../../gcc/gcc/cgraphbuild.c:404
0xe3cec7 varpool_node::analyze()
../../gcc/gcc/varpool.c:526
0x787e1a analyze_functions
../../gcc/gcc/cgraphunit.c:1129
0x788d98 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2535
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.





---
$ cat abc.c
struct str3 {
  struct str1 *a;
};
struct str1 b;
struct str3 c = {&b};

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at gcc dot gnu.org]

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

--- Comment #26 from Nick Clifton  ---
Hi Roger,

> I've tried the patch (applied to 232400 as trunk seems to have other
> problems on cygwin) and the build now completes successfully.

Including libstdc++-v3 ?

> Additionally, the test case no longer crashes.

Hooray.

Now all we need is for Rainer to confirm that the patch works for mingw32 and
we are good to go.

Oh actually - Roger - could you check one more thing for me please ?  Does the
patched compiler compile the test case in PR 68601 correctly ?

Cheers
  Nick

[Bug tree-optimization/69483] [6 Regression] gcc ICE on x86_64-linux-gnu with "expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|gcc ICE on x86_64-linux-gnu |[6 Regression] gcc ICE on
   |with "expected class|x86_64-linux-gnu with
   |'type', have 'exceptional'  |"expected class 'type',
   |(error_mark) in |have 'exceptional'
   |useless_type_conversion_p"  |(error_mark) in
   ||useless_type_conversion_p"
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r232622.

[Bug tree-optimization/69400] [5/6 Regression] wrong code with -O and int128

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue Jan 26 09:53:33 2016
New Revision: 232817

URL: https://gcc.gnu.org/viewcvs?rev=232817&root=gcc&view=rev
Log:
PR 69400: Invalid 128-bit modulus result

As described in the PR, wi::divmod_internal was sign- rather than
zero-extending a modulus result in cases where the result has fewer
HWIs than the precision and the upper bit of the upper HWI was set.

This patch tries to make things more robust by getting wi_pack
to handle the canonicalisation step itself.

Tested on x86_64-linux-gnu.  I added tests to the wide-int
plugin since that seemed more direct.

gcc/
PR tree-optimization/69400
* wide-int.cc (wi_pack): Take the precision as argument and
perform canonicalization here rather than in the callers.
Use the main loop to handle all full-width HWIs.  Add a
zero HWI if in_len isn't a full result.
(wi::divmod_internal): Update accordingly.
(wi::mul_internal): Likewise.  Simplify.

gcc/testsuite/
PR tree-optimization/69400
* gcc.dg/plugin/wide-int_plugin.c (test_wide_int_mod_trunc): New
function.
(plugin_init): Call it.
* gcc.dg/torture/pr69400.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69400.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/plugin/wide-int_plugin.c
trunk/gcc/wide-int.cc

[Bug tree-optimization/69400] [5 Regression] wrong code with -O and int128

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6 Regression] wrong code |[5 Regression] wrong code
   |with -O and int128  |with -O and int128

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug lto/69408] LD crashes with LTO

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to night_ghost from comment #4)
> I can attach script which GCC has been built, and ZIP of the project tree
> which cause crash.

Hi.

That would be beneficial!

[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #3 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Tue Jan 26 10:04:46 2016
New Revision: 232818

URL: https://gcc.gnu.org/viewcvs?rev=232818&root=gcc&view=rev
Log:
[PATCH] Do not set structural equality on polynomial types

gcc/ChangeLog:

PR target/67896
* config/aarch64/aarch64-builtins.c
(aarch64_init_simd_builtin_types): Do not set structural
equality to __Poly{8,16,64,128}_t types.

gcc/testsuite/ChangeLog:

PR target/67896
* gcc.target/aarch64/simd/pr67896.C: New.


Added:
trunk/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-builtins.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/69483] [6 Regression] gcc ICE on x86_64-linux-gnu with "expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 37472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37472&action=edit
gcc6-pr69483.patch

Untested fix.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #13 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #5)
> Already during the expansion TARGET_STV makes quite a big difference, won't
> just disabling the stv pass cause performance regression to -mno-stv?
There is a difference on how code is expanded but we didn't observe significant
code regressions because of it so far.

> Also, I'm surprised you are checking INCOMING_STACK_BOUNDARY, I'd have
> expected
> || ix86_preferred_stack_boundary >= 128
> instead.
I check INCOMING_STACK_BOUNDARY because that's what expand_stack_alignment
checks to determine if realignment and DRAP register are needed.

> 
> I had in mind either:
> 
> --- gcc/config/i386/i386.c.jj 2016-01-25 12:10:57.0 +0100
> +++ gcc/config/i386/i386.c2016-01-25 16:54:28.662713284 +0100
> @@ -5453,6 +5453,11 @@ ix86_option_override_internal (bool main
>  opts->x_target_flags |= MASK_VZEROUPPER;
>if (!(opts_set->x_target_flags & MASK_STV))
>  opts->x_target_flags |= MASK_STV;
> +  /* Disable STV if -mpreferred-stack-boundary={2,3} - the needed
> + stack realignment will be extra cost the pass doesn't take into
> + account and the pass does not ensure DRAP is created either.  */
> +  if (ix86_preferred_stack_boundary < 128)
> +opts->x_target_flags &= ~MASK_STV;
>if (!ix86_tune_features[X86_TUNE_AVX256_UNALIGNED_LOAD_OPTIMAL]
>&& !(opts_set->x_target_flags & MASK_AVX256_SPLIT_UNALIGNED_LOAD))
>  opts->x_target_flags |= MASK_AVX256_SPLIT_UNALIGNED_LOAD;
> 
> (i.e. force -mno-stv for -mpreferred-boundary={2,3}), but that will likely
> disable the pass altogether for the -miamcu (but your patch in most cases
> will too), not sure if that is a big deal or not).
IAMCU doesn't have SSE, thus it's not an issue.  But here we disable STV even
if we are going to align stack anyway (e.g. have vector code).

> Another alternative is if the STV pass changes anything and creates possible
> need for aligned vector spills, create drap rtx during that pass.

I like this option, but I wonder if it's safe to do that at STV pass. 
expand_stack_alignment calls fixup_tail_calls and invalidates some notes if
DRAP is allocated.  Can it be too late to do that in STV?

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

[ktkachov at gcc dot gnu.org]

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

--- Comment #13 from ktkachov at gcc dot gnu.org ---
We can look at the impact of enabling ree for arm for GCC 7 then.

[Bug fortran/69484] New: documentation issue: -Wtabs and -Wall

[janus at gcc dot gnu.org]

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

Bug ID: 69484
   Summary: documentation issue: -Wtabs and -Wall
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

There is an inconsistency in the documentation at
https://gcc.gnu.org/onlinedocs/gfortran/Error-and-Warning-Options.html.

The description of -Wall claims that it includes -Wno-tabs, while the
description of -Wtabs claims that -Wtabs is active for -Wall (and others).

One of the two must be wrong. From the behaviour of gfortran it seems that
-Wall does imply -Wtabs.

[Bug target/69442] [6 Regression] wrong code with -Og and 64bit modulo @ armv7a

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 26 11:12:03 2016
New Revision: 232819

URL: https://gcc.gnu.org/viewcvs?rev=232819&root=gcc&view=rev
Log:
PR target/69442
* combine.c (combine_instructions): For REG_EQUAL note with
SET_DEST being ZERO_EXTRACT, also temporarily set SET_DEST
to the underlying register.
* doc/rtl.texi (REG_EQUAL): Document the behavior of
REG_EQUAL/REG_EQUIV notes if SET_DEST is ZERO_EXTRACT.

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

Added:
trunk/gcc/testsuite/gcc.dg/pr69442.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c
trunk/gcc/doc/rtl.texi
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/69478] [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
  Known to work|4.8.2   |4.8.4
 Ever confirmed|0   |1
  Known to fail|4.9.2, 5.2.0|4.9.3, 5.3.0

[Bug fortran/69484] [5/6 Regression] documentation issue: -Wtabs and -Wall

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

Summary|documentation issue: -Wtabs |[5/6 Regression]
   |and -Wall   |documentation issue: -Wtabs
   ||and -Wall

--- Comment #1 from janus at gcc dot gnu.org ---
I guess this issue is related to the change of behaviour regarding -Wtabs from
4.9 to 5.

Also, the documentation bug is a regression: The documentation is correct in
4.9, but wrong for versions 5 and 6.

[Bug libstdc++/69478] [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Introduced by r204615 for PR 58982

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Have you tried H.J's patch?  If I understand it right, IMHO at least the
*mov_internal changes look desirable to me after the recent changes where
misaligned_operand matters even for pre-AVX, and the result could be that if
the stack can't be realigned and -mpreferred-stack-boundary is low, worst case
there will be unaligned loads/stores to the stack slots instead of aligned
ones.

[Bug fortran/69485] New: oddity with -Wtabs

[janus at gcc dot gnu.org]

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

Bug ID: 69485
   Summary: oddity with -Wtabs
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janus at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37473
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37473&action=edit
source files

The attachment contains two files: An almost empty source file and an include
file.

Compiling via

gfortran -Wtabs -c filter.f

gives:

f951: Warning: Nonconforming tab character in column 1 of line 3 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 5 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 7 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 8 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 9 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 10 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 11 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 13 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 20 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 21 [-Wtabs]
f951: Warning: Nonconforming tab character in column 2 of line 22 [-Wtabs]
f951: Warning: Nonconforming tab character in column 1 of line 25 [-Wtabs]
control.inc:20:13:

   real*4 wtcut
 1
Warning: Nonconforming tab character at (1) [-Wtabs]


So, the odd thing is that only for one of these tabs I am actually told that
it's in the include file, for all others that unfortunately does not happen.

Ideally the style of the last of these warnings should be used for the others
as well!

[Bug rtl-optimization/69482] Writing through pointers to volatile not always preserved

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 CC||rguenth at gcc dot gnu.org
Version|unknown |5.3.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  It might be a non-issue as RTL expansion assigns 'x' to a register,
thus we only omit zeroing the respective register.

'x' is assigned a register because 'x' is not volatile qualified and register
sets in RTL are not "volatile".

As said, this is a non-issue for secure memset in practice - secure deletion
has to make sure to clobber all CPU registers as well (as well as possibly
used stack space that registers with sensitive information could have been
spilled to).

[Bug target/69442] [6 Regression] wrong code with -Og and 64bit modulo @ armv7a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
Fixed.

[Bug libstdc++/69478] [4.9/5/6 Regression] std::copy/std::move broken with trivial move-only types

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|WAITING |NEW

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #15 from Richard Biener  ---
(In reply to Jeffrey A. Law from comment #14)
> Thanks.  This is definitely an issue with the changing version #s changing
> the ordering in which particular coalescing pairs are tried.
> 
> This is most likely coming from this (and related) code in
> tree-ssa-coalesce.c:
> 
> case GIMPLE_ASSIGN:
>   {
> tree lhs = gimple_assign_lhs (stmt);
> tree rhs1 = gimple_assign_rhs1 (stmt);
> if (gimple_assign_ssa_name_copy_p (stmt)
> && gimple_can_coalesce_p (lhs, rhs1))
>   {
> v1 = SSA_NAME_VERSION (lhs);
> v2 = SSA_NAME_VERSION (rhs1);
> cost = coalesce_cost_bb (bb);
> add_coalesce (cl, v1, v2, cost);
> bitmap_set_bit (used_in_copy, v1);
> bitmap_set_bit (used_in_copy, v2);
>   }
> 
> Note how the version #s are passed into add_coalesce.
> 
> Those are then used to order the coalesce pair for hashing in
> find_coalesce_pair as well as in the qsort function compare_pairs.  They
> could easily be used elsewhere.
> 
> So while we do pull pairs out in a priority order, once the priorities are
> the same, the order selected is based on the SSA_NAME_VERSION, which, due to
> SSA_NAME recycling is effectively random.  You can see this by looking at
> the Sorted Coalesce list in the dumps.The format is
> 
> (cost) obj1 <->obj2
> 
> If you compare the dumps you'll see that we have certain coalescing
> opportunities with the same cost, but which are ordered differently because
> of the SSA_NAME_VERSION differences.
> 
> The biggest obvious downside to coalescing  being dependent on
> SSA_NAME_VERSION is that a change in how names as returned to the name
> manager can affect code generation -- essentially causing code to improve or
> degrade in a random fashion.
> 
> One approach to fixing this problem might be to recompute the
> SSA_NAME_VERSION #s just prior to coalescing.
> 
> Essentially do a domwalk or some other walk of the IL reassigning version #s
> for the LHS operand.   This won't be 100% foolproof, but would probably be
> more stable than what we're doing now.  That may be possible in the gcc-6
> timeframe, I'm not really sure right now.

I think the easier solution is to preserve the order we created the coalesce
pairs by adding a "coalesce number" to sort against of the costs are equal.
coalesce_pair has three ints so on 64bit hosts there isn't any memory
wasted if adding another one given we go via glibc malloc for allocating
them (ugh).

Of course if that produces the desired order for the benchmark is another
question ;)  (it's really random before as well)

But comment #8 also still holds (keep the free ssa name list we allocate
from sorted to pack names dense).

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #15 from Ilya Enkovich  ---
(In reply to Jakub Jelinek from comment #14)
> Have you tried H.J's patch?  If I understand it right, IMHO at least the
> *mov_internal changes look desirable to me after the recent changes
> where misaligned_operand matters even for pre-AVX, and the result could be
> that if the stack can't be realigned and -mpreferred-stack-boundary is low,
> worst case there will be unaligned loads/stores to the stack slots instead
> of aligned ones.

I don't like it aligns stack if we vectorize in GIMPLE (even if preferred
alignment is lower) but don't align stack if we "vectorize" in rtl.  But I
don't see how to align stack properly at STV so I'm trying H.J.'s patch now.

[Bug ada/69476] accept size clause for 2-level discriminated record types with fixed sizes

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 CC||ebotcazou at gcc dot gnu.org
Summary|Fail to reconize types with |accept size clause for
   |an unrejected static size   |2-level discriminated
   |attribute as compile time   |record types with fixed
   |known size type |sizes
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Eric Botcazou  ---
The measure used to evaluate the minimality of the testcase is far from being
trivial because the following testcase trounces it if a simple character count
is used:

package P is

   type Rec1 (D : Boolean) is record
  B : Boolean; 
   end record;

   type Rec2 (D : Boolean) is record
  R : Rec1 (D);
   end record;
   for Rec2'Size use 24;

end P;

p.ads:10:04: size clause not allowed for variable length type

This has always been rejected historically by GNAT.  The clause is confirming
so this ought to be accepted.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
But it is for a relatively uncommon case (-mpreferred-stack-boundary lower than
default) and furthermore, you need to have something spilled to trigger it. 
Hopefully the most commonly used regs in loops will not be spilled...

[Bug tree-optimization/69452] [6 Regression] gcc ICE at -O3 on x86_64-linux-gnu in with verify_ssa failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69452] [6 Regression] gcc ICE at -O3 on x86_64-linux-gnu in with verify_ssa failed

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Jan 26 11:51:01 2016
New Revision: 232820

URL: https://gcc.gnu.org/viewcvs?rev=232820&root=gcc&view=rev
Log:
2016-01-26  Richard Biener  

PR tree-optimization/69452
* tree-ssa-loop-im.c (move_computations_dom_walker): Remove.
(move_computations_dom_walker::before_dom_children): Rename
to ...
(move_computations_worker): This.
(move_computations): Perform an RPO rather than a DOM walk.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr69452.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c

[Bug tree-optimization/69467] [6 Regression] Pattern X * C1 CMP 0 to X CMP 0 causes performance drop on 32-bit x86.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/69467] [6 Regression] Pattern X * C1 CMP 0 to X CMP 0 causes performance drop on 32-bit x86.

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Jan 26 12:05:22 2016
New Revision: 232821

URL: https://gcc.gnu.org/viewcvs?rev=232821&root=gcc&view=rev
Log:
2016-01-26  Richard Biener  

PR middle-end/69467
* match.pd: Guard X * CST CMP 0 pattern with single_use.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/match.pd

[Bug target/69471] "-march=native" unintentionally breaks further -march/-mtune flags

[wavexx at thregr dot org]

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

--- Comment #4 from wavexx at thregr dot org ---
Since I couldn't find documentation for it either, doesn't
-march=haswell by itself imply all associated ISA features?

If so, why -march=native expands to all individual features explicitly?

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

[Bug libstdc++/69486] New: Strange behaviour of bitset and c++11

[boris at dolgov dot name]

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

Bug ID: 69486
   Summary: Strange behaviour of bitset and c++11
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boris at dolgov dot name
  Target Milestone: ---

Hello!

When I try to compile the following program

#include 
std::bitset<2147483648> b;
int main() {}

cc1plus tries to eat all available memory and hangs.

Compilation command is g++ -o test test.cpp -std=c++11

When I use -std=c++98, everything works fine.

[Bug fortran/69268] [5 Regression] Sourced allocation calls function twice

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from vehre at gcc dot gnu.org ---
Patch proposed in:

https://gcc.gnu.org/ml/fortran/2016-01/msg00080.html

Awaiting approval/comments.

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener  ---
Created attachment 37474
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37474&action=edit
patch for SSA name management

This patch changes SSA name freelist management to keep the freelist sorted
and at flush_ssaname_freelist shrink num_ssa_names as much as possible.

The goal is to make used SSA names as dense as possible.

Does this patch fix the Coremark regression by chance?  (I'll note that a
proper fix would change the important coalesce cost so it is carried out
regardless of SSA name order).

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 37475
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37475&action=edit
gcc6-pr68662.patch

So what about this untested patch?  ASM_GENERATE_INTERNAL_LABEL doesn't look to
be too expensive to do unconditionally once, and for GC sanity it needs to go
through ggc_strdup anyway (it is invalid to refer to non-GC allocated strings
in GTY const char * fields that are not skipped by GC).

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

--- Comment #6 from Ilya Enkovich  ---
(In reply to amker from comment #5)
> Not sure if stage4 is a good time for a new hook either.
> 
> Any ideas?

We can try to improve i386 address recognition to ignore operands order.  With
this patch:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 34b57a4..b13d3f6 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -14111,8 +14111,16 @@ ix86_decompose_address (rtx addr, struct ix86_address
*out)
{
  if (n >= 4)
return 0;
- addends[n++] = XEXP (op, 1);
- op = XEXP (op, 0);
+ if (GET_CODE (XEXP (op, 1)) == PLUS)
+   {
+ addends[n++] = XEXP (op, 0);
+ op = XEXP (op, 1);
+   }
+ else
+   {
+ addends[n++] = XEXP (op, 1);
+ op = XEXP (op, 0);
+   }
}
   while (GET_CODE (op) == PLUS);
   if (n >= 4)

I get following ASM:

.L5:
movlind@GOTOFF(%ebx,%esi,4), %eax
movl12(%esp), %edi
movl%ebp, (%edi,%eax,4)

[Bug target/68986] [5/6 Regression] internal compiler error: Segmentation fault

[hjl at gcc dot gnu.org]

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

--- Comment #16 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue Jan 26 12:51:07 2016
New Revision: 232825

URL: https://gcc.gnu.org/viewcvs?rev=232825&root=gcc&view=rev
Log:
Update stack alignment in ix86_update_stack_boundary

Stack alignment adjustment for __tls_get_addr should be done in
ix86_update_stack_boundary, not ix86_compute_frame_layout.  Also
there is no need to over-align stack for __tls_get_addr and function
with __tls_get_addr call isn't a leaf function.

gcc/

PR target/68986
* config/i386/i386.c (ix86_compute_frame_layout): Move stack
alignment adjustment to ...
(ix86_update_stack_boundary): Here.  Don't over-align stack for
__tls_get_addr.
(ix86_finalize_stack_realign_flags): Use stack_alignment_needed
if __tls_get_addr is called.

gcc/testsuite/

PR target/68986
* gcc.target/i386/pr68986-1.c: New test.
* gcc.target/i386/pr68986-2.c: Likewise.
* gcc.target/i386/pr68986-3.c: Likewise.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr68986-1.c
trunk/gcc/testsuite/gcc.target/i386/pr68986-2.c
trunk/gcc/testsuite/gcc.target/i386/pr68986-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/69482] Writing through pointers to volatile not always preserved

[wipedout at yandex dot ru]

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

wipedout at yandex dot ru changed:

   What|Removed |Added

 CC||wipedout at yandex dot ru

--- Comment #2 from wipedout at yandex dot ru ---
I also found that this code

  int x[4];
  memset_s(x, 6);

also emits no writes. Is this because of undefined behavior or is it for any
other reason?

[Bug target/68986] [5 Regression] internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[5/6 Regression] internal   |[5 Regression] internal
   |compiler error: |compiler error:
   |Segmentation fault  |Segmentation fault

--- Comment #17 from H.J. Lu  ---
Fixed on trunk so far.

[Bug lto/69254] [6 Regression] ICE in streamer_get_builtin_tree when using -fsanitize=shift on the compile side only

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 26 13:01:44 2016
New Revision: 232826

URL: https://gcc.gnu.org/viewcvs?rev=232826&root=gcc&view=rev
Log:
PR lto/69254
* opts.h (parse_sanitizer_options): New prototype.
* opts.c (sanitizer_opts): New array.
(parse_sanitizer_options): New function.
(common_handle_option): Use parse_sanitizer_options.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/opts.c
trunk/gcc/opts.h

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #15)
> (In reply to Jakub Jelinek from comment #14)
> > Have you tried H.J's patch?  If I understand it right, IMHO at least the
> > *mov_internal changes look desirable to me after the recent changes
> > where misaligned_operand matters even for pre-AVX, and the result could be
> > that if the stack can't be realigned and -mpreferred-stack-boundary is low,
> > worst case there will be unaligned loads/stores to the stack slots instead
> > of aligned ones.
> 
> I don't like it aligns stack if we vectorize in GIMPLE (even if preferred
> alignment is lower) but don't align stack if we "vectorize" in rtl.  But I
> don't see how to align stack properly at STV so I'm trying H.J.'s patch now.

Do you have a testcase to show that you need to realign stack for STV?

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #18 from H.J. Lu  ---
(In reply to H.J. Lu from comment #17)
> 
> Do you have a testcase to show that you need to realign stack for STV?

You can keep track alignment requirement in STV and replace

 /* Conversion means we may have 128bit register spills/fills
 which require aligned stack.  */
  if (converted_insns)
{
  if (crtl->stack_alignment_needed < 128)
crtl->stack_alignment_needed = 128;
  if (crtl->stack_alignment_estimated < 128)
crtl->stack_alignment_estimated = 128;
}

with an assert.

[Bug fortran/62536] ICE (segfault) for invalid END BLOCK statement

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #19 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #17)
> Do you have a testcase to show that you need to realign stack for STV?

Reproducer for this tracker is such test, right?

[Bug rtl-optimization/44281] [4.9/5/6 Regression] Global Register variable pessimisation

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #22 from Bernd Schmidt  ---
Vlad, I'll investigate for a bit - I'll leave you assigned for now though.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #20 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #19)
> (In reply to H.J. Lu from comment #17)
> > Do you have a testcase to show that you need to realign stack for STV?
> 
> Reproducer for this tracker is such test, right?

Not really.  We only ask for 128-bit aligned stack only if we have 128-bit
aligned variable on stack.  Please do

# git grep stack_alignment_needed

to see how stack alignment is tracked.

[Bug c++/69487] New: Unexpected VLA initialization of char[] from ""

[rogero at howzatt dot demon.co.uk]

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

Bug ID: 69487
   Summary: Unexpected VLA initialization of char[] from ""
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rogero at howzatt dot demon.co.uk
  Target Milestone: ---

The initialization of a VLA char array from a string literal in C++ mode is
surprising: the code appears to copy a string literal starting with the NUL
character into the dynamically-sized buffer.

This is different from the (standard C/C++) treatment of the same syntax for a
fixed-size array.

--- vla-init.cxx ---
#include 
#include 
#include 
#include 

void testfixed()
{
const int size = 6;
char buffer[size] = "";
for (int i = 0; i != size; ++i)
{
printf("Fixed: buffer[%i] = %2.2x\n", i, buffer[i] & 0xff);
}
}

int size = 6;

void testvariable()
{
char buffer[size] = "";
for (int i = 0; i != size; ++i)
{
printf("Variable: buffer[%i] = %2.2x\n", i, buffer[i] & 0xff);
}
}


int main()
{
testfixed();
testvariable();
}
--- ends ---

Sample output:

Fixed: buffer[0] = 00
Fixed: buffer[1] = 00
Fixed: buffer[2] = 00
Fixed: buffer[3] = 00
Fixed: buffer[4] = 00
Fixed: buffer[5] = 00
Variable: buffer[0] =00
Variable: buffer[1] =00
Variable: buffer[2] =00
Variable: buffer[3] =00
Variable: buffer[4] =01
Variable: buffer[5] =1b

[Bug target/60410] [4.9/5/6 Regression] -fshort-double ICEs x86_64

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

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

--- Comment #16 from Bernd Schmidt  ---
Will post patch to remove -fshort-double.

[Bug tree-optimization/45216] Rotate expressions not recognized at tree level

[bernds at gcc dot gnu.org]

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

--- Comment #12 from Bernd Schmidt  ---
It looks like a patch was committed - can this be closed?

[Bug fortran/69485] oddity with -Wtabs

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #1 from Manuel López-Ibáñez  ---
(In reply to janus from comment #0)
> So, the odd thing is that only for one of these tabs I am actually told that
> it's in the include file, for all others that unfortunately does not happen.
> 
> Ideally the style of the last of these warnings should be used for the
> others as well!

To do that, this

gfc_warning_now (OPT_Wtabs,
   "Nonconforming tab character in column %d "
   "of line %d", i+1, linenum);

has to be replaced by this

gfc_warning_now (OPT_Wtabs, "Nonconforming tab character at %C");

or this

gfc_warning_now (OPT_Wtabs, "Nonconforming tab character at %L", where);

or

gfc_warning_now_at (location, OPT_Wtabs, "Nonconforming tab character at (1)");

Of course, the tricky part is how to set-up things such that one of those calls
will work.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #21 from H.J. Lu  ---
(In reply to H.J. Lu from comment #20)
> (In reply to Ilya Enkovich from comment #19)
> > (In reply to H.J. Lu from comment #17)
> > > Do you have a testcase to show that you need to realign stack for STV?
> > 
> > Reproducer for this tracker is such test, right?
> 
> Not really.  We only ask for 128-bit aligned stack only if we have 128-bit
> aligned variable on stack.

In another word, STV needs 128-bit aligned stack only when it generates
12-bit vector instructions.

[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Does this affect other branches as well?

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[rai...@emrich-ebersheim.de]

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

--- Comment #27 from Rainer Emrich  ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am 26.01.2016 um 10:30 schrieb nickc at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66655
> 
> --- Comment #26 from Nick Clifton  --- Hi
> Roger,
> 
>> I've tried the patch (applied to 232400 as trunk seems to have
>> other problems on cygwin) and the build now completes
>> successfully.
> 
> Including libstdc++-v3 ?
I did a full bootstrap including all working languages for
x86_64-w64-mingw32 and a full testsuite run. You may find the results
at gcc-testresults:
https://gcc.gnu.org/ml/gcc-testresults/2016-01/msg02541.html

> 
>> Additionally, the test case no longer crashes.
The test case does and did PASS.

> 
> Hooray.
> 
> Now all we need is for Rainer to confirm that the patch works for
> mingw32 and we are good to go.

Yeah, we good to go, congratulations, thank you.

Cheers

Rainer

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWp3V1AAoJEB3HOsWs+KJb1KkH/ApsmUJNHLIRIsdA9ayLgW2J
qoIFobCZSJWNzEPMv/a92zhC/9JJqh7HqkrCdb46Dmlm3FGZjIuhzfyreeI+xyNj
PNuXJoXV2US7s5ywhE2DbiOmsEkboe/vYBTUvsA7179YmZdBm3718tJU0U/IBeim
AB3rmtHIs0F8Ousho8kfwiF8fGY4KA0pF9i7PT1gyXpFyNTbljXom8nUhP/gZDJU
2V6/GPpu0kuP/0KLydBSDGUZYuujs/HZ7BMBfJRmpWyy4YDcSFikaroTSr3XXjad
oBZySKt/DuuRvnEhrOll4xVJTg6bfQhNhf0hS3L/BRG/IdhELrJvnpT/8WjtFL0=
=pSyU
-END PGP SIGNATURE-

[Bug tree-optimization/45216] Rotate expressions not recognized at tree level

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
.

[Bug tree-optimization/68654] [6 Regression] CoreMark Pro performance degradation

[afomin.mailbox at gmail dot com]

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

--- Comment #17 from Alexander Fomin  ---
Unfortunately, it doesn't. Moreover, it causes another perf loss (about 1.2%).

[Bug rtl-optimization/69052] [6 Regression] Performance regression after r229402.

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
(In reply to Ilya Enkovich from comment #6)
> (In reply to amker from comment #5)
> > Not sure if stage4 is a good time for a new hook either.
> > 
> > Any ideas?
> 
> We can try to improve i386 address recognition to ignore operands order. 
> With this patch:
> 
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 34b57a4..b13d3f6 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -14111,8 +14111,16 @@ ix86_decompose_address (rtx addr, struct
> ix86_address *out)
> {
>   if (n >= 4)
> return 0;
> - addends[n++] = XEXP (op, 1);
> - op = XEXP (op, 0);
> + if (GET_CODE (XEXP (op, 1)) == PLUS)
> +   {
> + addends[n++] = XEXP (op, 0);
> + op = XEXP (op, 1);
> +   }
> + else
> +   {
> + addends[n++] = XEXP (op, 1);
> + op = XEXP (op, 0);
> +   }
> }
>while (GET_CODE (op) == PLUS);
>if (n >= 4)
> 
> I get following ASM:
> 
> .L5:
> movlind@GOTOFF(%ebx,%esi,4), %eax
> movl12(%esp), %edi
> movl%ebp, (%edi,%eax,4)

According to discussion at https://gcc.gnu.org/ml/gcc/2016-01/msg00190.html,
hook is probably not wanted in this case.
Bernd gave another proposal by moving combine before loop transforms is also
interesting, but it can be for GCC6.
So a backend fix would be nice.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #22 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #21)
> In another word, STV needs 128-bit aligned stack only when it generates
> 12-bit vector instructions.

STV never generates such instructions.  But RA may spill SSE registers and
aligned moves are used for that.  I actually expected RA to fix-up alignment
requirements or even use DI spills/fills (since we never use full register for
STV) but it doesn't happen.

[Bug libstdc++/65434] Memory leak in pool constructor

[emil.styrke at gmail dot com]

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

Emil Styrke  changed:

   What|Removed |Added

 CC||emil.styrke at gmail dot com

--- Comment #4 from Emil Styrke  ---
I just discovered that this will become a real leak if dlopen/dlclose:ing a
library that has been statically linked to libstdc++.  Each time the library is
opened a new pool object is created, and after dlclose it will not have any
references left. Valgrind shows this (after looping the dlopen/dlsym/dlclose
part a few times):

==3679== 3,707,904 bytes in 51 blocks are definitely lost in loss record 106 of
106
==3679==at 0x4C2BBCF: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3679==by 0x77335EF: _GLOBAL__sub_I_eh_alloc.cc (in
[...]/libmock_di_plugin.so)
==3679==by 0x40105B9: call_init.part.0 (dl-init.c:72)
==3679==by 0x40106CA: call_init (dl-init.c:30)
==3679==by 0x40106CA: _dl_init (dl-init.c:120)
==3679==by 0x4015586: dl_open_worker (dl-open.c:579)
==3679==by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==by 0x40149A2: _dl_open (dl-open.c:663)
==3679==by 0x6B94FC8: dlopen_doit (dlopen.c:66)
==3679==by 0x4010463: _dl_catch_error (dl-error.c:187)
==3679==by 0x6B9562C: _dlerror_run (dlerror.c:163)
==3679==by 0x6B95060: dlopen@@GLIBC_2.2.5 (dlopen.c:87)
==3679==by 0x4F303E6: load_library (dipluginhandlerimpl.cpp:60)

I'm not sure if anything could be done about this, but it might be prudent to
add a warning to the documentation for -lstatic-libstdc++ explaining this.

[Bug target/68662] [6 regression] FAIL: gcc.dg/lto/20090210 c_lto_20090210_0.o-c_lto_20090210_1.o link, -O2 -flto -flto-partition=none -fuse-linker-plugin -fno-fat-lto-objects

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
Unconditionally generating toc_label_name is okay with me, but I thought that
Alan commented it was not sufficient in Comment #2.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[hjl.tools at gmail dot com]

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

--- Comment #23 from H.J. Lu  ---
(In reply to Ilya Enkovich from comment #22)
> (In reply to H.J. Lu from comment #21)
> > In another word, STV needs 128-bit aligned stack only when it generates
> > 12-bit vector instructions.
> 
> STV never generates such instructions.  But RA may spill SSE registers and
> aligned moves are used for that.  I actually expected RA to fix-up alignment
> requirements or even use DI spills/fills (since we never use full register
> for STV) but it doesn't happen.

RA should be OK.  We have addressed all RA issues on Linux when we
implemented stack realignment.  RA should only spill/fill the part
of registers which is used.

[Bug c++/69487] Unexpected VLA initialization of char[] from ""

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-01-26
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
The dumped trees show a memcpy from "" with the length as the length of the
array:

  __builtin_memcpy (buffer.1_23, "", _15);

That should presumably use strnlen("", _15 - 1) or just be consistent with the
C front-end and reject it:

vla.c:20:5: error: variable-sized object may not be initialized

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

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

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

--- Comment #19 from Chen Gang  ---
I build linux kernel with allyesconfig under x86_64 for linux-next tree
20160122. I can find some related cases for BUG28901 (but they are not quite
much), one case is below:

  CC  drivers/acpi/sbshc.o
In file included from drivers/acpi/sbshc.c:17:0:
drivers/acpi/sbshc.h:17:17: warning: ‘SMBUS_PEC’ defined but not used
[-Wunused-const-variable]
 static const u8 SMBUS_PEC = 0x80;
 ^

For me, I dislike -Wno-unused-const-variable option, the reason is "when C
programmers use static const int variable, in most cases, they want to use them
instead of #define".

So for me, -Wunused-variable need skip static const int variable warning. If
anyone wants to warn about it, they can add additional option (e.g.
-Wunused-const-int-variable) to let C compiler report warning for it.

Thanks.

[Bug middle-end/69454] [6 Regression] ix86_expand_prologue internal compiler error: Segmentation fault

[ienkovich at gcc dot gnu.org]

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

--- Comment #24 from Ilya Enkovich  ---
(In reply to H.J. Lu from comment #23)
> (In reply to Ilya Enkovich from comment #22)
> > (In reply to H.J. Lu from comment #21)
> > > In another word, STV needs 128-bit aligned stack only when it generates
> > > 12-bit vector instructions.
> > 
> > STV never generates such instructions.  But RA may spill SSE registers and
> > aligned moves are used for that.  I actually expected RA to fix-up alignment
> > requirements or even use DI spills/fills (since we never use full register
> > for STV) but it doesn't happen.
> 
> RA should be OK.  We have addressed all RA issues on Linux when we
> implemented stack realignment.  RA should only spill/fill the part
> of registers which is used.

Well, I'll try to just remove alignment code from STV and see what happens.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at gcc dot gnu.org]

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

--- Comment #28 from Nick Clifton  ---
Author: nickc
Date: Tue Jan 26 14:02:11 2016
New Revision: 232828

URL: https://gcc.gnu.org/viewcvs?rev=232828&root=gcc&view=rev
Log:
PR target/66655
* config/i386/winnt.c (i386_pe_binds_local_p): If a function has
been marked as DECL_ONE_ONLY but we do not the means to make it
so, then do not allow it to bind locally.

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

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

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

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

--- Comment #20 from Chen Gang  ---
(In reply to Chen Gang from comment #19)
> I build linux kernel with allyesconfig under x86_64 for linux-next tree
> 20160122. I can find some related cases for BUG28901 (but they are not quite
> much), one case is below:
> 
>   CC  drivers/acpi/sbshc.o
> In file included from drivers/acpi/sbshc.c:17:0:
> drivers/acpi/sbshc.h:17:17: warning: ‘SMBUS_PEC’ defined but not used
> [-Wunused-const-variable]
>  static const u8 SMBUS_PEC = 0x80;
>  ^

Oh, sorry, this case is not suitable, it is -Wunused-const-variable.


But my opinion still like what I said in comment #19.

Thanks.

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[nickc at gcc dot gnu.org]

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

Nick Clifton  changed:

   What|Removed |Added

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

--- Comment #29 from Nick Clifton  ---
New patch applied.  This time it works, and no-one will have to be nailed to
anything...

[Bug libstdc++/69486] Strange behaviour of bitset and c++11

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-01-26
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I can't reproduce this, please provide the missing information you were asked
to include: https://gcc.gnu.org/bugs/

[Bug target/66655] [5/6 Regression] miscompilation due to ipa-ra on MinGW

[amonakov at gcc dot gnu.org]

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

--- Comment #30 from Alexander Monakov  ---
Nick, can you please post the patch to gcc-patches too, to avoid confusing
future people who wouldn't be able to find the explanation of the patch in the
archives?

(did you get approval for this patch offline?)