[Bug target/66540] New: [5/6 Regression] glibc testsuite: error: unrecognizable insn with -mavx512f

[trippels at gcc dot gnu.org]

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

Bug ID: 66540
   Summary: [5/6 Regression] glibc testsuite:  error:
unrecognizable insn with -mavx512f
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

Running the glibc testsuite shows:

markus@x4 math % cat test-double-vlen8-wrappers.i
void
fn1 ()
{
  int i;
  __attribute__ ((__vector_size__ (8 * sizeof (double double a;
  i = 0;
  for (; i < 8; i++)
a[i] = 0;
  fn1 (a);
}

markus@x4 math % gcc -c -O2 -mavx512f test-double-vlen8-wrappers.i
test-double-vlen8-wrappers.i: In function ‘fn1’:
test-double-vlen8-wrappers.i:10:1: error: unrecognizable insn:
 }
 ^
(insn 35 34 36 2 (set (reg:QI 112)
(const_int 128 [0x80])) test-double-vlen8-wrappers.i:8 -1
 (nil))
test-double-vlen8-wrappers.i:10:1: internal compiler error: in extract_insn, at
recog.c:2319
0xaa7038 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc/gcc/rtl-error.c:110
0xaa7069 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc/gcc/rtl-error.c:118
0xa74479 extract_insn(rtx_insn*)
../../gcc/gcc/recog.c:2319
0x849213 instantiate_virtual_regs_in_insn
../../gcc/gcc/function.c:1588
0x849213 instantiate_virtual_regs
../../gcc/gcc/function.c:1956
0x849213 execute
../../gcc/gcc/function.c:2005
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/66540] [5/6 Regression] glibc testsuite: error: unrecognizable insn with -mavx512f

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.2

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[y.gribov at samsung dot com]

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

Yury Gribov  changed:

   What|Removed |Added

 CC||y.gribov at samsung dot com

--- Comment #2 from Yury Gribov  ---
Related discussion in ASan tracker:
https://code.google.com/p/address-sanitizer/issues/detail?id=73&can=1&q=destructor&colspec=ID%20Type%20Status%20Priority%20OpSys%20Owner%20Summary

[Bug c++/66537] An explicit default constructor is accepted when initializing from empty braces

[ville.voutilainen at gmail dot com]

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

--- Comment #3 from Ville Voutilainen  ---
Oh well, I guess CWG 1518 as referenced in the other bug should solve this.
I'm fine either way, if explicit default constructors are decided to
work with the example, we can close this bug as invalid, and I should pursue
harder making library tag types non-default-constructible.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||ppalka at gcc dot gnu.org

--- Comment #14 from Manuel López-Ibáñez  ---
Patrick, it seems to me we can close this as FIXED, no?

[Bug fortran/66534] Compilation error of gfortran building on YDL6.2

[textdirected at gmail dot com]

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

HEMMI, Shigeru  changed:

   What|Removed |Added

 CC||textdirected at gmail dot com

--- Comment #2 from HEMMI, Shigeru  ---
Created attachment 35780
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35780&action=edit
The file
`/home/zgzg/gcc-5.1.0/powerpc-unknown-linux-gnu/libgfortran/config.log'

Thanks for the support.
The file attached.
Regards,

[Bug target/66540] [5/6 Regression] glibc testsuite: error: unrecognizable insn with -mavx512f

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #1 from Uroš Bizjak  ---
Dup.

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

[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

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

[Bug middle-end/66432] libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
At fnsplit, we split off f.part.0 from f.

That introduces a debug_insn and ssa-name that references param B in f:
...
  # DEBUG D#4ptD.0 => B_3(D)
..

And a debug_insn that references param B in f.part.0:
...
  # DEBUG D#7ptD.0 s=> BD.1846
...

At this point, the type of the ssa name and the param are the same.

Then at inline, we decide to inline f.part.0 back into the f.

For inlining, we rewrite the body of inlined function f.part.0. While rewriting
the debug insn mentioned above, we hit this code for param B:
...
  if (TREE_CODE (*tp) != OMP_CLAUSE)
TREE_TYPE (*tp) = remap_type (TREE_TYPE (*tp), id);
...

And since it's a variable-sized type, the type of param is changed.

Now the type of the ssa name and the param are no longer the same, and a bit
later we hit the ICE.

[Bug target/66541] New: r224314 causes ICE in gcc.dg/torture/pr52429.c

[jgreenhalgh at gcc dot gnu.org]

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

Bug ID: 66541
   Summary: r224314 causes ICE in gcc.dg/torture/pr52429.c
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jgreenhalgh at gcc dot gnu.org
CC: christian.bruel at st dot com
  Target Milestone: ---
Target: arm-none-linux-gnueabihf

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

Looks closely related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64047

Reduced testcase attached, but the one in the testsuite is just as good.

.../gcc/cc1 besttry.c -O2  -ftree-parallelize-loops=4  -O2 -flto 
-fno-use-linker-plugin  -ftree-parallelize-loops=4 -o pr52429.s

 foo
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
 
Assembling functions:
 foo
.../gcc/testsuite/gcc.dg/torture/pr52429.c: In function ‘foo’:
.../gcc/testsuite/gcc.dg/torture/pr52429.c:11:1: internal compiler error:
Segmentation fault
   int i;
 ^
0xafa15f crash_signal
.../gcc/toplev.c:369
0x97c2b4 record_operand_costs
.../gcc/ira-costs.c:1305
0x97c7a4 scan_one_insn
.../gcc/ira-costs.c:1483
0x97c7a4 process_bb_for_costs
.../gcc/ira-costs.c:1604
0x97d715 find_costs_and_classes
.../gcc/ira-costs.c:1711
0x97ec3a ira_set_pseudo_classes(bool, _IO_FILE*)
.../gcc/ira-costs.c:2245
0xffd743 alloc_global_sched_pressure_data
.../gcc/haifa-sched.c:7119
0xffd743 sched_init()
.../gcc/haifa-sched.c:7269
0xffebcf haifa_sched_init()
.../gcc/haifa-sched.c:7281
0xaab8dc schedule_insns
.../gcc/sched-rgn.c:3411
0xaac0b3 schedule_insns
.../gcc/sched-rgn.c:3405
0xaac0b3 rest_of_handle_sched
.../gcc/sched-rgn.c:3624
0xaac0b3 execute
.../gcc/sched-rgn.c:3732
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[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 #9 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Jun 15 10:08:04 2015
New Revision: 224477

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

2015-06-15  Andre Vehreschild  

PR fortran/44672
PR fortran/45440
PR fortran/57307
* gfortran.dg/allocate_with_source_3.f90: Removed check for
unimplemented error.
* gfortran.dg/allocate_with_source_7.f08: New test.
* gfortran.dg/allocate_with_source_8.f08: New test.

gcc/fortran/ChangeLog:

2015-06-15  Andre Vehreschild  

PR fortran/44672
PR fortran/45440
PR fortran/57307
* gfortran.h: Extend gfc_code.ext.alloc to carry a
flag indicating that the array specification has to be
taken from expr3.
* resolve.c (resolve_allocate_expr): Add F2008 notify
and flag indicating source driven array spec.
(resolve_allocate_deallocate): Check for source driven
array spec, when array to allocate has no explicit
array spec.
* trans-array.c (gfc_array_init_size): Get lower and
upper bound from a tree array descriptor, except when
the source expression is an array-constructor which is
fixed to be one-based.
(retrieve_last_ref): Extracted from gfc_array_allocate().
(gfc_array_allocate): Enable allocate(array, source= 
array_expression) as specified by F2008:C633.
(gfc_conv_expr_descriptor): Add class tree expression
into the saved descriptor for class arrays.
* trans-array.h: Add temporary array descriptor to
gfc_array_allocate ().
* trans-expr.c (gfc_conv_procedure_call): Special handling
for _copy() routine translation, that comes without an
interface. Third and fourth argument are now passed by value.
* trans-stmt.c (gfc_trans_allocate): Get expr3 array
descriptor for temporary arrays to allow allocate(array,
source = array_expression) for array without array
specification.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_7.f08
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_8.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_3.f90

[Bug fortran/57307] ICE with sourced allocation with array constructor

[vehre at gcc dot gnu.org]

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

--- Comment #3 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Jun 15 10:08:04 2015
New Revision: 224477

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

2015-06-15  Andre Vehreschild  

PR fortran/44672
PR fortran/45440
PR fortran/57307
* gfortran.dg/allocate_with_source_3.f90: Removed check for
unimplemented error.
* gfortran.dg/allocate_with_source_7.f08: New test.
* gfortran.dg/allocate_with_source_8.f08: New test.

gcc/fortran/ChangeLog:

2015-06-15  Andre Vehreschild  

PR fortran/44672
PR fortran/45440
PR fortran/57307
* gfortran.h: Extend gfc_code.ext.alloc to carry a
flag indicating that the array specification has to be
taken from expr3.
* resolve.c (resolve_allocate_expr): Add F2008 notify
and flag indicating source driven array spec.
(resolve_allocate_deallocate): Check for source driven
array spec, when array to allocate has no explicit
array spec.
* trans-array.c (gfc_array_init_size): Get lower and
upper bound from a tree array descriptor, except when
the source expression is an array-constructor which is
fixed to be one-based.
(retrieve_last_ref): Extracted from gfc_array_allocate().
(gfc_array_allocate): Enable allocate(array, source= 
array_expression) as specified by F2008:C633.
(gfc_conv_expr_descriptor): Add class tree expression
into the saved descriptor for class arrays.
* trans-array.h: Add temporary array descriptor to
gfc_array_allocate ().
* trans-expr.c (gfc_conv_procedure_call): Special handling
for _copy() routine translation, that comes without an
interface. Third and fourth argument are now passed by value.
* trans-stmt.c (gfc_trans_allocate): Get expr3 array
descriptor for temporary arrays to allow allocate(array,
source = array_expression) for array without array
specification.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_7.f08
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_8.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_3.f90

[Bug fortran/45440] [F03] ALLOCATE with SOURCE gives an ICE (segfault)

[vehre at gcc dot gnu.org]

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

--- Comment #12 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Mon Jun 15 10:08:04 2015
New Revision: 224477

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

2015-06-15  Andre Vehreschild  

PR fortran/44672
PR fortran/45440
PR fortran/57307
* gfortran.dg/allocate_with_source_3.f90: Removed check for
unimplemented error.
* gfortran.dg/allocate_with_source_7.f08: New test.
* gfortran.dg/allocate_with_source_8.f08: New test.

gcc/fortran/ChangeLog:

2015-06-15  Andre Vehreschild  

PR fortran/44672
PR fortran/45440
PR fortran/57307
* gfortran.h: Extend gfc_code.ext.alloc to carry a
flag indicating that the array specification has to be
taken from expr3.
* resolve.c (resolve_allocate_expr): Add F2008 notify
and flag indicating source driven array spec.
(resolve_allocate_deallocate): Check for source driven
array spec, when array to allocate has no explicit
array spec.
* trans-array.c (gfc_array_init_size): Get lower and
upper bound from a tree array descriptor, except when
the source expression is an array-constructor which is
fixed to be one-based.
(retrieve_last_ref): Extracted from gfc_array_allocate().
(gfc_array_allocate): Enable allocate(array, source= 
array_expression) as specified by F2008:C633.
(gfc_conv_expr_descriptor): Add class tree expression
into the saved descriptor for class arrays.
* trans-array.h: Add temporary array descriptor to
gfc_array_allocate ().
* trans-expr.c (gfc_conv_procedure_call): Special handling
for _copy() routine translation, that comes without an
interface. Third and fourth argument are now passed by value.
* trans-stmt.c (gfc_trans_allocate): Get expr3 array
descriptor for temporary arrays to allow allocate(array,
source = array_expression) for array without array
specification.


Added:
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_7.f08
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_8.f08
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.h
trunk/gcc/fortran/resolve.c
trunk/gcc/fortran/trans-array.c
trunk/gcc/fortran/trans-array.h
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/allocate_with_source_3.f90

[Bug c++/66542] New: [C++11] Can create static variable of type that has deleted destructor

[fordeso2 at gmail dot com]

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

Bug ID: 66542
   Summary: [C++11] Can create static variable of type that has
deleted destructor
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fordeso2 at gmail dot com
  Target Milestone: ---

Created attachment 35782
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35782&action=edit
Preprocessed file with bug

when a class has user-defined (not default) constructor and destructor marked
deleted, gcc allows creating of a static variable of class's type.

Command line: gcc -std=c++11 -lstdc++ ret.cpp

Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5-20150519/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --with-default-libstdcxx-abi=c++98
Thread model: posix

Attached preprocessed file.

[Bug c++/66542] [4.9/5/6 Regression] [C++11] Can create static variable of type that has deleted destructor

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-15
  Known to work||4.8.3
Summary|[C++11] Can create static   |[4.9/5/6 Regression]
   |variable of type that has   |[C++11] Can create static
   |deleted destructor  |variable of type that has
   ||deleted destructor
 Ever confirmed|0   |1
  Known to fail||4.9.2, 5.1.0, 6.0

[Bug tree-optimization/66512] PRE fails to optimize calls to pure functions in C++, ok in C

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
In that case I'd like to contribute a documentation patch to make that clear in
the pure/const attribute information, but I need more explanation.  I see that

int p(void) __attribute__((const));
void f()
{
  p();
  p();
}

is optimized to an empty function, even though p may throw.  Is that not a bug?

Also, could you please expand your explanation in the first paragraph, i.e.
this:

  What we miss here is the fact that it should only matter
  if p throws internally for IL consistency.  Of course it
  still matters for observing other side-effects if p throws
  and after the transform now does so before side-effects
  that should be observed otherwise.

I'm probably missing a lot of contextual knowledge to understand that.  TIA.

[Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Jennifer Yao from comment #0)
> My hypothesis (and please correct me if I'm wrong) is that the libstdc++
> that is being loaded at runtime is the preexisting (unaltered/unpatched)
> library in the install tree, rather than the altered/patched library in the
> build tree.

If that's true it must be a cygwin problem, as it doesn't happen for other
targets. All testing should be done against the build tree, and that's what
happens for me.

Does the
/cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/src/.libs
directory in the LD_LIBRAY_PATH contain the libstdc++.so.6 library?

[Bug c++/51048] Class template inheritance doesn't work well with function-local types

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #5 from Paolo Carlini  ---
Mine.

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #1)
> There is some minimal support in -fsanitize=vptr, but that catches only
> destructed objects with virtual methods (by disabling the clobbers and
> clearing the vptr).

I see.

> Other than that, this is something that is more in line with the address
> sanitizer (which also has very limited support for file scope objects, but
> only makes the objects unavailable during construction of each TU, so
> catches constructor ordering issues within a single TU).  Other than that,
> the concept of making a chunk of memory available at certain point and
> unavailable at another point is something -fsanitize=address is able to do. 
> The question is what can be done with operator new, e.g. if you have a char
> buffer in some class and construct something else at that spot, then
> destructing it; reading those bytes afterwards is supposedly UB, but storing
> there something say with memcpy shouldn't be invalid.

Ok, after reading your caution and test-cases mentioned in the ASAN tracker, I
think emitting a poison memory call in a dtor for instances that does not use
placement new can be beneficial. However, I can't evaluate if getting such kind
of information in doable in GCC?

[Bug target/66483] [4.9 Regression] ICE (in add_stores, at var-tracking.c:6000) on arm-linux-gnueabihf

[thopre01 at gcc dot gnu.org]

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

--- Comment #9 from Thomas Preud'homme  ---
Patch can be backported without any changes and fixes the issue. I'll launch
regression testing tomorrow and ask for it to be committed on 4.9 branch.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #11 from John Paul Adrian Glaubitz  ---
Any news on this issue? The sh4 buildds in Debian are currently building a
snapshot as of 2015-06-13 (r224454), let's see how far it gets.

Adrian

[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #5 from John Paul Adrian Glaubitz  ---
Hello!

Just as a heads up: This particular problem did not occur with the snapshot as
of 2014-12-20 (r218987) and we actually always built gdc in Debian. So it's
definitely a regression as a result of the various changes to the SH target
since r218987 as we discussed earlier.

This problem affects gcc-4.8 and 4.9 and can be avoided by disabling the gdc
package. We have currently disabled gdc in gcc-4.9 and 5 which results in
gcc-4.9 being built (gcc-5 is still not being built for known reasons). But it
_seems_ that this particular bug shows itself now when trying to build gcc-4.9
as the compiler reproducibly segfaults now [1].

I still have to confirm this by trying another buildd, but I have the suspicion
that this segfault is directly related to the aforementioned regression. If
this is actually a bug, building gcc-4.9 on tirpitz should fail within
approximately an hour. I will report back then!

Adrian

> [1] 
> http://buildd.debian-ports.org/status/fetch.php?pkg=gcc-4.9&arch=sh4&ver=4.9.2-21&stamp=1434293660

[Bug c++/59975] [C++11] Bogus "declared using local type ‘...’, is used but never defined"

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #1 from Paolo Carlini  ---
Dup.

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

[Bug c++/51048] Class template inheritance doesn't work well with function-local types

[paolo.carlini at oracle dot com]

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

--- Comment #6 from Paolo Carlini  ---
*** Bug 59975 has been marked as a duplicate of this bug. ***

[Bug fortran/64589] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||vehre at gcc dot gnu.org

--- Comment #3 from vehre at gcc dot gnu.org ---
Works with current trunk as of r224477. Please cross check!

[Bug middle-end/66432] libgomp.c/appendix-a/a.29.1.c -O2 -g: type mismatch between an SSA_NAME and its symbol

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
Created attachment 35783
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35783&action=edit
tentative patch

[Bug target/66541] r224314 causes ICE in gcc.dg/torture/pr52429.c

[chrbr at gcc dot gnu.org]

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

chrbr at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-15
 CC||chrbr at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from chrbr at gcc dot gnu.org ---
Confirmed.

since r217659. DECL_FUNCTION_SPECIFIC_TARGET is set with
target_option_default_node.

Needs catch up with i386 ix86_set_current_function changes.

[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
Author: redi
Date: Mon Jun 15 12:31:15 2015
New Revision: 224478

URL: https://gcc.gnu.org/viewcvs?rev=224478&root=gcc&view=rev
Log:
Backport from mainline
2015-06-09  Jonathan Wakely  

PR libstdc++/66030
* config/abi/pre/gnu.ver: Export codecvt_byname and codecvt symbols
for mingw32.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/config/abi/pre/gnu.ver

[Bug libstdc++/66030] [5.1.0] std::codecvt_byname missing from libstdc++ DLL

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Version|unknown |5.1.0
 Resolution|--- |FIXED
   Target Milestone|--- |5.2

--- Comment #16 from Jonathan Wakely  ---
Fixed for 5.2

[Bug libgomp/66429] ICE in expand_GOMP_SIMD_LAST_LANE

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-15
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

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

Untested fix.

[Bug target/66473] ICE: in extract_insn, at recog.c:2343 (unrecognizable insn) with -mavx512f

[andrew.n.senkevich at gmail dot com]

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

Andrew Senkevich  changed:

   What|Removed |Added

 Status|RESOLVED|VERIFIED

--- Comment #11 from Andrew Senkevich  ---
Thank you!

[Bug c++/66543] New: False positive warning "variable set but not used"

[ldionne.2 at gmail dot com]

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

Bug ID: 66543
   Summary: False positive warning "variable set but not used"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldionne.2 at gmail dot com
  Target Milestone: ---

The following code triggers a "unused but set variable" warning on GCC trunk:

int main() {
auto f = []() { };
[=](auto) {
using Foo = decltype(f());
};
}

I think it is a false positive, since `f` is obviously used.

> g++ --version
g++ (GCC) 6.0.0 20150613 (experimental)

> g++ -std=c++14 worksheet.cpp -fsyntax-only -Wall -Wno-unused-local-typedefs

In function ‘int main()’:
warning: variable ‘f’ set but not used [-Wunused-but-set-variable]
 auto f = []() { };
  ^

Regards,
Louis Dionne

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

--- Comment #12 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #11)
> Any news on this issue? The sh4 buildds in Debian are currently building a
> snapshot as of 2015-06-13 (r224454), let's see how far it gets.

It will take a while to develop the R0 pre-allocating RTL pass as mentioned in
c#10.  Once this has been done and it's been stabilized it can be backported to
the GCC 5 release branch -- assuming that it will fix the R0 reload problems.

[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo  ---
(In reply to John Paul Adrian Glaubitz from comment #5)

> Just as a heads up: This particular problem did not occur with the snapshot
> as of 2014-12-20 (r218987) and we actually always built gdc in Debian. So
> it's definitely a regression as a result of the various changes to the SH
> target since r218987 as we discussed earlier.

Please try to find out which revision/patch caused the regression as mentioned
above.  That would be really helpful.

[Bug c++/65168] diagnostic: missing: reference cannot be bound to dereferenced null pointer

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #15 from Patrick Palka  ---
Yes, thanks.

[Bug target/66312] [SH] Regression: Bootstrap failure gcc/d/ctfeexpr.dmd.o differs with gcc-4.8/4.9

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #7 from John Paul Adrian Glaubitz  ---
(In reply to Oleg Endo from comment #6)
> Please try to find out which revision/patch caused the regression as
> mentioned above.  That would be really helpful.

I am currently waiting for the build queue to empty completely (about two more
days), then I'll have a look.

Oh, and the segfault seems to be hardware-related, it doesn't occur on my own
sh4 board.

Adrian

[Bug testsuite/65767] Test pr65276 failed on arm-none-eabi

[ro at gcc dot gnu.org]

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

--- Comment #9 from Rainer Orth  ---
It's been more than a month without any activity to fix this.  There's now also
PR testsuite/65944 about the same issue.

Please fix.
  Rainer

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[kassafari at gmail dot com]

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

kassafari at gmail dot com changed:

   What|Removed |Added

 CC||kassafari at gmail dot com

--- Comment #2 from kassafari at gmail dot com ---
status check

[Bug target/66523] the new clang-based assembler in Xcode 7 on 10.11 fails on libobjc/NXConstStr.m

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
(In reply to kassafari from comment #2)
> status check

you can use the patch in the short-term, but I want to check for other
solutions too.

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #13 from Jason Merrill  ---
*** Bug 66537 has been marked as a duplicate of this bug. ***

[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization

[jason at gcc dot gnu.org]

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

Bug 54835 Summary: [C++11][DR 1518] Explicit default constructors not respected 
during copy-list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54835

   What|Removed |Added

 Status|RESOLVED|SUSPENDED
 Resolution|FIXED   |---

[Bug c++/54835] [C++11][DR 1518] Explicit default constructors not respected during copy-list-initialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|SUSPENDED
 Resolution|FIXED   |---

--- Comment #14 from Jason Merrill  ---
Suspended pending resolution of DR 1518.

[Bug c++/66537] [DR 1518] An explicit default constructor is accepted when initializing from empty braces

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE
Summary|An explicit default |[DR 1518] An explicit
   |constructor is accepted |default constructor is
   |when initializing from  |accepted when initializing
   |empty braces|from empty braces

--- Comment #4 from Jason Merrill  ---
This seems the same as 54835.

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

[Bug debug/66535] segfault in gen_subprogram_die after debug-early merge

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-15
   Assignee|unassigned at gcc dot gnu.org  |aldyh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Aldy Hernandez  ---
Mine.

[Bug debug/66535] segfault in gen_subprogram_die after debug-early merge

[aldyh at gcc dot gnu.org]

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

--- Comment #2 from Aldy Hernandez  ---
Author: aldyh
Date: Mon Jun 15 16:34:53 2015
New Revision: 224486

URL: https://gcc.gnu.org/viewcvs?rev=224486&root=gcc&view=rev
Log:
PR debug/66535
* dwarf2out.c (gen_subprogram_die): Do not check a parent's tag if
there is no parent.

Added:
trunk/gcc/testsuite/gnat.dg/debug4.adb
trunk/gcc/testsuite/gnat.dg/debug4_pkg.adb
trunk/gcc/testsuite/gnat.dg/debug4_pkg.ads
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug debug/66535] segfault in gen_subprogram_die after debug-early merge

[aldyh at gcc dot gnu.org]

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

Aldy Hernandez  changed:

   What|Removed |Added

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

--- Comment #3 from Aldy Hernandez  ---
Fixed in mainline.

[Bug tree-optimization/54013] Loop with control flow not vectorized

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-06-15
 CC||alalaw01 at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from alalaw01 at gcc dot gnu.org ---
Indeed it does (confirmed).

So there are a few tricks here, but they are not Intel-specific, and don't even
look to require new tree codes. The loop body can be vectorized by computing
the (x < tab[i]) predicate across the vector, and then using a reduction opcode
(a bitwise-or reduction would be most natural but others work) to convert to a
scalar which then jumps out of the loop, i.e. if *any* of the lanes in the
vector would exit:

int foo (float x, float *tab)
{
  for (i = 2; i < 45; i+= 4)
{
  v4sf v_tab = ...load from tab...
  unsigned v4si v_exit_cond = vec_cond_expr({x,x,x,x} < v_tab, -1, 0);
  if (reduc_max_expr (v_exit_cond)) break;
}
  ...
}

The epilogue must then work out the value of i at exit (possibly a separate
epilogue for the "break" vs the other exit). I see two schemes:

(1) use vec_pack_trunc_expr, or similar, to narrow v_exit_cond down to a
scalar, where we can find the first set bit, and use this as an index to add to
the value still in i.

(2) compute a vector of the value i would have had if each element had been the
one that exitted:

v4si v_i_on_exit = vec_cond_expr (v_exit_cond,
{i, i+1, i+2, i+3}, /* Maybe available as induction variable?  */
{MAX_INT, MAX_INT, MAX_INT, MAX_INT})

and then take a reduc_min_expr to look for the *first* value of i that exits.

(There is one more issue, i.e. that we need to speculate the read of
tab[i+1...i+3], as the vector load will probably read all the lanes before we
know whether earlier iterations should have exited. So we'd need to have some
kind of check against that, or e.g. if tab[] were a global with known bounds.
Similar/complicated conditions apply to any/everything else in the loop, too!)

[Bug fortran/64589] [OOP] Linking error due to undefined integer symbol with unlimited polymorphism

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
> Works with current trunk as of r224477. Please cross check!

Not for me at r224485 (clean):

[Book15] f90/bug% gfc pr64589.f90
Undefined symbols for architecture x86_64:
  "___vtab_INTEGER_4_.3443", referenced from:
  ___astg_mpifilehandler_mod_MOD_getsuffix in ccsS2B1M.o
...
[Book15] f90/bug% gfc pr64589_1.f90
pr64589_1.f90:11:0:

 program p
1
internal compiler error: in build_function_decl, at fortran/trans-decl.c:2046
...

[Bug fortran/66544] New: ICE on function with pointer result in combination with implicit none

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

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

Bug ID: 66544
   Summary: ICE on function with pointer result in combination
with implicit none
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code with "implicit none" :
   module m
  implicit none
   contains
  function f() result(z)
 procedure(f), pointer :: z
  end
   end module

yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit) :
internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064

---

Deleting "implicit none" from source :
   module m
   contains
  function f() result(z)
  implicit none
 procedure(f), pointer :: z
  end
   end module


$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize -c z0.f90
   function f() result(z)
 1
Warning: Return value 'z' of function 'f' declared at (1) not set

---

With option -fimplicit-none same issue as above :

$ gfortran -g -O0 -Wall ... -fimplicit-none -c z0.f90
z0.f90:3:0: internal compiler error: in gfc_typenode_for_spec, at
fortran/trans-types.c:1064
function f() result(z)
 ^
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug fortran/66545] New: ICE on using undefined parameter/variable values

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

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

Bug ID: 66545
   Summary: ICE on using undefined parameter/variable values
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

This code uses parameter/variable values before they are defined/initialized.

$ cat z1_complex.f90
   program p
  complex, parameter :: c1 = (c1)
  complex, parameter :: c2 = c2
  complex :: c3 = (c3)
  complex :: c4 = c4
  complex :: c5
  complex :: c6
  c5 = (c5)
  c6 = c6
   end


For example, compiling with :

$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize \
  -Wuninitialized -fsanitize=undefined \
  -c z1_complex.f90


yields (with gfortran 5.1.1 on SUSE Linux 13.2, 64 bit) :
f951: internal compiler error: Segmentation fault

[Bug fortran/66545] ICE on using undefined parameter/variable values

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Trivially, the following cases behave similar :


$ cat z1_real.f90
program p
   real, parameter :: c1 = (c1)
   real, parameter :: c2 = c2
   real :: c3 = (c3)
   real :: c4 = c4
   real :: c5
   real :: c6
   c5 = (c5)
   c6 = c6
end


$ cat z1_integer.f90
program p
   integer, parameter :: c1 = (c1)
   integer, parameter :: c2 = c2
   integer :: c3 = (c3)
   integer :: c4 = c4
   integer :: c5
   integer :: c6
   c5 = (c5)
   c6 = c6
end


$ cat z1_logical.f90
program p
   logical, parameter :: c1 = (c1)
   logical, parameter :: c2 = c2
   logical :: c3 = (c3)
   logical :: c4 = c4
   logical :: c5
   logical :: c6
   c5 = (c5)
   c6 = c6
end


$ cat z1_character.f90
program p
   character, parameter :: c1 = (c1)
   character, parameter :: c2 = c2
   character :: c3 = (c3)
   character :: c4 = c4
   character :: c5
   character :: c6
   c5 = (c5)
   c6 = c6
end


$ cat z1_type.f90
program p
   type t; end type
   type(t), parameter :: c1 = (c1)
   type(t), parameter :: c2 = c2
   type(t) :: c3 = (c3)
   type(t) :: c4 = c4
   type(t) :: c5
   type(t) :: c6
   c5 = (c5)
   c6 = c6
end

[Bug fortran/66244] ICE on assigning a value to a pointer variable

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Perhaps it's better to make the target array a bit larger.
And to provide a not so minimalistic version :

   program p
  integer, target :: a(4)
  integer, pointer :: z => a(3)
  call s
   contains
  subroutine s
 a = 123
 z = 0
 print *, a
 print *, z
  end
   end

yields :
f951: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:179

---

Whereas this modification compiles and works as expected :

$ cat z92.f90
   program p
  integer, target :: a(4)
  integer, pointer :: z
  z => a(3)
  call s
   contains
  subroutine s
 a = 123
 z = 0
 print *, a
 print *, z
  end
   end

$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z92.f90
$ a.out
 123 123   0 123
   0

[Bug debug/66535] segfault in gen_subprogram_die after debug-early merge

[ebotcazou at gcc dot gnu.org]

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

--- Comment #4 from Eric Botcazou  ---
Thanks for the quick fix!

[Bug c++/66542] [4.9/5/6 Regression] [C++11] Can create static variable of type that has deleted destructor

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
This seems to be a regression versus gcc 4.8.2

[Bug sanitizer/66514] UBSAN: Add -fsanitize=lifetime

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
(In reply to Martin Liška from comment #3)
> Ok, after reading your caution and test-cases mentioned in the ASAN tracker,
> I think emitting a poison memory call in a dtor for instances that does not
> use placement new can be beneficial. However, I can't evaluate if getting
> such kind of information in doable in GCC?

We could certainly emit the poison call where we currently have the clobber.

[Bug fortran/66544] ICE on function with pointer result in combination with implicit none

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

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

--- Comment #1 from Gerhard Steinmetz  
---
Originally not the above z0.f90, but this code was thought as test case :

$ cat z0.f90
   module m
   contains
  function f() result(z)
 procedure(f), pointer :: z
  end
   end module


$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize -fimplicit-none -c
z0.f90

But anyway, the result is the same.

[Bug fortran/66545] ICE on using undefined parameter/variable values

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

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

--- Comment #2 from Gerhard Steinmetz  
---
FYI, it's astonishing, but this code compiles without an ICE
and prints some reasonable error messages :


$ cat z2_type.f90
program p
   type t
  integer :: n
   end type
   type(t), parameter :: c1 = (t(c1%n))
   type(t), parameter :: c2 = t(c2%n)
   type(t) :: c3 = (t(c3%n))
   type(t) :: c4 = t(c4%n)
   type(t) :: c5
   type(t) :: c6
   c5 = (t(c5%n))
   c6 = t(c6%n)
end


$ gfortran -c z2_type.f90
z2_type.f90:5:33:

type(t), parameter :: c1 = (t(c1%n))
 1
Error: PARAMETER ‘c1’ is used at (1) before its definition is complete
z2_type.f90:6:32:

type(t), parameter :: c2 = t(c2%n)
1
Error: PARAMETER ‘c2’ is used at (1) before its definition is complete
z2_type.f90:7:22:

type(t) :: c3 = (t(c3%n))
  1
Error: Parameter ‘c3’ at (1) has not been declared or is a variable, which does
not reduce to a constant expression
z2_type.f90:8:21:

type(t) :: c4 = t(c4%n)
 1
Error: Parameter ‘c4’ at (1) has not been declared or is a variable, which does
not reduce to a constant Expression

#
# c5, c6 differs
#

[Bug c++/51048] Class template inheritance doesn't work well with function-local types

[paolo at gcc dot gnu.org]

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

--- Comment #7 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Jun 15 19:26:27 2015
New Revision: 224492

URL: https://gcc.gnu.org/viewcvs?rev=224492&root=gcc&view=rev
Log:
/cp
2015-06-15  Paolo Carlini  

PR c++/51048
* decl2.c (no_linkage_error): Do not issue a permerror if the DECL
using a local type is pure virtual.

/testsuite
2015-06-15  Paolo Carlini  

PR c++/51048
* g++.dg/cpp0x/local-type1.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/local-type1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/51048] Class template inheritance doesn't work well with function-local types

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

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

[Bug fortran/66545] ICE on using undefined parameter/variable values

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-06-15
 CC||tkoenig at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Thomas Koenig  ---
This fixes the complex part, the others need their own parts.

Index: primary.c
===
--- primary.c   (Revision 224450)
+++ primary.c   (Arbeitskopie)
@@ -1254,6 +1254,13 @@ match_sym_complex_part (gfc_expr **result)
   return MATCH_ERROR;
 }

+  if (sym->value == NULL)
+{
+  gfc_error ("PARAMETER %qs is used at %C before its definition "
+"is complete", sym->name);
+  return MATCH_ERROR;
+}
+
   if (!gfc_numeric_ts (&sym->value->ts))
 {
   gfc_error ("Numeric PARAMETER required in complex constant at %C");

[Bug fortran/66545] ICE on using undefined parameter/variable values

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #3)
> This fixes the complex part, the others need their own parts.
> 
> Index: primary.c
> ===
> --- primary.c   (Revision 224450)
> +++ primary.c   (Arbeitskopie)
> @@ -1254,6 +1254,13 @@ match_sym_complex_part (gfc_expr **result)
>return MATCH_ERROR;
>  }
>  
> +  if (sym->value == NULL)
> +{
> +  gfc_error ("PARAMETER %qs is used at %C before its definition "
> +"is complete", sym->name);
> +  return MATCH_ERROR;
> +}
> +
>if (!gfc_numeric_ts (&sym->value->ts))
>  {
>gfc_error ("Numeric PARAMETER required in complex constant at %C");

I have 

  if (!sym->value)
goto error;

which leads to the same error.

[Bug c++/66542] [4.9/5/6 Regression] [C++11] Can create static variable of type that has deleted destructor

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Daniel Krügler from comment #1)
> This seems to be a regression versus gcc 4.8.2

That's why I changed the title to say [4.9/5/6 Regression] :-)

[Bug jit/66546] New: No way to disable check for unreachable blocks

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 66546
   Summary: No way to disable check for unreachable blocks
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Currently libgccjit always issues a hard error about unconditional blocks.

Some interpreters (e.g. Lua) generate bytecode that may have unreachable
instructions, so it should make it easier for client code if they can have a
way to turn off this check.

See https://gcc.gnu.org/ml/jit/2015-q2/msg00057.html

[Bug fortran/66545] ICE on using undefined parameter/variable values

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---

> I have 
> 
>   if (!sym->value)
> goto error;
> 
> which leads to the same error.

I think your approach is better.

Your bug :-)

[Bug jit/66546] No way to disable check for unreachable blocks

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
(In reply to David Malcolm from comment #0)
> instructions, so it should make it easier for client code if they can have a
jit client code, that is, i.e. interpreters linking against libgccjit

[Bug jit/66546] No way to disable check for unreachable blocks

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
(In reply to David Malcolm from comment #0)
> Currently libgccjit always issues a hard error about unconditional blocks.
"unreachable", that should say

[Bug fortran/66545] ICE on using undefined parameter/variable values

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Mon, Jun 15, 2015 at 09:19:45PM +, tkoenig at gcc dot gnu.org wrote:
> 
> > I have 
> > 
> >   if (!sym->value)
> > goto error;
> > 
> > which leads to the same error.
> 
> I think your approach is better.
> 
> Your bug :-)
> 

This passes regression testing.  So, do I have
your approval (with an appropriate testcase of
course)?

[Bug c/66516] missing diagnostic on taking the address of a builtin function

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Working on a patch.

[Bug libstdc++/60407] [C++11] call of overloaded ‘isnan’ is ambiguous

[eugene.zelenko at gmail dot com]

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

Eugene Zelenko  changed:

   What|Removed |Added

 CC||eugene.zelenko at gmail dot com

--- Comment #13 from Eugene Zelenko  ---
Same problem exists in 4.9.2.

In my code combining  with  (later includes os_defines.h then
features.h and mathcalls.h) produce same effect.

[Bug c/66547] New: arm-none-eabi-gcc - stack misaligned when calling va_arg function

[matt at hpamotorsport dot com]

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

Bug ID: 66547
   Summary: arm-none-eabi-gcc - stack misaligned when calling
va_arg function
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at hpamotorsport dot com
  Target Milestone: ---

Created attachment 35785
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35785&action=edit
File from project

I'm working on a project that uses ChibiOS
(https://github.com/ChibiOS/ChibiOS/tree/stable_2.6.x) where I have a function
that calls a va_arg function but the stack is not aligned after the calling
function allocates it's local resources. This causes 64-bit variables (long
long as well as double) to be incorrectly placed.

The assembly generated shows that the stack pointer is moved by 116 where it
should be moved by 120 to keep the alignment to 8-bytes.




arm-none-eabi-gcc -c -mcpu=cortex-m3 -Os -ggdb -fsingle-precision-constant
-mno-unaligned-access -mabi=aapcs -mtune=cortex-m3 -save-temps
-ffunction-sections -fdata-sections -fno-common  -Wall -Wextra
-Wstrict-prototypes -Wa,-alms=build/lst/performance.lst  -DCORTEX_USE_FPU=FALSE
-DBOARD_HALDEX_STM32_P105_A1=1 -DOSC_HAS_64BIT -DOSC_HAS_FLOAT
-DOSC_HAS_HEARTBEAT -DSLP_HAS_USB -D__BUILD_NUMBER=`cat build-number.txt`
-DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF
.dep/performance.o.d -mthumb -DTHUMB -I.
-I../ChibiOS_2.6.7/os/ports/common/ARMCMx/CMSIS/include
-I../ChibiOS_2.6.7/os/ports/common/ARMCMx
-I../ChibiOS_2.6.7/os/ports/GCC/ARMCMx
-I../ChibiOS_2.6.7/os/ports/GCC/ARMCMx/STM32F1xx
-I../ChibiOS_2.6.7/os/kernel/include -I../ChibiOS_2.6.7/os/hal/include
-I../ChibiOS_2.6.7/os/hal/platforms/STM32F1xx
-I../ChibiOS_2.6.7/os/hal/platforms/STM32
-I../ChibiOS_2.6.7/os/hal/platforms/STM32/GPIOv1
-I../ChibiOS_2.6.7/os/hal/platforms/STM32/I2Cv1
-I../ChibiOS_2.6.7/os/hal/platforms/STM32/RTCv1
-I../ChibiOS_2.6.7/os/hal/platforms/STM32/SPIv1
-I../ChibiOS_2.6.7/os/hal/platforms/STM32/TIMv1
-I../ChibiOS_2.6.7/os/hal/platforms/STM32/USARTv1
-I../ChibiOS_2.6.7/os/hal/platforms/STM32/OTGv1 -I../HPA_Libraries/board
-I../ChibiOS_2.6.7/os/various -I../HPA_Libraries performance.c -o
build/obj/performance.o

[Bug target/66547] arm-none-eabi-gcc - stack misaligned when calling va_arg function

[matt at hpamotorsport dot com]

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

--- Comment #1 from Matthew Peters  ---
Adding some notes.

The stack is a local stack generated with "static WORK_AREA(...)" from ChibiOS.
I've checked and the stack is aligned at the beginning of
performance_suite_thread.

I've been unable to make a test that produces the error.

[Bug c++/66548] New: Invalid class member access expression in decltype sometimes accepted

[rs2740 at gmail dot com]

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

Bug ID: 66548
   Summary: Invalid class member access expression in decltype
sometimes accepted
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

The following code is accepted by GCC 5.1 and 6.0.0 20150615 (experimental),
even though it is plainly invalid:

struct Meow {};

int main(){
decltype(Meow.purr()) d;
}

GCC 4.9.2 correctly rejects this code.

[Bug c++/66548] Invalid class member access expression in decltype sometimes accepted

[rs2740 at gmail dot com]

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

--- Comment #1 from TC  ---
See also http://stackoverflow.com/q/30856911/2756719

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

--- Comment #4 from Nathan Sidwell  ---
Author: nathan
Date: Tue Jun 16 01:59:55 2015
New Revision: 224502

URL: https://gcc.gnu.org/viewcvs?rev=224502&root=gcc&view=rev
Log:
cp/
PR c++/58583
* cp-tree.h (DECL_INSTANTIATING_NSDMI_P): New.
* init.c (get_nsdmi): Check for DEFAULT_ARG in template case and
protect it from recursive instantiation.

testsuite/
PR c++/58583
* g++.dg/cpp0x/nsdmi-template14.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/58583] [c++11] ICE with invalid non-static data member initialization in template

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #5 from Nathan Sidwell  ---
fixed on trunk.  Note initializers are instantiated lazily, so invalid ones may
be accepted without error, if never instantiated.

[Bug c++/58616] [meta-bug] nsdmi

[nathan at gcc dot gnu.org]

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

Bug 58583 Summary: [c++11] ICE with invalid non-static data member 
initialization in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58583

   What|Removed |Added

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

[Bug fortran/66549] New: ICE on valid in OMP parallel region

[abensonca at gmail dot com]

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

Bug ID: 66549
   Summary: ICE on valid in OMP parallel region
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abensonca at gmail dot com
  Target Milestone: ---

The following causes an ICE with gfortran 6.0 (r224494):

module smfa
  type :: sgc
   contains
 procedure :: sla => sa
  end type sgc
  class(sgc), pointer :: sg_
  double precision, allocatable, dimension(:) :: vni 
contains
  double precision function sa(self,i)
class(sgc), intent(in   ) :: self
  end function sa
  subroutine cvn(sg_,vn)
class(sgc), intent(inout) :: sg_
double precision, intent(  out), dimension(:) :: vn
integer :: i
do i=1,2
   vn(i)= sg_%sla(i)
end do
  end subroutine cvn
  subroutine clwf()
!$omp parallel
call cvn(sg_,vni)
!$omp end parallel
  end subroutine clwf
end module smfa

$ gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/gcc-trunk/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/opt/gcc-trunk
--enable-languages=c,c++,fortran --disable-multilib
Thread model: posix
gcc version 6.0.0 20150615 (experimental) (GCC)

$ gfortran -c test2.F90 -O2 -fopenmp
test2.F90:12:0:

   subroutine cvn(sg_,vn)
^
internal compiler error: in create_component_ref_by_pieces_1, at
tree-ssa-pre.c:2585
0xcfb5bf create_component_ref_by_pieces_1
../../gcc-trunk/gcc/tree-ssa-pre.c:2585
0xcfb02f create_component_ref_by_pieces_1
../../gcc-trunk/gcc/tree-ssa-pre.c:2538
0xcfacb0 create_component_ref_by_pieces_1
../../gcc-trunk/gcc/tree-ssa-pre.c:2594
0xcfa40e create_component_ref_by_pieces
../../gcc-trunk/gcc/tree-ssa-pre.c:2735
0xcfa40e create_expression_by_pieces
../../gcc-trunk/gcc/tree-ssa-pre.c:2826
0xcfb875 insert_into_preds_of_block
../../gcc-trunk/gcc/tree-ssa-pre.c:3025
0xcff1de do_regular_insertion
../../gcc-trunk/gcc/tree-ssa-pre.c:3353
0xcff1de insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3563
0xcfe807 insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3573
0xcfe807 insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3573
0xcfe807 insert_aux
../../gcc-trunk/gcc/tree-ssa-pre.c:3573
0xd0126d insert
../../gcc-trunk/gcc/tree-ssa-pre.c:3596
0xd0126d execute
../../gcc-trunk/gcc/tree-ssa-pre.c:4864
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

If compiled with -O1 instead of -O2 a different ICE occurs:

$ gfortran -c test2.F90 -O1 -fopenmp
test2.F90:16:0:

 do i=1,2
^
internal compiler error: in make_decl_rtl, at varasm.c:1320
0xe3f385 make_decl_rtl(tree_node*)
../../gcc-trunk/gcc/varasm.c:1316
0x854c93 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc-trunk/gcc/expr.c:9489
0x861bbe expand_expr
../../gcc-trunk/gcc/expr.h:255
0x861bbe expand_assignment(tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/expr.c:5130
0x755a95 expand_gimple_stmt_1
../../gcc-trunk/gcc/cfgexpand.c:3318
0x755a95 expand_gimple_stmt
../../gcc-trunk/gcc/cfgexpand.c:3414
0x757ebc expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5426
0x75e846 execute
../../gcc-trunk/gcc/cfgexpand.c:6045
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

If compiled without -fopenmp compilation is successful.

[Bug libstdc++/66530] libstdc++ testsuite links to incorrect shared libstdc++ library

[jy38 at zips dot uakron.edu]

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

--- Comment #2 from Jennifer Yao  ---
(In reply to Jonathan Wakely from comment #1)
> Does the
> /cygdrive/c/Users/yaoj3/Code/gcc/build/trunk/x86_64-pc-cygwin/./libstdc++-v3/
> src/.libs directory in the LD_LIBRAY_PATH contain the libstdc++.so.6 library?

The requisite DLL and import library are both present (cygstdc++-6.dll and
libstdc++.dll.a, respectively).

(In reply to Jonathan Wakely from comment #1)
> (In reply to Jennifer Yao from comment #0)
> > My hypothesis (and please correct me if I'm wrong) is that the libstdc++
> > that is being loaded at runtime is the preexisting (unaltered/unpatched)
> > library in the install tree, rather than the altered/patched library in the
> > build tree.
> 
> If that's true it must be a cygwin problem, as it doesn't happen for other
> targets. All testing should be done against the build tree, and that's what
> happens for me.

Are you sure that the libstdc++ in the build tree is the one that's loaded at
runtime on your system? I only ask because I don't have a Linux system to test
on, and it would be relatively easy to overlook since much of libstdc++ is
header-only anyway.

[Bug c++/55805] Empty brace-init-list causes warning "missing initializer for member" in C++11

[dave.gittins at gmail dot com]

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

Gubbins  changed:

   What|Removed |Added

 CC||dave.gittins at gmail dot com

--- Comment #2 from Gubbins  ---
The original bug report points that in C++11 this is *not* aggregate
initialization, but is in fact value initialization (because this is a class
type with a default constructor).

Therefore no field initializers are involved. The warning in this situation is
surely incorrect? I think the original bug report was correct and the problem
should be fixed.

[Bug debug/66550] New: [6 Regression] internal compiler error: verify_type failed

[ienkovich at gcc dot gnu.org]

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

Bug ID: 66550
   Summary: [6 Regression] internal compiler error: verify_type
failed
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

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

There is an ICE which appears when '-g' is used.  Reduced test is actually
invalid code (has undefined type) but there is a bigger valid test which fails
similarly.

>gcc test.i -g -S
test.i:4:11: error: field 'f1' has incomplete type
   enum e1 f1;
   ^
test.i:9:1: error: type variant has different TYPE_VFIELD
 };
 ^
...
test.i:9:1: internal compiler error: verify_type failed
...

Reproduced on r224363

Re: gcc 4.9.2 and above are not aware of malloc (and friends) hooks

[Gilles Gouaillardet]

Andrew and all,

as i explained, i already marked the global variable as volatile to get it work.

my (and other Open MPI folks) question is more about gcc :
- is this a bug ? (and it will be fixed, and volatile will not be
needed in the future)
- is this a known "feature" and it will not be fixed. (gcc
deliberately makes such aggressive optimizations that are known to be
illegal in very rare cases, so marking the variable as volatile is not
a workaround but a requirement)

thanks in advance for the clarification

Gilles

On Wed, Jun 10, 2015 at 10:33 AM, Gilles Gouaillardet
 wrote:
> Andrew and all,
>
> as i explained, i already marked the global variable as volatile to get it 
> work.
>
> my (and other Open MPI folks) question is more about gcc :
> - is this a bug ? (and it will be fixed, and volatile will not be
> needed in the future)
> - is this a known "feature" and it will not be fixed. (gcc
> deliberately makes such aggressive optimizations that are known to be
> illegal in very rare cases, so marking the variable as volatile is not
> a workaround but a requirement)
>
> thanks in advance for the clarification
>
> Gilles
>
> On Tue, Jun 9, 2015 at 1:48 PM, Andrew Pinski  wrote:
>> On Tue, Jun 9, 2015 at 12:42 PM, Gilles Gouaillardet
>>  wrote:
>>> This is a follow-up on a discussion about OpenMPI that started at
>>> http://www.open-mpi.org/community/lists/users/2015/06/27039.php
>>> and continued at https://github.com/open-mpi/ompi/pull/625
>>>
>>> The attached test program does not produce correct results with gcc
>>> 4.9.2 and gcc 5.1.0 with -O1 or greater (gcc 4.8.7 is safe)
>>>
>>> At first glance, it seems gcc is not aware a wrapper can be added to
>>> posix_memalign and hence posix_memalign can have some side effects
>>> such as updating user global variables.
>>
>> mark the global variable as volatile.
>>
>> Thanks,
>> Andrew
>>
>>>
>>>
>>> A workaround is to declare the global variable as volatile.
>>>
>>> The expected output of this test program is :
>>> global = 0
>>> changed !
>>> global = 1
>>>
>>>
>>> here are the full outputs with gcc 4.9.2 and 5.1.0 and from O0 to O3
>>>
>>> $ gcc --version ; for i in 0 1 2 3 ; do echo ; echo opt = O$i ; gcc -o
>>> test.O$i -Wno-deprecated-declarations -O$i test.c ; ./test.O$i ; done
>>> gcc (GCC) 4.9.2
>>> Copyright (C) 2014 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>
>>>
>>> opt = O0
>>> global = 0
>>> changed !
>>> global = 1
>>>
>>> opt = O1
>>> global = 0
>>> global = 1
>>>
>>> opt = O2
>>> global = 0
>>> global = 0
>>>
>>> opt = O3
>>> global = 0
>>> global = 0
>>>
>>>
>>> $ gcc --version ; for i in 0 1 2 3 ; do echo ; echo opt = O$i ; gcc -o
>>> test.O$i -Wno-deprecated-declarations -O$i test.c ; ./test.O$i ; done
>>> gcc (GCC) 5.1.0
>>> Copyright (C) 2015 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>>>
>>>
>>> opt = O0
>>> global = 0
>>> changed !
>>> global = 1
>>>
>>> opt = O1
>>> global = 0
>>> global = 0
>>>
>>> opt = O2
>>> global = 0
>>> global = 0
>>>
>>> opt = O3
>>> global = 0
>>> global = 0
>>>
>>>
>>> please note the different behaviour with O1 between gcc 4.9.2 and gcc 5.1.0
>>>
>>>
>>> Could you please comment on this issue ?
>>> - is this a bug ?
>>> - is this a "feature" ? (e.g. a known to be aggressive optimization
>>> that explicitly requires the global variable is declared as volatile)
>>>
>>>
>>> Thanks and regards,
>>>
>>> Gilles

[Bug debug/66068] [6 Regression] error: type variant has different TYPE_VFIELD

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||ienkovich at gcc dot gnu.org

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

[Bug debug/66550] [6 Regression] internal compiler error: verify_type failed

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

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

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