[Bug fortran/80257] Cygwin test fail: pointer_check_1.f90 output test

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Is this PR still valid (over a year without feedback)?

[Bug fortran/44589] Missing not-set diagnositic (as READ arguments are clobbered)

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
(b) is pr30802.

[Bug c++/88819] New: ICE (segfault) when compiling C++ code with -std=c++2a

[su at cs dot ucdavis.edu]

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

Bug ID: 88819
   Summary: ICE (segfault) when compiling C++ code with -std=c++2a
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression.

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20190112 (experimental) [trunk revision 267885] (GCC) 
$ 
$ g++tk -std=c++2a tmp.cpp
g++tk: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ 


--


template < typename T, template < T > class TT, class R = TT < 0 > > struct A 
{
  template < R > struct B {};
};

template < int > struct C {};

A < int, C, C < 0 > > a;

[Bug fortran/34706] FE should reuse array temporaries, reduce temporaties and tell ME the array-size type

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #5 from Dominique d'Humieres  ---
No activity for over 11 years!-(

> Unassigning for the rest of the improvements in this bug.

What is "the rest of the improvements"?

If it is not an empty set, one should file new PRs for them and close this one
as FIXED.

[Bug fortran/38619] error message when converting between different derived types with same name

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|NEW |WAITING
   Severity|normal  |enhancement

--- Comment #2 from Dominique d'Humieres  ---
The test compiles if SEQUENCE is added after

   TYPE :: ta

I agree that the error "Can't convert TYPE(ta) to TYPE(ta)" is not very
helpful.

One possibility is to split

  gfc_error ("Can't convert %s to %s at %L",
 gfc_typename (&from_ts), gfc_typename (ts), &expr->where);

in intrinsic.c, one for the general case and one for derived types with the
addition of something such as "consider adding a SEQUENCE statement".

Is it worth the trouble (the PR is ten year old)?

[Bug fortran/31592] Better message if using non-intrinsic initialization expression

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres  ---
In the F2018 draft I see

10.1.11 Specification expression

...

5 A function is a specification function if it is a pure function,
 is not a standard intrinsic function, is not an internal function,
 is not a statement function, and does not have a dummy procedure argument.

It seems that the "is not defined with the RECURSIVE keyword." has been
dropped.

[Bug fortran/59345] _gfortran_internal_pack on compiler generated temps

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jan 13 11:06:03 2019
New Revision: 267903

URL: https://gcc.gnu.org/viewcvs?rev=267903&root=gcc&view=rev
Log:
2019-01-13  Thomas Koenig  

PR fortran/59345
* trans-array.c (gfc_conv_array_parameter): Remove TODO.  Do not
pack/unpack results of functions which return an explicit-shaped
or allocatable array.

2019-01-13  Thomas Koenig  

PR fortran/59345
* gfortran.dg/internal_pack_17.f90: New test.
* gfortran.dg/alloc_comp_auto_array_3.f90: Adjust number of calls
to builtin_free.


Added:
trunk/gcc/testsuite/gfortran.dg/internal_pack_17.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_3.f90

[Bug fortran/59345] _gfortran_internal_pack on compiler generated temps

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Fixed, closing.

[Bug fortran/35267] VOLATILE constrain: Misleading error message "Incompatible ranks"

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Dominique d'Humieres  ---
Considering 

(1) that the code is invalid, hence the compiler can do anything deemed
suitable.
(2) the PR is almost eleven year old without feedback

I am closing the PR as WONTFIX.

[Bug fortran/56789] Handling of contiguous dummy arguments

[tkoenig at gcc dot gnu.org]

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

--- Comment #19 from Thomas Koenig  ---
I have asked in
https://groups.google.com/forum/#!search/comp.lang.fortran$20contiguous$20dummy%7Csort:date/comp.lang.fortran/QiFkx8b48uw/wtQE9M_aFwAJ
.

Let's see what sort of answers there will be, apart from the almost
inevitable references to PL/I...

[Bug c++/88820] New: ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[hanicka at hanicka dot net]

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

Bug ID: 88820
   Summary: ICE in in C++2a mode for code which is able to be
compiled in C++17 mode
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hanicka at hanicka dot net
  Target Milestone: ---

Created attachment 45420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45420&action=edit
one file with all includes included

Hi, I found ICE in GCC9-HEAD with CTRE library (I'm author) when I compiled it
with C++2a mode. Same code with C++17 mode is compiled correctly, I wasn't able
to minimize code which reproduce the error.

But I was able to find responsible part of the library and reimplement it
differently (problematic part is enabled with
-DCTRE_ENABLE_TRAMPOLINING_ON_GCC9)

I think that problem is related to class-nontype-template-arguments change in
C++2a, check line 314.

I'm using GCC9 current head (January 13th 2019). 

https://gcc.godbolt.org/z/_G0854
(GCC8.2 is compiling correctly the same code.)


g++-HEAD test-me.cpp -std=c++17 -DCTRE_ENABLE_TRAMPOLINING_ON_GCC9 -g0
 => correct

g++-HEAD test-me.cpp -std=c++2a -DCTRE_ENABLE_TRAMPOLINING_ON_GCC9 -g0
 => fail

: In substitution of 'template template static
constexpr auto ctll::parser::trampoline_decide(Subject) [with Subject = ;
Grammar = ctll::empty_subject; basic_fixed_string input = ;
ActionSelector = ; bool IgnoreUnknownActions = ]':
:464:74:   required from here
:458:68: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'error_mark' in decl_anon_ns_mem_p, at
cp/tree.c:3478
  458 |  template  static constexpr auto
trampoline_decide(Subject subject = {}) noexcept {
  |   
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Compiler returned: 1


test.me.cpp is attached

[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
Let's see if I can do anything about this...

[Bug c++/86356] "invalid use of pack expansion" with fold expressions

[ensadc at mailnesia dot com]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:

template struct mp_bool { static constexpr bool value = B; };

template using mp_any =
  mp_bool<(static_cast(T::value) || ...)>;

template
struct A { static constexpr bool value = true; };

template struct variant_base_impl {};
template using variant_base
  = variant_base_impl, A...>::value>;

int main()
{
variant_base();
}

[Bug fortran/67277] segfault when passing a missing optional argument to an elemental intrinsic

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
I thought something like this

Index: trans-intrinsic.c
===
--- trans-intrinsic.c   (Revision 267903)
+++ trans-intrinsic.c   (Arbeitskopie)
@@ -6355,6 +6355,9 @@ gfc_conv_intrinsic_ishftc (gfc_se * se, gfc_expr *
   tree rrot;
   tree zero;
   unsigned int num_args;
+  bool optional_size = false;
+  gfc_expr *size = NULL;
+  tree library, inlined, present;

   num_args = gfc_intrinsic_argument_list_length (expr);
   args = XALLOCAVEC (tree, num_args);
@@ -6363,6 +6366,11 @@ gfc_conv_intrinsic_ishftc (gfc_se * se, gfc_expr *

   if (num_args == 3)
 {
+  size = expr->value.function.actual->next->next->expr;
+  optional_size = size->expr_type == EXPR_VARIABLE
+   && size->symtree->n.sym->attr.dummy
+   && size->symtree->n.sym->attr.optional;
+
   /* Use a library function for the 3 parameter version.  */
   tree int4type = gfc_get_int_type (4);

@@ -6396,14 +6404,19 @@ gfc_conv_intrinsic_ishftc (gfc_se * se, gfc_expr *
default:
  gcc_unreachable ();
}
-  se->expr = build_call_expr_loc (input_location,
+  library = build_call_expr_loc (input_location,
  tmp, 3, args[0], args[1], args[2]);
   /* Convert the result back to the original type, if we extended
 the first argument's width above.  */
   if (expr->ts.kind < 4)
-   se->expr = convert (type, se->expr);
+   library = convert (type, se->expr);

-  return;
+  if (!optional_size)
+   {
+ se->expr = library;
+ return;
+   }
+  //  debug_tree (library);
 }
   type = TREE_TYPE (args[0]);

@@ -6427,8 +6440,20 @@ gfc_conv_intrinsic_ishftc (gfc_se * se, gfc_expr *
   /* Do nothing if shift == 0.  */
   tmp = fold_build2_loc (input_location, EQ_EXPR, logical_type_node, args[1],
 zero);
-  se->expr = fold_build3_loc (input_location, COND_EXPR, type, tmp, args[0],
- rrot);
+
+  inlined = fold_build3_loc (input_location, COND_EXPR, type, tmp, args[0],
+rrot);
+
+  //  debug_tree(inlined);
+  if (!optional_size)
+{
+  se->expr = inlined;
+  return;
+}
+
+  present = gfc_conv_expr_present (size->symtree->n.sym);
+  se->expr = fold_build3_loc (input_location, COND_EXPR, type, present,
+ library, inlined);
 }

would do the trick. However, this results in

{
  integer(kind=4) r;
  integer(kind=4) s[4];

  {
static integer(kind=4) A.0[4] = {1, 2, 3, 4};
integer(kind=4) D.3868;

D.3868 = *j;
{
  integer(kind=8) S.1;

  S.1 = 0;
  while (1)
{
  if (S.1 > 3) goto L.1;
  {
integer(kind=4) D.3870;
integer(kind=4) D.3871;

D.3870 = j != 0B ? D.3868 : 0;
D.3871 = A.0[S.1];
s[S.1] = j != 0B ? _gfortran_ishftc4 (A.0[S.1], 1, D.3870) : D.3871
r>> 31;
  }
  S.1 = S.1 + 1;
}
  L.1:;
}
  }

so *j is dereferenced outside the check for presence.

Unassigning for now.

[Bug fortran/88803] gfortran documentation warning: '.' or ',' must follow @xref

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #1)
> More annoying than the warnings id the text displayed in the manual:
> 
> the See CONVERT specifier on the open statement or the See
> GFORTRAN_CONVERT_UNIT environment variable.
> 
> The text has been introduced at revision r251074.
> 
> Would
> 
> --- ../_clean/gcc/fortran/gfortran.texi   2019-01-01 13:17:33.0 
> +0100
> +++ gcc/fortran/gfortran.texi 2019-01-11 23:23:55.0 +0100
> @@ -1469,8 +1469,8 @@ are four-byte integers by default, and e
>  compability only) is in effect.
>  
>  The representation of the record markers is that of unformatted files
> -given with the @option{-fconvert} option, the @xref{CONVERT specifier}
> -on the open statement or the @xref{GFORTRAN_CONVERT_UNIT} environment
> +given with the @option{-fconvert} option, the @ref{CONVERT specifier}
> +in an open statement or the @ref{GFORTRAN_CONVERT_UNIT} environment
>  variable.
>  
>  The maximum number of bytes of user data in a subrecord is 2147483639
> 
> be OK? or does it exist a better replacement for @xref?

Looks OK to me, pre-approved.

[Bug fortran/57992] Pointless packing of contiguous arrays for simply contiguous functions results as actual arguments

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #5 from Thomas Koenig  ---
After the fix for 56789, only one case left, the call to f2
(contiguous pointer).

Should be straightforward...

[Bug c++/88664] [9 Regression] False positive -Waddress-of-packed-member

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
There's STRIP_NOPS, isn't there?

[Bug fortran/56789] Handling of contiguous dummy arguments

[paul.richard.thomas at gmail dot com]

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

--- Comment #20 from paul.richard.thomas at gmail dot com  ---
Hi Thomas,

I was mulling this over a few months ago and came to the conclusion
that copy-in/copy-out was the only thing that made sense.

The IBM manual is explicit about this:
https://www.ibm.com/support/knowledgecenter/SSGH4D_15.1.3/com.ibm.xlf1513.aix.doc/language_ref/contiguous.html

Regards

Paul

On Sun, 13 Jan 2019 at 12:36, tkoenig at gcc dot gnu.org
 wrote:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56789
>
> --- Comment #19 from Thomas Koenig  ---
> I have asked in
> https://groups.google.com/forum/#!search/comp.lang.fortran$20contiguous$20dummy%7Csort:date/comp.lang.fortran/QiFkx8b48uw/wtQE9M_aFwAJ
> .
>
> Let's see what sort of answers there will be, apart from the almost
> inevitable references to PL/I...
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.

[Bug fortran/56789] Handling of contiguous dummy arguments

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #21 from Thomas Koenig  ---
Hi Paul,

> I was mulling this over a few months ago and came to the conclusion
> that copy-in/copy-out was the only thing that made sense.

Well, in that case, I'll take this (if you don't mind).

I am currently working in that area anyway, so I might as
well look at this.

Regards

Thomas

[Bug fortran/88821] New: Inline packing of non-contiguous arguments

[tkoenig at gcc dot gnu.org]

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

Bug ID: 88821
   Summary: Inline packing of non-contiguous arguments
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Because the packing / unpacking routines are opaque, they
could result in lots of missed opportunities for inlining.

See https://gcc.gnu.org/bugzilla/attachment.cgi?id=45014 for
PR 57992.

It should be doable to inline this.

[Bug fortran/57992] Pointless packing of contiguous arrays for simply contiguous functions results as actual arguments

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
(In reply to Chris Elrod from comment #3)
> Created attachment 45014 [details]
> Code that produces lots of unnecessary and performance-crippling
> _gfortran_internal_pack@PLT and _gfortran_internal_unpack@PLT

The packing is not unnecessary, but it is performed in a way
that I am now convinced is sub-optimal.

I have created PR 88821 for this.

[Bug fortran/59345] _gfortran_internal_pack on compiler generated temps

[tkoenig at gcc dot gnu.org]

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

--- Comment #9 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jan 13 14:57:39 2019
New Revision: 267905

URL: https://gcc.gnu.org/viewcvs?rev=267905&root=gcc&view=rev
Log:
2019-01-13  Thomas Koenig  

PR fortran/57992
* trans-array.c (gfc_conv_array_parameter):  Do not pack/unpack
functions with contiguous results.

2019-01-13  Thomas Koenig  

PR fortran/59345
* gfortran.dg/internal_pack_18.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/internal_pack_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/57992] Pointless packing of contiguous arrays for simply contiguous functions results as actual arguments

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Jan 13 14:57:39 2019
New Revision: 267905

URL: https://gcc.gnu.org/viewcvs?rev=267905&root=gcc&view=rev
Log:
2019-01-13  Thomas Koenig  

PR fortran/57992
* trans-array.c (gfc_conv_array_parameter):  Do not pack/unpack
functions with contiguous results.

2019-01-13  Thomas Koenig  

PR fortran/59345
* gfortran.dg/internal_pack_18.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/internal_pack_18.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/88664] [9 Regression] False positive -Waddress-of-packed-member

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Nathan Sidwell from comment #6)
> There's STRIP_NOPS, isn't there?

The updated patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00732.html

[Bug fortran/57992] Pointless packing of contiguous arrays for simply contiguous functions results as actual arguments

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
The original part of this bug is fixed.

Closing.

[Bug fortran/36854] [meta-bug] fortran front-end optimization

[tkoenig at gcc dot gnu.org]

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

Bug 57992 Summary: Pointless packing of contiguous arrays for simply contiguous 
functions results as actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57992

   What|Removed |Added

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

[Bug c/88822] New: Strange inconsistency between types of qualified rvalues.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88822
   Summary: Strange inconsistency between types of qualified
rvalues.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  int main()
  {
int * const p1 = 0;
int *   _Atomic p2 = 0;
int * const _Atomic p3 = 0;

struct S { int x; } s;

s = &*p1; // Type of  &*p1  is  int * const  according to error message.
s = &*p2; // Type of  &*p2  is  int *according to error message.
s = &*p3; // Type of  &*p3  is  int *according to error message.
  }

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observations:

  The following error messages are outputed:

incompatible types when assigning to type 'struct S' from type 'int *
const'
incompatible types when assigning to type 'struct S' from type 'int *'
incompatible types when assigning to type 'struct S' from type 'int *'

  From the error messages it looks like GCC thinks that the type of  &*p1  is
  int * const  and that the types of  &*p2  and  &*p3  are both  int * .

  So it seems like if the  _Atomic  qualifier is used, all qualifiers are
  removed, else they are keept.

  6.5.3.2/3 describing the special case of  &*  does not say anything about
  droping any qualifiers. However since the result of  &*  is an rvalue the
  intention of the standard was probably to remove all qualifiers always.

[Bug tree-optimization/88823] New: ivopts introduces -1(OVF)

[glisse at gcc dot gnu.org]

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

Bug ID: 88823
   Summary: ivopts introduces -1(OVF)
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

int g (int a, int *v)
{
v[0] = a;
v[1] = 0;
while (v[0]-- > 0)
   v[1] += v[0];
return v[1];
}

With -O2, ivopts replaces "if (_18 > 0)" with "if (_4 != -1(OVF))". IIUC, it
should at least use drop_tree_overflow to get a clean constant -1, although I
don't know why the overflow appeared in the first place. Maybe the overflow
flag is harmless and you can just close as not-a-bug.

[Bug fortran/87689] Memory corruption on Power 8

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Depends on||40976

--- Comment #8 from Thomas Koenig  ---
This is probably caused by PR40976.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40976
[Bug 40976] Merge DECL of procedure call with DECL of gfc_get_function_type

[Bug fortran/52351] Wrong bounds when passing an array section to an intent-in pointer dummy

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=56789

--- Comment #4 from Thomas Koenig  ---
See also PR 56789, where we also need to add a new descriptor.

[Bug fortran/56789] Handling of contiguous dummy arguments

[pault at gcc dot gnu.org]

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

--- Comment #22 from Paul Thomas  ---
(In reply to Thomas Koenig from comment #21)
> Hi Paul,
> 
> > I was mulling this over a few months ago and came to the conclusion
> > that copy-in/copy-out was the only thing that made sense.
> 
> Well, in that case, I'll take this (if you don't mind).
> 
> I am currently working in that area anyway, so I might as
> well look at this.
> 
> Regards
> 
> Thomas

Be my guest!

Paul

[Bug c++/88824] New: ICE on invalid

[su at cs dot ucdavis.edu]

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

Bug ID: 88824
   Summary: ICE on invalid
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

[Bug c++/88825] New: ICE on (invalid) C++11 code: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in can_do_nrvo_p, at cp/typeck.c:9361

[su at cs dot ucdavis.edu]

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

Bug ID: 88825
   Summary: ICE on (invalid) C++11 code: tree check: expected
class ‘type’, have ‘exceptional’ (error_mark) in
can_do_nrvo_p, at cp/typeck.c:9361
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This seems to be a recent regression.

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20190112 (experimental) [trunk revision 267885] (GCC) 
$ 
$ g++tk -c tmp.cpp
tmp.cpp: In function ‘auto* f()’:
tmp.cpp:4:10: error: unable to deduce ‘auto*’ from ‘t’
4 |   return t;
  |  ^
tmp.cpp:4:10: note:   mismatched types ‘auto*’ and ‘int’
tmp.cpp:4:10: internal compiler error: tree check: expected class ‘type’, have
‘exceptional’ (error_mark) in can_do_nrvo_p, at cp/typeck.c:9361
0x608e99 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc-source-trunk/gcc/tree.c:9864
0x8fee4b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc-source-trunk/gcc/tree.h:3299
0x8fee4b can_do_nrvo_p
../../gcc-source-trunk/gcc/cp/typeck.c:9360
0x9126ae check_return_expr(tree_node*, bool*)
../../gcc-source-trunk/gcc/cp/typeck.c:9671
0x8b065e finish_return_stmt(tree_node*)
../../gcc-source-trunk/gcc/cp/semantics.c:895
0x805227 cp_parser_jump_statement
../../gcc-source-trunk/gcc/cp/parser.c:12848
0x805227 cp_parser_statement
../../gcc-source-trunk/gcc/cp/parser.c:11120
0x805d4f cp_parser_statement_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:11586
0x805e5f cp_parser_compound_statement
../../gcc-source-trunk/gcc/cp/parser.c:11540
0x806560 cp_parser_function_body
../../gcc-source-trunk/gcc/cp/parser.c:22523
0x806560 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-source-trunk/gcc/cp/parser.c:22558
0x806912 cp_parser_function_definition_after_declarator
../../gcc-source-trunk/gcc/cp/parser.c:27621
0x81ef1a cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-source-trunk/gcc/cp/parser.c:27538
0x81ef1a cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:20196
0x81f3c5 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13480
0x829104 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13167
0x827e0e cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4692
0x827e0e c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:40993
0x981bca c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1151
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 





auto f () -> auto *
{
  int t = 0;
  return t;
}

[Bug c++/88820] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[hanicka at hanicka dot net]

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

--- Comment #1 from Hana Dusíková  ---
I think I found a related problem. It's about deducting argument of a class
when instantiating subtype. I created a minimal case. I'm attaching.

[Bug c++/88092] class nontype template deduction failed when providing type to class

[hanicka at hanicka dot net]

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

--- Comment #6 from Hana Dusíková  ---
Created attachment 45421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45421&action=edit
argument deduction of parent type

[Bug c++/88092] class nontype template deduction failed when providing type to class

[hanicka at hanicka dot net]

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

--- Comment #7 from Hana Dusíková  ---
If you compile it with:

g++-HEAD minimal.cpp -std=c++2a -DREFERENCE
 => correct

g++-HEAD minimal.cpp -std=c++2a -DAUTO
 => correct

g++-HEAD minimal.cpp -std=c++2a -DCNTTP
minimal.cpp: In member function 'unsigned int Foo::count()':
minimal.cpp:32:19: error: class template argument deduction failed:
   32 |   return SubType<0>().value();
  |   ^
minimal.cpp:32:19: error: no matching function for call to 'ArgType(ArgType)'
minimal.cpp:11:21: note: candidate: 'template
ArgType(const char (&)[N])-> ArgType'
   11 | template  ArgType(const char (&)[N]) -> ArgType;
  | ^~~
minimal.cpp:11:21: note:   template argument deduction/substitution failed:
minimal.cpp:32:19: note:   mismatched types 'const char [N]' and 'ArgType'
   32 |   return SubType<0>().value();
  |   ^
minimal.cpp:8:12: note: candidate: 'template
ArgType(...)-> ArgType'
8 |  constexpr ArgType(...) noexcept { }
  |^~~
minimal.cpp:8:12: note:   template argument deduction/substitution failed:
minimal.cpp:32:19: note:   couldn't deduce template parameter 'N'
   32 |   return SubType<0>().value();
  |   ^
minimal.cpp:4:28: note: candidate: 'template
ArgType(ArgType)-> ArgType'
4 | template  struct ArgType {
  |^~~
minimal.cpp:4:28: note:   template argument deduction/substitution failed:
minimal.cpp:32:19: note:   mismatched types 'ArgType' and 'ArgType'
   32 |   return SubType<0>().value();
  |   ^

[Bug fortran/82215] Feature request to better support two pass compiling with gfortran

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #8 from Thomas Koenig  ---
Looking into this.

[Bug c++/88826] New: ICE (segfault) when compiling invalid C++ code with -std=c++2a

[su at cs dot ucdavis.edu]

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

Bug ID: 88826
   Summary: ICE (segfault) when compiling invalid C++ code with
-std=c++2a
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

This appears to be a recent regression.

$ g++tk -v
Using built-in specs.
COLLECT_GCC=g++tk
COLLECT_LTO_WRAPPER=/home/su/software/tmp/gcc/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/9.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/home/su/software/tmp/gcc/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 9.0.0 20190112 (experimental) [trunk revision 267885] (GCC) 
$ 
$ g++tk -std=c++2a -c tmp.cpp
tmp.cpp:1:40: error: types may not be defined in parameter types
1 | template < class A, class B : public A {}; > void f ();
  |^
tmp.cpp:1:41: error: ‘B’ is not a valid type for a template non-type parameter
because it is not literal
1 | template < class A, class B : public A {}; > void f ();
  | ^
tmp.cpp:1:27: note: ‘B’ is not literal because:
1 | template < class A, class B : public A {}; > void f ();
  |   ^
tmp.cpp:1:41: internal compiler error: Segmentation fault
1 | template < class A, class B : public A {}; > void f ();
  | ^
0xec3aff crash_signal
../../gcc-source-trunk/gcc/toplev.c:326
0x6db371 explain_non_literal_class(tree_node*)
../../gcc-source-trunk/gcc/cp/class.c:5516
0x82bce7 invalid_nontype_parm_type_p
../../gcc-source-trunk/gcc/cp/pt.c:24929
0x849768 process_template_parm(tree_node*, unsigned int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:4316
0x81d79e cp_parser_template_parameter_list
../../gcc-source-trunk/gcc/cp/parser.c:15565
0x82145b cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:27910
0x82145b cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:27944
0x829129 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:13116
0x827e0e cp_parser_translation_unit
../../gcc-source-trunk/gcc/cp/parser.c:4692
0x827e0e c_parse_file()
../../gcc-source-trunk/gcc/cp/parser.c:40993
0x981bca c_common_parse_file()
../../gcc-source-trunk/gcc/c-family/c-opts.c:1151
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


template < class A, class B : public A {}; > void f ();

[Bug c++/88824] erroneous report

[su at cs dot ucdavis.edu]

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

Zhendong Su  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
Summary|ICE on invalid  |erroneous report

--- Comment #1 from Zhendong Su  ---
incomplete report for PR 88825 erroneously reported --- apologies

[Bug c++/88820] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[hanicka at hanicka dot net]

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

--- Comment #2 from Hana Dusíková  ---
Created attachment 45422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45422&action=edit
referencing subtype unable to deduce parent type

 ~/projekty/ice-gcc > g++-HEAD minimal.cpp -std=c++2a -DREFERENCE
 ~/projekty/ice-gcc > g++-HEAD minimal.cpp -std=c++2a -DAUTO 
 ~/projekty/ice-gcc > g++-HEAD minimal.cpp -std=c++2a -DCNTTP
minimal.cpp: In member function 'unsigned int Foo::count()':
minimal.cpp:33:19: error: class template argument deduction failed:
   33 |   return SubType<0>().value();
  |   ^
minimal.cpp:33:19: error: no matching function for call to 'ArgType(ArgType)'
minimal.cpp:8:21: note: candidate: 'template ArgType(const
char (&)[N])-> ArgType'
8 | template  ArgType(const char (&)[N]) -> ArgType;
  | ^~~
minimal.cpp:8:21: note:   template argument deduction/substitution failed:
minimal.cpp:33:19: note:   mismatched types 'const char [N]' and 'ArgType'
   33 |   return SubType<0>().value();
  |   ^
minimal.cpp:5:12: note: candidate: 'template
ArgType(...)-> ArgType'
5 |  constexpr ArgType(...) noexcept { }
  |^~~
minimal.cpp:5:12: note:   template argument deduction/substitution failed:
minimal.cpp:33:19: note:   couldn't deduce template parameter 'N'
   33 |   return SubType<0>().value();
  |   ^
minimal.cpp:4:28: note: candidate: 'template
ArgType(ArgType)-> ArgType'
4 | template  struct ArgType {
  |^~~
minimal.cpp:4:28: note:   template argument deduction/substitution failed:
minimal.cpp:33:19: note:   mismatched types 'ArgType' and 'ArgType'
   33 |   return SubType<0>().value();
  |   ^

[Bug c++/88092] class nontype template deduction failed when providing type to class

[hanicka at hanicka dot net]

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

--- Comment #8 from Hana Dusíková  ---
Please ignore two last comments, I sent them to wrong bug, it was supposed to
be for #88820.

[Bug c/88647] Rejects valid program dereferencing pointer with incomplete reference type.

[anders.granlund.0 at gmail dot com]

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

Anders Granlund  changed:

   What|Removed |Added

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

--- Comment #5 from Anders Granlund  ---
Invalid, but will open another bug case with a different test case.

[Bug c++/88820] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-13
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #3 from Marek Polacek  ---
The first ICE started with r265734.  Will try to reduce...

[Bug c++/88800] Spurious -Werror=array-bounds for non-taken branch

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug fortran/56386] [F03] ICE with ASSOCIATE construct and an derived type array component

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #13 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org]

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

Bug 56386 Summary: [F03] ICE with ASSOCIATE construct and an derived type array 
component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56386

   What|Removed |Added

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

[Bug c/88827] New: Rejects valid program using &* operator combination.

[anders.granlund.0 at gmail dot com]

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

Bug ID: 88827
   Summary: Rejects valid program using &* operator combination.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

Test case (prog.c):

  int main()
  {
struct S *p = 0;
&*p;
  } 

Compilation command line:

  gcc prog.c -Wall -Wextra -std=c11 -pedantic-errors

Observed behaviour:

  The following error message was outputed:

error: dereferencing pointer to incomplete type 'struct S'

Expected behaviour:

  No error messages outputed. The program is valid. Note that using the value
  0 for pointer  p  is not a problem since neither & nor * is evaluated due to
  the special rule for &* in 6.5.3.2/3.

Note:

  Clang accepts the program without outputing any error messages.

[Bug fortran/58618] Wrong code with character substring and ASSOCIATE

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #14 from Paul Thomas  ---
Fixed on trunk.

Thanks for the report.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org]

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

Bug 58618 Summary: Wrong code with character substring and ASSOCIATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58618

   What|Removed |Added

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

[Bug c/88729] ICE in libiberty during bootstrap with debug info

[koenigni at gcc dot gnu.org]

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

Nicolas Koenig  changed:

   What|Removed |Added

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

--- Comment #3 from Nicolas Koenig  ---
It still doesn't work, but the error is a new one

[Bug target/88828] New: Inefficient update of the first element of vector registers

[hjl.tools at gmail dot com]

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

Bug ID: 88828
   Summary: Inefficient update of the first element of vector
registers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---

[hjl@gnu-cfl-1 pr88778]$ cat u4.i
typedef float __v4sf __attribute__ ((__vector_size__ (16)));
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));

__m128
foo (__m128 x, float f)
{
  __m128 y =  __extension__ (__m128)(__v4sf)
  { f, ((__v4sf) x)[1], ((__v4sf) x)[2], ((__v4sf) x)[3] };
  return y;
}
[hjl@gnu-cfl-1 pr88778]$ gcc -S -O2 u4.i
[hjl@gnu-cfl-1 pr88778]$ cat u4.s
.file   "u4.i"
.text
.p2align 4,,15
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
movaps  %xmm0, %xmm4
movaps  %xmm0, %xmm3
shufps  $85, %xmm0, %xmm4
unpckhps%xmm0, %xmm3
unpcklps%xmm4, %xmm1
shufps  $255, %xmm0, %xmm0
unpcklps%xmm0, %xmm3
movaps  %xmm1, %xmm0
movlhps %xmm3, %xmm0
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 8.2.1 20190109 (Red Hat 8.2.1-7)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 pr88778]$ 

A simple movss will do.

[Bug fortran/88803] gfortran documentation warning: '.' or ',' must follow @xref

[dominiq at gcc dot gnu.org]

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

--- Comment #3 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Jan 13 19:18:46 2019
New Revision: 267906

URL: https://gcc.gnu.org/viewcvs?rev=267906&root=gcc&view=rev
Log:
2019-01-13  Dominique d'Humieres  

PR fortran/88803
* gfortran.texi: Replace @xref with @ref and adjust the sentence.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/gfortran.texi

[Bug c++/88820] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[hanicka at hanicka dot net]

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

--- Comment #4 from Hana Dusíková  ---
The ICE will not happen if you comment out line 464 from first example.

[Bug fortran/88803] gfortran documentation warning: '.' or ',' must follow @xref

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #4 from Dominique d'Humieres  ---
FIXED.

[Bug c++/88829] New: Failure to deduce size of array of 2^31 chars

[Casey at Carter dot net]

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

Bug ID: 88829
   Summary: Failure to deduce size of array of 2^31 chars
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Casey at Carter dot net
  Target Milestone: ---

This sample TU:

using size_t = decltype(sizeof(int));

template T&& declval();

template
void f(T(&&)[N]) {}

using U = decltype(f(declval())); // error: size of
array is negative

fails to compile on trunk with "g++ -std=c++2a repro.cpp", diagnosing:

:8:51: error: no matching function for call to 'f(char
[2147483648])'
8 | using U = decltype(f(declval())); // error:
size of array is negative
  |   ^
:6:6: note: candidate: 'template void
f(T (&&)[N])'
6 | void f(T(&&)[N]) {}
  |  ^
:6:6: note:   template argument deduction/substitution failed:
: In substitution of 'template void
f(T (&&)[N]) [with T = char; long unsigned int N = 18446744071562067968]':
:8:51:   required from here
:6:6: error: size of array is negative
:6:8: error: size of array is negative
6 | void f(T(&&)[N]) {}
  |^~~~
:8:49: error: invalid initialization of reference of type 'char
(&&)[1]' from expression of type 'char [2147483648]'
8 | using U = decltype(f(declval())); // error:
size of array is negative
  |  ~~~^~
:6:8: note: in passing argument 1 of 'void f(T (&&)[N]) [with T =
char; long unsigned int N = 18446744071562067968]'
6 | void f(T(&&)[N]) {}
  |^~~~

If arrays of size >= 2^31 aren't supported - which is a perfectly legitimate
implementation limit - I expect the formation of the array type to be diagnosed
rather than the deduction to fail. Also, the "size of array is negative"
diagnostic is confusing (#87996 already makes that point).

[Bug c/80354] Poor support to silence -Wformat-truncation=1

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
(In reply to Alejandro Colomar from comment #10)
> Many other warnings are supressed with (void), why is this one so special?

Not too many warnings can be suppressed by casts.  Those that can must be at
least partially implemented in the front end where otherwise pointless casts
are still visible.  -Wformat-truncation (and other warnings like it) is
implemented in the middle-end to benefit from optimizations such as constant
propagation or value range optimization.  Semantically pointless casts have
long been removed from expressions by the time the warning sees the program.

It might be possible to use a cast as a suppression mechanism for this warning,
but I'm not convinced it would be helpful.  Casting value-returning function
calls to void is a fairly common style used to denote that the return value is
unused.  In the case of snprintf, that doesn't necessarily imply that the
program is prepared to deal correctly with the truncated output.  In my
experience very few programs are.  Most assume it simply doesn't happen.  I
don't recall coming across an example involving a non-trivial format string
with arguments, especially of numeric types, where truncation would not have
caused some sort of an unexpected condition later on in the program.

[Bug c++/88830] New: ice in maybe_emit_vtables

[dcb314 at hotmail dot com]

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

Bug ID: 88830
   Summary: ice in maybe_emit_vtables
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this C++ code, compiled with recent gcc:

struct a {
  ~a();
};
class b {
  virtual void c(int &);
};
class C : b {
  void c(int &);
  virtual int d() = 0;
  a e;
};
void C::c(int &) {}

does this:

$ ~/gcc/results/bin/gcc -c -w bug495.cc
: internal compiler error: Segmentation fault
0x10c3017 crash_signal
../../trunk/gcc/toplev.c:326
0x9765b4 maybe_emit_vtables
../../trunk/gcc/cp/decl2.c:2232
0x9765b4 c_parse_final_cleanups()
../../trunk/gcc/cp/decl2.c:4797
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 

The bug seems to occur between revisions 267850 and 267900.

[Bug c++/88825] ICE on (invalid) C++11 code: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in can_do_nrvo_p, at cp/typeck.c:9361

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-01-13
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
ICE in can_do_nrvo_p -> mine.

[Bug c++/88820] ICE in in C++2a mode for code which is able to be compiled in C++17 mode

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
This reduced test ICEs left and right with -std=c++17/14 since r236221, but the
ICE changed into another ICE with r248433.


template <__SIZE_TYPE__> class basic_fixed_string;
struct empty_subject;
template  struct parser {
  template  static auto trampoline_decide();
  bool correct = trampoline_decide();
};

[Bug c++/88830] [9 Regression] ice in maybe_emit_vtables

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-13
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|ice in maybe_emit_vtables   |[9 Regression] ice in
   ||maybe_emit_vtables
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/88830] [9 Regression] ice in maybe_emit_vtables

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r267855.

[Bug c++/88830] [9 Regression] ice in maybe_emit_vtables

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/88819] ICE (segfault) when compiling C++ code with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-01-13
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.  This started crashing with r265789 and the infinite looping started
with r267108.

[Bug c++/88825] [7/8/9 Regression] ICE on (invalid) C++11 code: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in can_do_nrvo_p, at cp/typeck.c:9361

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.5
Summary|ICE on (invalid) C++11  |[7/8/9 Regression] ICE on
   |code: tree check: expected  |(invalid) C++11 code: tree
   |class ‘type’, have  |check: expected class
   |‘exceptional’ (error_mark)  |‘type’, have ‘exceptional’
   |in can_do_nrvo_p, at|(error_mark) in
   |cp/typeck.c:9361|can_do_nrvo_p, at
   ||cp/typeck.c:9361

--- Comment #2 from Marek Polacek  ---
I think it is a regression because in the past we'd just give an error. 
Started with r197248.

[Bug libfortran/88776] Namelist read from stdin: loss of data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Jan 14 00:22:00 2019
New Revision: 267910

URL: https://gcc.gnu.org/viewcvs?rev=267910&root=gcc&view=rev
Log:
2019-01-13  Jerry DeLisle  

PR libfortran/88776
* io/open.c (newunit): Free format buffer if the unit specified is for
stdin, stdout, or stderr.

* gfortran.dg/namelist_96.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_96.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/open.c

[Bug libstdc++/86655] std::assoc_legendre should not constrain the value of m

[emsr at gcc dot gnu.org]

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

--- Comment #5 from emsr at gcc dot gnu.org ---
Created attachment 45423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45423&action=edit
Final patch that passes.

2018-01-14  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/86655 - std::assoc_legendre should not constrain
the value of m.
* include/tr1/legendre_function.tcc (__assoc_legendre_p,
__sph_legendre): If degree > order Don't throw, return 0.
* testsuite/special_functions/02_assoc_legendre/pr86655.cc: New test.
* testsuite/special_functions/20_sph_legendre/pr86655.cc: New test.
* testsuite/tr1/5_numerical_facilities/special_functions/
02_assoc_legendre/pr86655.cc: New test.
* testsuite/tr1/5_numerical_facilities/special_functions/
22_sph_legendre/pr86655.cc: New test.

[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Yes, I would guess that clang's "dumb" warning is fine for 99% of cases, and
the handful of exceptions could use #pragma to disable the warning.

But until/unless G++ gets such a warning, decorating the library in a few
specific places will be an improvement.

[Bug libfortran/88776] Namelist read from stdin: loss of data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Jan 14 01:12:27 2019
New Revision: 267911

URL: https://gcc.gnu.org/viewcvs?rev=267911&root=gcc&view=rev
Log:
2019-01-13  Jerry DeLisle  

PR libfortran/88776
* io/list_read.c (namelist_read): Use nml_err_ret path on read error
not based on stdin_unit.
* io/open.c (newunit): Free format buffer if the unit specified is for
stdin, stdout, or stderr.

* gfortran.dg/namelist_96.f90: New test.

Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/libgfortran/ChangeLog
branches/gcc-7-branch/libgfortran/io/list_read.c
branches/gcc-7-branch/libgfortran/io/open.c

[Bug libfortran/88776] Namelist read from stdin: loss of data

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle  ---
Author: jvdelisle
Date: Mon Jan 14 02:03:34 2019
New Revision: 267912

URL: https://gcc.gnu.org/viewcvs?rev=267912&root=gcc&view=rev
Log:
2019-01-13  Jerry DeLisle  

Backport from trunk
PR libfortran/88776
* io/list_read.c (namelist_read): Use nml_err_ret path on read error
not based on stdin_unit.
* io/open.c (newunit): Free format buffer if the unit specified is for
stdin, stdout, or stderr.

* gfortran.dg/namelist_96.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/namelist_96.f90
Modified:
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/libgfortran/ChangeLog
branches/gcc-8-branch/libgfortran/io/list_read.c
branches/gcc-8-branch/libgfortran/io/open.c

[Bug libfortran/88776] Namelist read from stdin: loss of data

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #10 from Jerry DeLisle  ---
Fixed 7,8, and 9

[Bug pch/56549] #pragma once ineffective with BOM in include file

[leolchat at gmail dot com]

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

leonard gerard  changed:

   What|Removed |Added

 CC||leolchat at gmail dot com

--- Comment #4 from leonard gerard  ---
Confirmed with g++ (Ubuntu 7.3.0-27ubuntu1~18.04)

[Bug rtl-optimization/87329] ICE in patch_jump_insn, at cfgrtl.c:1271

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
I can reproduce it on the 8 branch but not on the current trunk w/ the rs6000
backend.

[Bug testsuite/85368] [8 regression] phi-opt-11 test fails on IBM Z

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #17 from Arseny Solokha  ---
Jakub, --param logical-op-non-short-circuit seems to still lack user's
documentation. Is it intentional?

[Bug tree-optimization/88828] Inefficient update of the first element of vector registers

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64
  Component|target  |tree-optimization

--- Comment #1 from Andrew Pinski  ---
I think there are two issues here (maybe only one since I have not tested one
of them).

The first is not recognizing:
typedef float __v4sf __attribute__ ((__vector_size__ (16)));

__v4sf 
foo (__v4sf x, float f)
{
  __v4sf y =  __extension__ (__v4sf)
  { f, x[1], x[2], x[3] };
  return y;
}

is the same as:
__v4sf 
foo1 (__v4sf x, float f)
{
  __v4sf y =  x;
  y[0] = f;
  return y;
}

This is a generic tree optimization issue.
The second is if foo1 is not optimized to what you want it to be.  That would
be a target issue.

[Bug libstdc++/88738] treat shared_ptr and unique_ptr more like plain old pointers

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #7)
> Yes, I would guess that clang's "dumb" warning is fine for 99% of cases, and
> the handful of exceptions could use #pragma to disable the warning.

Or an attribute that says the opposite of nodiscard? (maydiscard? unused?)

[Bug c++/88832] New: the layout of .data section of a binary is slightly changed when -g option is enabled.

[wangchang15 at huawei dot com]

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

Bug ID: 88832
   Summary: the layout of .data section of a binary is slightly
changed when -g option is enabled.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangchang15 at huawei dot com
  Target Milestone: ---

Dear all,

I use a little-endian cross compiler ( gcc7.3-based
build=host=x86_64-suse-linux target=aarch64-linux-gnu) to compile a C
application temp.c which is randomly generated by a CSmith tool.  




To check whether the binaries are the same when compiling temp.c with and
without -g option, the following command is used.

/some/path/to/my/cross/compiler/aarch64-linux-gnu-gcc temp.c  -static -O2  -I
./csmith/runtime  -fcompare-debug=-g -lm -w  -o ./temp_O2.exe

The result is an error message " error: temp.c: -fcompare-debug failure
(length)".

I checked the .data section in both binaries (with/without -g option), the
reason is that the position of an array variable (g_32) is changed. Because the
alignment requirement, different number of 0s are supplemented to this array
variable and another array variable g_1161 which leads to the length of .data
section in both binaries are different.
The disassembly fragment of .data section of both binaries are listed below. 
The position of array variable g_32 is different in the two binaries.

I do not know whether this situation is normal or this could be some deeper
error.

Definitions of relative variables are listed as follows. All these variables
have initialized to non-zero values at the beginning of the C example.
static int8_t g_32[3][5][7];
static uint16_t g_1161;
static uint64_t g_97[5];
static int32_t g_132;
static int32_t g_562[4][3][6];
static int32_t ** volatile g_997;
static union U0 g_198[5];

.data section fragment 1st (without -g, with -O2):
++
temp_O2.exe: file format elf64-littleaarch64

Disassembly of section .data:

...

00480070 :
  480070:   ff ff ff ff ff ff ff ff f6 ff ff ff ff ff ff ff

  480080:   ff ff ff ff ff ff ff ff f6 ff ff ff ff ff ff ff

  480090:   ff ff ff ff ff ff ff ff 

00480098 :
  480098:   b1 bf 00 00 

0048009c :
  48009c:   01 00 00 00 

004800a0 :
  4800a0:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  4800b0:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  4800c0:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  4800d0:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  4800e0:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  4800f0:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480100:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  480110:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  480120:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480130:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  480140:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  480150:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480160:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  480170:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  480180:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480190:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  4801a0:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  4801b0:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY

004801c0 :
  4801c0:   88 0d 48 00 00 00 00 00 ..H.

004801c8 :
  4801c8:   cc 06 01 40 01 06 cc cc 06 01 40 01 06 cc cc 06
...@..@.
  4801d8:   01 40 01 06 cc cc 06 01 40 01 06 cc cc 06 01 40
.@..@..@
  4801e8:   01 06 cc cc 06 01 40 01 06 cc cc 06 01 40 01 06
..@..@..
  4801f8:   cc cc 06 01 40 01 06 cc cc 06 01 40 01 06 cc cc
@..@
  480208:   06 01 40 01 06 cc cc 06 01 40 01 06 cc cc 06 01
..@..@..
  480218:   40 01 06 cc cc 06 01 40 01 06 cc cc 06 01 40 01
@..@..@.
  480228:   06 cc cc 06 01 40 01 06 cc 00 00 00 00 00 00 00
.@..

00480238 :
  480238:   9e b0 49 35 07 f7 e4 57 01 00 00 00 00 00 00 00
..I5...W
  480248:   9e b0

[Bug c++/88831] New: the layout of .data section of a binary is slightly changed when -g option is enabled.

[wangchang15 at huawei dot com]

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

Bug ID: 88831
   Summary: the layout of .data section of a binary is slightly
changed when -g option is enabled.
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangchang15 at huawei dot com
  Target Milestone: ---

Dear all,

I use a little-endian cross compiler ( gcc7.3-based
build=host=x86_64-suse-linux target=aarch64-linux-gnu) to compile a C
application temp.c which is randomly generated by a CSmith tool.  




To check whether the binaries are the same when compiling temp.c with and
without -g option, the following command is used.

/some/path/to/my/cross/compiler/aarch64-linux-gnu-gcc temp.c  -static -O2  -I
./csmith/runtime  -fcompare-debug=-g -lm -w  -o ./temp_O2.exe

The result is an error message " error: temp.c: -fcompare-debug failure
(length)".

I checked the .data section in both binaries (with/without -g option), the
reason is that the position of an array variable (g_32) is changed. Because the
alignment requirement, different number of 0s are supplemented to this array
variable and another array variable g_1161 which leads to the length of .data
section in both binaries are different.
The disassembly fragment of .data section of both binaries are listed below. 
The position of array variable g_32 is different in the two binaries.

I do not know whether this situation is normal or this could be some deeper
error.

Definitions of relative variables are listed as follows. All these variables
have initialized to non-zero values at the beginning of the C example.
static int8_t g_32[3][5][7];
static uint16_t g_1161;
static uint64_t g_97[5];
static int32_t g_132;
static int32_t g_562[4][3][6];
static int32_t ** volatile g_997;
static union U0 g_198[5];

.data section fragment 1st (without -g, with -O2):
++
temp_O2.exe: file format elf64-littleaarch64

Disassembly of section .data:

...

00480070 :
  480070:   ff ff ff ff ff ff ff ff f6 ff ff ff ff ff ff ff

  480080:   ff ff ff ff ff ff ff ff f6 ff ff ff ff ff ff ff

  480090:   ff ff ff ff ff ff ff ff 

00480098 :
  480098:   b1 bf 00 00 

0048009c :
  48009c:   01 00 00 00 

004800a0 :
  4800a0:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  4800b0:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  4800c0:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  4800d0:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  4800e0:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  4800f0:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480100:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  480110:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  480120:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480130:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  480140:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  480150:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480160:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  480170:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  480180:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY
  480190:   01 00 00 00 a8 63 4b 59 cc 4f 0a a8 38 29 ad 89
.cKY.O..8)..
  4801a0:   cc 4f 0a a8 a8 63 4b 59 01 00 00 00 a8 63 4b 59
.O...cKY.cKY
  4801b0:   cc 4f 0a a8 38 29 ad 89 cc 4f 0a a8 a8 63 4b 59
.O..8)...O...cKY

004801c0 :
  4801c0:   88 0d 48 00 00 00 00 00 ..H.

004801c8 :
  4801c8:   cc 06 01 40 01 06 cc cc 06 01 40 01 06 cc cc 06
...@..@.
  4801d8:   01 40 01 06 cc cc 06 01 40 01 06 cc cc 06 01 40
.@..@..@
  4801e8:   01 06 cc cc 06 01 40 01 06 cc cc 06 01 40 01 06
..@..@..
  4801f8:   cc cc 06 01 40 01 06 cc cc 06 01 40 01 06 cc cc
@..@
  480208:   06 01 40 01 06 cc cc 06 01 40 01 06 cc cc 06 01
..@..@..
  480218:   40 01 06 cc cc 06 01 40 01 06 cc cc 06 01 40 01
@..@..@.
  480228:   06 cc cc 06 01 40 01 06 cc 00 00 00 00 00 00 00
.@..

00480238 :
  480238:   9e b0 49 35 07 f7 e4 57 01 00 00 00 00 00 00 00
..I5...W
  480248:   9e b0