[Bug testsuite/67959] New: "width of 'code' exceeds its type" error in ssa-thread-13

[thopre01 at gcc dot gnu.org]

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

Bug ID: 67959
   Summary: "width of 'code' exceeds its type" error in
ssa-thread-13
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
CC: law at redhat dot com
  Target Milestone: ---

By declaring the field "code" in struct rtx_def

ssa-thread-13 assumes that enum rtx_code is 16-bit or more in size when
declaring the field "code" in struct rtx_def. This can only be assumed if
passing -fno-short-enums when compiling since targets are free to default to
short enum (ARM does for AAPCS based API, see arm_default_short_enums in
config/arm/arm.c).

Because of that the test is currently failing on ARM.

[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Confirmed and the problem is in the front end side.

Yes, if I remove 'parameter' in the definition of 'string', I get the correct
KIND for the section.

> The bug is still present in gfortran 5.2.0. It makes it impossible
> to modify a substring of a unicode string; it has to be treated as a whole.

Still on trunk (6.0)!-(usual answer: "what did you do to fix the PR?").

[Bug fortran/67938] ICE on using assumed rank character with some intrinsics

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #2 from Gerhard Steinmetz  
---
As meanwhile noticed, example z1.f90 from comment #1 overlaps with PR66833.
Examples z2.f90 (comment #0) and z1s.f90 are describing additional effects.

[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references

[alexandros.syrakos at outlook dot com]

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

Alexandros Syrakos  changed:

   What|Removed |Added

 CC||alexandros.syrakos@outlook.
   ||com

--- Comment #2 from Alexandros Syrakos  
---
The bug is still present in gfortran 5.2.0. It makes it impossible to modify a
substring of a unicode string; it has to be treated as a whole.

[Bug target/67946] Function multiversioning ICE

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
You should compile this with -mavx, otherwise x, y and z global variables get
expanded in BLKmode. So, we get:

(gdb) p code
$1 = PLUS_EXPR
(gdb) p op0
$2 = (rtx) 0x2aaab05a4918
(gdb) p debug_rtx (op0)
(mem/c:BLK (symbol_ref:DI ("z") [flags 0x2] ) [1 z+0
S32 A256])
$3 = void
(gdb) p debug_rtx (op1)
(mem/c:BLK (symbol_ref:DI ("y") [flags 0x2] ) [1 y+0
S32 A256])

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0

--- Comment #2 from Dominique d'Humieres  ---
On x86_64-apple-darwin14, the tests mostly hang after the warning from 4.8 up
to trunk (6.0).

[Bug tree-optimization/67945] Testsuite failures starting with revision 228616

[afomin.mailbox at gmail dot com]

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

Alexander Fomin  changed:

   What|Removed |Added

 CC||afomin.mailbox at gmail dot com

--- Comment #2 from Alexander Fomin  ---
At least x86-64 also regressed ont SPEC2006 410.bwaves because of the same
folding problem.

[Bug debug/63135] [4.9 regression] Infinite loop in var-tracking

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

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

--- Comment #5 from Maxim Kuvyrkov  ---
This is likely a DUP of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61033 . 
Assigning to myself.

[Bug fortran/67938] ICE on using assumed rank character with some intrinsics

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0

--- Comment #3 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). The code compiles and executes if
'character' is replaced with 'integer' or 'real'. Also related to pr67894.

[Bug lto/67923] [6 Regression] ICEs in the gfortran test suite with -flto after r228680

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
The ICEs appeared after an incremental update, but disappeared after a clean
bootstrap (missing dependencies?). Sorry for the noise, closing as INVALID.

[Bug target/67946] Function multiversioning ICE

[evstupac at gmail dot com]

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

--- Comment #2 from Stupachenko Evgeny  ---
I see, but shouldn't compiler generate en error on this instead of ICE?

[Bug target/67366] Poor assembly generation for unaligned memory accesses on ARM v6 & v7 cpus

[ramana at gcc dot gnu.org]

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

--- Comment #17 from Ramana Radhakrishnan  ---
(In reply to Fredrik Hederstierna from comment #16)
> Could this fix also possibly improve:
> Bug 67507 - "Code size increase with -Os from GCC 4.8.x to GCC 4.9.x for ARM
> thumb1", which also seems related to alignment on ARM targets?
> Thanks, Fredrik

No I don't think so ...

[Bug tree-optimization/67920] [6 Regression] wrong code with -O3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #7 from Marek Polacek  ---
This should be the same as PR67947 which has a testcase.

[Bug tree-optimization/67916] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r228599 as well.

[Bug other/62279] Demangler crash

[stanislav.angelovic at kistler dot com]

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

Stanislav Angelovic  changed:

   What|Removed |Added

 CC||stanislav.angelovic@kistler
   ||.com

--- Comment #3 from Stanislav Angelovic  ---
GDB 7.7.1 demangler crashes upon this symbol in our binary:

_ZSt7forwardIKSaINSt6thread5_ImplISt12_Bind_simpleIFZN6WIM_DL5Utils9AsyncTaskC4IMNS3_8Hardware12FpgaWatchdogEKFvvEIPS8_EEEibOT_DpOT0_EUlvE_vEESD_RNSt16remove_referenceISC_E4typeE

We have tried the patch at
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html , but to no avail.

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[thopre01 at gcc dot gnu.org]

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

--- Comment #4 from Thomas Preud'homme  ---
(In reply to Richard Biener from comment #3)
> Was this maybe fixed by
> 
> 2015-10-13  Richard Sandiford  
> 
> * real.h (real_isinteger): Declare.
> * real.c (real_isinteger): New function.
> * match.pd: Simplify pow(|x|,y) and pow(-x,y) to pow(x,y)
> if y is an even integer.
> 
> ?

It does for builtins-10.c on arm-none-eabi at least. Thanks Richard S for the
quick fix.

[Bug tree-optimization/67949] New: Regression in GCC-6.0.0's optimizer

[ishiura-compiler at ml dot kwansei.ac.jp]

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

Bug ID: 67949
   Summary: Regression in GCC-6.0.0's optimizer
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ishiura-compiler at ml dot kwansei.ac.jp
  Target Milestone: ---

We compiled a program (A.c) by GCC-5.1.0 and GCC-6.0.0 with -O3 option.
GCC-5.1.0 performed better optimization than GCC-6.0.0.

(A.c)
#include 
int x110 = 0;
int main (void)
{
volatile int x129 = 1;
int t0 = 1;

t0 = (x129==1)<=(2U^(-(1-x110<<2)));

if (t0 == 1) { } 
else { __builtin_abort(); }

return 0;
}

+-+-+
|gcc-5.1.0.s (gcc-5.1.0 A.c -O3 -S)   |   gcc-6.0.0.s (gcc-6.0.0 A.c -O3
-S)|
+-+-+
|.globl  main |.globl  main
|
|.type   main, @function  |.type   main, @function 
|
|main:|main:   
|
|.LFB23:  |.LFB11: 
|
|.cfi_startproc   |.cfi_startproc  
|
|movl$1, -4(%rsp) |subq$24, %rsp   
|
|movl-4(%rsp), %eax   |.cfi_def_cfa_offset 32  
|
| |xorl%edx, %edx  
|
| |movl$1, 12(%rsp)
|
| |movl12(%rsp), %eax  
|
| |cmpl$1, %eax
|
| |movl$1, %eax
|
| |sete%dl 
|
| |sublx110(%rip), %eax
|
| |sall$2, %eax
|
| |negl%eax
|
| |xorl$2, %eax
|
| |cmpl%eax, %edx  
|
| |ja  .L5 
|
|xorl%eax, %eax   |xorl%eax, %eax  
|
| |addq$24, %rsp   
|
| |.cfi_remember_state 
|
| |.cfi_def_cfa_offset 8   
|
|ret  |ret 
|
| |.L5:
|
| |.cfi_restore_state  
|
| |callabort   
|
|.cfi_endproc |.cfi_endproc
|
|.LFE23:  |.LFE11: 
|
|.size   main, .-main |.size   main, .-main
|
|.section.text.unlikely   |.section   
.text.unlikely   |
|.LCOLDE0:|.LCOLDE0:   
|
|.size   x110, 4  |.size   x110, 4 
|
|x110:|x110:   
|
|.zero   4|.zero   4   
|
+-+-+

Using built-in specs.
COLLECT_GCC=gcc-5
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.1.0-0ubuntu11~14.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=c++98 --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo

[Bug fortran/67933] [4.9/5/6 Regression] ICE for array of a derived type with allocatable class in derived type object

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
  Known to work||4.8.5
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.2.0, 6.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. The ICE appeared between revisions r206362 (2014-01-06, compiles)
and r206567 (2014-01-12, ICE): usual suspect r206379 (pr59589).

[Bug c++/67950] AIX: Illegal instruction in accept()

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
The output of building GCC is not very helpful, please see
https://gcc.gnu.org/bugs/

[Bug middle-end/67946] Function multiversioning ICE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
  Component|target  |middle-end
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
I don't think compiling with -mavx is desired here.  The "bug" is that
DECL_MODE doesn't have the same special-casing of vectors as TYPE_MODE has
and ...

/* Holds the machine mode corresponding to the declaration of a variable or
   field.  Always equal to TYPE_MODE (TREE_TYPE (decl)) except for a
   FIELD_DECL.  */
#define DECL_MODE(NODE) (DECL_COMMON_CHECK (NODE)->decl_common.mode)

... the comment also is wrong here.

Not sure if we really want to change the above to sth like

#define DECL_MODE(NODE) \
 (VECTOR_TYPE_P (TREE_TYPE (NODE)) \
  ? vector_type_mode (TREE_TYPE (NODE)) \
  : DECL_COMMON_CHECK (NODE)->decl_common.mode)

though.  Maybe changing references to DECL_MODE to use TYPE_MODE in some
selected places would be enough ...

[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Most interesting would be a C testcase that produces the CFG with the bogus
counters ;)

[Bug c++/67935] internal compiler error: Segmentation fault

[niqingliang2003 at gmail dot com]

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

--- Comment #3 from Yi Qingliang  ---
Created attachment 36493
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36493=edit
the array version 'save-temps' result

the array version 'save-temps' result

[Bug c++/67935] internal compiler error: Segmentation fault

[niqingliang2003 at gmail dot com]

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

Yi Qingliang  changed:

   What|Removed |Added

  Attachment #36484|0   |1
is obsolete||
 CC||niqingliang2003 at gmail dot 
com

--- Comment #2 from Yi Qingliang  ---
Created attachment 36492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36492=edit
the array version

the array version compile result:

$ gcc -v -save-temps -std=c++11 main.cpp 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-5.2.0/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --disable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -E -quiet -v -D_GNU_SOURCE
main.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o main.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../include/c++/5.2.0/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/cc1plus -fpreprocessed main.ii
-quiet -dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -std=c++11
-version -o main.s
GNU C++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.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++11 (GCC) version 5.2.0 (x86_64-unknown-linux-gnu)
compiled by GNU C version 5.2.0, GMP version 6.0.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: 9ed1d81099b98de89457560501a9ea0c
main.cpp: In substitution of ‘template void base_t::serialize(_T&)
[with _T = packer_rp]’:
main.cpp:16:3:   required from ‘void packer_rp::pack_data(const _T&) [with _T =
base_t]’
main.cpp:6:3:   required from ‘void packer_rp::operator()(const _T&) [with _T =
base_t]’
main.cpp:45:3:   required from ‘void test::serialize(_T&) const [with _T =
packer_rp]’
main.cpp:53:30:   required from here
main.cpp:34:22: error: invalid use of ‘restrict’
  void serialize(_T & o)

[Bug fortran/67933] [4.9/5/6 Regression] ICE for array of a derived type with allocatable class in derived type object

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4
Summary|[4.9/5/Trunk Regression]|[4.9/5/6 Regression] ICE
   |ICE for array of a derived  |for array of a derived type
   |type with allocatable class |with allocatable class in
   |in derived type object  |derived type object

[Bug rtl-optimization/67814] cmp instruction register allocation error (x86)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Uroš Bizjak  ---
(In reply to Jameson from comment #4)
> I couldn't find any generic linux binaries for 5.2 (or 6) to test. The
> downlink link from the download page to
> https://gcc.gnu.org/wiki/GFortranBinaries seems to go to a non-existant site
> gfortran.com
> 
> I tested with the mingw64-gcc v5.2.0 compiler and, like you, was not able to
> reproduce the issue (I had originally noticed the issue on mingw64-gcc). So
> it seems like either the issue got resolved, or some other optimization is
> hiding it (it was pretty sensitive to the set of flags passed to gcc in
> 4.9.1 and 5.1.1). Is there any chance the fix will be backported to the
> major binary distribution channels such as Ubuntu?

It is up to the distribution to update releases or backport specific patches
from the master repository.

I have checked all active branches (gcc-4.9, gcc-5 and gcc-6) and all latest
revisions fail to generate problematic instruction with the provided compile
flags.

So, WORKSFORME.

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Oct 13 10:08:40 2015
New Revision: 228754

URL: https://gcc.gnu.org/viewcvs?rev=228754=gcc=rev
Log:
Handle original loop tree in expand_omp_for_generic

2015-10-13  Tom de Vries  

PR tree-optimization/67476
* omp-low.c (expand_omp_for_generic): Handle original loop tree.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #12 from vries at gcc dot gnu.org ---
Author: vries
Date: Tue Oct 13 10:08:59 2015
New Revision: 228756

URL: https://gcc.gnu.org/viewcvs?rev=228756=gcc=rev
Log:
Add param parloops-schedule

2015-10-13  Tom de Vries  

PR tree-optimization/67476
* doc/invoke.texi (@item parloops-schedule): New item.
* params.def (PARAM_PARLOOPS_SCHEDULE): New DEFPARAMENUM5.
* tree-parloops.c: Include params-enum.h.
(create_parallel_loop): Handle PARAM_PARLOOPS_SCHEDULE.

* testsuite/libgomp.c/autopar-3.c: New test.
* testsuite/libgomp.c/autopar-4.c: New test.
* testsuite/libgomp.c/autopar-5.c: New test.
* testsuite/libgomp.c/autopar-6.c: New test.
* testsuite/libgomp.c/autopar-7.c: New test.
* testsuite/libgomp.c/autopar-8.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/autopar-3.c
trunk/libgomp/testsuite/libgomp.c/autopar-4.c
trunk/libgomp/testsuite/libgomp.c/autopar-5.c
trunk/libgomp/testsuite/libgomp.c/autopar-6.c
trunk/libgomp/testsuite/libgomp.c/autopar-7.c
trunk/libgomp/testsuite/libgomp.c/autopar-8.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi
trunk/gcc/params.def
trunk/gcc/tree-parloops.c
trunk/libgomp/ChangeLog

[Bug c++/67950] New: AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

Bug ID: 67950
   Summary: AIX: Illegal instruction in accept()
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: streibel.2003 at gmx dot net
  Target Milestone: ---

Created attachment 36494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36494=edit
Output of the GCC build process (make)

I compiled GCC, Version 4.9.3 on an AIX 7.1 machine.
The output of the build process (make) is in the appendix.

A C test program which calls accept() works fine when compiled with gcc.
However it crashes within the accept() function when compiled with g++.
The crash happens as soon as a client connects to the server:

[root@dev71 tmp]# uname -a
AIX dev71 1 7 00F6C0A94C00
[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/gcc -o tcpserver tcpserver.c
[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/g++ -o tcpserver tcpserver.c
ld: 0711-768 WARNING: Object /tmp//ccy8CL9X.o, section 1, function .accept:
The branch at address 0x8a8 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x7C691B78.
ld: 0711-768 WARNING: Object /tmp//ccy8CL9X.o, section 1, function .accept:
The branch at address 0x8a8 is not followed by a recognized no-op
or TOC-reload instruction. The unrecognized instruction is 0x7C691B78.
[root@dev71 tmp]# ./tcpserver 1234
--> before accept() <--
Illegal instruction (core dumped)
[root@dev71 tmp]#

A self compiled GCC, Version 4.9.1 Shows the same behaviour.
A GCC, Version 4.8.3 which we installed via an RPM package works fine.

[Bug c++/67951] New: Wshadow for type inferenced (auto) lambda parameters

[jens.auer at cgi dot com]

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

Bug ID: 67951
   Summary: Wshadow for type inferenced (auto) lambda parameters
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.auer at cgi dot com
  Target Milestone: ---

int f()
{
auto l = [](int i) {};

int i=0;
l(i);

return i;
}

void h()
{
auto l = [](auto i) {};

int i=0;
l(i);
}

If compiled with "g++ -std=c++1y -Wshadow", I get a warning in h:
shadow.cpp:15:23: warning: declaration of ‘i’ shadows a previous local
[-Wshadow]
 auto l = [](auto i) {};
   ^
shadow.cpp:17:9: note: shadowed declaration is here
 int i=0;

I think this is wrong. If it is not wrong, it is inconsistent because there is
no warning in f().

[Bug tree-optimization/67947] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Started with r228599, I think there's a dup somewhere...  likely PR67920.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I can't reproduce, with the current trunk I see

.p2align 4,,15
.globl  main
.type   main, @function
main:
.LFB11:
.cfi_startproc
movl$1, -4(%rsp)
movl-4(%rsp), %eax
xorl%eax, %eax
ret
.cfi_endproc
.LFE11:
.size   main, .-main
.globl  x110
.bss
.align 4
.type   x110, @object
.size   x110, 4
x110:
.zero   4

[Bug other/62279] Demangler crash

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

 CC||miyuki at gcc dot gnu.org

--- Comment #4 from Mikhail Maltsev  ---
(In reply to Stanislav Angelovic from comment #3)
> GDB 7.7.1 demangler crashes upon this symbol in our binary:
> 
> _ZSt7forwardIKSaINSt6thread5_ImplISt12_Bind_simpleIFZN6WIM_DL5Utils9AsyncTask
> C4IMNS3_8Hardware12FpgaWatchdogEKFvvEIPS8_EEEibOT_DpOT0_EUlvE_vEESD_RNSt1
> 6remove_referenceISC_E4typeE

Whis works fine with binutils 2.25 and gives:

std::allocator > > const&&
std::forward > > const&&,
WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > >
const>(std::remove_reference > > const>::type&)

Could you try a newer version of GDB?

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|Testsuite failures starting |[6 Regression] Testsuite
   |with revision 228616|failures starting with
   ||revision 228616

--- Comment #3 from Richard Biener  ---
Was this maybe fixed by

2015-10-13  Richard Sandiford  

* real.h (real_isinteger): Declare.
* real.c (real_isinteger): New function.
* match.pd: Simplify pow(|x|,y) and pow(-x,y) to pow(x,y)
if y is an even integer.

?

[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So sth like the following (ISTR some missed foldings that way, it's not too
long
ago that I tested this)

Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 228706)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -110,10 +110,9 @@ cleanup_control_expr_graph (basic_block
   switch (gimple_code (stmt))
{
case GIMPLE_COND:
- val = fold_binary_loc (loc, gimple_cond_code (stmt),
-boolean_type_node,
-gimple_cond_lhs (stmt),
-gimple_cond_rhs (stmt));
+ val = const_binop (gimple_cond_code (stmt),
+boolean_type_node,
+gimple_cond_lhs (stmt), gimple_cond_rhs (stmt));
  break;

case GIMPLE_SWITCH:

Or alternatively try to go down

Index: gcc/passes.c
===
--- gcc/passes.c(revision 228750)
+++ gcc/passes.c(working copy)
@@ -1909,7 +1909,16 @@ execute_function_todo (function *fn, voi

   push_cfun (fn);

-  /* Always cleanup the CFG before trying to update SSA.  */
+  if (flags & TODO_update_ssa_any)
+{
+  /* Always delete unreachable blocks before trying to update SSA.  */
+  if (!dom_info_available_p (CDI_DOMINATORS))
+   delete_unreachable_blocks ();
+
+  unsigned update_flags = flags & TODO_update_ssa_any;
+  update_ssa (update_flags);
+}
+
   if (flags & TODO_cleanup_cfg)
 {
   cleanup_tree_cfg ();
@@ -1930,10 +1939,9 @@ execute_function_todo (function *fn, voi
 still need to do one.  */
   if (!(flags & TODO_update_ssa_any) && need_ssa_update_p (cfun))
flags |= TODO_update_ssa;
-}

-  if (flags & TODO_update_ssa_any)
-{
+  /* ???  We want to fix the above issue by keeping SSA for up-to-date
+ which might be easier when we have updated SSA before CFG cleanup. 
*/
   unsigned update_flags = flags & TODO_update_ssa_any;
   update_ssa (update_flags);
 }

with all the consequences of even after fixing ??? the probably more expensive
SSA update (on a not cleaned up CFG).

I'm re-testing the first hunk (without instrumenting for regressions...)

[Bug tree-optimization/67921] [6 Regression] "internal compiler error: in build_polynomial_chrec, at tree-chrec.h:147" when using -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Started with r224020.

[Bug tree-optimization/67947] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|wrong code at -O3 on|[6 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu

[Bug tree-optimization/67947] [6 Regression] wrong code at -O3 on x86_64-linux-gnu

[ysrumyan at gmail dot com]

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

--- Comment #2 from Yuri Rumyantsev  ---
revision 228760 must fix this bug.

[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
On x86_64-apple-darwin14 with lldb I get

frame #5: 0x00010e95 a.out`__foo_MOD_cp__b + 14 at pr67696.f90:4
frame #6: 0x00010e9e a.out`test + 9 at pr67696.f90:10
frame #7: 0x00010ed7 a.out`main(argc=1,
argv="/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out") + 54 at
pr67696.f90:9

and with gdb

#5  0x00010e95 in cp__b () at pr67696.f90:4
#6  0x00010e9e in test () at pr67696.f90:10
#7  0x00010ed7 in main (argc=1, argv=0x7fff5fbff5b0) at pr67696.f90:9

[Bug rtl-optimization/67954] New: [5 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1281

[dbaryshkov at gmail dot com]

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

Bug ID: 67954
   Summary: [5 Regression] internal compiler error: in
patch_jump_insn, at cfgrtl.c:1281
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dbaryshkov at gmail dot com
  Target Milestone: ---

Created attachment 36501
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36501=edit
Preprocessed source file

Since https://gcc.gnu.org/viewcvs/gcc?view=revision=210824 GCC fails
with ICE when generating ARM Thumb1 code:

/tmp/test.i: In function 'ubidi_writeReordered_55':
/tmp/test.i:4748:1: internal compiler error: in patch_jump_insn, at
cfgrtl.c:1303
 }
 ^
0x63700e patch_jump_insn
../../gcc/gcc/cfgrtl.c:1303
0x63715b redirect_branch_edge
../../gcc/gcc/cfgrtl.c:1329
0x6376e2 rtl_redirect_edge_and_branch
../../gcc/gcc/cfgrtl.c:1462
0x629889 redirect_edge_and_branch(edge_def*, basic_block_def*)
../../gcc/gcc/cfghooks.c:376
0xd0be1d try_forward_edges
../../gcc/gcc/cfgcleanup.c:621
0xd0be1d try_optimize_cfg
../../gcc/gcc/cfgcleanup.c:2835
0xd0be1d cleanup_cfg(int)
../../gcc/gcc/cfgcleanup.c:3049
0xd0d318 execute
../../gcc/gcc/cfgcleanup.c:3178


The following commands fail:

* gcc -march=armv4t -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv5te -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv6 -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping

The following work:
* gcc -march=armv6t2 -mthumb /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv5te -marm /tmp/test.i -S -o /tmp/test.o  -O1 -fcrossjumping
* gcc -march=armv5te -mthumb /tmp/test.i -S -o /tmp/test.o  -O1

The log was produced using clear gcc from gcc-5_1_0-release tag.

The following configure options were passed to gcc:

../gcc/configure --build=x86_64-linux  --host=x86_64-linux 
   --target=arm-linux-gnueabi
--enable-languages=c --enable-checking=all --disable-nls

[Bug fortran/51380] ASSIGNMENT(=): Reject ALLOCATABLE/POINTER dummy argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Still no error/warning at r228753 (trunk 6.0).

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
On trunk (6.0 r228753) this has been changed to

  /* Functions returning pointers or allocatables need temporaries.  */
  c = expr2->value.function.esym
  ? (expr2->value.function.esym->attr.pointer
 || expr2->value.function.esym->attr.allocatable)
  : (expr2->symtree->n.sym->attr.pointer
 || expr2->symtree->n.sym->attr.allocatable);
  if (c)
return true;

Any point to keep this PR opened?

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[redflames1003 at gmail dot com]

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

--- Comment #39 from Christopher Torres  ---
(In reply to Alexandre Oliva from comment #36)
> Created attachment 36472 [details]
> backported patch for the 4.9 branch
> 
> Chris,
> 
> retbnd is of no concern, nothing equivalent existed back then.
> 
> call_stmt was called gimple_call.
> 
> Here's a backported patch, barely tested.  Please let me know how it goes
> for you.

Thank you. Looking at the diff it doesn't look like this will actually compile
since redbnd and call_stmt is still in there. Did you maybe upload the wrong
patch file? 

Thanks

[Bug fortran/51820] [doc] underscoring documentation incorrect

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
Any interest for this?

[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele  changed:

   What|Removed |Added

 Target||x86_64-unknown-linux-gnu
 Status|WAITING |UNCONFIRMED
 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch
 Ever confirmed|1   |0

--- Comment #2 from Joost VandeVondele  
---
so seemingly target specific ?

[Bug tree-optimization/67955] New: tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

Bug ID: 67955
   Summary: tree-dse does not use pointer info
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider this testcase, with dead store '*p = 1':
...
int
f ()
{
  int a;
  int *p = 
  *p = 1;
  a = 2;
  return a;
}
...

We compile with -O2 -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre.

At dse1 we have
...
f ()
{
  int * p;
  int a;
  int _5;

  :
  p_1 = 
  *p_1 = 1;
  a = 2;
  _5 = a;
  a ={v} {CLOBBER};
  return _5;

}
...

So, the dead store '*p_1 = 1' has not been eliminated.

However, at ealias we already know:
...
Alias information for f

Aliased symbols

a, UID D.1757, int, is addressable

Call clobber information

ESCAPED, points-to non-local, points-to vars: { }

Flow-insensitive points-to information

p_1, points-to vars: { D.1757 }
...

So, we could use points-to info in dce.

[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

[Bug fortran/52265] [OOP] TREE dump confusing with nested SELECT TYPE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
Still present at r228753.

[Bug fortran/48997] Don't use allocatable arrays for function elimination

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #2 from Dominique d'Humieres  ---
> Thomas, what is the status of this?

PING!

[Bug fortran/49590] ENTRY: Reject combining USE associated variable with RESULT variable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Still present at r228753 (trunk 6.0).

[Bug fortran/47495] .mod files: File modification time - Makefile build issue

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #13 from Dominique d'Humieres  ---
Is this still of interest?

[Bug c++/67952] [C++14] Compilation error with boost::signals2 and generic lambda: cannot call member function without object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Does look like another dup.

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

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #2 from Hans Streibel  ---
Ok, here is the missing Information:

[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-4.9.3-hans/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc-4.9.3-hans/libexec/gcc/powerpc-ibm-aix7.1.0.0/4.9.3/lto-wrapper
Target: powerpc-ibm-aix7.1.0.0
Configured with: ./configure --with-as=/usr/bin/as --with-ld=/usr/bin/ld
--prefix=/opt/gcc-4.9.3-hans --enable-languages=c,c++
--enable-version-specific-runtime-libs --disable-nls --enable-decimal-float=dpd
--host=powerpc-ibm-aix7.1.0.0
Thread model: aix
gcc version 4.9.3 (GCC)

Compiler warnings:
Beside the warnings that where already in the original post, there are no
warnings, even None with -W and -Wall

Preprocessed files:
- tcpserver.i (produced by gcc)
- tcpserver.ii (produced by g++)

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #3 from Hans Streibel  ---
Created attachment 36496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36496=edit
gcc preprocessed result

[Bug tree-optimization/67953] New: [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign

[glisse at gcc dot gnu.org]

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

Bug ID: 67953
   Summary: [6 Regression] match.pd: X - (X / Y) * Y wrong on
change of sign
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

$ cat z.c
#include 
unsigned f(signed a){
  return (unsigned)a-((a/3)*3);
}
unsigned g(signed a){
  return a-((a/3)*3);
}
int main(){
  printf("%d %d\n", f(-5), g(-5));
}
$ gcc-5 z.c && ./a.out
-2 -2
$ clang z.c && ./a.out   
-2 -2
$ gcc-snapshot z.c && ./a.out 
2 -2

[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'

[matthijs at stdin dot nl]

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

--- Comment #9 from Matthijs Kooijman  ---
Created attachment 36499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36499=edit
Second testcase, needs -Os to break

[Bug fortran/67744] polymorphic associating entity is refused TBP invocation

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Dominique d'Humieres  ---
> The first sentence, I think, implies that my code example is valid.

IMO everything is in the "if", but I don't know the answer. Note that this may
be related to pr67743.

[Bug c++/61636] generic lambda "cannot call member function without object"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||jens.auer at cgi dot com

--- Comment #14 from Jonathan Wakely  ---
*** Bug 67952 has been marked as a duplicate of this bug. ***

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #5 from Hans Streibel  ---
Just noticed:
Adding an optimization flag -O1 or -O2 to g++ removes this bug (-O0 does not
help):

[root@dev71 tmp]# /opt/gcc-4.9.3-hans/bin/g++ -o tcpserver.4.9.3++ -O1 -Wall
tcpserver.c
[root@dev71 tmp]# ./tcpserver.4.9.3++ 1234
--> before accept() <--
--> accept() returned: 4 <--
fd after accept(): 4
abc
read 0 bytes from the socket. Socket is closed
--> before accept() <--

[Bug tree-optimization/67953] [6 Regression] match.pd: X - (X / Y) * Y wrong on change of sign

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r225195 :(.

[Bug other/62279] Demangler crash

[stanislav.angelovic at kistler dot com]

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

--- Comment #5 from Stanislav Angelovic  ---
(In reply to Mikhail Maltsev from comment #4)
> (In reply to Stanislav Angelovic from comment #3)
> > GDB 7.7.1 demangler crashes upon this symbol in our binary:
> > 
> > _ZSt7forwardIKSaINSt6thread5_ImplISt12_Bind_simpleIFZN6WIM_DL5Utils9AsyncTask
> > C4IMNS3_8Hardware12FpgaWatchdogEKFvvEIPS8_EEEibOT_DpOT0_EUlvE_vEESD_RNSt1
> > 6remove_referenceISC_E4typeE
> 
> Whis works fine with binutils 2.25 and gives:
> 
> std::allocator(int, bool, void
> (WIM_DL::Hardware::FpgaWatchdog::*&&)() const,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&&
> std::forward(int, bool,
> std::allocator(int, bool, void
> (WIM_DL::Hardware::FpgaWatchdog::*&&)() const,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const&&,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > >
> const>(std::remove_reference WIM_DL::Hardware::FpgaWatchdog*>(int, bool, void
> (WIM_DL::Hardware::FpgaWatchdog::*&&)() const,
> WIM_DL::Hardware::FpgaWatchdog*&&)::{lambda()#1} ()> > > const>::type&)
> 
> Could you try a newer version of GDB?

Thanks for the fast response, Mikhail. We use tools shipped with Yocto, so our
hands are tied to some extent. But I tried binutils 2.25 and there it works.
Thank you!

[Bug other/60040] AVR: error: unable to find a register to spill in class 'POINTER_REGS'

[matthijs at stdin dot nl]

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

Matthijs Kooijman  changed:

   What|Removed |Added

 CC||matthijs at stdin dot nl

--- Comment #8 from Matthijs Kooijman  ---
Seems not - just tried with avr-gcc 5.1 and it is still broken:

$ avr-gcc -fpreprocessed -w -mmcu=atmega128 -O2 -s test.i -o /dev/null
test.i: In function 'rtems_fdisk_recycle_segment':
test.i:107:1: error: unable to find a register to spill in class
'POINTER_REGS'
 }
 ^
test.i:107:1: error: this is the insn:
(insn 30 29 31 2 (set (reg:HI 26 r26)
(reg/v/f:HI 51 [ dpd ])) /home/matthijs/test.i:95 83 {*movhi}
 (nil))
test.i:107: confused by earlier errors, bailing out

$ avr-gcc --version
avr-gcc (GCC) 5.1.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

On the Arduino bugtracker [1], another testcase with the same symptoms was
reported. I'm attaching that here. This testcase works with -O2, but
breaks when -Os is used.

$ avr-gcc -c -Os  -mmcu=atmega328p  test2.c -o /dev/null

test2.c: In function 'getSlope':
test2.c:22:1: error: unable to find a register to spill in class
'POINTER_REGS'
 }
 ^
test2.c:22:1: error: this is the insn:
(insn 40 38 42 3 (set (reg:SF 63 [ D.1613 ])
(mem:SF (post_inc:HI (reg:HI 16 r16 [orig:73 ivtmp.13 ] [73]))
[1 MEM[base: _27, offset: 0B]+0 S4 A8])) /home/matthijs/test.c:15 100 {*movsf}
 (expr_list:REG_INC (reg:HI 16 r16 [orig:73 ivtmp.13 ] [73])
(nil)))
test2.c:22: confused by earlier errors, bailing out

[1]: https://github.com/arduino/Arduino/issues/3972

[Bug fortran/67936] Off-by-one column for some caret locations

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 CC||manu at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed for 5.2 and 6.0 (trunk).

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Seems to be fixed if it was ever broken.

[Bug c++/67952] New: Compilation error with boost::signals2 and generic lambda: cannot call member function without object

[jens.auer at cgi dot com]

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

Bug ID: 67952
   Summary: Compilation error with boost::signals2 and generic
lambda: cannot call member function without object
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.auer at cgi dot com
  Target Milestone: ---

Created attachment 36495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36495=edit
Preprocessed source code

The following code doesn't compile with boost 1.59 and gcc 5.1, but with clang
3.6:

#include 

class A
{
public:
A()
{
// these two work
sig2.connect( [this]() {f();} );
sig.connect( [this](auto x) {this->g(x);} );

// this does not work
sig.connect( [this](auto x) {g(x);} );
}


private:
void f();
void g(int);

boost::signals2::signal sig;
boost::signals2::signal sig2;
};

The error message is
shadow.cpp: In instantiation of ‘A::A():: [with auto:2 = int]’:
/lhome1/auerj/opt/include/boost/function/function_template.hpp:153:11:  
required from ‘static void
boost::detail::function::void_function_obj_invoker1::invoke(boost::detail::function::function_buffer&, T0) [with FunctionObj =
A::A()::; R = void; T0 = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:934:38:  
required from ‘void boost::function1::assign_to(Functor) [with Functor =
A::A()::; R = void; T0 = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:722:7:  
required from ‘boost::function1::function1(Functor, typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type) [with Functor = A::A()::; R = void; T0 = int;
typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:1071:16:  
required from ‘boost::function::function(Functor, typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type) [with Functor = A::A()::; R = void; T0 = int;
typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
int>::type = int]’
/lhome1/auerj/opt/include/boost/function/function_template.hpp:1126:5:  
required from ‘typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
boost::function&>::type boost::function::operator=(Functor) [with
Functor = A::A()::; R = void; T0 = int; typename
boost::enable_if_c<(boost::type_traits::ice_not<(boost::is_integral::value)>::value),
boost::function&>::type = boost::function&]’
/lhome1/auerj/opt/include/boost/signals2/detail/slot_template.hpp:160:24:  
required from ‘void boost::signals2::slot::init_slot_function(const F&) [with F = A::A()::;
SlotFunction = boost::function; R = void; Args = {int}]’
/lhome1/auerj/opt/include/boost/signals2/detail/slot_template.hpp:85:27:  
required from ‘boost::signals2::slot::slot(const F&)
[with F = A::A()::; SlotFunction = boost::function;
R = void; Args = {int}]’
shadow.cpp:13:45:   required from here
shadow.cpp:13:38: error: cannot call member function ‘void A::g(int)’ without
object
 sig.connect( [this](auto x) {g(x);} );

I think it is a compiler bug because adding the implicit this-> solves the
problem (see second connect).

My gcc version:
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/lhome1/auerj/opt/libexec/gcc/x86_64-unknown-linux-gnu/5.1.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-5.1.0/configure --prefix=/lhome1/auerj/opt
--enable-languages=c,c++
Thread model: posix
gcc version 5.1.0 (GCC) 

I have attached the preprocessed output so it should be easy to reproduce the
issue.

It is probably a duplicate of 61636, but I such that it can be tracked as such.
I guess boost::signals2 is a popular library, so it may be worth to have it in
the database explicitly.

[Bug c++/67952] [C++14] Compilation error with boost::signals2 and generic lambda: cannot call member function without object

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
Summary|Compilation error with  |[C++14] Compilation error
   |boost::signals2 and generic |with boost::signals2 and
   |lambda: cannot call member  |generic lambda: cannot call
   |function without object |member function without
   ||object
 Ever confirmed|0   |1
  Known to fail||4.9.3, 5.2.0, 6.0

--- Comment #1 from Jonathan Wakely  ---
Nothing to do with Boost, so it doesn't need thousands of lines of Boost
headers to reproduce it:


template struct signal;

template
struct signal
{
  template
void connect(F f) { f( Args{}... ); }
};

class A
{
public:
A()
{
// these two work
sig2.connect( [this]() {f();} );
sig.connect( [this](auto x) {this->g(x);} );

// this does not work
sig.connect( [this](auto x) {g(x);} );
}


private:
void f();
void g(int);

signal sig;
signal sig2;
};

[Bug c++/67950] AIX: Illegal instruction in accept()

[streibel.2003 at gmx dot net]

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

--- Comment #4 from Hans Streibel  ---
Created attachment 36497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36497=edit
g++ preprocessed result

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[ysrumyan at gmail dot com]

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

--- Comment #4 from Yuri Rumyantsev  ---
Created attachment 36498
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36498=edit
proposed patch

This patch cures run-time error for 416.gamess.

[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c   (revision 228753)
+++ gcc/tree-cfgcleanup.c   (working copy)
@@ -103,17 +103,22 @@ cleanup_control_expr_graph (basic_block
   edge e;
   edge_iterator ei;
   bool warned;
-  location_t loc;

   fold_defer_overflow_warnings ();
-  loc = gimple_location (stmt);
   switch (gimple_code (stmt))
{
case GIMPLE_COND:
- val = fold_binary_loc (loc, gimple_cond_code (stmt),
-boolean_type_node,
-gimple_cond_lhs (stmt),
-gimple_cond_rhs (stmt));
+ val = const_binop (gimple_cond_code (stmt),
+boolean_type_node,
+gimple_cond_lhs (stmt), gimple_cond_rhs (stmt));
+ if (!val)
+   {
+ tree tem = fold_binary (gimple_cond_code (stmt),
+ boolean_type_node,
+ gimple_cond_lhs (stmt),
+ gimple_cond_rhs (stmt));
+ gcc_assert (!tem || TREE_CODE (tem) != INTEGER_CST);
+   }
  break;

case GIMPLE_SWITCH:

fails in configuring stage2 gcc/ on

if (_12 < 0)

but probably because of your earlier patch now ... and with that disabled on

if (base.96 != base.96)

which is during CFG build in stage2 libcpp lex.c.  It's the GIMPLIFIERs
"CSE" producing

  :
  base.96 = base;
  base.96 = base;
  if (base.96 != base.96)

(see gimplify.c:lookup_tmp_var) and us not folding that stmt during
gimplification (the thing to fix).  Let's see how far I get with that ;)

[Bug tree-optimization/67920] [6 Regression] wrong code with -O3

[ysrumyan at gmail dot com]

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

--- Comment #8 from Yuri Rumyantsev  ---
Please check that revision 228760 will cure your issue.

[Bug inline-asm/67944] GCC emits unnecessary push/pop for callee-save reads.

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Your expectation is not in line with what the compiler actually promises
you: the only guarantee is that the local register variable will be in
(in your case) ebx _where used in an asm statement_.

Other than that, it is just a local variable.

You get a save/restore sequence in the prologue and epilogue because ebx
is a non-volatile register and this function uses that register.  Scheduling
later moves the push later in the code.

If you want to simply grab what is in ebx, you can use asm, like

long reg; asm("mov %%ebx,%0" : "=r"(reg));

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[ysrumyan at gmail dot com]

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

--- Comment #3 from Yuri Rumyantsev  ---
Check that guard edge is around the inner loop was missed. After adding it
416.gamess run successfully.
I sent the fix for review.

[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary

[dominiq at lps dot ens.fr]

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

--- Comment #1 from Dominique d'Humieres  ---
The test

   Module m200c2
 Integer,Target :: x = 42
   Contains
 Function fx()
   Integer,Pointer :: fx
   fx => x
 End Function
   End Module

   Program q1
 Use m200c2
 Call test(x,fx())  ! The call.
   Contains
 Subroutine test(a,b)
   Integer :: a,b
   a = a*10 ! The assignment.
   Print *,a,b
 End Subroutine
   End Program

outputs 

 420 420

Am I correct to understand that this answer is OK for Fortran 2008, but should
be

 420 42

for Fortran 2003 and older?

Note that if I replace the line

 Call test(x,fx())  ! The call.

with

 Call test(x,(fx()))  ! The call.

I get the later answer.

[Bug fortran/67743] Associating entity is not auto-typed

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.3, 5.2.0, 6.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed on 4.8 up to trunk (6.0). Probably related to pr67744.

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[afomin.mailbox at gmail dot com]

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

--- Comment #5 from Alexander Fomin  ---
Created attachment 36500
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36500=edit
Folding regression reproducer

Unfortunately, it does not for x86-64.
Please take a look at the attached reproducer.
When compiling with -m64 -O2 -ffast-math -S it does not perform expected 
folding.

r228614
:
y.1_2 = y;
_3 = __builtin_sqrt (y.1_2);
*x_4(D) = _3;
powroot_18 = __builtin_sqrt (_3);
powroot_19 = _3 * powroot_18;
powroot_20 = y.1_2 * powroot_19;
y = powroot_20;

r228616
:
y.1_2 = y;
_3 = __builtin_sqrt (y.1_2);
*x_4(D) = _3;
powroot_18 = __builtin_pow (y.1_2, 2.5e-1);
powroot_19 = _3 * powroot_18;
powroot_20 = y.1_2 * powroot_19;
y = powroot_20;

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[ienkovich at gcc dot gnu.org]

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

--- Comment #5 from Ilya Enkovich  ---
Author: ienkovich
Date: Tue Oct 13 13:08:31 2015
New Revision: 228760

URL: https://gcc.gnu.org/viewcvs?rev=228760=gcc=rev
Log:
gcc/

2014-10-13  Yuri Rumyantsev  

PR tree-optimization/67909, 67947
* tree-ssa-loop-unswitch.c (find_loop_guard): Add check that GUARD_EDGE
really skip the inner loop.

gcc/testsuite/

2014-10-13  Yuri Rumyantsev  

PR tree-optimization/67909, 67947
* gcc.dg/torture/pr67947.c: New test.

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

[Bug rtl-optimization/67954] [5 Regression] internal compiler error: in patch_jump_insn, at cfgrtl.c:1303

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |5.3

[Bug c/67930] segmentation fault

[ka_bena at yahoo dot fr]

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

--- Comment #2 from BENAÏSSA  ---

 Thank you for your reply.

 Comments::

 I am not convinced by your point of view.

 1- the compilation step does not deliver any message.

 2- I modify the string by address and this is permitted by C for any entity
not 
    private in its context.

 3- if the compiler gcc allows segmentation fault for basic operations on
pointers,
    I think that this is a severe bug and in consequence the compiler must be
    modified to remedie for such situations.

 This is my point of view.    
    A.Benaïssa 


 Le Lundi 12 octobre 2015 13h16, mpolacek at gcc dot gnu.org
 a écrit :


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

Marek Polacek  changed:

          What    |Removed                    |Added

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

--- Comment #1 from Marek Polacek  ---
You're trying to modify a string literal.  That's no-no.

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #9 from R Copley  ---
For information, this has already been entered on the mingw-w64 issue tracker
(months ago) (see http://sourceforge.net/p/mingw-w64/bugs/459/).

[Bug c/67930] segmentation fault

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Try adding -W -Wall and also -WWrite-string

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||http://sourceforge.net/p/mi
   ||ngw-w64/bugs/459/
 Resolution|--- |MOVED

--- Comment #10 from Jonathan Wakely  ---
Thanks for the link.

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

Arkadiusz Drabczyk  changed:

   What|Removed |Added

  Attachment #36488|0   |1
is obsolete||

--- Comment #7 from Arkadiusz Drabczyk  ---
Created attachment 36502
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36502=edit
better suggested patch

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

--- Comment #8 from Arkadiusz Drabczyk  ---
I attach a new patch with an extra whitespace after dot to keep up with an
existing convention.

[Bug c/67956] New: gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

Bug ID: 67956
   Summary: gcc's printf attribute accepts %m as a format
character
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christos at zoulas dot com
  Target Milestone: ---

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

According to TOG
(http://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html), %m is
not a legal formatting character for printf(3) like functions. Some
implementations (glibc) accept this formatting character as an extension and
expand it to the error string via strerror(3) that errno currently points to.
Most other c library implementations do not expand %m. 

Attached is a patch that makes printf warn when %m is present and adds a
"syslog" attribute that accepts %m. I recognize that this is an incompatible
change, and I welcome suggestions how to do this in a less intrusive way.

I tried to mininize the size of the patch; there are better ways to do this,
but require more refactoring.

[Bug c/67957] New: gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

Bug ID: 67957
   Summary: gcc's printf attribute accepts %m as a format
character
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christos at zoulas dot com
  Target Milestone: ---

According to TOG
(http://pubs.opengroup.org/onlinepubs/009695399/functions/fprintf.html), %m is
not a legal formatting character for printf(3) like functions. Some
implementations (glibc) accept this formatting character as an extension and
expand it to the error string via strerror(3) that errno currently points to.
Most other c library implementations do not expand %m. 

Attached is a patch that makes printf warn when %m is present and adds a
"syslog" attribute that accepts %m. I recognize that this is an incompatible
change, and I welcome suggestions how to do this in a less intrusive way.

I tried to mininize the size of the patch; there are better ways to do this,
but require more refactoring.

[Bug c/67957] gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

--- Comment #1 from Christos Zoulas  ---
Created attachment 36504
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36504=edit
patch

[Bug tree-optimization/67955] tree-dse does not use pointer info

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
We use "must point to" nowhere because we don't compute it ;)

The same points-to set results from

int *p = (int *)((char *) + 2);

or even

int *p =  + 1;

so you can't use points-to info that way (to derive a must-alias).

[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved

[Pidgeot18 at gmail dot com]

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

--- Comment #4 from Joshua Cranmer  ---
(In reply to Richard Biener from comment #3)
> Most interesting would be a C testcase that produces the CFG with the bogus
> counters ;)

Yeah, I know, but doing the minimization on a 5MLOC program takes time.

[Bug c/67957] gcc's printf attribute accepts %m as a format character

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

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #2 from Andreas Schwab  ---
.

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

[Bug c/67956] gcc's printf attribute accepts %m as a format character

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

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

--- Comment #1 from Andreas Schwab  ---
*** Bug 67957 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #1)
> The same points-to set results from
> 
> int *p = (int *)((char *) + 2);
> 
> or even
> 
> int *p =  + 1;
> 

I see, I didn't realize that. But AFAICT, in both these cases, storing to *p is
illegal (if 'a' is a scalar int).

> so you can't use points-to info that way (to derive a must-alias).

I see your point related to an array object, there pointers to different array
elements would have identical points-to sets.

I wonder though: if we have a store '*p = 0', and the size of the store is the
same as the size of the pointed-to object of pointer p, can't we conclude that 
pointer p points to the start of the object?

[Bug c/67956] gcc's printf attribute accepts %m as a format character

[christos at zoulas dot com]

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

--- Comment #2 from Christos Zoulas  ---
something is wrong with the bug tracking system, when posting a bug with an
attachment as the first post; this is how the dup got created.

[Bug fortran/65141] ISO_10646 constant parameters convert kind when used with substring references

[alexandros.syrakos at outlook dot com]

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

--- Comment #4 from Alexandros Syrakos  
---
Dominique, thanks for the quick reply. Your answer is just, but I'm afraid that
due to lack of appropriate skills I can't be much more help than reporting
bugs.

Concerning the present bug, let me add some more information: Your suggestion
of removing the "parameter" keyword is nice as a workaround but it doesn't work
for arrays of strings. Consider for example the following modification of the
original code:



program ISO_CONST_SUBST_PR
implicit none
integer, parameter :: UNICODE=selected_char_kind('ISO_10646')
integer, parameter :: DEFAULT=selected_char_kind('DEFAULT')
!character(kind=UNICODE,len=*),parameter :: string='my string'
character(kind=UNICODE,len=9) :: string='my string'
character(kind=UNICODE,len=9), dimension(2) :: page

page = string

write(*,'(A, I0, A, I0)') 'Unicode and default character kinds are:
',UNICODE,', ',DEFAULT
write(*,'(A, I0)') 'kind(string) should be UNICODE and is UNICODE for me:
',kind(string)
write(*,'(A, I0)') 'kind(string(2:4)) should be UNICODE and is UNICODE for
me: ',kind(string(2:4))
write(*,'(A, I0)') 'kind(page) should be UNICODE and is UNICODE for me:
',kind(page)
write(*,'(A, I0)') 'kind(page(1)) should be UNICODE and is UNICODE for me:
',kind(page(1))
write(*,'(A, I0)') 'kind(page(1)(2:4)) should be UNICODE and is DEFAULT for
me: ',kind(page(1)(2:4))
end program ISO_CONST_SUBST_PR



With gfortran 5.2.0 I get kind(page(1)(2:4)) == DEFAULT instead of UNICODE,
although no parameters are involved. Let me include another sample code:



program test
use iso_fortran_env
implicit none
integer, parameter ::ucs4 = selected_char_kind( 'ISO_10646' )
character(kind=ucs4) :: a
character(kind=ucs4, len=8), dimension(2) :: page

a = char( int(z'f17c'), ucs4 )

open (output_unit, encoding='UTF-8')
page(1) = repeat(a,8)
print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) contains: ",
page(1)

page(1)(2:4) = a
print "(a,i0,2a)", "kind(page(1)) is ", kind(page(1)), "; page(1) contains: ",
page(1)
end program test



You can see that, once substring page(1)(2:4) has been modified, although the
kind of page(1) is unaltered, printing page(1) to the screen gives rubbish.
This practically makes it impossible to use arrays of unicode strings.

[Bug fortran/53940] Optionally warn about multiple explicit USE-association of the same symbol

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
No warning at r228753.

[Bug fortran/52083] Misleading warning for internal procedures with names of intrinsic procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||4.8.5, 4.9.3, 5.2.0, 6.0
 Resolution|--- |FIXED

--- Comment #1 from Dominique d'Humieres  ---
> Expected: Do the same as for module procedures, namely print:
>
>   Warning: 'fraction' declared at (1) may shadow the intrinsic of the same
> name.  In order to call the intrinsic, explicit INTRINSIC declarations
> may be required.

This is exactly the warning I get with 4.8 up to trunk (6.0). With 5.2.0 and
6.0 the message ends with ' [-Wintrinsic-shadow]'.

[Bug c++/67942] diagnose placement new buffer overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-13
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch posted for review here:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01284.html

[Bug tree-optimization/67945] [6 Regression] Testsuite failures starting with revision 228616

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
(In reply to Richard Biener from comment #3)
> Was this maybe fixed by
> 
> 2015-10-13  Richard Sandiford  
> 
> * real.h (real_isinteger): Declare.
> * real.c (real_isinteger): New function.
> * match.pd: Simplify pow(|x|,y) and pow(-x,y) to pow(x,y)
> if y is an even integer.
> 
> ?

That did not fix the powerpc64 failures, they still fail with r228762.

[Bug fortran/47805] [OOP] Overridding hidden (private) TPB is rejected

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #5 from Dominique d'Humieres  ---
For what it worth, updated link in comment 1:

http://mailman.j3-fortran.org/pipermail/j3/2011-February/004197.html

The problems are still there at r228753.

[Bug fortran/54082] Program name shadows other entities with the same name

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Dominique d'Humieres  ---
As said by Tobias, the code is invalid and, although the error message could be
improved, nobody tried to do it during the past three years. IMO it is more
realistic to close this PR as WONTFIX rather to let it rot for the next decade.

[Bug c/67956] gcc's printf attribute accepts %m as a format character

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
The gnu_printf format attribute is specifically supposed to accept %m; you 
can use -pedantic to disallow it.  Targets can override what the printf 
attribute maps to; see config/i386/msformat-c.c for example; other OSes 
should do likewise so the correct set of formats for each target is 
accepted.  The desire for a syslog format is bug 15338.