[Bug libgomp/68242] New: [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c -DACC_DEVICE_TYPE_host=1 execution test

[vries at gcc dot gnu.org]

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

Bug ID: 68242
   Summary: [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c
-DACC_DEVICE_TYPE_host=1 execution test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

I observe when testing gomp4_0-branch on x86_64 with -m32:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-2.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 -foffload=disable execution test
...

[Bug libgomp/68242] [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c -DACC_DEVICE_TYPE_host=1 execution test

[vries at gcc dot gnu.org]

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

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

With tracing patch, for -m64, we see:
...
res:5050.00 vres:5050.00
res:inf vres:inf
res:5050.00 vres:5050.00
res:inf vres:inf
res:5050.00 vres:5050.00
res:inf vres:inf
res:5050.00 vres:5050.00
res:inf vres:inf
...

The inf means that the multiply-reductions overflow. We could try to reduce the
values in the array to prevent that.

With tracing patch, for -m32, we see:
...
res:5050.00 vres:5050.00
res:inf
vres:93326215443944150965646704795953882578400970373184098831012889540582227238570431295066113089288327277825849664006524270554535976289719382852181865895959724032.00
Aborted (core dumped)
...

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

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

--- Comment #12 from Markus Trippelsdorf  ---
(In reply to Markus Trippelsdorf from comment #11)
> (In reply to rguent...@suse.de from comment #10)
> > >
> > > Valgrind points to r228599:
> > 
> > Nothing obvious but does removing
> > 
> >   mark_virtual_operands_for_renaming (cfun);
> > 
> > help?  It's the only thing that may end up releasing SSA names
> > (if only virtuals).
> 
> No, it doesn't help. But reverting r228760 and r228599 fixes the issue.

No, reverting  r228760 and r228599 doesn't help. So back to square one.

trippels@gcc2-power8 shell % ~//gcc_test/usr/local/bin/c++ -o js -Wall
-Wignored-qualifiers -Wsign-compare -Wtype-limits -Werror=char-subscripts
-Werror=comment -Werror=empty-body -Werror=endif-labels
-Werror=int-to-pointer-cast -Werror=missing-braces -Werror=overloaded-virtual
-Werror=pointer-arith -Werror=reorder -Werror=return-type
-Werror=sequence-point -Werror=switch -Werror=trigraphs -Werror=unknown-pragmas
-Werror=unused-label -Werror=unused-value -Werror=write-strings
-Werror=conversion-null -Wno-invalid-offsetof -Wcast-align -std=c++1z -w
-flto=80 --param lto-partitions=80 -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pthread -pipe -DNDEBUG
-DTRIMMED -O3 -fomit-frame-pointer Unified_cpp_js_src_shell0.o
../../../mozglue/build/dummy.o ../../../mfbt/Compression.o
../../../mfbt/Decimal.o ../../../mfbt/Unified_cpp_mfbt0.o -lpthread
-Wl,--hash-style=gnu,--as-needed,--gc-sections,--icf=all -Wl,-z,noexecstack
-Wl,-z,text -Wl,--build-id -Wl,-rpath-link,../../../dist/bin
-Wl,-rpath-link,/home/trippels/moz-build-dir/dist/lib ../libjs_static.a
-rdynamic -lm -ldl -lffi -licui18n -licuuc -licudata -L/usr/lib64 -lplds4
-lplc4 -lnspr4 -lz -lm -ldl   
/home/trippels/gecko-dev/js/src/builtin/SIMD.cpp: In function
‘simd_float32x4_reciprocal’:
/home/trippels/gecko-dev/js/src/builtin/SIMD.cpp:1221:1: error: incompatible
types in PHI argument 0
 FLOAT32X4_FUNCTION_LIST(DEFINE_SIMD_FLOAT32X4_FUNCTION)
 ^

unsigned int

struct BarrieredBase *

i_38 = PHI 
/home/trippels/gecko-dev/js/src/builtin/SIMD.cpp:1221:1: internal compiler
error: verify_gimple failed
0x107448cb verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:5082
0x105ecabf execute_function_todo
../../gcc/gcc/passes.c:1945
0x105ed773 do_per_function
../../gcc/gcc/passes.c:1632
0x105eda9f execute_todo
../../gcc/gcc/passes.c:2000
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/home/trippels/tmp/ccL2JcUK.ltrans5.ltrans.o] Error 1

Adding  -r -nostdlib makes it segfault instead:
trippels@gcc2-power8 shell % ~//gcc_test/usr/local/bin/c++ -r -nostdlib -o js
-Wall -Wignored-qualifiers -Wsign-compare -Wtype-limits -Werror=char-subscripts
-Werror=comment -Werror=empty-body -Werror=endif-labels
-Werror=int-to-pointer-cast -Werror=missing-braces -Werror=overloaded-virtual
-Werror=pointer-arith -Werror=reorder -Werror=return-type
-Werror=sequence-point -Werror=switch -Werror=trigraphs -Werror=unknown-pragmas
-Werror=unused-label -Werror=unused-value -Werror=write-strings
-Werror=conversion-null -Wno-invalid-offsetof -Wcast-align -std=c++1z -w
-flto=80 --param lto-partitions=80 -ffunction-sections -fdata-sections
-fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pipe -DNDEBUG -DTRIMMED
-O3 -fomit-frame-pointer Unified_cpp_js_src_shell0.o
../../../mozglue/build/dummy.o ../../../mfbt/Compression.o
../../../mfbt/Decimal.o ../../../mfbt/Unified_cpp_mfbt0.o -lpthread -Wl,-z,text
-Wl,--build-id -Wl,-rpath-link,../../../dist/bin
-Wl,-rpath-link,/home/trippels/moz-build-dir/dist/lib ../libjs_static.a
-rdynamic -lm -ldl -lffi -licui18n -licuuc -licudata -L/usr/lib64 -lplds4
-lplc4 -lnspr4 -lz -lm -ldl
/home/trippels/gecko-dev/js/src/jsgc.cpp: In member function
‘sweepCompartments’:
/home/trippels/gecko-dev/js/src/jsgc.cpp:3420:1: error: invalid PHI argument
 Zone::sweepCompartments(FreeOp *fop, bool keepAtleastOne, bool lastGC)
 ^

<<< Unknown tree:  >>>
/home/trippels/gecko-dev/js/src/jsgc.cpp:3420:1: internal compiler error:
Segmentation fault
0x106eba33 crash_signal
../../gcc/gcc/toplev.c:336
0x10743ee4 contains_struct_check
../../gcc/gcc/tree.h:3030
0x10743ee4 verify_gimple_phi
../../gcc/gcc/tree-cfg.c:4658
0x10743ee4 verify_gimple_in_cfg(function*, bool)
../../gcc/gcc/tree-cfg.c:4952
0x105ecabf execute_function_todo
../../gcc/gcc/passes.c:1945
0x105ed773 do_per_function
../../gcc/gcc/passes.c:1632
0x105eda9f execute_todo
../../gcc/gcc/passes.c:2000
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [/home/trippels/tmp/ccv49A7w.ltrans35.ltrans.o] Error 1
make: *** Wait

[Bug fortran/68243] New: QOI: no warning about unused entities in submodules

[mar...@mpa-garching.mpg.de]

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

Bug ID: 68243
   Summary: QOI: no warning about unused entities in submodules
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mar...@mpa-garching.mpg.de
  Target Milestone: ---

Created attachment 36665
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36665&action=edit
test case

When compiling the attached test case with current gfortran trunk, it emits the
warnings:

martin@marvin ~/tmp $ gfortran -W -Wall -c test.f08 
test.f08:12:17:

   integer unused1
 1

Warning: Unused PRIVATE module variable ‘unused1’ declared at (1)
[-Wunused-value]
test.f08:16:0:

   subroutine unused2


Warning: ‘unused2’ defined but not used [-Wunused-function]

But the unused entities "unused3" and "unused4" in the submodule are not
mentioned. As far as I can tell, they are invisible outside the submodule, and
should therefore be provably unused.

[Bug tree-optimization/68235] gimple optimisations always use global -fmath-errno setting

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Sat Nov  7 09:58:32 2015
New Revision: 229917

URL: https://gcc.gnu.org/viewcvs?rev=229917&root=gcc&view=rev
Log:
Add -fno-math-errno to gcc.dg/lto/20110201-1_0.c

At the moment the ECF_* flags for a gimple call to a built-in
function are derived from the function decl, which in turn is
derived from the global command-line options.  So if the compiler
is run with -fno-math-errno, we always assume functions don't set
errno, regardless of local optimization options.  Similarly if the
compiler is run with -fmath-errno, we always assume functions set errno.

This shows up in gcc.dg/lto/20110201-1_0.c, where we compile
the file with -O0 and use -O2 -ffast-math for a specific function.
-O2 -ffast-math is enough for us to convert cabs to sqrt as hoped,
but because of the global -fmath-errno setting, we assume that the
call to sqrt is not pure or const and create vops for it.  This makes
it appear to the gimple code that a simple sqrt optab isn't enough.

Later patches move more decisions about maths functions to gimple
and think that in this case we should use:

y = sqrt (x);
if (!(x >= 0))
sqrt (x); // to set errno.

This is being tracked as PR68235.  For now the patch adds
-fno-math-errno to the dg-options for this test.

Tested on x86_64-linux-gnu, aarch64-linux-gnu and arm-linux-gnueabi.

gcc/testsuite/
PR tree-optimization/68235
* gcc.dg/lto/20110201-1_0.c: Add -fno-math-errno.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/lto/20110201-1_0.c

[Bug fortran/68243] QOI: no warning about unused entities in submodules

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 CC||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug fortran/68226] ICE on wrong assignment of function pointer to allocatable

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed for 4.9.3 up to trunk (6.0). Version 4.8.5 gives the following error

   a = f()
   1
Error: Can't convert CLASS(t) to TYPE(t) at (1)

A first change occurred between revisions r201266 (2013-07-26, error) and
r201631 (2013-08-09, no error->wrong code?). A second change occurred between
revisions r205679 (2013-12-04, no error) and r206069 (2013-12-17, ICE).

[Bug fortran/68225] ICE with -Wrealloc-lhs-all on structure constructor with allocatable components

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Compiling the first three tests with 4.8.5 or 4.9.3 and -Wrealloc-lhs-all gives
the following error

   x = t2()
   1
Error: No initializer for component 'a' given in the structure constructor at
(1)!

i.e., no ICE. Am I correct to understand that this error is bogus for Fortran
2008 (at least)? The last test compiles but segfault at run time.

I confirm the ICE for 5.2.0 and trunk (6.0).

A first change occurred between revisions r219067 (2014-12-25, error) and
r219174+two patches (2015-01-04, no error, segfault at run time). A second
change occurred between revisions r219763 (2015-01-16, no error, segfault) and
r219772+one patch (2015-01-16, ICE).

[Bug libgomp/68242] [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c -DACC_DEVICE_TYPE_host=1 execution test

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 CC||cesar at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
Yes, I had reported that to Cesar in
,
but it has not yet been fixed.  (Same for the other items that I reported in
this email.)

[Bug fortran/68224] ICE on referencing parameter array with dimension null

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (6.0). Note that only one of the two lines

   integer, parameter :: a = c(1)
   integer :: b = c(2)

is enough to trigger the ICE.

[Bug middle-end/68117] [6 Regression] error: invalid PHI argument <<< Unknown tree: >>>

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||Joost.VandeVondele at mat dot 
ethz
   ||.ch

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

[Bug middle-end/68127] [6 Regression] ICE: error: incompatible types in PHI argument 0 / Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #3 from Markus Trippelsdorf  ---
Lets merge the two bugs.

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

[Bug fortran/67623] interaction between cpp and Fortran

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

[Bug fortran/53977] CPP: Support __func__/__FUNCTION__

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
Any interest for this PR (more than three years without any activity)?

[Bug fortran/53934] Better CPP macro diagnostics

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

[Bug fortran/40978] Use named return value (NRV) for functions returning the result as argument

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Six years without any activity. Is there any reason to keep this PR opened?

[Bug fortran/53481] Allow for gfortran (f951) specs option

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-11-07
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
No activity for more than three years. Is anybody interested or should this PR
closed as WONTFIX?

[Bug fortran/68243] QOI: no warning about unused entities in submodules

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #2 from Paul Thomas  ---
That's a wierd one! I'll take a look later on.

Thanks

Paul

[Bug fortran/68216] [F2003] IO problem with allocatable, deferred character length arrays

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
I had a devil of a job fixing the second testcase, from "Blockbuster", in the
clf thread above:

program testdefchar
implicit none
character(:), allocatable :: test(:)

allocate(character(3) :: test(2))
test(1) = 'abc'
test(2) = 'def'
write(*,*) test(1), test(2)

test = ['aa','bb','cc']
write(*,*) test(1), test(2), test(3)

end program testdefchar

The fix is now regtesting.

Paul

[Bug libgomp/68242] [gomp4] FAIL: libgomp.oacc-c-c++-common/reduction-2.c -DACC_DEVICE_TYPE_host=1 execution test

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
I think my firstprivate patch resolves this one.

[Bug fortran/68224] ICE on referencing parameter array with dimension null

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #3 from kargl at gcc dot gnu.org ---
It appears that this needs to be fixed in match_array_element_spec.
When the lower and upper array indices are matched, there is no
checking for NULL().  NULL() is an interesting intrinsic function.

[Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Nov  7 18:13:17 2015
New Revision: 229935

URL: https://gcc.gnu.org/viewcvs?rev=229935&root=gcc&view=rev
Log:
2015-11-07 Jerry DeLisle  

Backport from trunk
PR libgfortran/65089
* io/format.h (free_format): New function to free memory
allocated for building format error messages.
* io/format.c (format_error): Add checks before freeing memory
to avoid potential segfaults and free formatting data when
needed on error conditions. Always allocate and NULL terminate
the string.
* io/transfer.c (st_read_done, st_write_done): Use new
free_format function to clean up memory allocations when done.

Modified:
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/io/format.c
branches/gcc-5-branch/libgfortran/io/format.h
branches/gcc-5-branch/libgfortran/io/transfer.c

[Bug fortran/68224] ICE on referencing parameter array with dimension null

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from kargl at gcc dot gnu.org ---
I have a patch regression testing.

[Bug fortran/65089] FAIL: gfortran.dg/io_real_boz(2|_[45]).f90 when tested with -fsanitize=address

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #18 from Jerry DeLisle  ---
Closing

[Bug libobjc/24775] libobjc should not include GCC's target headers

[tbsaunde at gcc dot gnu.org]

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

--- Comment #8 from tbsaunde at gcc dot gnu.org ---
Author: tbsaunde
Date: Sat Nov  7 19:36:26 2015
New Revision: 229936

URL: https://gcc.gnu.org/viewcvs?rev=229936&root=gcc&view=rev
Log:
replace BITS_PER_UNIT with __CHAR_BIT__ in target libs

libgcc/ChangeLog:

2015-11-07  Trevor Saunders  

* config/visium/lib2funcs.c (__set_trampoline_parity): Use
__CHAR_BIT__ instead of BITS_PER_UNIT.
* fixed-bit.h: Likewise.
* fp-bit.h: Likewise.
* libgcc2.c (__popcountSI2): Likewise.
(__popcountDI2): Likewise.
* libgcc2.h: Likewise.
* libgcov.h: Likewise.

libobjc/ChangeLog:

2015-11-07  Trevor Saunders  

PR libobjc/24775
* encoding.c (_darwin_rs6000_special_round_type_align): Use
__CHAR_BIT__ instead of BITS_PER_UNIT.
(objc_sizeof_type): Likewise.
(objc_layout_structure): Likewise.
(objc_layout_structure_next_member): Likewise.
(objc_layout_finish_structure): Likewise.
(objc_layout_structure_get_info): Likewise.

Modified:
trunk/libgcc/ChangeLog
trunk/libgcc/config/visium/lib2funcs.c
trunk/libgcc/fixed-bit.h
trunk/libgcc/fp-bit.h
trunk/libgcc/libgcc2.c
trunk/libgcc/libgcc2.h
trunk/libgcc/libgcov.h
trunk/libobjc/ChangeLog
trunk/libobjc/encoding.c

[Bug rtl-optimization/67864] [6 Regression] CSiBE size regression

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool  ---
Author: segher
Date: Sat Nov  7 19:44:21 2015
New Revision: 229937

URL: https://gcc.gnu.org/viewcvs?rev=229937&root=gcc&view=rev
Log:
i386: Use the STC bb-reorder algorithm at -Os (PR67864)

For x86, STC still gives better results for optimise-for-size than
"simple" does.  So use STC at -Os as well.


PR rtl-optimization/67864
* common/config/i386/i386-common.c (ix86_option_optimization_table)
: Use REORDER_BLOCKS_ALGORITHM_STC
at -Os and up.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/i386/i386-common.c

[Bug fortran/68151] ICE on using select case with function of wrong type

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Nov  7 20:04:43 2015
New Revision: 229938

URL: https://gcc.gnu.org/viewcvs?rev=229938&root=gcc&view=rev
Log:
2015-11-07  Steven G. Kargl  

PR fortran/68151
* match.c (match_case_selector):  Check for invalid type.

2015-11-07  Steven G. Kargl  

PR fortran/68151
* gfortran.dg/pr68151.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68151.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/68153] ICE for intrinsic reshape with negative dim in effective shape

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Sat Nov  7 20:18:17 2015
New Revision: 229939

URL: https://gcc.gnu.org/viewcvs?rev=229939&root=gcc&view=rev
Log:
2015-11-07  Steven G. Kargl  

PR fortran/68153
* check.c (gfc_check_reshape): Improve check for valid SHAPE argument.

2015-11-07  Steven G. Kargl  

PR fortran/68153
* gfortran.dg/pr68153.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr68153.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/check.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68244] New: FAIL: g++.dg/parse/parens3.C -std=gnu++98 (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 68244
   Summary: FAIL: g++.dg/parse/parens3.C  -std=gnu++98 (internal
compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/parse/parens3.C
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test
/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++98
-w -S -o parens3.s/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/parse/parens3.C: In
function 'int f()':/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/parse/parens3.C:18:1:
internal compiler error: in dwarf2out_frame_debug_expr, at
dwarf2cfi.c:1596libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
compiler exited with status 1
output is:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/parse/parens3.C: In function 'int f()':
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/parse/parens3.C:18:1: internal compiler
e
rror: in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1596
libbacktrace could not find executable to openPlease submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

FAIL: g++.dg/parse/parens3.C  -std=gnu++98 (internal compiler error)
FAIL: g++.dg/parse/parens3.C  -std=gnu++98 (test for excess errors)
Excess errors:
/test/gnu/gcc/gcc/gcc/testsuite/g++.dg/parse/parens3.C:18:1: internal compiler
error: in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1596
libbacktrace could not find executable to open

The ICE is here:
  /* Saving a register in a register.  */
  gcc_assert (!fixed_regs [REGNO (dest)]
  /* For the SPARC and its register window.  */
  || (dwf_regno (src) == DWARF_FRAME_RETURN_COLUMN));

The parsing of this statement

register struct s *reg __asm__( "1" );

causes register "1" to be gloabized and fixed:

Breakpoint 7, _Z13globalize_regP9tree_nodei (decl=0x7b0200b0, i=1)
at ../../gcc/gcc/reginfo.c:800
800   fixed_regs[i] = call_used_regs[i] = 1;
(gdb) p i
$24 = 1
(gdb) bt
Python Exception  Failed to load
/home/gnu/lib/python2.7/lib-dynload/itertools.sl: 
#0  _Z13globalize_regP9tree_nodei (decl=0x7b0200b0, i=1)
at ../../gcc/gcc/reginfo.c:800
#1  0x022aaac8 in _Z11SOURCE_LINEPK17line_map_ordinaryj (ord_map=0x7b0200b0, 
loc=12) at ../../gcc/libcpp/include/line-map.h:894
#2  0x016a7878 in _Z24rest_of_decl_compilationP9tree_nodeii (decl=0x7b0200b0, 
top_level=1, at_end=0) at ../../gcc/gcc/passes.c:192
#3  0x00123374 in _ZL26make_rtl_for_nonlocal_declP9tree_nodeS0_PKc (
decl=0x7b0200b0, init=0x0, asmspec=0x7aede220 "1")
at ../../gcc/gcc/cp/decl.c:6225
#4  0x00127da0 in _Z14cp_finish_declP9tree_nodeS0_bS0_i (decl=0x7b0200b0, 
init=0x0, init_const_expr_p=false, asmspec_tree=0x7aede210, flags=1)
at ../../gcc/gcc/cp/decl.c:6840
#5  0x00372e98 in
_ZL25cp_parser_init_declaratorP9cp_parserP21cp_decl_specifier_seqP3vecI21deferred_access_check5va_gc8vl_embedEbbiPbPP9tree_nodePj
(
parser=0x7b020058, decl_specifiers=0x7eff0a6c, checks=0x0, 
function_definition_allowed_p=true, member_p=false, 
declares_class_or_enum=1, function_definition_p=0x7eff0aec, 
maybe_range_for_decl=0x0, init_loc=0x7eff0ae8)
at ../../gcc/gcc/cp/parser.c:18214
#6  0x00360bb0 in _ZL28cp_parser_simple_declarationP9cp_parserbPP9tree_node (
parser=0x7b020058, function_definition_allowed_p=true, 
maybe_range_for_decl=0x0) at ../../gcc/gcc/cp/parser.c:11988
#7  0x003607b8 in _ZL27cp_parser_block_declarationP9cp_parserb (
---Type  to continue, or q  to quit---
parser=0x7b020058, statement_p=false) at ../../gcc/gcc/cp/parser.c:11862
#8  0x00360364 in _ZL21cp_parser_declarationP9cp_parser (parser=0x7b020058)
at ../../gcc/gcc/cp/parser.c:11759
#9  0x0035fb64 in _ZL29cp_parser_declaration_seq_optP9cp_parser (
parser=0x7b020058) at ../../gcc/gcc/cp/parser.c:11638
#10 0x00347df8 in _ZL26cp_parser_translation_unitP9cp_parser (
parser=0x7b020058) at ../../gcc/gcc/cp/parser.c:4168
#11 0x003bee00 in _Z12c_parse_filev () at ../../gcc/gcc/cp/parser.c:36138
#12 0x0073ec98 in _Z19c_common_parse_filev ()
at ../../gcc/gcc/c-family/c-

[Bug c++/68245] New: FAIL: c-c++-common/gomp/clauses-2.c -std=c++98 (internal compiler error)

[danglin at gcc dot gnu.org]

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

Bug ID: 68245
   Summary: FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98
(internal compiler error)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/gcc/testsuite/g++/../../xg++
-B/test/gnu/gcc/objdir/g
cc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/test/
gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include/hppa2.0w-hp-hpux11.11 
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/include
-I/test/gnu/gc
c/gcc/libstdc++-v3/libsupc++ -I/test/gnu/gcc/gcc/libstdc++-v3/include/backward
-
I/test/gnu/gcc/gcc/libstdc++-v3/testsuite/util -fmessage-length=0 -std=c++98
-fo
penmp -S -o clauses-2.s
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c: In function
'void
 foo(int*, int, S, int, int, int, int)':
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:9:109: error: 'p' 
appears more than once in data clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:11:110: error:
'p'
 appears more than once in data clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:17:96: error: 'q' 
appears more than once in map clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:19:103: error:
'p'
 appears more than once in data clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:21:98: error: 't' 
appears more than once in map clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:23:98: error: 't' 
appears more than once in map clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:35:111: error:
't'
 appears more than once in data clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:37:111: error:
't'
 appears more than once in data clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:49:128: error:
't'
 appears more than once in data
clauses/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:49:128:
error: 't'
 appears more than once in map clauses
/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:51:129: error:
't'
 appears more than once in data
clauses/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:51:129:
error: 't' appears more than once in map
clauses/test/gnu/gcc/gcc/gcc/testsuite/c-c++-common/gomp/clauses-2.c:21:11:
internal compiler error: in gimplify_scan_omp_clauses, at
gimplify.c:6553libbacktrace could not find executable to openPlease submit a
full bug report,with preprocessed source if appropriate.
See  for instructions.compiler exited with status
1

FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98 (internal compiler error)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 9)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 11)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 17)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 19)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 21)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 23)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 25)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 35)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 37)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 39)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 41)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 43)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 49)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 49)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 51)
PASS: c-c++-common/gomp/clauses-2.c  -std=c++98  (test for errors, line 51)
FAIL: c-c++-common/gomp/clauses-2.c  -std=c++98 (test for excess errors)

  gcc_assert (base == decl
  && (offset == NULL_TREE
  || TREE_CODE (offset) == INTEGER_CST));

Breakpoint 1,
_ZL25gimplify_scan_omp_clausesPP9tree_nodePP6gimple15omp_region_type9tree_code
(list_p=0x7aebdcbc, pre_p=0x7eff0cd4, region_type=ORT_TARGET, 
code=OMP_TARGET) at ../../gcc/gcc/gimplify.c:6553
6553  || TREE_CODE (offset) ==
INTEGER_CST));
(gdb) p base
$1 = (tree) 0x7b0200b0
(gdb) p decl
$2 = (tree) 0x7ae38550
(gdb) p deb

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||segher at gcc dot gnu.org
 Resolution|FIXED   |---

--- Comment #5 from Segher Boessenkool  ---
This patch regresses Linux build for 32-bit powerpc.  We have code like

struct s {
  int fpr[32][1];
  int fpscr;
};

assert(offsetof(s, fpr[32][0]) == offsetof(s, fpscr));

which is well-defined code afaics; but after this patch GCC will not
allow it.

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
We discussed this case and agreed it's invalid because it attempts to compute
the offset of an element of an array past the end.  The equivalent but correct
expression is:

assert(offsetof(s, fpr[32]) == offsetof(s, fpscr));

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
Discussed, where?  I didn't see it.  Got a link?

[Bug c/67882] surprising offsetof result on an invalid array member without diagnostic

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
See the discussion of the __builtin_offsetof (FA5_7, a5_7 [5][0]) case below:
  https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01993.html

[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #6 from Mikael Pettersson  ---
Started with r208165 (on x86_64-linux with -O3).

[Bug c++/68246] New: Incorrect evaluation of C++1z fold expressions (... || expr) in concepts

[richardpku at gmail dot com]

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

Bug ID: 68246
   Summary: Incorrect evaluation of C++1z fold expressions (... ||
expr) in concepts
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richardpku at gmail dot com
  Target Milestone: ---

template  concept bool A_concept = (... || (x < 0));
template  constexpr bool A_constexpr = (... || (x < 0));

static_assert(A_concept<-1, 1>);   // This assertion fails, while it should not
static_assert(A_constexpr<-1, 1>); // OK.

Both static assertions should not fail.


It appears "&&" doesn't has this problem:

template  concept bool B_concept = (... && (x < 0));
template  constexpr bool B_constexpr = (... && (x < 0));

static_assert(B_concept<-1, -1>); // OK
static_assert(B_constexpr<-1, -1>); // OK

[Bug fortran/66577] ICE in generate_finalization_wrapper, at fortran/class.c:1567

[neil.n.carlson at gmail dot com]

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

neil.n.carlson at gmail dot com changed:

   What|Removed |Added

 CC||neil.n.carlson at gmail dot com

--- Comment #2 from neil.n.carlson at gmail dot com ---
I'm getting an ICE at the same line in generate_finalization_wrapper with the
following much smaller example:

module json

  type :: array_element
  contains
final :: array_element_delete
  end type

  type, public :: json_array_iterator
type(array_element), pointer :: element
  end type

contains

  subroutine array_element_delete (this)
type(array_element) :: this
  end subroutine

  subroutine array_iter_next (this)
class(json_array_iterator) :: this
  end subroutine

end module

% gfortran -c json.F90 
f951: internal compiler error: in generate_finalization_wrapper, at
fortran/class.c:1567
0x5fbccb generate_finalization_wrapper
../../gcc-5.2.0/gcc/fortran/class.c:1566
0x5fbccb gfc_find_derived_vtab(gfc_symbol*)
../../gcc-5.2.0/gcc/fortran/class.c:2401
0x67ce35 resolve_fl_derived
../../gcc-5.2.0/gcc/fortran/resolve.c:12946
0x6778c7 resolve_symbol
../../gcc-5.2.0/gcc/fortran/resolve.c:13226
0x69014b do_traverse_symtree
../../gcc-5.2.0/gcc/fortran/symbol.c:3646
0x67aa02 resolve_types
../../gcc-5.2.0/gcc/fortran/resolve.c:14973
0x67664f gfc_resolve(gfc_namespace*)
../../gcc-5.2.0/gcc/fortran/resolve.c:15083
0x661f56 gfc_parse_file()
../../gcc-5.2.0/gcc/fortran/parse.c:5476
0x6a15f5 gfc_be_parse_file
../../gcc-5.2.0/gcc/fortran/f95-lang.c:229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.

This is with 5.2.  But I get the same ICE with 4.9.2 and 6.0 20151025

[Bug fortran/37336] [F03] Finish derived-type finalization

[dominiq at lps dot ens.fr]

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

Bug 66577 Summary: ICE in generate_finalization_wrapper, at fortran/class.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66577

   What|Removed |Added

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

[Bug fortran/61767] ICE in generate_finalization_wrapper at fortran/class.c:1491

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 CC||Daniel.Kokron at nasa dot gov

--- Comment #3 from Dominique d'Humieres  ---
*** Bug 66577 has been marked as a duplicate of this bug. ***

[Bug fortran/66577] ICE in generate_finalization_wrapper, at fortran/class.c:1567

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #3 from Dominique d'Humieres  ---
Since the ICE is at the same location as for pr61767 and the following test

module json

  type :: array_element
  contains
final :: array_element_delete
  end type

  type, public :: json_array_iterator
integer, allocatable :: Dummy
type(array_element), pointer :: element
  end type

contains

  subroutine array_element_delete (this)
type(array_element) :: this
  end subroutine

  subroutine array_iter_next (this)
class(json_array_iterator) :: this
  end subroutine

end module

compiles fine (addition of "integer, allocatable :: Dummy" to the test in
comment 2), I think this is a duplicate of pr61767.

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

[Bug fortran/66577] ICE in generate_finalization_wrapper, at fortran/class.c:1567

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Note that if I do the same modification as in comment 3 to the original test

module SingleLinkedListClass
  implicit none
  private

  integer, parameter :: intG_IK = SELECTED_INT_KIND (8)

  type SingleLinkItem
integer (kind=4), public:: intTag
logical (kind=4), public:: blnIsPointer
class (*),  pointer :: udtData => NULL ()
type (SingleLinkItem),  pointer :: udtNext => NULL()
  contains
final :: Destroy
  end type SingleLinkItem

  type SingleLinkedList
 private
 integer, allocatable :: Dummy
 type (SingleLinkItem), pointer :: udtFirstLink => NULL ()
 integer (intG_IK), public  :: intItemCount = 0
   contains
 procedure, public,  pass(this) :: GoToStart
  end type SingleLinkedList

contains
  function GoToStart (this) result (intSuccess)
implicit none 
class (SingleLinkedList), intent (inout) :: this
integer (intG_IK) :: intSuccess = -1
  end function GoToStart

  subroutine Destroy (this)
implicit none
type(SingleLinkItem), intent(inout) :: this
integer(kind=4) :: intStat
DEALLOCATE (this%udtData, STAT=intStat)
this%intTag = 0
  end subroutine Destroy

end module SingleLinkedListClass

the ICE is gone, but I get the following error

   function GoToStart (this) result (intSuccess)
   1

Error: Function result 'intsuccess' at (1) cannot have an initializer

I don't understand.