[Bug target/67756] New: ICE compiling Linux Kernel fs/namei.c on ARM

[bernd.edlinger at hotmail dot de]

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

Bug ID: 67756
   Summary: ICE compiling Linux Kernel fs/namei.c on ARM
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

arm-linux-gnueabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-gcc
COLLECT_LTO_WRAPPER=/home/ed/gnu/arm-linux-gnueabihf-linux64/libexec/gcc/arm-linux-gnueabihf/6.0.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-6-20150927/configure
--prefix=/home/ed/gnu/arm-linux-gnueabihf-linux64 --target=arm-linux-gnueabihf
--enable-languages=c,c++,fortran,ada --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 6.0.0 20150927 (experimental) (GCC) 

arm-linux-gnueabihf-gcc -Wp,-MD,fs/.namei.o.d  -nostdinc -isystem
/home/ed/gnu/arm-linux-gnueabihf-linux64/lib/gcc/arm-linux-gnueabihf/6.0.0/include
-I./arch/arm/include -Iarch/arm/include/generated  -Iinclude
-I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__
-mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -std=gnu89 -fno-dwarf2-cfi-asm -fno-omit-frame-pointer
-mapcs -mno-sched-prolog -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp
-funwind-tables -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm
-fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0
-Wframe-larger-than=1024 -fstack-protector -Wno-unused-but-set-variable
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fno-var-tracking-assignments -g -pg -Wdeclaration-after-statement
-Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int
-Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO   
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(namei)" 
-D"KBUILD_MODNAME=KBUILD_STR(namei)" -c -o fs/namei.o fs/namei.c
fs/namei.c: In function 'vfs_link':
fs/namei.c:3934:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 85 281 86 12 (parallel [
(set (reg/v:SI 1 r1 [orig:113 max_links ] [113])
(and:SI (ne:SI (reg/v:SI 1 r1 [orig:113 max_links ] [113])
(const_int 0 [0]))
(leu:SI (reg/v:SI 1 r1 [orig:113 max_links ] [113])
(reg:SI 2 r2 [orig:125 _25 ] [125]
(clobber (reg:CC 100 cc))
]) fs/namei.c:3917 262 {*and_scc_scc_nodom}
 (nil))
fs/namei.c:3934:1: internal compiler error: in extract_constrain_insn, at
recog.c:2200
0xa3db48 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-6-20150927/gcc/rtl-error.c:109
0xa3db6f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-6-20150927/gcc/rtl-error.c:120
0xa1028d extract_constrain_insn(rtx_insn*)
../../gcc-6-20150927/gcc/recog.c:2200
0x9efc9d reload_cse_simplify_operands
../../gcc-6-20150927/gcc/postreload.c:408
0x9f29b5 reload_cse_simplify
../../gcc-6-20150927/gcc/postreload.c:194
0x9f29b5 reload_cse_regs_1
../../gcc-6-20150927/gcc/postreload.c:233
0x9f2acb reload_cse_regs
../../gcc-6-20150927/gcc/postreload.c:81
0x9f2acb execute
../../gcc-6-20150927/gcc/postreload.c:2350
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/67756] ICE compiling Linux Kernel fs/namei.c on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger  ---
Created attachment 36411
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36411&action=edit
preprocessed source file

[Bug target/67732] [SH] Strange LRA addsi3 usage

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #1)
> There are some improvements with LRA, but the regression in teem-1.6.0-src
> 
>  total:   1105728 -> 1122288+16560 / +1.497656 %
> 
> outweighs all of the improvements.

teem shows problems with -mlra.  I'm not sure whether all of them
are pure RA issues or not, though.  Typical inflation with LRA in
teem would be oparations against float matrices.  An example

void
foo (float mat[])
{
  float *p = &mat[16];

  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;
  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;  *--p = 0.0;
}

shows ~20% code size regression with -O2.  At .ira, it looks like:

r165 := 0.0
...
r167 := r162 + 56
mem[r167] := r165
r170 := r162 + 52
mem[r170] := r165
r173 := r162 + 48
mem[r173] := r165
...

and the old reload generates:

fr1 := 0.0
...
r1 := r4
r1 := r1 + 56
mem[r1] := fr1
r1 := r4
r1 := r1 + 52
mem[r1] := fr1
r1 := r4
r1 := r1 + 48
mem[r1] := fr1
...

Then postreload fixes it up to

fr1 := 0.0
...
r1 := r1 + 56
mem[r1] := fr1
r1 := r1 - 4
mem[r1] := fr1
r1 := r1 - 4
mem[r1] := fr1
...

OTOH, LRA generates:
fr1 := 0.0
...
r1 := r4 + 56
mem[r1] := fr1
r1 := r4 + 52
mem[r1] := fr1
r1 := r4 + 48
mem[r1] := fr1
...

Unfortunately postreload doesn't fix it up and split2 makes it
into the similar code generated with the old reload.
I've run postreload_cse again just after pass_split_after_reload
and got same text size with the old reload for the above example
at -mlra.  The CSiBE total sizes are:

3303471  -mno-lra without 2nd postreload_cse
3315689  -mlra without 2nd postreload_cse
3293271  -mno-lra with 2nd postreload_cse
3299813  -mlra with 2nd postreload_cse

and teem only comparison is:

1079932  -mno-lra without 2nd postreload_cse
1094468  -mlra without 2nd postreload_cse
1073104  -mno-lra with 2nd postreload_cse
1082764  -mlra with 2nd postreload_cse

[Bug tree-optimization/67742] 3rd-level restrict ignored

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Mon, 28 Sep 2015, vries at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67742
> 
> --- Comment #3 from vries at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #1)
> > Confirmed.
> 
> Richard,
> 
> any ideas or hints how this can be implemented in tree-ssa-structalias.c?

I think you'd want to refactor create_variable_info_for_1 to take
a parameter on whether restrict should be proceesed like in
intra_create_variable_infos, moving the special handling there
and instead of calling get_vi_for_tree on the PARM_DECL directly
call create_variable_info_for_1.

You'd have to record the respective pointer type in the fieldstack
for only-restrict-pointer vars (and similar things for non-aggregates).

Basically create_variable_info_for_1 (, yes-process-restrict)
should handle arbitrary level restrict by means of recursion.

[Bug tree-optimization/49367] missed optimization with __restrict field

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to Richard Biener from comment #3)
> As for the first example the only case that would work is by passing
> the argument in a way that the FE sets DECL_BY_REFERENCE and uses a
> restrict qualified pointer for it.  Which it does when the source passes
> it by value I think.  That's the only case where we can assume something
> about the pointed-to type.

The restricts in the first example of comment 2 are effective in current trunk,
and the call to g is optimized away.

[Bug middle-end/48390] Multiple setting to restricted pointer variable not optimized away

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vries at gcc dot gnu.org

--- Comment #2 from vries at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #0)
> float
> foo (float * restrict a, float * restrict b, float * restrict c, float *ptr)
> {
>  *a = 1; /* Can delete.  */
>  *b = *ptr + 2;
>  *a = 3;
> 
>  return *a + *b;
> }
> 

This is supported in current trunk, and the dead store '*a = 1' is removed.

[Bug fortran/67757] New: ICE after "ambiguous reference"

[arjen.markus895 at gmail dot com]

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

Bug ID: 67757
   Summary: ICE after "ambiguous reference"
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arjen.markus895 at gmail dot com
  Target Milestone: ---

The following code causes the compiler to produce a message about an ambiguous
reference and then to crash with a segmentation fault (this is on Windows 7,
both MinGW and Cygwin)":

module quaternion_def_basic
implicit none

type quaternion
!type(complex) :: c(2)
complex :: c(2)
end type quaternion
end module quaternion_def_basic

module quaternion_def
use quaternion_def_basic, only: T => quaternion
end module quaternion_def

module octonion_def
use quaternion_def, T2 => T

implicit none

!private :: T2

type T
type(T2) :: c(2)
end type T
end module octonion_def

module sedenion_def
use octonion_def, T2 => T

implicit none

!private :: T2

type T
type(T2) :: c(2)
end type T
end module sedenion_def

When I bring the "private" statements back, all is well.

[Bug target/67756] [6 Regression] ICE compiling Linux Kernel fs/namei.c on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|ICE compiling Linux Kernel  |[6 Regression] ICE
   |fs/namei.c on ARM   |compiling Linux Kernel
   ||fs/namei.c on ARM

[Bug ada/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug target/65105] [i386] XMM registers are not used for 64bit computations on 32bit target

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
Author: ienkovich
Date: Tue Sep 29 09:32:40 2015
New Revision: 228231

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

PR target/65105
* config/i386/i386.c: Include dbgcnt.h.
(has_non_address_hard_reg): New.
(convertible_comparison_p): New.
(scalar_to_vector_candidate_p): New.
(remove_non_convertible_regs): New.
(scalar_chain): New.
(scalar_chain::scalar_chain): New.
(scalar_chain::~scalar_chain): New.
(scalar_chain::add_to_queue): New.
(scalar_chain::mark_dual_mode_def): New.
(scalar_chain::analyze_register_chain): New.
(scalar_chain::add_insn): New.
(scalar_chain::build): New.
(scalar_chain::compute_convert_gain): New.
(scalar_chain::replace_with_subreg): New.
(scalar_chain::replace_with_subreg_in_insn): New.
(scalar_chain::emit_conversion_insns): New.
(scalar_chain::make_vector_copies): New.
(scalar_chain::convert_reg): New.
(scalar_chain::convert_op): New.
(scalar_chain::convert_insn): New.
(scalar_chain::convert): New.
(convert_scalars_to_vector): New.
(pass_data_stv): New.
(pass_stv): New.
(make_pass_stv): New.
(ix86_option_override): Created and register stv pass.
(flag_opts): Add -mstv.
(ix86_option_override_internal): Likewise.
* config/i386/i386.md (SWIM1248x): New.
(*movdi_internal): Add xmm to mem alternative for TARGET_STV.
(and3): Use SWIM1248x iterator instead of SWIM.
(*anddi3_doubleword): New.
(*zext_doubleword): New.
(*zextsi_doubleword): New.
(3): Use SWIM1248x iterator instead of SWIM.
(*di3_doubleword): New.
* config/i386/i386.opt (mstv): New.
* dbgcnt.def (stv_conversion): New.

gcc/testsuite/

PR target/65105
* gcc.target/i386/pr65105-1.c: New.
* gcc.target/i386/pr65105-2.c: New.
* gcc.target/i386/pr65105-3.c: New.
* gcc.target/i386/pr65105-4.C: New.
* gcc.dg/lower-subreg-1.c: Add -mno-stv options for ia32.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr65105-1.c
trunk/gcc/testsuite/gcc.target/i386/pr65105-2.c
trunk/gcc/testsuite/gcc.target/i386/pr65105-3.c
trunk/gcc/testsuite/gcc.target/i386/pr65105-4.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/i386.md
trunk/gcc/config/i386/i386.opt
trunk/gcc/dbgcnt.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/lower-subreg-1.c

[Bug target/65105] [i386] XMM registers are not used for 64bit computations on 32bit target

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #4 from Ilya Enkovich  ---
New pass_stv handles it by transforming scalar computations into vector ones.

[Bug target/67756] [6 Regression] ICE compiling Linux Kernel fs/namei.c on ARM

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 36412
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36412&action=edit
Reduced testcase

Confirmed.
Attaching reduced testcase. Needs -O2 -mapcs

[Bug target/67756] [6 Regression] ICE compiling Linux Kernel fs/namei.c on ARM

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-29
 Ever confirmed|0   |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Changing status...

[Bug fortran/67758] New: [GCC 6 regression] ICE on invalid code

[ienkovich at gcc dot gnu.org]

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

Bug ID: 67758
   Summary: [GCC 6 regression] ICE on invalid code
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

>cat test.f
  COMMON /FMCOM / X(80 000 000)
CALL T(XX(A))
  COMMON /FMCOM / XX(80 000 000)
>builds/trunk/64/20150927/bin/gfortran test.f
f951: internal compiler error: Segmentation fault
0xb1878f crash_signal
/export/users/gnutester/stability/svn/trunk/gcc/toplev.c:353
0x3b21c3567f ???
   
/home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x66eaf3 gfc_restore_last_undo_checkpoint()
/export/users/gnutester/stability/svn/trunk/gcc/fortran/symbol.c:3205
0x630bff reject_statement
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:2296
0x630d6c match_word_omp_simd
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:99
0x634621 match_word
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:442
0x634621 decode_statement
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:442
0x6351c4 next_free
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:1059
0x6351c4 next_statement
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:1293
0x638b61 parse_executable
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:4706
0x639f7e parse_progunit
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:5125
0x63b163 gfc_parse_file()
/export/users/gnutester/stability/svn/trunk/gcc/fortran/parse.c:5665
0x67cca2 gfc_be_parse_file
/export/users/gnutester/stability/svn/trunk/gcc/fortran/f95-lang.c:209
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Regression started 20150808.

[Bug c/67741] Invalid built-in usage should not cause segmentation fault in compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Testing.

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[aurelien at aurel32 dot net]

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

--- Comment #2 from Aurelien Jarno  ---
Thanks for the patch. I have just tested it, and it indeed fixes the issue from
the testcase. I am currently trying to build ffmpeg, from which the testcase
has been extracted to see if all the issues are really fixed.

[Bug c/67759] New: Missing warning "makes pointer from integer without a cast" after multiline assert

[jens at 4k2 dot de]

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

Bug ID: 67759
   Summary: Missing warning "makes pointer from integer without a
cast" after multiline assert
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens at 4k2 dot de
  Target Milestone: ---

Created attachment 36413
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36413&action=edit
Stripped down failing c source.

Hello,

when compiling the attached source, i do not get the "makes pointer from
integer without a cast" warning.

I see this behavior with 
 - gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)" on fedora 21.
 - gcc (GCC) 4.9.0
but NOT with
 - gcc (GCC) 4.7.2
 - gcc (SUSE Linux) 4.5.1 20101208

To miss the warning, compile with:
gcc -Wall -W --save-temps -c missing_warning.c -o missing_warning.o

Without the "--save-temps" option, the warning appears.
Without the newline in the assert(1) the warning also appears!

Maybe this is related to or a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60100
and/or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57201

Regards,
Jens

[Bug target/67037] [4.9/5/6 Regression] Wrong code at -O1 and above on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger  ---
I believe that when we see this in testcase.c.232r.reload

   73: [r166:SI++]=r142:SI#0
  REG_DEAD r142:SI
  REG_INC r149:SI
Inserting insn reload before:
  153: r166:SI=[afp:SI+0x14f8]
Inserting insn reload after:
  154: [afp:SI+0x14f8]=r166:SI

the insns before and after have the same address rtx
and while the insn 154 is transformed to:

  155: r3:SI=sp:SI+0x14f8
  154: [r3:SI]=r1:SI

insn 153's address suddenly becomes [r3:SI] too.

The following patch seems to fix it:

--- lra-constraints.c.jj2015-09-25 23:06:08.0 +0200
+++ lra-constraints.c   2015-09-29 13:29:01.695783261 +0200
@@ -1339,7 +1339,7 @@ process_addr_reg (rtx *loc, bool check_o
   if (after != NULL)
 {
   start_sequence ();
-  lra_emit_move (reg, new_reg);
+  lra_emit_move (before_p ? copy_rtx (reg) : reg, new_reg);
   emit_insn (*after);
   *after = get_insns ();
   end_sequence ();

[Bug fortran/67760] New: ICE on contained subroutine in function modifying function return value

[thomas.or...@uni-hamburg.de]

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

Bug ID: 67760
   Summary: ICE on contained subroutine in function modifying
function return value
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.or...@uni-hamburg.de
  Target Milestone: ---
  Host: x86_64-unknown-linux-gnu

Created attachment 36414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36414&action=edit
example code triggering the ICE

I get a reliable gfortran internal compiler error with all versions I tried so
far (version 5.1.0 picked as the one where the installation reports a backtrace 
that may be useful).

In my tests this affects gcc-4.8.3 (CentOS), gcc-4.1.2 (SLES) and
self-compiled vanilla gcc 4.9.2, 5.1.0, 5.2.0 . I therefore conclude that it
probably still is there in more current/upcoming releases.

The culprit is a contained subroutine inside a function that is accessing the 
return value of that function through the functions's name:

function fancy()
   !integer :: fancy  ! both gcc and icc happy
   !integer :: fancy(4)   ! gcc crash, icc depends on more_fancy
   integer :: fancy(3,2) ! gcc crash, icc depends on more_fancy

   call more_fancy

contains

subroutine more_fancy

   fancy = 42  ! Fine, generally.
   !fancy(:) = 42   ! icc giving error about substring
   !fancy(:,:) = 42 ! icc giving error about function name conflict
end subroutine

end function

I am not really sure what the standard says about this, especially since this 
works for a scalar return value for both gcc and the Intel compiler, and also
for an array if the first assignment in more_fancy is used. For a non-recursive
function, I actually don't see any problem when one considers the code of the
contained subroutine still being in the scope of the function.

But anyhow: At least an error should be produced instead of the compiler 
crashing. Example from gcc-5.1.0:

$ LANG=C gfortran -Wall -Wextra -o gfortran-ice gfortran-ice.f90 
gfortran-ice.f90:16:0:

 function fancy()
 ^
internal compiler error: Segmentation fault
0x90c276 crash_signal
/usr/src/gcc-5.1.0/gcc/toplev.c:383
0x2b47551271ef ???
   
/usr/src/glibc-2.21/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x97bd0a get_frame_type
/usr/src/gcc-5.1.0/gcc/tree-nested.c:263
0x97bd0a get_chain_decl
/usr/src/gcc-5.1.0/gcc/tree-nested.c:369
0x97e2ea get_chain_decl
/usr/src/gcc-5.1.0/gcc/tree-nested.c:875
0x97e2ea get_nonlocal_debug_decl
/usr/src/gcc-5.1.0/gcc/tree-nested.c:880
0x97e408 convert_nonlocal_reference_op
/usr/src/gcc-5.1.0/gcc/tree-nested.c:958
0xaff4e4 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*))
/usr/src/gcc-5.1.0/gcc/tree.c:11093
0x74f66c walk_gimple_op(gimple_statement_base*, tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/usr/src/gcc-5.1.0/gcc/gimple-walk.c:235
0x74f8d4 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/usr/src/gcc-5.1.0/gcc/gimple-walk.c:575
0x74fab0 walk_gimple_seq_mod(gimple_statement_base**, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/usr/src/gcc-5.1.0/gcc/gimple-walk.c:72
0x74f992 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/usr/src/gcc-5.1.0/gcc/gimple-walk.c:585
0x74fab0 walk_gimple_seq_mod(gimple_statement_base**, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/usr/src/gcc-5.1.0/gcc/gimple-walk.c:72
0x74f992 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/usr/src/gcc-5.1.0/gcc/gimple-walk.c:585
0x74fab0 walk_gimple_seq_mod(gimple_statement_base**, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
/usr/src/gcc-5.1.0/gcc/gimple-walk.c:72
0x97b7b1 walk_body
/usr/src/gcc-5.1.0/gcc/tree-nested.c:628
0x97ba5e walk_function
/usr/src/gcc-5.1.0/gcc/tree-nested.c:639
0x97ba5e walk_all_functions
/usr/src/gcc-5.1.0/gcc/tree-nested.c:704
0x97d2c7 lower_nested_functions(tree_node*)
/usr/src/gcc-5.1.0/gcc/tree-nested.c:3008
0x608d7b cgraph_node::analyze()
/usr/src/gcc-5.1.0/gcc/cgraphunit.c:640
Please submit a full bug report,
with preprocessed source if appropriate.
Ple

[Bug libstdc++/67747] experimental/filesystem/iterators/recursive_directory_iterator.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Proposed patch at https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02186.html

[Bug rtl-optimization/67736] Wrong optimization with -fexpensive-optimizations on mips64el

[aurelien at aurel32 dot net]

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

--- Comment #3 from Aurelien Jarno  ---
The ffmpeg testsuite is successful on mips64el-linux-gnu with this patch
applied.

[Bug bootstrap/67761] New: [6 Regression] Bootstrap failure on x86

[hjl.tools at gmail dot com]

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

Bug ID: 67761
   Summary: [6 Regression] Bootstrap failure on x86
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---

On Linux/x86, r228231 gave

make[6]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/coverage.o differs
gcc/dwarf2out.o differs
gcc/loop-iv.o differs
gcc/cp/init.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/predict.o differs
gcc/cfgloopmanip.o differs
gcc/tree-ssa-math-opts.o differs
gcc/function.o differs
gcc/tree-ssa-forwprop.o differs
gcc/tree-ssa-reassoc.o differs
gcc/tree-vect-loop.o differs
gcc/gimple-fold.o differs
gcc/loop-unroll.o differs
gcc/double-int.o differs
gcc/tree-ssa-alias.o differs
gcc/expr.o differs
gcc/gcov.o differs
gcc/i386-c.o differs
gcc/combine.o differs
gcc/tree-ssa-ccp.o differs
gcc/tree-chkp.o differs
gcc/fortran/trans-common.o differs
gcc/tree-vrp.o differs
gcc/var-tracking.o differs
gcc/tree-dfa.o differs
gcc/ipa-prop.o differs
gcc/gimple-ssa-strength-reduction.o differs
gcc/fold-const.o differs
gcc/dwarf2cfi.o differs
gcc/tree-ssa-sccvn.o differs
gcc/reload1.o differs
gcc/gcov-dump.o differs
gcc/mcf.o differs
gcc/tree-affine.o differs
gcc/tree-ssa-loop-niter.o differs
gcc/value-prof.o differs
libbacktrace/dwarf.o differs
libbacktrace/.libs/dwarf.o differs
libcpp/expr.o differs
libiberty/simple-object-coff.o differs
libiberty/pic/simple-object-coff.o differs
libiberty/pic/simple-object-xcoff.o differs
libiberty/simple-object-xcoff.o differs
Makefile:23262: recipe for target 'compare' failed
make[5]: *** [compare] Error 1
make[5]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
Makefile:23241: recipe for target 'stage3-bubble' failed
make[4]: *** [stage3-bubble] Error 2
make[4]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
Makefile:23304: recipe for target 'bootstrap' failed
make[3]: *** [bootstrap] Error 2
make[3]: Leaving directory '/export/gnu/import/git/gcc-test-ia32/bld'
14439.95user 447.65system 1:10:45elapsed 350%CPU (0avgtext+0avgdata
542356maxresident)k
144528inputs+14881128outputs (6202major+106936680minor)pagefaults 0swaps
Makefile:291: recipe for target 'bootstrap' failed
make[2]: *** [bootstrap] Error 2

when configured with

--with-arch=core2 --with-cpu=slm --prefix=/usr/6.0.0 --enable-clocale=gnu
--with-system-zlib --enable-shared --with-demangler-in-ld --enable-libmpx
i686-linux --with-fpmath=sse --enable-languages=c,c++,fortran,java,lto,objc

[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec

[zmi007 at gmail dot com]

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

zmi  changed:

   What|Removed |Added

 CC||zmi007 at gmail dot com

--- Comment #13 from zmi  ---
(In reply to vehre from comment #12)
Does it fix also the same situation with mold= specifier? f.e. in this simple
program?


program test_mold
   integer, allocatable, dimension(:) :: a,b
   type ac
  integer :: a
   end type ac
   type(ac), allocatable, dimension(:) :: aa,bb

   allocate(a(10))
   allocate(aa(10))
   allocate (b, mold=a) !<---
   allocate (bb, mold=aa) !<---

end program test_mold


gfortran --version
GNU Fortran (SUSE Linux) 5.2.1 20150721 [gcc-5-branch revision 226027]
Copyright (C) 2015 Free Software Foundation, Inc.
gfortran test_mold.f90 -o test_mold.xtest_mold.f90:11:13:

allocate (b, mold=a)
 1
Error: Array specification required in ALLOCATE statement at (1)
test_mold.f90:13:13:

allocate (bb, mold=aa)
 1
Error: Array specification required in ALLOCATE statement at (1)


Interpretation of F2008 6.7.1.2 is a bit tedious but mold= should work similar
to source= specifier ?

[Bug rtl-optimization/67037] [4.9/5/6 Regression] Wrong code at -O1 and above on ARM

[edlinger at gcc dot gnu.org]

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

Bernd Edlinger  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
   Assignee|unassigned at gcc dot gnu.org  |bernd.edlinger at 
hotmail dot de

--- Comment #5 from Bernd Edlinger  ---
change component to "rtl-optimization", as it is certainly not the target's
fault.

[Bug c++/67762] New: [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[trippels at gcc dot gnu.org]

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

Bug ID: 67762
   Summary: [C++1z] 'not a constant expression" errors only with
-fsanitize=undefined
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
  Target Milestone: ---

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

The attached testcase compiles fine without -fsanitize=undefined.

markus@x4 test % g++ -c -std=c++1z -Wall -Wextra variant.ii
markus@x4 test % g++ -c -fsanitize=undefined -std=c++1z -Wall -Wextra
variant.ii
/var/tmp/cmcstl2/test/variant.cpp: In function ‘void
{anonymous}::test_visit()’:
/var/tmp/cmcstl2/test/variant.cpp:886:5: error: non-constant condition for
static assertion
 static_assert(visit(f, V{42}, V{42}) == 84ull);
 ^
In file included from /var/tmp/cmcstl2/include/stl2/variant.hpp:30:0,
 from /var/tmp/cmcstl2/test/variant.cpp:16:
/var/tmp/cmcstl2/test/variant.cpp:886:24:   in constexpr expansion of
‘std::experimental::ranges_v1::__variant::visit&,
{std::experimental::ranges_v1::variant
, std::experimental::ranges_v1::variant}>(f,
std::experimental::ranges_v1::variant(42),
 std::experimental::ranges_v1::variant(42))’
/var/tmp/cmcstl2/include/stl2/detail/variant/visit.hpp:414:32:   in constexpr
expansion of
‘std::experimental::ranges_v1::__variant::visit_with_indices&>,
{std::experimental::ranges_v1::variant, std::experimental::ranges_v1::variant}>((*(UBSAN_NULL((&
std::experimental::ran
ges_v1::__variant::no_index_visitor&>{(*(UBSAN_NULL((&
std::forward&>((*(UBSAN_NULL((& f), 2u, 0u), (& f), 2u,
0u), (& std::forward&>((*(UBSAN_NULL((& f), 2u, 0u), (& f)))}), 2u, 8u), (&
std::experimental::ranges_v1::__variant::no_index_visitor&>{(*(UBSAN_NULL((&
std::forward
&>((*(UBSAN_NULL((& f), 2u, 0u), (& f), 2u, 0u), (&
std::forward&>((*(UBSAN_NULL((& f), 2u, 0u), (& f)))}))),
(*(UBSAN_NULL((& std::fo
rward >((*(UBSAN_NULL((& vs#0),
2u, 8u), (& vs#0)
, 2u, 8u), (& std::forward >((*(UBSAN_NULL((&
 vs#0), 2u, 8u), (& vs#0))), (*(UBSAN_NULL((&
std::forward >((*(UBSAN_NULL((& vs#1), 2u, 8u), (& vs#1), 2u, 8u), (&
std::forward >((*(UBSAN_NULL((& vs#1), 2u, 8u), (&
vs#1’
/var/tmp/cmcstl2/include/stl2/detail/variant/visit.hpp:388:36:   in constexpr
expansion of
‘std::experimental::ranges_v1::__variant::raw_visit_with_indices&>,
std::experimental::ranges_v1::variant,
std::experimental::ranges_v1::variant >, {std::experimental::ranges_v1::variant,
std::experimental::ranges_
v1::variant}>((*(UBSAN_NULL((&
std::experimental::ranges_v1::__variant::cooked_visitor<
std::experimental::ranges_v1::__variant::no_index_visitor&>,
std::experimental::ranges_v1::variant, std::experimental::ranges_v1::variant >{(*(UBSAN_NULL((& s
td::forward&>
>((*(UBSAN_NULL((& f), 2u, 8u), (& f), 2u, 8u), (&
std::forward&> >((*(UBSAN_NULL((&
f), 2u, 8u), (& f)))}), 2u, 8u), (&
std::experimental::ranges_v1::__variant::cooked_visitor&>,
std::experimental::ranges_v1::variant, std::experimental::ranges_v1::variant
>{(*(UBSAN_NULL((& st
d::forward&>
>((*(UBSAN_NULL((& f), 2u, 8u), (& f), 2u, 8u), (&
std::forward&> >((*(UBSAN_NULL((& f),
2u, 8u), (& f)))}))), (*(UBSAN_NULL((&
std::forward >((*(UBSAN_NULL((& vs#0), 2u, 8u), (& vs#0), 2u, 8u), (&
std::forward >((*(UBSAN_NULL((& vs#0), 2u, 8u), (&
vs#0))), (*(UBSAN_NU
LL((& std::forward
>((*(UBSAN_NULL((& vs#1), 2u, 
8u), (& vs#1), 2u, 8u), (&
std::forward >((*(
UBSAN_NULL((& vs#1), 2u, 8u), (& vs#1’
/var/tmp/cmcstl2/include/stl2/detail/variant/visit.hpp:300:13: error:
‘(std::experimental::ranges_v1::__variant::o1_visit_handler,
std::experimental::ranges_v1::__variant::cooked_visitor&>,
std::experimental::ranges_v1::var
iant, std::experimental::ranges_v1::variant >,
{std::experimental::ranges_v1::variant, 
std::experimental::ranges_v1::variant}> == 0u)’ is not a
constant expression
   STL2_CONSTEXPR_ASSUME(Dispatch::table[i]);
 ^
...

[Bug libstdc++/65393] std::thread shared_ptr inefficiency

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 29 12:54:05 2015
New Revision: 228242

URL: https://gcc.gnu.org/viewcvs?rev=228242&root=gcc&view=rev
Log:
Reduce space and time overhead of std::thread

PR libstdc++/65393
* config/abi/pre/gnu.ver: Export new symbols.
* include/std/thread (thread::_State, thread::_State_impl): New types.
(thread::_M_start_thread): Add overload taking unique_ptr<_State>.
(thread::_M_make_routine): Remove.
(thread::_S_make_state): Add.
(thread::_Impl_base, thread::_Impl, thread::_M_start_thread)
[_GLIBCXX_THREAD_ABI_COMPAT] Only declare conditionally.
* src/c++11/thread.cc (execute_native_thread_routine): Rename to
execute_native_thread_routine_compat and re-define to use _State.
(thread::_State::~_State()): Define.
(thread::_M_make_thread): Define new overload.
(thread::_M_make_thread) [_GLIBCXX_THREAD_ABI_COMPAT]: Only define old
overloads conditionally.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/abi/pre/gnu.ver
trunk/libstdc++-v3/include/std/thread
trunk/libstdc++-v3/src/c++11/thread.cc

[Bug libstdc++/65393] std::thread shared_ptr inefficiency

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
shared_ptr is no longer used on trunk.

[Bug fortran/44672] [F08] ALLOCATE with SOURCE and no array-spec

[vehre at gcc dot gnu.org]

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

--- Comment #14 from vehre at gcc dot gnu.org ---
Yes, it does, but the fix is due to its size only available on trunk.

[Bug c/67741] Invalid built-in usage should not cause segmentation fault in compiler

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 29 13:02:42 2015
New Revision: 228243

URL: https://gcc.gnu.org/viewcvs?rev=228243&root=gcc&view=rev
Log:
2015-09-29  Richard Biener  

PR tree-optimization/67741
* tree-ssa-math-opts.c (pass_cse_sincos::execute): Only recognize
builtin calls with correct signature.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67741.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-math-opts.c

[Bug fortran/67170] PRE can't hoist out a readonly argument

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 29 13:04:18 2015
New Revision: 228244

URL: https://gcc.gnu.org/viewcvs?rev=228244&root=gcc&view=rev
Log:
2015-09-29  Richard Biener  

PR tree-optimization/67170
* tree-ssa-alias.h (get_continuation_for_phi): Adjust
the translate function pointer parameter to get the
bool whether to disambiguate only by reference.
(walk_non_aliased_vuses): Likewise.
* tree-ssa-alias.c (maybe_skip_until): Adjust.
(get_continuation_for_phi_1): Likewise.
(get_continuation_for_phi): Likewise.
(walk_non_aliased_vuses): Likewise.
* tree-ssa-sccvn.c (const_parms): New bitmap.
(vn_reference_lookup_3): Adjust for interface change.
Disambiguate parameters pointing to readonly memory.
(free_scc_vn): Free const_parms.
(run_scc_vn): Initialize const_parms from a fn spec attribute.

* gfortran.dg/pr67170.f90: New testcase.

Added:
trunk/gcc/testsuite/gfortran.dg/pr67170.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-alias.c
trunk/gcc/tree-ssa-alias.h
trunk/gcc/tree-ssa-sccvn.c

[Bug other/67652] liboffloadmic/runtime/offload_engine.cpp:176: strange expression in sizeof ?

[iverbin at gcc dot gnu.org]

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

iverbin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from iverbin at gcc dot gnu.org ---
Fixed in trunk.
GCC 5 doesn't have such an issue.

[Bug tree-optimization/67741] Invalid built-in usage should not cause segmentation fault in compiler

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Component|c   |tree-optimization
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

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

[Bug fortran/67170] PRE can't hoist out a readonly argument

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug bootstrap/67761] [6 Regression] Bootstrap failure on x86

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Target Milestone|--- |6.0

[Bug target/67763] New: [SH] Redirect conditional branches

[olegendo at gcc dot gnu.org]

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

Bug ID: 67763
   Summary: [SH] Redirect conditional branches
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

In CSiBE renderMite.c there's the following sequence when compiled with -O2 -m4
-ml:

mov.l   @(16,r12),r4
tst r0,r0
mov r0,r11
movtr9
bt/s.L40   // (1)
mov r9,r0

mov.l   .L74,r0
mov r11,r5
jsr @r0
mov.l   @(16,r12),r4
or  r9,r0
.L40:
// if predecessor block is (1), then
//  T = r0 = 1
tst r0,r0   T = !r0 = 0
bf  .L42(2) always branch

bra .L41
mov r14,r9
.L42:
mov.l   .L87,r0
mov r15,r6
mov.l   .L76,r5
add #16,r6

The branch (1) can be "straightened" by redirecting it to .L42.

[Bug c/67764] New: -Wconversion generates false warnings for bitmask+cast expressions

[marcin.slusarz at intel dot com]

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

Bug ID: 67764
   Summary: -Wconversion generates false warnings for bitmask+cast
expressions
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marcin.slusarz at intel dot com
  Target Milestone: ---

void _setbit(unsigned char *b, unsigned int i)
{
b[i / 8] |= (unsigned char)(1 << (i % 8));
}
void _setbit_works(unsigned char *b, unsigned int i)
{
unsigned char ii = (unsigned char)(1 << (i % 8));
b[i / 8] |= ii;
}

void _mask_stupid(unsigned char *b, unsigned int i)
{
b[i] |= (unsigned char)i;
}

void _mask_stupid_works(unsigned char *b, unsigned int i)
{
unsigned char ii = (unsigned char)i;
b[i] |= ii;
}

$ gcc -c conversion_bug.c -Wconversion -o /dev/null

generates:

conversion_bug.c: In function ‘_setbit’:
conversion_bug.c:3:21: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value [-Wconversion]
 b[i / 8] |= (unsigned char)(1 << (i % 8));
 ^
conversion_bug.c: In function ‘_mask_stupid’:
conversion_bug.c:13:17: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value [-Wconversion]
 b[i] |= (unsigned char)i;
 ^


gcc-4.9.3 does *not* generate this warning, while gcc-5.2.1 does.


gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
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='Debian 5.2.1-17'
--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=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 5.2.1 20150911 (Debian 5.2.1-17)

[Bug testsuite/67583] libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/char/1.cc:92 erroneous call to sputn

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Author: redi
Date: Tue Sep 29 13:31:51 2015
New Revision: 228245

URL: https://gcc.gnu.org/viewcvs?rev=228245&root=gcc&view=rev
Log:
PR libstdc++/67583 Fix invalid sputn calls in tests

PR libstdc++/67583
* testsuite/27_io/basic_stringbuf/seekoff/char/1.cc: Fix sputn call
with mismatched arguments.
* testsuite/27_io/basic_stringbuf/seekoff/wchar_t/1.cc: Likewise.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/char/1.cc
trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/wchar_t/1.cc

[Bug target/67745] [ARM] wrong alignments when __attribute__ ((optimize,target,align) is used

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Target||arm
   Target Milestone|--- |6.0

[Bug testsuite/67583] libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/char/1.cc:92 erroneous call to sputn

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Indeed, thanks for the report. It's fixed now.

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[olegendo at gcc dot gnu.org]

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

--- Comment #19 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #18)
> (In reply to Oleg Endo from comment #16)
> > Regardless of those, Kaz, can you please commit attachment 36397 [details]? 
> > Then I can handle the other cases on top of that.
> 
> Done.

Thank you.  Since this was reported for GCC 5, I think it should be backported.
 It's not a regression, but a latent issue.  If you have no objections, I can
do it.

[Bug other/67698] internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2297

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #3 from H.J. Lu  ---
Fixed on hjl/interrupt/master branch.

[Bug other/67552] [meta] x86 interrupt attribute

[hjl.tools at gmail dot com]

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

Bug 67698 Summary: internal compiler error: in maybe_record_trace_start, at 
dwarf2cfi.c:2297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67698

   What|Removed |Added

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

[Bug target/67765] New: [SH] Improve treg_combine pass

[olegendo at gcc dot gnu.org]

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

Bug ID: 67765
   Summary: [SH] Improve treg_combine pass
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olegendo at gcc dot gnu.org
  Target Milestone: ---
Target: sh*-*-*

Currently the sh_treg_combine.cc pass uses conditional branches as a trigger
for its optimizations.  However, if the addsicc pattern is added from PR 54236
attachment 36012, then the following reduced test case, compiled with -O2 -m4
-ml, will exhibit the following sequence:

cmp/eq  #32,r0
movtr7
.L7:
cmp/hi  r6,r2
bf/s.L8
tst r7,r7 << r7 known to be 0 or 1 because of preceeding movt
mov #-1,r1
addcr1,r2 << r7 == 0: r2 = r2 + (-1) + 1 = r2 + 0
 r7 == 1: r2 = r2 + (-1) + 0 = r2 - 1
 r2 = r2 - r1

Without the addsicc pattern, a "sub r1,r2" is generated.  The treg_combine pass
should actually be triggered by the tst insn and should propagate known reg
values that originated from a movt or movrt insn into the following insns.


extern void free_bootmem (unsigned long addr, unsigned long size);

struct { unsigned long addr, size, type; } memory_chunk[16] = { { 0 } };

static char command_line[896] = { 0, };

void setup_arch(char **cmdline_p)
{
  char c = ' ', cn, *to = command_line, *from = ((char *) (0x10480));
  unsigned long start_pfn, end_pfn;
  int i = 0;

  for (;;)
  {
cn = *(from++);
if (!cn)
  break;
if (cn == ' ' && c == ' ')
  continue;
c = cn;
if (to - command_line >= 896)
  break;
*(to++) = c;
  }

  if (c == ' ' && to > command_line)
to--;

  *to = '\0';

  unsigned long start_chunk, end_chunk;

  start_chunk = (memory_chunk[i].addr + (1UL << 12) - 1);
  start_chunk >>= 12;
  end_chunk = (memory_chunk[i].addr + memory_chunk[i].size);

  end_chunk >>= 12;
  if (start_chunk < start_pfn)
start_chunk = start_pfn;
  if (end_chunk > end_pfn)
end_chunk = end_pfn;
  if (start_chunk < end_chunk)
free_bootmem(start_chunk << 12, (end_chunk - start_chunk) << 12);
}

[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-29
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  I'll reduce this to something more usable.

Note that I get ICE with gcc-5:

In file included from /var/tmp/cmcstl2/include/stl2/type_traits.hpp:16:0,
 from /var/tmp/cmcstl2/test/variant.cpp:15:
/var/tmp/cmcstl2/include/stl2/detail/fwd.hpp:47:5: error: ‘requires’ does not
name a type
In file included from /var/tmp/cmcstl2/include/stl2/type_traits.hpp:18:0,
 from /var/tmp/cmcstl2/test/variant.cpp:15:
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:24:3: error: ‘concept’
does not name a type
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:27:3: error: ‘concept’
does not name a type
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:30:3: error: ‘concept’
does not name a type
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:33:3: error: ‘concept’
does not name a type
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:42:5: error: ‘concept’
does not name a type
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:55:32: error:
‘std::experimental::ranges_v1::detail::_Same’ has not been declared
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:55:37: error: expected
‘>’ before ‘<’ token
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:56:28: error: ‘Rest’ was
not declared in this scope
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:56:32: error: expected
parameter pack before ‘...’
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:56:20: error: template
argument 2 is invalid
/var/tmp/cmcstl2/include/stl2/detail/concepts/core.hpp:56:20: internal compiler
error: tree check: expected tree_vec, have error_mark in
get_innermost_template_args, at cp/pt.c:595
0xf2bdac tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/marek/src/gcc/gcc/tree.c:9297
0x652619 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marek/src/gcc/gcc/tree.h:2851
0x652619 get_innermost_template_args(tree_node*, int)
/home/marek/src/gcc/gcc/cp/pt.c:595
0x6a23e3 process_partial_specialization
/home/marek/src/gcc/gcc/cp/pt.c:4148
0x6a4467 push_template_decl_real(tree_node*, bool)
/home/marek/src/gcc/gcc/cp/pt.c:4907
0x640104 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
/home/marek/src/gcc/gcc/cp/decl.c:4839
0x735afd cp_parser_init_declarator
/home/marek/src/gcc/gcc/cp/parser.c:17195
0x736702 cp_parser_single_declaration
/home/marek/src/gcc/gcc/cp/parser.c:23850
0x7369b8 cp_parser_template_declaration_after_export
/home/marek/src/gcc/gcc/cp/parser.c:23641
0x73bf19 cp_parser_declaration
/home/marek/src/gcc/gcc/cp/parser.c:11343
0x73a41a cp_parser_declaration_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:11265
0x73ac95 cp_parser_namespace_body
/home/marek/src/gcc/gcc/cp/parser.c:16293
0x73ac95 cp_parser_namespace_definition
/home/marek/src/gcc/gcc/cp/parser.c:16274
0x73be79 cp_parser_declaration
/home/marek/src/gcc/gcc/cp/parser.c:11367
0x73a41a cp_parser_declaration_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:11265
0x73ac95 cp_parser_namespace_body
/home/marek/src/gcc/gcc/cp/parser.c:16293
0x73ac95 cp_parser_namespace_definition
/home/marek/src/gcc/gcc/cp/parser.c:16274
0x73be79 cp_parser_declaration
/home/marek/src/gcc/gcc/cp/parser.c:11367
0x73a41a cp_parser_declaration_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:11265
0x73ac95 cp_parser_namespace_body
/home/marek/src/gcc/gcc/cp/parser.c:16293
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/67766] New: [6 Regression]: Bootstrap failure on alpha-linux-gnu: ICE in simplify_subreg, at simplify-rtx.c

[ubizjak at gmail dot com]

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

Bug ID: 67766
   Summary: [6 Regression]: Bootstrap failure on alpha-linux-gnu:
ICE in simplify_subreg, at simplify-rtx.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
CC: aoliva at gcc dot gnu.org
  Target Milestone: ---
Target: alpha-linux-gnu

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

alpha-linux-gnu bootstrap is currently broken due to r228175:

2015-09-27  Alexandre Oliva 

PR rtl-optimization/64164
PR tree-optimization/67312
PR middle-end/67340
PR middle-end/67490
PR bootstrap/67597
* cfgexpand.c (parm_in_stack_slot_p): Remove.
(ssa_default_def_partition): Remove.
(get_rtl_for_parm_ssa_default_def): Remove.
(set_rtl): Check that RTL assignments match expectations.
Loop on SUBREGs, CONCATs and PARALLELs subexprs.  Set only the
default def location for params and results.  Record SSA names
or types in REG and MEM attrs, respectively.
...

The ICE can be reproduced with a crosscompiler from x86_64-linux-gnu to
alpha-linux-gnu, configured with: --target=alpha-linux-gnu --enable-languages=c
--with-long-double-128

~/gcc-build-alpha/gcc/cc1 -O2 -quiet -fpreprocessed -o libgcc2.o libgcc2.i
/space/homedirs/uros/gcc-svn/trunk/libgcc/libgcc2.c: In function ‘__mulsc3’:
/space/homedirs/uros/gcc-svn/trunk/libgcc/libgcc2.c:1992:1: internal compiler
error: in simplify_subreg, at simplify-rtx.c:5807
0xa50bb0 simplify_subreg(machine_mode, rtx_def*, machine_mode, unsigned int)
../../gcc-svn/trunk/gcc/simplify-rtx.c:5807
0xa5104c simplify_gen_subreg(machine_mode, rtx_def*, machine_mode, unsigned
int)
../../gcc-svn/trunk/gcc/simplify-rtx.c:6031
0xa1a494 gen_lowpart_general(machine_mode, rtx_def*)
../../gcc-svn/trunk/gcc/rtlhooks.c:54
0x7885cf convert_move(rtx_def*, rtx_def*, int)
../../gcc-svn/trunk/gcc/expr.c:581
0x7e6edd expand_function_end()
../../gcc-svn/trunk/gcc/function.c:5461
0x67c669 construct_exit_block
../../gcc-svn/trunk/gcc/cfgexpand.c:5820
0x67c669 execute
../../gcc-svn/trunk/gcc/cfgexpand.c:6326
Please submit a full bug report,
[...]

gdb session:

Breakpoint 1, internal_error (gmsgid=0x11f6cd5 "in %s, at %s:%d") at
../../gcc-svn/trunk/gcc/diagnostic.c:1134
1134internal_error (const char *gmsgid, ...)
(gdb) bt
#0  internal_error (gmsgid=0x11f6cd5 "in %s, at %s:%d") at
../../gcc-svn/trunk/gcc/diagnostic.c:1134
#1  0x0102091c in fancy_abort (file=, line=5807, 
function=0x1121860  "simplify_subreg")
at ../../gcc-svn/trunk/gcc/diagnostic.c:1209
#2  0x00a50bb1 in simplify_subreg (outermode=VOIDmode,
op=0x2eae4d20, innermode=SCmode, byte=0)
at ../../gcc-svn/trunk/gcc/simplify-rtx.c:5807
#3  0x00a5104d in simplify_gen_subreg (outermode=18836693, 
op=0x1121860 , innermode=17959616, byte=5807)
at ../../gcc-svn/trunk/gcc/simplify-rtx.c:6031
#4  0x00a1a495 in gen_lowpart_general (mode=VOIDmode, x=0x2eae4d20)
at ../../gcc-svn/trunk/gcc/rtlhooks.c:54
#5  0x007885d0 in convert_move (to=0x2ea95df0, from=, unsignedp=0) at ../../gcc-svn/trunk/gcc/expr.c:581
#6  0x007e6ede in expand_function_end () at
../../gcc-svn/trunk/gcc/function.c:5461
#7  0x0067c66a in construct_exit_block () at
../../gcc-svn/trunk/gcc/cfgexpand.c:5820
#8  (anonymous namespace)::pass_expand::execute (this=,
fun=0x2ea8b348) at ../../gcc-svn/trunk/gcc/cfgexpand.c:6326

convert_move tries to generate a VOIDmode subreg:

(gdb) f 5
#5  0x007885d0 in convert_move (to=0x2ea95df0, from=, unsignedp=0) at ../../gcc-svn/trunk/gcc/expr.c:581
581   emit_move_insn (to, gen_lowpart (to_mode, from));
(gdb) p debug_rtx (to)
(parallel/i [
(expr_list:REG_DEP_TRUE (reg:SF 32 $f0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:SF 33 $f1)
(const_int 4 [0x4]))
])
$4 = void
(gdb) f 4
#4  0x00a1a495 in gen_lowpart_general (mode=VOIDmode, x=0x2eae4d20)
at ../../gcc-svn/trunk/gcc/rtlhooks.c:54
54rtx result = gen_lowpart_common (mode, x);
(gdb) p mode
$5 = VOIDmode
(gdb) p debug_rtx (x)
(concat:SC (reg:SF 608)
(reg:SF 609))
$6 = void

[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
The compile-time error goes away when adding
-fno-sanitize=null,returns-nonnull-attribute,nonnull-attribute to the
command-line options.

[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Not reducing anymore; creduce dies for me :(.

[Bug target/55212] [SH] Switch to LRA

[olegendo at gcc dot gnu.org]

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

--- Comment #117 from Oleg Endo  ---
(In reply to Oleg Endo from comment #94)
> Kaz, do you think we can enable LRA by default for GCC 6?
> 
> Some early results from the AMS optimization show new R0 spill failures. 
> For example, AMS uses @(R0,Rn) address modes more often.  Although I still
> would like to try this R0 prealloc pass, I don't know when I will have time
> for that.  Enabling LRA might be easier.

So I've tried compiling the CSiBE set with AMS and LRA.  The AMS branch still
has some problems, but without LRA CSiBE at least compiles without errors. 
With LRA I get a lot of:

ll_rw_blk.i: In function 'generic_plug_device':
ll_rw_blk.i:8464:1: error: unable to find a register to spill
 }
 ^
ll_rw_blk.i:8464:1: error: this is the insn:
(insn 32 74 61 5 (set (mem/j:QI (plus:SI (reg/v/f:SI 170 [ q ])
(reg:SI 283 [272])) [0 q_2(D)->plugged+0 S1 A32])
(reg:QI 0 r0)) ll_rw_blk.i:8462 276 {*movqi}
 (expr_list:REG_DEAD (reg:SI 283 [272])
(expr_list:REG_DEAD (reg:QI 0 r0)
(nil
ll_rw_blk.i:8464:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1431

It seems it has trouble rearranging this:

   mov.b  r0,@(Rm,Rn)

into
   mov.b  Rx,@(R0,Rn)

[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
(In reply to Marek Polacek from comment #3)
> Not reducing anymore; creduce dies for me :(.

Yes, I was unsuccessful in reducing it with creduce, too.
(Well, clang doesn't support C++ concepts yet, so perhaps it is not
too surprising.)

[Bug target/67732] [SH] Strange LRA addsi3 usage

[olegendo at gcc dot gnu.org]

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

--- Comment #3 from Oleg Endo  ---
Hm, those addressing mode issues are supposed to be improved by the AMS pass. 
But it's not ready yet.

Compiling CSiBE with the current AMS branch, without LRA:

sum:  879 -> 3318319-15560 / -0.466724 %

and teem is again the bigger chunk:

total:   1106660 -> 1098296-8364 / -0.755788 %

It seems that the big improvement there comes from better utilization of
post-inc/pre-dec and index-mode FP loads/stores.

Unfortunately, running AMS + LRA doesn't work, so I can't get any numbers for
that ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212#c117 )

[Bug c/67730] [5/6 Regression] No warning when returning NULL in void function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-29
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #4 from Marek Polacek  ---
Mine then.

[Bug c++/67767] New: -Wsuggest-attribute=noreturn suggests noreturn for function which already has noreturn and cold.

[zerotype at yahoo dot com]

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

Bug ID: 67767
   Summary: -Wsuggest-attribute=noreturn suggests noreturn for
function which already has noreturn and cold.
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zerotype at yahoo dot com
  Target Milestone: ---

(Observed in Ubuntu builds of g++ 4.9.2 and 5.1.0)

I have a class containing various function pointers which are initialised
depending on command-line parameters specified by the user. To catch any bugs
which could result in one of the pointers not pointing to a valid function, the
class's constructor normally default-initialises them to point to functions
which throw exceptions - like so:

//header file containing declaration:
> typedef void (*objfunc_entity_specific_assignment_function)   
> (objective_function_struct& ofs, gmips_entity_specific_information_struct& 
> gesis, const sbox_size_object& sso);
> void entity_specific_assignment_function_not_set  [[gnu::cold, 
> gnu::noreturn]] (objective_function_struct& ofs, 
> gmips_entity_specific_information_struct& gesis, const sbox_size_object& sso);

//cpp file:
> void entity_specific_assignment_function_not_set(objective_function_struct& 
> ofs, gmips_entity_specific_information_struct& gesis, const sbox_size_object& 
> sso)
> {
>   throw misc_exception(__FILE__" " + std::string(__PRETTY_FUNCTION__) + " 
> called.\n");
> }

Before I added the gnu::cold attribute, compiling with
-Wsuggest-attribute=noreturn did not result in the noreturn attribute being
suggested, because of course the function already had it. After changing from
[[gnu::noreturn]] to [[gnu::cold, gnu::noreturn]] I get:

> warning: function might be candidate for attribute ‘noreturn’ 
> [-Wsuggest-attribute=noreturn]
> void entity_specific_assignment_function_not_set(objective_function_struct& 
> ofs, gmips_entity_specific_information_struct& gesis, const sbox_size_object&
>  ^

[Bug c++/67767] -Wsuggest-attribute=noreturn suggests noreturn for function which already has noreturn and cold.

[zerotype at yahoo dot com]

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

--- Comment #1 from zerotype at yahoo dot com ---
This particular use case also challenges the assertion in the GCC documentation
that "It does not make sense for a noreturn function to have a return type
other than void.". Some of the function pointers are to functions with non-void
return types, and so the exception-throwing default functions have to have
these as well, to have the correct signature for the pointer.

[Bug c++/67768] New: Second and subsequent captured variable in variadic template unpaking are default constructed

[dtyazskwindows7 at gmail dot com]

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

Bug ID: 67768
   Summary: Second and subsequent captured variable in variadic
template unpaking are default constructed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dtyazskwindows7 at gmail dot com
  Target Milestone: ---

When you compile and run the following code in gcc6.0
=
#include
#include
#include

templateT echo(T v)
{
return v;
}
templateauto run(std::index_sequence)
{
int x = 10;
return std::make_tuple(echo([y=x](){std::cout<());
std::get<0>(v)();
std::get<1>(v)();
std::get<2>(v)();
}

output is as follows:
10
0
0

[Bug middle-end/67754] [graphite] Many testsuite failures

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |spop at gcc dot gnu.org

--- Comment #1 from Sebastian Pop  ---
All these tests are passing with ISL-0.15.

I also tried with ISL-0.14.1 and most of the tests are failing as reported,
with the exception of gfortran.dg/graphite/block-1.f90 that is passing on my
side.  This may be related to the fact that we have not built a bootstrap
compiler with ISL-0.14.1.

We will investigate first the wrong code for the interchange-* files, and then
we will try to reproduce the error in block-1.f90.

[Bug target/67718] [aarch64] long double incorrect code for copysign

[thanm at google dot com]

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

--- Comment #2 from Than McIntosh  ---

>>using __builtin_copysignl should generate better code generation anyways.

Tried replacing the guts of the function with a call to __builtin_copysignl --
the bug is still present.

Any recommendations on someone in the extended GCC community who could help me
triage/analyze the bug? I have worked with register allocators before, but not
with gcc's; I could use some guidance.

[Bug middle-end/67754] [graphite] Many testsuite failures

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
We diffed the output of -fdump-tree-graphite-all for interchange-1.c and the
problem seems to be related to the ISL scheduler: I would highly recommend that
people stop using outdated ISL versions.

with ISL 0.15, the code generated looks like this:

ISL AST generated by ISL: 
{
  for (int c1 = 0; c1 <= 1334; c1 += 51)
for (int c2 = 0; c2 <= 1334; c2 += 51)
  for (int c3 = c1; c3 <= min(1334, c1 + 50); c3 += 1)
for (int c4 = c2; c4 <= min(1334, c2 + 50); c4 += 1)
  S_4(c3, c4);
  for (int c1 = 0; c1 <= 1334; c1 += 1)
S_10(c1);
  S_8();
}

with ISL 0.14:

ISL AST generated by ISL: 
{
  for (int c0 = -1377; c0 < 0; c0 += 51)
for (int c1 = -1326; c1 <= c0 + 70; c1 += 51)
  for (int c2 = max(max(-1334, c0), c1 - 20); c2 <= c0 + 50; c2 += 1)
for (int c3 = max(-1314, c1); c3 <= min(c1 + 50, c2 + 20); c3 += 1)
  S_4(c2 - c3 + 20, -c3 + 20);
  for (int c1 = -1326; c1 < 0; c1 += 51) {
for (int c3 = max(-1314, c1); c3 <= c1 + 50; c3 += 1) {
  S_4(-c3 + 20, -c3 + 20);
  S_10(-c3 + 20);
}
for (int c2 = 1; c2 <= min(50, c1 + 1364); c2 += 1)
  for (int c3 = max(c1, c2 - 1314); c3 <= c1 + 50; c3 += 1)
S_4(c2 - c3 + 20, -c3 + 20);
  }
  S_4(20, 20);
  S_10(20);
  S_8();
  for (int c3 = 1; c3 <= 20; c3 += 1) {
S_4(-c3 + 20, -c3 + 20);
S_10(-c3 + 20);
  }
  for (int c2 = 1; c2 <= 50; c2 += 1)
for (int c3 = 0; c3 <= 20; c3 += 1)
  S_4(c2 - c3 + 20, -c3 + 20);
  for (int c0 = 51; c0 <= 1334; c0 += 51)
for (int c1 = c0 - 1326; c1 <= 20; c1 += 51)
  for (int c2 = c0; c2 <= min(min(1334, c0 + 50), c1 + 1364); c2 += 1)
for (int c3 = max(c1, c2 - 1314); c3 <= min(20, c1 + 50); c3 += 1)
  S_4(c2 - c3 + 20, -c3 + 20);
}

[Bug middle-end/67754] [graphite] Many testsuite failures

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
(In reply to Sebastian Pop from comment #2)
> We diffed the output of -fdump-tree-graphite-all for interchange-1.c and the
> problem seems to be related to the ISL scheduler: I would highly recommend
> that people stop using outdated ISL versions.
> 
> with ISL 0.15, the code generated looks like this:

Should we require ISL 0.15 for trunk?

[Bug bootstrap/67761] [6 Regression] Bootstrap failure on x86

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-29
   Assignee|unassigned at gcc dot gnu.org  |ienkovich at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ilya Enkovich  ---
The problem is in debug insns which are not ignored by introduced
transformation. It results in cost model affected by debug info and causes
these comparison failures.  I'm testing this fix:

diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 6f2380f..7b3ffb0 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -2919,6 +2919,10 @@ scalar_chain::analyze_register_chain (bitmap candidates,
df_ref ref)
   for (chain = DF_REF_CHAIN (ref); chain; chain = chain->next)
 {
   unsigned uid = DF_REF_INSN_UID (chain->ref);
+
+  if (!NONDEBUG_INSN_P (DF_REF_INSN (chain->ref)))
+   continue;
+
   if (!DF_REF_REG_MEM_P (chain->ref))
{
  if (bitmap_bit_p (insns, uid))
@@ -3279,7 +3283,7 @@ scalar_chain::convert_reg (unsigned regno)
bitmap_clear_bit (conv, DF_REF_INSN_UID (ref));
  }
   }
-else
+else if (NONDEBUG_INSN_P (DF_REF_INSN (ref)))
   {
replace_rtx (DF_REF_INSN (ref), reg, scopy);
df_insn_rescan (DF_REF_INSN (ref));

[Bug c/67769] New: VRP pass does wrong optimization

[bmei at broadcom dot com]

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

Bug ID: 67769
   Summary: VRP pass does wrong optimization
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmei at broadcom dot com
  Target Milestone: ---

#include 

static int
clamp (int x, int lo, int hi)
{
return (x < lo) ? lo : ((x > hi) ? hi : x);
}


__attribute__((noinline))
short
foo (int N)
{
short value =
clamp (N, 0, 16);


return value;
}

int main ()
{
  if (foo (-5) != 0)
abort();
  return 0;
}


Compile this simple code and run. 

bash:bmei:xl-cam-21:34271> ~/scratch/install-x86/bin/gcc tst.c -O2
bash:bmei:xl-cam-21:34272> ./a.out
Aborted
bash:bmei:xl-cam-21:34273> ~/scratch/install-x86/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/bmei/scratch/install-x86/bin/gcc
COLLECT_LTO_WRAPPER=/projects/firepath_tools1_scratch/bmei/install-x86/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../trunk/configure
--prefix=/projects/firepath_tools1_scratch/bmei/install-x86 --disable-nls
--with-mpfr=/projects/firepath_tools/work/bmei/packages/mpfr/2.4.1/x86-64
--with-gmp=/projects/firepath_tools/work/bmei/packages/gmp/4.3.0/x86-64
--with-mpc=/projects/firepath_tools/work/bmei/packages/mpc/0.8.1/x86-64
--disable-libsanitizer --disable-target-libsanitizer CFLAGS='-O0 -g3'
CXXFLAGS='-O0 -g3' --enable-languages=c --no-recursion --disable-bootstrap :
(reconfigured) ../trunk/configure
--prefix=/projects/firepath_tools1_scratch/bmei/install-x86 --disable-nls
--with-mpfr=/projects/firepath_tools/work/bmei/packages/mpfr/2.4.1/x86-64
--with-gmp=/projects/firepath_tools/work/bmei/packages/gmp/4.3.0/x86-64
--with-mpc=/projects/firepath_tools/work/bmei/packages/mpc/0.8.1/x86-64
--disable-libsanitizer --disable-target-libsanitizer CFLAGS='-O0 -g3'
CXXFLAGS='-O0 -g3' --disable-bootstrap --enable-languages=c,lto --no-create
--no-recursion
Thread model: posix
gcc version 6.0.0 20150929 (experimental) [trunk revision 143368] (GCC)


I looked into the tree dump, it seems that VRP2 pass. The second MAX_EXPR is
folded.

Folding statement: iftmp.0_3 = MIN_EXPR ;
Not folded
Folding statement: iftmp.0_6 = MAX_EXPR ;
Folded into: iftmp.0_6 = iftmp.0_3;

Folding statement: value_4 = (short int) iftmp.0_6;
Not folded
Folding statement: return value_4;
Not folded
foo (int N)
[ noinline ]
{
  short int value;
  int iftmp.0_3;
  int iftmp.0_6;

  :
  iftmp.0_3 = MIN_EXPR ;
  iftmp.0_6 = iftmp.0_3;
  value_4 = (short int) iftmp.0_6;
  return value_4;

}

[Bug middle-end/67754] [graphite] Many testsuite failures

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
The release managers will decide the requirements and when lib versions will be
deprecated.

I am still investigating a fix to continue supporting ISL-0.14: we will add
code to configure.ac to detect ISL version number based on which we will
disable functionality that we know is broken for older ISL versions.

[Bug ipa/66424] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode

[vmakarov at gcc dot gnu.org]

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

--- Comment #9 from Vladimir Makarov  ---
Author: vmakarov
Date: Tue Sep 29 16:37:26 2015
New Revision: 228256

URL: https://gcc.gnu.org/viewcvs?rev=228256&root=gcc&view=rev
Log:
2015-09-29  Vladimir Makarov  

Backport from mainline
2015-07-21  Vladimir Makarov  

PR ipa/66424.
* lra-remat.c (operand_to_remat): Prevent using insns with input
subregs processed separately by IRA.

2015-09-29  Vladimir Makarov  

Backport from mainline
2015-07-21  Vladimir Makarov  

PR ipa/66424.
* gcc.target/i386/pr66424.c: New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr66424.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/lra-remat.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

  Attachment #36415|0   |1
is obsolete||

--- Comment #5 from Markus Trippelsdorf  ---
Created attachment 36417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36417&action=edit
Somewhat reduced testcase

C-Reduce 2.4.0 was released yesterday, which doesn't crash anymore.
Somewhat reduced testcase attached.

[Bug fortran/67431] ALLOCATE with SOURCE ignores overloaded assignment operator and uses intrinsic when copying values

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Dominique d'Humieres  ---
No feedback! closing as INVALID.

[Bug fortran/63205] [OOP] Wrongly rejects type = class (for identical declared type)

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #15 from Dominique d'Humieres  ---
No feedback for almost six months. Closing as FIXED. Please open new PR(s) for
remaining issue(s).

[Bug fortran/58644] [OOP] Missing .data ref in passing a CLASS array as actual argument to a TYPE.

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> I believe that my imminent fix for PR63205 will correct this issue
> and so eliminate this PR.

Does it? If yes, this PR should be closed as FIXED. If no, what is missing?

[Bug fortran/61960] internal compiler error: in gfc_conv_component_ref

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #6 from Dominique d'Humieres  ---
> I guess it is okay to consider the issue solved.

So closing as FIXED.

[Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-29
Summary|[GCC 6 regression] ICE on   |[GCC 6 regression] ICE on
   |invalid code|invalid use of COMMON
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
WORKSFORME!

pr67758.f90:1:26:

   COMMON /FMCOM / X(80 000 000)
  1
Error: Expected another dimension in array declaration at (1)
pr67758.f90:3:24:

   COMMON /FMCOM / XX(80 000 000)
1
Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)

with r227016 (2015-08-19) and all the revisions I have tested (I have added an
END statement). Could you please post the output of 'gfortran -v'?

[Bug fortran/67721] deep copy missing when assigning a derived type constructor to an array

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
Any plan to back port the fix to 5.3? If no, the PR could be closed as FIXED.

[Bug fortran/67721] deep copy missing when assigning a derived type constructor to an array

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-29
 Ever confirmed|0   |1

[Bug tree-optimization/67769] [6 Regression] VRP pass does wrong optimization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-29
   Target Milestone|--- |6.0
Summary|VRP pass does wrong |[6 Regression] VRP pass
   |optimization|does wrong optimization
 Ever confirmed|0   |1
   Severity|major   |normal

--- Comment #1 from Marek Polacek  ---
Started with r226809.

[Bug tree-optimization/67769] [6 Regression] VRP pass does wrong optimization

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
Probably phiopt not clearing the flow sensitive info.

[Bug tree-optimization/67769] [6 Regression] VRP pass does wrong optimization

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Yea, something like that.  I'm taking this; it's sort of dependent on my patch
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg02210.html (we'll probably need
to call reset_flow_sensitive_info_in_bb somewhere to fix this).

[Bug ipa/66424] [5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu in 32-bit mode

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

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

--- Comment #10 from Matthias Klose  ---
fixed on trunk and the gcc-5 branch.

[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

  Attachment #36417|0   |1
is obsolete||

--- Comment #6 from Markus Trippelsdorf  ---
Created attachment 36418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36418&action=edit
Somewhat reduced testcase

[Bug target/67770] New: i386: -fshrink-wrap can interact badly with trampolines

[felix.von.s at posteo dot de]

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

Bug ID: 67770
   Summary: i386: -fshrink-wrap can interact badly with
trampolines
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.von.s at posteo dot de
  Target Milestone: ---

Created attachment 36419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36419&action=edit
Miscompiled program

Compiling the attached program with -m32 -DCRASH=1 produces a crash on run
time. Without either switch, the program runs fine (the host is x86-64).

The reason for crashing can be revealed by inspecting the generated assembly:
the instruction which pushes the trampoline context on the stack is moved along
with the frame setup code from the very start of the function where the
trampoline expects it to be. The crucial optimisation seems to be
-fshrink-wrap; however, for some reason I was unable to trigger the bug without
enabling the full -O1 optimisation level, even by manually listing all the
-f... options enabled by -O1.

[Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #1)
> WORKSFORME!
> 
> pr67758.f90:1:26:
> 
>COMMON /FMCOM / X(80 000 000)
>   1
> Error: Expected another dimension in array declaration at (1)
> pr67758.f90:3:24:
> 
>COMMON /FMCOM / XX(80 000 000)
> 1
> Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)
> 
> with r227016 (2015-08-19) and all the revisions I have tested (I have added
> an END statement). Could you please post the output of 'gfortran -v'?

troutmask:sgk[204] gfc6 -c r5.f
f951: internal compiler error: Segmentation fault
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
troutmask:sgk[205] gfc5 -c r5.f
r5.f:3:24:

   COMMON /FMCOM / XX(80 000 000)
1
Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)
f951: Error: Unexpected end of file in 'r5.f'
troutmask:sgk[206] gfc49 -c r5.f
r5.f:3.24:

  COMMON /FMCOM / XX(80 000 000)
1
Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)
Error: Unexpected end of file in 'r5.f'

Looks like a regression in symbol.c.

(gdb) p p->common_block->head->common_next
$9 = (gfc_symbol *) 0x0
(gdb) list
3205  else
3206{
3207  gfc_symbol *cparent, *csym;
3208
3209  cparent = p->common_block->head;
3210  csym = cparent->common_next;
3211
3212  while (csym != p)
3213{
3214  cparent = csym;
3215  csym = csym->common_next;
3216}
3217
3218  gcc_assert(cparent->common_next == p);
3219  cparent->common_next = csym->common_next;
3220}
3221}

[Bug c/67764] -Wconversion generates false warnings for bitmask+cast expressions

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #1 from Eric Gallager  ---
Remember, x |= y is the same as x = (x | y). So if we rewrite the problematic
conversions like that, it becomes clearer where the warning is really pointing:

$ /usr/local/bin/gcc -c conversion_bug.c -Wconversion
conversion_bug.c: In function ‘_setbit’:
conversion_bug.c:4:13: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value [-Wconversion]
  b[i / 8] = (b[i / 8] | (unsigned char)(1 << (i % 8)));
 ^
conversion_bug.c: In function ‘_mask_stupid’:
conversion_bug.c:15:9: warning: conversion to ‘unsigned char’ from ‘int’ may
alter its value [-Wconversion]
  b[i] = (b[i] | (unsigned char)i);
 ^

If you cast the entire expression after it has been re-written like that, the
warning goes away:

b[i / 8] = (unsigned char)(b[i / 8] | (unsigned char)(1 << (i % 8)));
b[i] = (unsigned char)(b[i] | (unsigned char)i);

(no warnings generated for either of those)

[Bug target/59672] Add -m16 support for x86

[felix.von.s at posteo dot de]

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

felix  changed:

   What|Removed |Added

 CC||felix.von.s at posteo dot de

--- Comment #10 from felix  ---
Out of curiosity: given that hjl's -m16 patch has been merged, is there a
reason for keeping this open? Is anyone hoping to have a more complete support
for x86-16 target, or at least to drop the .code16gcc kludge?

[Bug target/59672] Add -m16 support for x86

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #11 from H.J. Lu  ---
Fixed for 4.9.0.

[Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl  ---
On Tue, Sep 29, 2015 at 07:56:16PM +, kargl at gcc dot gnu.org wrote:
> 
> troutmask:sgk[204] gfc6 -c r5.f
> f951: internal compiler error: Segmentation fault
> no stack trace because unwind library not available
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

This fixes the regression.

Index: symbol.c
===
--- symbol.c(revision 228264)
+++ symbol.c(working copy)
@@ -3211,6 +3211,8 @@ gfc_restore_last_undo_checkpoint (void)

  while (csym != p)
{
+ if (!csym)
+   goto syntax;
  cparent = csym;
  csym = csym->common_next;
}
@@ -3242,6 +3244,11 @@ gfc_restore_last_undo_checkpoint (void)

   if (!single_undo_checkpoint_p ())
 pop_undo_change_set (latest_undo_chgset);
+
+  return;
+
+syntax:
+   gfc_error ("syntax or semantics issue at %C");
 }

But, the real issue is that the second COMMON is not
allowed to appear in the execution block of a program.
gfortran should probably error out earlier.

[Bug target/67771] New: integer-to-floating-point conversions wrongly produce -0 in FE_DOWNWARD mode

[jsm28 at gcc dot gnu.org]

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

Bug ID: 67771
   Summary: integer-to-floating-point conversions wrongly produce
-0 in FE_DOWNWARD mode
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

For older powerpc processors without support for fcfid in 32-bit code,
integer-to-floating-point conversions involve constructing a floating-point
representation, loading it into a floating-point register and subtracting a
constant.  In FE_DOWNWARD mode, if the integer is 0 then the result is -0, but
integer 0 should always convert for +0.  That is, this code is incorrect for
-frounding-math, and some other code sequence allowing for that should be
generated in that case (whether saving and restoring the rounding mode like
some other code generated by the powerpc back end does, or special-casing a
check for 0).

This results in incorrect returns from some glibc functions such as logb.

[Bug target/67716] [5] [SH]: Miscompiles libraw: Assembler: unaligned opcodes detected in executable segment

[kkojima at gcc dot gnu.org]

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

--- Comment #20 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #19)

I have no objection.  I thought that the fix for PR67723 on trunk is first,
though either way will be fine.

[Bug middle-end/67754] [graphite] Many testsuite failures

[spop at gcc dot gnu.org]

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

--- Comment #5 from Sebastian Pop  ---
Author: spop
Date: Tue Sep 29 22:15:08 2015
New Revision: 228268

URL: https://gcc.gnu.org/viewcvs?rev=228268&root=gcc&view=rev
Log:
use MIN fusion for ISL-14

This patch fixes PR66754 by reverting an earlier unintended change.
We now generate a much simpler AST for interchange-1.c:

ISL AST generated by ISL:
{
  for (int c1 = 0; c1 <= 1334; c1 += 1) {
S_7(c1);
for (int c3 = 0; c3 <= 1334; c3 += 1)
  S_4(c1, c3);
S_5(c1);
  }
  for (int c1 = 0; c1 <= 1334; c1 += 1)
S_10(c1);
  S_8();
}

Bootstrap and check pass on x86_64-linux with isl-0.14.1

  PR tree-optimization/67754
  * graphite-optimize-isl.c (optimize_isl): Call
  isl_options_set_schedule_fuse with ISL_SCHEDULE_FUSE_MIN for ISL-14.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-optimize-isl.c

[Bug target/66960] Add interrupt/exception attribute to x86 backend

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
From

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

To be feature complete, it would be nice to have two styles of interrupt
functions, one that returns with iret, and one that returns with ret.
The point is that the user might want to call functions from a interrupt
handler and not save and restore all call clobbered registers.  By
allowing a ret style interrupt handler, calls to a ret style interrupt
routine can avoid saving and restoring all call clobbered registers.

[hjl@gnu-6 interrupt-7]$ cat call-1.i
extern void bar (void);

void
 __attribute__ ((interrupt))
fn1 (void *frame)
{
  bar ();
}

void
 __attribute__ ((interrupt))
fn2 (void *frame)
{
  bar ();
}
[hjl@gnu-6 interrupt-7]$ make
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O2 -Wall -Wunused-parameter
-mno-push-args -mno-sse -m32 -S -o call-1.s call-1.i
[hjl@gnu-6 interrupt-7]$ cat call-1.s
.file   "call-1.i"
.text
.p2align 4,,15
.globl  fn1
.type   fn1, @function
fn1:
.LFB3:
.cfi_startproc
pushl   %ecx
.cfi_def_cfa_offset 8
.cfi_offset 1, -8
pushl   %edx
.cfi_def_cfa_offset 12
.cfi_offset 2, -12
pushl   %eax
.cfi_def_cfa_offset 16
.cfi_offset 0, -16
callbar
popl%eax
.cfi_restore 0
.cfi_def_cfa_offset 12
popl%edx
.cfi_restore 2
.cfi_def_cfa_offset 8
popl%ecx
.cfi_restore 1
.cfi_def_cfa_offset 4
iret
.cfi_endproc
.LFE3:
.size   fn1, .-fn1
.p2align 4,,15
.globl  fn2
.type   fn2, @function
fn2:
.LFB1:
.cfi_startproc
pushl   %ecx
.cfi_def_cfa_offset 8
.cfi_offset 1, -8
pushl   %edx
.cfi_def_cfa_offset 12
.cfi_offset 2, -12
pushl   %eax
.cfi_def_cfa_offset 16
.cfi_offset 0, -16
callbar
popl%eax
.cfi_restore 0
.cfi_def_cfa_offset 12
popl%edx
.cfi_restore 2
.cfi_def_cfa_offset 8
popl%ecx
.cfi_restore 1
.cfi_def_cfa_offset 4
iret
.cfi_endproc
.LFE1:
.size   fn2, .-fn2
.ident  "GCC: (GNU) 6.0.0 20150929 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 interrupt-7]$  

Both fn1 and fn2 have to save and restore caller-saved registers.
If all registers in bar are callee-saved, fn1 and fn2 can be
much smaller.

[Bug middle-end/67754] [graphite] Many testsuite failures

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

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

--- Comment #6 from Sebastian Pop  ---
Fixed.

[Bug rtl-optimization/67753] [6 Regression] FAIL: cxg1005, cxg2002, cxg2006, cxg2007, cxg2008, cxg2018, cxg2019 and cxg2020

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

  Component|ada |rtl-optimization

--- Comment #1 from John David Anglin  ---
There are also these similar fails:
FAIL: gcc.c-torture/execute/complex-7.c   -O1  execution test
FAIL: gcc.c-torture/execute/complex-7.c   -O2  execution test
FAIL: gcc.c-torture/execute/complex-7.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/complex-7.c   -Os  execution test
FAIL: gcc.c-torture/execute/complex-7.c   -O2 -flto -fno-use-linker-plugin
-flto
-partition=none  execution test
FAIL: gcc.c-torture/execute/complex-7.c   -O2 -flto -fuse-linker-plugin
-fno-fat
-lto-objects  execution test
FAIL: gcc.c-torture/execute/pr38969.c   -O1  execution test
FAIL: gcc.c-torture/execute/pr38969.c   -O2  execution test
FAIL: gcc.c-torture/execute/pr38969.c   -O3 -g  execution test
FAIL: gcc.c-torture/execute/pr38969.c   -Os  execution test
FAIL: gcc.c-torture/execute/pr38969.c   -O2 -flto -fno-use-linker-plugin
-flto-p

[Bug fortran/67758] [GCC 6 regression] ICE on invalid use of COMMON

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Dominique d'Humieres  ---
OK. I can reproduce the ICE in free form (*.f90) by replacing '80 000 000' with
'8000'. The change occurred between r226476 (2015-08-02, error) and r227016
(2015-08-19, ICE), likely r226732 (pr59746).

> But, the real issue is that the second COMMON is not
> allowed to appear in the execution block of a program.
> gfortran should probably error out earlier.

Agreed, although the original error

Error: PROCEDURE attribute conflicts with COMMON attribute in 'xx' at (1)

may not be obvious to understand.

[Bug middle-end/67754] [graphite] Many testsuite failures

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres  ---
Note that the failures

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

with -m32 are still there with isl-0.15 and r228270:

[Book15] f90/bug% gfc
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/graphite/block-1.f90 -O2
-floop-nest-optimize -m32
/opt/gcc/_clean/gcc/testsuite/gfortran.dg/graphite/block-1.f90:1:0:

 subroutine matrix_multiply(a,b,c,n)
^
internal compiler error: in extract_affine_chrec, at
graphite-sese-to-poly.c:605

[Bug middle-end/67754] [graphite] Many testsuite failures

[spop at gcc dot gnu.org]

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

Sebastian Pop  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
   Last reconfirmed||2015-09-29
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #8 from Sebastian Pop  ---
As I do not see the errors in my builds, I will investigate.
Thanks for letting me know that this testcase is still failing.

[Bug middle-end/67754] [graphite] Many testsuite failures

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres  ---
> As I do not see the errors in my builds, I will investigate.
> Thanks for letting me know that this testcase is still failing.

Are you testing with -m32?

[Bug c++/67772] New: wrong type_info emitted for cv-qualified pointer to member types

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 67772
   Summary: wrong type_info emitted for cv-qualified pointer to
member types
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Consider:

  namespace std { struct type_info {}; }
  struct A {};
  auto x = typeid(void(A::*)() const);

Clang emits the type info as:

_ZTIM1AKFvvE:
.quad   _ZTVN10__cxxabiv129__pointer_to_member_type_infoE+16
.quad   _ZTSM1AKFvvE
.long   0   # 0x0
.zero   4
.quad   _ZTIKFvvE
.quad   _ZTI1A

GCC emits it as:

_ZTIM1AKFvvE:
.quad   _ZTVN10__cxxabiv129__pointer_to_member_type_infoE+16
.quad   _ZTSM1AKFvvE
.long   0
.zero   4
.quad   _ZTIFvvE
.quad   _ZTI1A

It appears that Clang is correct here; the 'const' in this case is not a
qualifier, so should not be removed when forming the pointee type_info. If GCC
really did think this was a const qualifier applied to a function type, it
would be emitting the wrong flags (should be .long 1, not .long 0 in that
case).


This translates into a wrong-code bug in a case like this:

struct A;
extern "C" void puts(const char*);
int main() {
  try {
throw (void(A::*)())0;
  } catch (void (A::*)() const) {
puts("bad catch");
  }
}

... where GCC erroneously catches a pointer to non-const member function as a
pointer to const member function.

[Bug c++/67773] New: dealloc called on temp object before and named object after move, while not being called on named object before move

[awenocur at aol dot com]

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

Bug ID: 67773
   Summary: dealloc called on temp object before and named object
after move, while not being called on named object
before move
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: awenocur at aol dot com
  Target Milestone: ---

Created attachment 36420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36420&action=edit
pre-processed C++11 file exhibiting this behavior

The problem occurs on line 23813 of the provided .ii file.
An object initialized with specific parameters is dealloc'd once before moving,
and once after moving, while the target of the move is never dealloc'd.

This demo is simplified from a program I'm writing that has to assign an object
with an embedded pointer.  In the original, this object is destroyed twice
separately, resulting in a double free on the pointer.  In the demo there is no
pointer member, but the undesired behavior is the same.
The workaround featured in the demo is the same one that fixed the real
program.

This problem appears to exist on dialects of C++, at least from '03 onward, but
I chose to use C++11, because move constructors can be explicitly declared.  In
C++03, it does the move in the same manner.

compilation command:
c++ -g -O0 -std=c++11 -save-temps -o test test.cpp

GCC info:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.8.4-2ubuntu1~14.04' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) 

OS description:
Ubuntu 3.13.0-48.80-generic 3.13.11-ckt16

[Bug c++/67774] New: [concepts] ICE when mismatching template arguments to concept

[ryan.burn at gmail dot com]

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

Bug ID: 67774
   Summary: [concepts] ICE when mismatching template arguments to
concept
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Below code produces this ICE:

t.cpp: In function ‘int main()’:
t.cpp:21:16: error: wrong number of template arguments (1, should be 2)
   std::cout << cpt_KEvaluator << '\n';
^
t.cpp:16:48: note: provided for ‘template
constexpr const bool cpt_KEvaluator’
 template  concept bool cpt_KEvaluator =
^
t.cpp:21:16: internal compiler error: tree check: expected tree_vec, have
error_mark in tsubst, at cp/pt.c:12570
   std::cout << cpt_KEvaluator << '\n';
^
0xf2508c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.c:9512
0x6642bc tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:2858
0x6642bc tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12570
0x676b70 tsubst_copy
../../gcc/gcc/cp/pt.c:13675
0x680c0a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15474
0x66aad1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15044
0x66fbbc tsubst_template_arg
../../gcc/gcc/cp/pt.c:10260
0x67cd12 tsubst_template_args
../../gcc/gcc/cp/pt.c:10839
0x6621c1 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12829
0x6623bf tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12452
0x67cd12 tsubst_template_args
../../gcc/gcc/cp/pt.c:10839
0x67fafb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15230
0x66aad1 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15044
0x823207 satisfy_predicate_constraint
../../gcc/gcc/cp/constraint.cc:1694
0x823207 satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1898
0x823f76 satisfy_constraint
../../gcc/gcc/cp/constraint.cc:1949
0x797988 finish_id_expression(tree_node*, tree_node*, tree_node*, cp_id_kind*,
bool, bool, bool*, bool, bool, bool, bool, char const**, unsigned int)
../../gcc/gcc/cp/semantics.c:3585
0x702615 cp_parser_primary_expression
../../gcc/gcc/cp/parser.c:4817
0x70ec1b cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6201
0x713679 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7486
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

//
#include 
#include 
#include 

template  concept bool cpt_RealScalar() {
  return std::is_floating_point::value;
}

namespace detail {
template  constexpr bool k_evaluator_impl = false;

template 
constexpr bool k_evaluator_impl, E> = true;
}

template  concept bool cpt_KEvaluator =
  detail::k_evaluator_impl, X>;

int main() {
  auto f = [](int, int, int) -> double { return 3; };
  std::cout << cpt_KEvaluator << '\n';
  return 0;
}
//

[Bug c++/67775] New: [concepts] bug when using variadic expansions in compound requirements

[ryan.burn at gmail dot com]

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

Bug ID: 67775
   Summary: [concepts] bug when using variadic expansions in
compound requirements
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code prints 0, but it should print 1.

/
#include   
#include   
#include  

template   
concept bool cpt_RealScalar = std::is_floating_point::value; 

namespace detail {  
template  constexpr bool k_evaluator_impl = false;

template   
  requires requires(E e) {  
{ e((Indexes, 0)...) } -> cpt_RealScalar;   
// requires cpt_RealScalar; // this version
works
  } 
constexpr bool k_evaluator_impl, E> = true; 
}   

template  concept bool cpt_KEvaluator = 
  detail::k_evaluator_impl, X>; 

int main() {
  auto f = [](int, int, int) -> double { return 3; };   
  std::cout << cpt_KEvaluator << '\n';  
  return 0; 
} 
/

[Bug c++/67773] destructor called on temp object before and named object after move, while not being called on named object before move

[awenocur at aol dot com]

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

--- Comment #1 from Adam Wenocur  ---
compiler output:

-*- mode: compilation; default-directory: "~/compiler-test/" -*-  
Compilation started at Wed Sep 30 00:45:55

./compile.sh  

Compilation finished at Wed Sep 30 00:45:55


the command:
./test

[Bug c++/67776] New: Missing warning when using asm labels

[gccbugzilla at limegreensocks dot com]

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

Bug ID: 67776
   Summary: Missing warning when using asm labels
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugzilla at limegreensocks dot com
  Target Milestone: ---

When compiling this code:

void f(void)
{
   int foo asm("myfoo") = 42;
}

using: gcc -c sta7.c

I (correctly) get the warning message: 

   warning: ignoring asm-specifier for non-static local variable 'foo'

However, if I rename the file from sta7.c to sta7.cpp, I no longer get the
warning.  Since the variable is still a non-static local variable, I expected
to still get the warning.

While not particularly interesting of itself, this makes me wonder what other c
error checking might be getting skipped in c++.

[Bug target/67718] [aarch64] long double incorrect code for copysign

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-30
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Ramana Radhakrishnan  ---
With the latest build for aarch64-none-linux-gnu of 4.9 and trunk that I had
lying around, I see with -O2 and with and without a variety of tuning options,
which looks a whole load better than the original bug report.

copysignl:
fmovx2, d0
fmovx1, v1.d[1]
fmovx3, v0.d[1]
fmovd0, x2
lsr x1, x1, 63
bfi x3, x1, 63, 1
fmovv0.d[1], x3
ret
.size   copysignl, .-copysignl
.ident  "GCC: 4.9.4 20150924 (prerelease)"

I am traveling currently and can't dig any further but I remember something
being fixed in this pattern with respect to early clobbers- Aha PR61633 may be
your friend.

Can you check if you have the fix for PR61633 in your 4.9 based tree ? 

In the future please report with command line options and the exact upstream
source revision used to create the issue.

regards
Ramana

[Bug c++/67777] New: unsigned wchar_t and signed wchar_t should cause compiler errors but do not.

[TrevorJamesHickey at gmail dot com]

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

Bug ID: 6
   Summary: unsigned wchar_t and signed wchar_t should cause
compiler errors but do not.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TrevorJamesHickey at gmail dot com
  Target Milestone: ---

Is the following program valid C++?

void f(unsigned wchar_t){}
int main(){}

It compiles without errors.   

The standard specifies that:  
"signed or unsigned can be combined with char, long, short, or int."

wchar_t is a distinct type, but the standard makes no mention of it being able
to be qualified with signed or unsigned.

"Type wchar_t shall have the same size, signedness, and alignment requirements
(3.11) as one of the other integral types, called its underlying type."  

Why can we add signed/unsigned qualifiers to wchar_t?  
Is this by design?  Can I get a warning about this?

[Bug target/67143] [5/6 Regression] ICE (could not split insn) on aarch64-linux-gnu

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #6 from Ramana Radhakrishnan  ---
Fixed then.