[Bug tree-optimization/87693] ICE in thread_around_empty_blocks, at tree-ssa-threadedge.c:984

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-23
  Component|c   |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  The testcase is undefined at runtime, GCC doesn't support computed
goto to function addresses IIRC.

I have a trivial patch.

[Bug testsuite/87694] [9 regression] problem in g++.dg/concepts/memfun-err.C starting with r263343

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
(In reply to Jozef Lawrynowicz from comment #5)
> (In reply to Richard Biener from comment #4)
> 
> Thanks for the pointers.
> 
> > What happens if you make the attribute work for a MODE_INT union with a
> > MODE_PARTIAL_INT first field that has MODE_SIZE of the union mode?
> >
> > Is there
> > a generic way to query SImode for PSImode as defined in
> > 
> > PARTIAL_INT_MODE (SI, 20, PSI);
> > 
> > ?  Or does one need to compare MODE_SIZE?
> 
> I believe you just have to compare MODE_SIZE as I did below.
> 
> >  Can there be multiple non-partial integer modes with the same size?
> 
> Currently for the targets using PARTIAL_INT_MODE there is only a one-to-one
> mapping from the "full" mode to the partial mode. But where it can get
> tricky is when examining the BITSIZE of a partial int mode, as depending on
> the context, the bitsize could be the bitsize of the SI mode or the true
> bitsize of the PSImode i.e. the precision.
> 
> I tried this (there may well be a neater way):
> 
> diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> index 4416b50..74f6a76 100644
> --- a/gcc/c-family/c-attribs.c
> +++ b/gcc/c-family/c-attribs.c
> @@ -1280,7 +1280,11 @@ handle_transparent_union_attribute (tree *node, tree
> name,
>   tree first = first_field (type);
>   if (first == NULL_TREE
>   || DECL_ARTIFICIAL (first)
> - || TYPE_MODE (type) != DECL_MODE (first))
> + || (TYPE_MODE (type) != DECL_MODE (first)
> + && !(GET_MODE_CLASS (TYPE_MODE (type)) == MODE_INT
> +  && GET_MODE_CLASS (DECL_MODE(first)) ==
> MODE_PARTIAL_INT
> +  && known_eq (GET_MODE_BITSIZE (TYPE_MODE (type)),
> +   GET_MODE_BITSIZE (DECL_MODE (first))
> goto ignored;
> }
> 
> It fixes most of those failing DejaGNU tests, except pr34885.c ends up
> ICE-ing at "-O3 -g".
> 
> during RTL pass: final^M
> /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c: In
> function 'send':^M
> /home/jozef/msp430/gcc/gcc/testsuite/gcc.c-torture/compile/pr34885.c:9:1:
> internal compiler error: Segmentation fault^M
> 0xb58f4f crash_signal^M
>   ../../gcc/toplev.c:325^M
> 0x7bf92d gen_subprogram_die^M
>   ../../gcc/dwarf2out.c:23270^M
> 0x7c1c5b gen_decl_die^M
>   ../../gcc/dwarf2out.c:26197^M
> 0x7c3f9e dwarf2out_decl^M
>   ../../gcc/dwarf2out.c:26765^M
> 0x7d707e dwarf2out_function_decl^M
>   ../../gcc/dwarf2out.c:26780^M
> 0x83e757 rest_of_handle_final^M
>   ../../gcc/final.c:4681^M
> 0x83e757 execute^M
>   ../../gcc/final.c:4723^M
> 
> I haven't investigated the above ICE as the below alternative approach fixes
> the issue and offers codegen benefits.
> 
> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 58a3aa3..6449f16 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -1844,10 +1844,15 @@ compute_record_mode (tree type)
>  }
>  
>/* If we only have one real field; use its mode if that mode's size
> - matches the type's size.  This only applies to RECORD_TYPE.  This
> - does not apply to unions.  */
> + matches the type's size.  This generally only applies to RECORD_TYPE.
> + As an exception, if the union will be passed by reference then it is
> + acceptable to use the mode of the widest field for the mode of the
> + union.  */
>poly_uint64 type_size;
> -  if (TREE_CODE (type) == RECORD_TYPE
> +  if (((TREE_CODE (type) == RECORD_TYPE)
> +   || (TREE_CODE (type) == UNION_TYPE
> +  && targetm.calls.pass_by_reference (pack_cumulative_args (NULL),
> +  mode, type, 0)))
>&& mode != VOIDmode
>&& poly_int_tree_p (TYPE_SIZE (type), &type_size)
>&& known_eq (GET_MODE_BITSIZE (mode), type_size))
> 
> The codegen benefits are that the target might have instructions to
> specifically operate on the partial int mode, which it can use if the mode
> of the union is set to this partial int mode.
> 
> So for msp430 if the widest type in a union is __int20 (PSImode), then
> allowing the union mode to be PSImode results in fewer instructions being
> used to manipulate the union, compared to if the union mode was SImode.
> 
> I'll go ahead and test the second patch, unless there is a reason not to
> allow non-MODE_INT unions. If, for example, we'd rather not have unions be
> MODE_FLOAT I could always restrict the above logic further to only allow the
> union mode to be set to a MODE_PARTIAL_INT in addition to the currently
> allowable MODE_INT.

I think it's better to, at this place, simply allow MODE_INT or
MODE_PARTIAL_INT
for unions.

[Bug other/87695] Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 Target||avr
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
The compiler segfaulted.

Note that GCC 5.4 is no longer maintained, esp. for using link-time
optimization you should try newer toolchains using GCC 7 or GCC 8.

In any case to debug your issue you need to follow
https://gcc.gnu.org/bugs.html
and provide a testcase in the form of preprocessed sources.

[Bug rtl-optimization/87701] New: [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[marxin at gcc dot gnu.org]

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

Bug ID: 87701
   Summary: [9 Regression] ICE in elimination_costs_in_insn, at
reload1.c:3640 since r265398
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: segher at gcc dot gnu.org
  Target Milestone: ---

Following fails:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/tree-ssa/pr57380.C -O3 -c
during RTL pass: ira
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/tree-ssa/pr57380.C: In
function ‘int f(my_array, my_array)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/tree-ssa/pr57380.C:19:1:
internal compiler error: in elimination_costs_in_insn, at reload1.c:3640
   19 | }
  | ^
0x1324d4a elimination_costs_in_insn
/home/marxin/Programming/gcc/gcc/reload1.c:3637
0x131f461 calculate_elim_costs_all_insns()
/home/marxin/Programming/gcc/gcc/reload1.c:1609
0x1110da8 ira_costs()
/home/marxin/Programming/gcc/gcc/ira-costs.c:2256
0x1105d4f ira_build()
/home/marxin/Programming/gcc/gcc/ira-build.c:3432
0x10fa8e8 ira
/home/marxin/Programming/gcc/gcc/ira.c:5299
0x10fb16a execute
/home/marxin/Programming/gcc/gcc/ira.c:5610

[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2018-10-23
  Known to work||8.2.0
   Target Milestone|--- |9.0
  Known to fail||9.0

[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
Aren't you comparing apples and oranges?  A shared library build with
-flto -ffat-lto-objects but linked with -fno-lto will produce a shared
library as built _without_ -flto but with LTO bytecode sections.
A shared library build with -flto -fno-fat-lto-objects will be a
shared library as built with -flto.

So of course the actual shared library .text will differ?

[Bug c/87615] Possible excessive compile time with -O2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #8 from Richard Biener  ---
(In reply to Jan Hubicka from comment #7)
> > Looks like the IPA-CP stmt walking is still unbound?
> There is also walking in ipa-fnsummary that is unbound, perhaps that is the
> problem...
> 
> Honza

Can any of you fix that please?

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[tnfchris at gcc dot gnu.org]

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

--- Comment #38 from Tamar Christina  ---
> Probably not much.  So let's go with your kludge from comment #19 but with a 
> comment giving the rationale for putting it in.

Thinking about this and what Richard said before, If we go with that approach
the  Include directories, Library paths etc will all be wrong. It'll work but
it's going to use a mix of the host and target compiler includes/libs (because
all -I and -L seem to be absolute paths).  Isn't this potentially dangerous?
could end up with an ABI issue.

[Bug tree-optimization/86144] GCC is not generating vector math calls to svml/acml functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Testing this patch now.

[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*

--- Comment #1 from Richard Biener  ---
x86?

[Bug tree-optimization/87700] [9 Regression] Compile time hog w/ -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-23
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

[Bug rtl-optimization/87701] [9 Regression] ICE in elimination_costs_in_insn, at reload1.c:3640 since r265398

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
(In reply to Richard Biener from comment #1)
> x86?

Yes! I forgot to mention that.

[Bug tree-optimization/87700] [8/9 Regression] Compile time hog w/ -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.2.0
   Target Milestone|9.0 |8.3
Summary|[9 Regression] Compile time |[8/9 Regression] Compile
   |hog w/ -O1  |time hog w/ -O1

--- Comment #1 from Richard Biener  ---
This looks like a latent issue in set_copy_of_val.  The GCC 8 branch is also
affected after backporting the SSA propagator re-org.  Testing patch.

[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails

[ebotcazou at gcc dot gnu.org]

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

--- Comment #39 from Eric Botcazou  ---
> Thinking about this and what Richard said before, If we go with that
> approach the  Include directories, Library paths etc will all be wrong.
> It'll work but it's going to use a mix of the host and target compiler
> includes/libs (because all -I and -L seem to be absolute paths).  Isn't this
> potentially dangerous? could end up with an ABI issue.

In most practical cases -B../../ is just redundant with $(CXX).  It's only when
you configure like Richard that you may run into issues, but then we can assume
that we're on Linux so the paths are OK I think.

[Bug fortran/85603] ICE with character array substring assignment

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Tue Oct 23 08:27:14 2018
New Revision: 265412

URL: https://gcc.gnu.org/viewcvs?rev=265412&root=gcc&view=rev
Log:
2018-10-23  Paul Thomas  

PR fortran/85603
* frontend-passes.c (get_len_call): New function to generate a
call to intrinsic LEN.
(create_var): Use this to make length expressions for variable
rhs string lengths.
Clean up some white space issues.

2018-10-23  Paul Thomas  

PR fortran/85603
* gfortran.dg/deferred_character_23.f90 : Check reallocation is
occurring as it should and a regression caused by version 1 of
this patch.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/frontend-passes.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/deferred_character_23.f90

[Bug ada/87688] [9.0 regression] ACATS cb1010a cb1010d failure

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #2 from Eric Botcazou  ---
> Confirmed, it appeared between revisions r264819 (OK) and r264901 (FAIL).

Maybe r264897 then, it seems to be rather far-reaching a change and may expose
secondary issues.

[Bug c/87615] Possible excessive compile time with -O2

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
(In reply to Richard Biener from comment #8)
>
> Can any of you fix that please?

If doing that only in stage 3 is fine, I can.

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org

--- Comment #9 from Richard Biener  ---
For the original testcase there's also the issue that the bez[] accesses end up
as

  _68 = MEM[(double *)bez_27(D) + 16B];
  _69 = MEM[(double *)bez_27(D) + 24B];

and thus they possibly alias with the earlier stores

  bBox_33(D)->x0 = iftmp.1_190;
  bBox_33(D)->y0 = iftmp.1_193;
  bBox_33(D)->x1 = iftmp.0_196;
  bBox_33(D)->y1 = iftmp.0_199;

which we subsequently fail to eliminate against the final ones

  iftmp.1_49 = MIN_EXPR <_119, iftmp.1_190>;
  bBox_33(D)->x0 = iftmp.1_49;
  iftmp.1_31 = MIN_EXPR <_118, iftmp.1_193>;
  bBox_33(D)->y0 = iftmp.1_31;
  iftmp.0_102 = MAX_EXPR <_119, iftmp.0_196>;
  bBox_33(D)->x1 = iftmp.0_102;
  iftmp.0_105 = MAX_EXPR <_118, iftmp.0_199>;
  bBox_33(D)->y1 = iftmp.0_105;

if we'd eliminate the earlier ones then vectorization would have had a chance
here.  That's from

// Linear interpolation, works with points as well.
template
inline V lerp(const V& a, const V& b, const T& t) noexcept {
  return (a * (1.0 - t)) + (b * t);
}

and

// Min/Max - different semantics compared to std.
template constexpr T myMin(const T& a, const T& b) noexcept
{ return b < a ? b : a; }
template constexpr T myMax(const T& a, const T& b) noexcept
{ return a < b ? b : a; }

taking references to double.

Plus it is because IPA SRA decomposing the by reference Point passing
to

  _17 = MEM[(double *)b_2(D)];
  _18 = MEM[(double *)b_2(D) + 8B];
  _19 = MEM[(double *)&t];
  _20 = MEM[(double *)&t + 8B];
  D.19260 = _ZmlRK5PointS1_.isra.5 (_17, _18, _19, _20);

that's quite bad for TBAA ... the function uses b->x, etc. to access the
memory.

[Bug tree-optimization/87693] ICE in thread_around_empty_blocks, at tree-ssa-threadedge.c:984

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/87693] ICE in thread_around_empty_blocks, at tree-ssa-threadedge.c:984

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 08:51:20 2018
New Revision: 265413

URL: https://gcc.gnu.org/viewcvs?rev=265413&root=gcc&view=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/87693
* tree-ssa-threadedge.c (thread_around_empty_blocks): Handle
the case we do not find the taken edge.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87693.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-threadedge.c

[Bug target/87674] AVX512: incorrect intrinsic signature

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #2)
> Dunno if we want to change anything from the above beyond the above patch,
> perhaps the const type * vs. type * differences might be highest on the list
> to change.

ICC is our gold standard as far as intrinsics are concerned. So, unless there
is a real issue with some specific builtin, I think we should follow ICC.

[Bug c/87615] Possible excessive compile time with -O2

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Tue, 23 Oct 2018, jamborm at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615
> 
> Martin Jambor  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |ASSIGNED
>Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
> gnu.org
> 
> --- Comment #9 from Martin Jambor  ---
> (In reply to Richard Biener from comment #8)
> >
> > Can any of you fix that please?
> 
> If doing that only in stage 3 is fine, I can.

Sure.

[Bug tree-optimization/86144] GCC is not generating vector math calls to svml/acml functions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||9.0
 Resolution|--- |FIXED

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

[Bug tree-optimization/86144] GCC is not generating vector math calls to svml/acml functions

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 08:58:39 2018
New Revision: 265414

URL: https://gcc.gnu.org/viewcvs?rev=265414&root=gcc&view=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/86144
* tree-vect-stmts.c (vect_analyze_stmt): Prefer -mveclibabi
over simd attribute.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-stmts.c

[Bug c++/49574] Give a warning for insane overloading

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
OK here's the documentation patch:

--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -3383,6 +3383,11 @@ object to the same type, to a base class of that type,
or to void; such
 a conversion function will never be called.
 @end table

+@item -Winsane-overloading @r{(C++ and Objective-C++ only)}
+@opindex Winsane-overloading
+@opindex Wno-insane-overloading
+Warn about whatever was agreed to in Bugzilla.
+
 @node Objective-C and Objective-C++ Dialect Options
 @section Options Controlling Objective-C and Objective-C++ Dialects


The rest should be a simple matter of programming.

More seriously, I'm not the one asking for the warning, so it's not up to me to
describe what's wanted.

[Bug c++/87692] Reuse guard variable for multiple initializations

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I think this needs to be specified by the ABI before we can change it, and
you'd still you have a backwards compatibility problem. If the function is
inline and included in two translation units, the compilers of those two TUs
need to agree to only use one guard variable.

[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations

[romain.geissler at amadeus dot com]

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

--- Comment #3 from Romain Geissler  ---
Well I might not understand everything but no I don't think I am comparing
uncomparable things.

I never build/link with -fno-lto, -flto is *always* provided.

See for example the case with fat objects:
compile command line is:

libtool: compile:  gcc -DHAVE_CONFIG_H -I../include -I../src
-I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/include
-I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/crypto/latest/osp/include
-I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/include
-std=gnu11 -fno-working-directory -ggdb3 -flto -ffat-lto-objects
-fuse-linker-plugin
-I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/include
-I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/crypto/latest/osp/include
-I/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/include
-MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c openssl.c  -fPIC -DPIC -o
.libs/openssl.o

link command line is:
libtool: link:  gcc -shared  -fPIC -DPIC  .libs/channel.o .libs/comp.o
.libs/crypt.o .libs/hostkey.o .libs/kex.o .libs/mac.o .libs/misc.o
.libs/packet.o .libs/publickey.o .libs/scp.o .libs/session.o .libs/sftp.o
.libs/userauth.o .libs/transport.o .libs/version.o .libs/knownhost.o
.libs/agent.o .libs/openssl.o .libs/pem.o .libs/keepalive.o .libs/global.o  
-Wl,-rpath
-Wl,/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/lib
-Wl,-rpath
-Wl,/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/lib
-L/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/ssl/latest/osp/lib
-lssl -lcrypto
-L/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/ZLib/latest/osp/lib
-lz
-L/remote/users/rgeissler/wk/ospack/ssh2/rpm-bms-scripts/DEPS/osp/OpenSSL/crypto/latest/osp/lib
 -ggdb3 -flto -fuse-linker-plugin -g -O3 -ggdb3 -flto -fuse-linker-plugin  
-Wl,-soname -Wl,libssh2.so.1 -Wl,-version-script -Wl,.libs/libssh2.ver -o
.libs/libssh2.so.1.0.1

[Bug c++/87699] Implement CWG 1512

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed.

Martin, I thought this was a dup of an existing bug that you'd filed or
commented on, but can't find anything. Am I imagining it?

[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations

[rguenther at suse dot de]

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

--- Comment #4 from rguenther at suse dot de  ---
On Tue, 23 Oct 2018, romain.geissler at amadeus dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87698
> 
> --- Comment #3 from Romain Geissler  ---
> Well I might not understand everything but no I don't think I am comparing
> uncomparable things.
> 
> I never build/link with -fno-lto, -flto is *always* provided.

OK, so both libraries do not contain LTO bytecode then.  Indeed
there should be zero differences in that case.

A (smaller) testcase showing such differences would be appreciated.

[Bug target/87674] AVX512: incorrect intrinsic signature

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Oct 23 09:25:57 2018
New Revision: 265416

URL: https://gcc.gnu.org/viewcvs?rev=265416&root=gcc&view=rev
Log:
PR target/87674
* config/i386/avx512vlintrin.h (_mm_mask_mullo_epi32): Change type of
second argument from __mmask16 to __mmask8.
* config/i386/avx512vlbwintrin.h (_mm_mask_packus_epi32,
_mm_mask_packs_epi32): Likewise.
* config/i386/avx512pfintrin.h (_mm512_mask_prefetch_i64scatter_ps):
Likewise.
(_mm512_mask_prefetch_i64scatter_pd): Likewise.  Formatting fix.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/avx512pfintrin.h
trunk/gcc/config/i386/avx512vlbwintrin.h
trunk/gcc/config/i386/avx512vlintrin.h

[Bug c++/87697] Casting a base class to derived gives no warning

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to jynelson from comment #0)
> Casting a base class to a derived class gives no warning, even with -Wall
> -Werror enabled. I've been told on IRC that this sort of cast is undefined
> behaviour according to spec if neither class is virtual.

It has nothing to do with whether anything is virtual or not. The relevant
standard wording is:

   If the object of type “cv1 B” is actually a base class subobject of an
   object of type D, the result refers to the enclosing object of type D.
   Otherwise, the behavior is undefined.

Since the pointer returned by 'new c1' does not point to a base class subobject
of an object of type derived, the behaviour is undefined.

> If that is the
> case, it would be nice to have a warning.

It's only possible to warn when the compiler can statically prove that the
pointer really isn't pointing to a derived. That's possible in your example
because it was created right there by the 'new c1' expression, but that is a
very silly thing to do and surely nobody does it in real code. Generally a
function just gets passed a pointer to a base class, and can't see its
construction, so can't tell if the cast is valid or not.

> If that isn't the case, there are several more questions that arise, like
> `why does c1 have access to c2` and `why can the const value c2::x be
> accessed without be initialized`?

It doesn't, because there's no c2 object constructed. Obviously the code is
silly and broken.

I don't think a compiler warning would be worthwhile, because it would only
warn about code which is obviously wrong by inspection i.e. which should be
caught by the most cursory code review.

The general case can be diagnosed through runtime instrumentation but
-fsanitize=undefined only gives a runtime error for an invalid static_cast
involving polymorphic types (because the type identification is linked to the
vtable).

-fsanitize=address does diagnose that accessing members of c2 performs an
out-of-bounds read:

constructor 1
=
==16923==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x60200010 at pc 0x00400b03 bp 0x7ffc6744ca60 sp 0x7ffc6744ca58
READ of size 4 at 0x60200010 thread T0
#0 0x400b02 in c2::foo() /tmp/inh.cc:14
#1 0x400a41 in main /tmp/inh.cc:30
#2 0x7f1f0cb87fe9 in __libc_start_main ../csu/libc-start.c:308
#3 0x400969 in _start (/tmp/a.out+0x400969)

0x60200011 is located 0 bytes to the right of 1-byte region
[0x60200010,0x60200011)
allocated by thread T0 here:
#0 0x7f1f0d8f04f0 in operator new(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cc:90
#1 0x400a26 in main /tmp/inh.cc:27
#2 0x7f1f0cb87fe9 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow /tmp/inh.cc:14 in c2::foo()
Shadow bytes around the buggy address:
  0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa[01]fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==16923==ABORTING

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[rearnsha at gcc dot gnu.org]

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

--- Comment #15 from Richard Earnshaw  ---
(In reply to coypu from comment #14)
> Also, after these two patches, my own build of arm--netbsdelf is failing
> from this:
> configure: error: Pthreads are required to build libgomp
> 
> Looking at config.log, the error is actually:
> configure:15118: /tmp/build/./gcc/xgcc -B/tmp/build/./gcc/
> -B/usr/local/arm--netbsdelf/bin/ -B/usr/local/arm--netbsdelf/lib/ -isystem
> /usr/local/arm--netbsdelf/include -isystem
> /usr/local/arm--netbsdelf/sys-include
> --sysroot=/home/fly/shark/destdir.shark/   -o conftest -g -O2   conftest.c
> -lpthread  >&5
> /home/fly/shark/destdir.shark/usr/lib/libpthread.so: undefined reference to
> `__modsi3@GCC_3.0'
> collect2: error: ld returned 1 exit status
> 
> I'm not sure what is the cause of that.

My guess is that it's something to do with the symbol versioning.  IIRC netbsd
provides its own versions of __modsi3 and it probably doesn't have a GCC_3.0
symbol version on it, which then confuses the linker.

However, this bug is getting confused as it seems to be a hybrid of oabi and
eabi issues.

Please separate the two issues out and keep this one for the existing oabi
port.

[Bug tree-optimization/87700] [8/9 Regression] Compile time hog w/ -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 09:36:13 2018
New Revision: 265418

URL: https://gcc.gnu.org/viewcvs?rev=265418&root=gcc&view=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/87700
* tree-ssa-copy.c (set_copy_of_val): Fix change detection logic.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr87700.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-copy.c

[Bug tree-optimization/87700] [8/9 Regression] Compile time hog w/ -O1

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 09:35:31 2018
New Revision: 265417

URL: https://gcc.gnu.org/viewcvs?rev=265417&root=gcc&view=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/87700
* tree-ssa-copy.c (set_copy_of_val): Fix change detection logic.

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

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr87700.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-copy.c

[Bug ada/87688] [9 regression] ACATS cb1010a cb1010d failure

[simon at pushface dot org]

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

--- Comment #3 from simon at pushface dot org ---
So far I have reached r264892 (PASS), r264901 (FAIL).

[Bug c++/84636] internal compiler error: Segmentation fault (identifier_p()/grokdeclarator())

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

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

[Bug other/86198] Libbacktrace does not properly work with ".note.gnu.build-id" section

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 09:59:38 2018
New Revision: 265419

URL: https://gcc.gnu.org/viewcvs?rev=265419&root=gcc&view=rev
Log:
2018-10-23  Richard Biener  

Backport from mainline
2018-06-21  Denis Khalikov 

PR other/86198
* elf.c (elf_add): Increase ".note.gnu.build-id" section size
checking up to 36 bytes.

Modified:
branches/gcc-8-branch/libbacktrace/ChangeLog
branches/gcc-8-branch/libbacktrace/elf.c

[Bug tree-optimization/87700] [8/9 Regression] Compile time hog w/ -O1

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/87702] New: [5/6/7/8 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[mihail.zenkov at gmail dot com]

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

Bug ID: 87702
   Summary: [5/6/7/8 Regression] Segfault in glibc if compiled
with -march=amdfam10 -O2 (x86)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mihail.zenkov at gmail dot com
  Target Milestone: ---

I compiled glibc-2.27 with gcc-8.2 on 32-bit system and have segfaults in
busybox and other software which use this lib. With gcc-4.9.4 all works
correct.

I do bisect and found two regression:

1.
https://github.com/gcc-mirror/gcc/commit/6271bd93bf201cf83b48ad349f06919e87da54fd

I have it with "-march=amdfam10 -O2".

2.
https://github.com/gcc-mirror/gcc/commit/a9d8ab3820ccd10d2ac547295dadf75a33077f14

I have it with "-march=amdfam10 -O2 -mfpmath=sse".

Not sure is this regressions limited to amdfam10 or not.

[Bug target/86383] [9 Regression] arm-netbsdelf cross compiler fails in selftests

[rearnsha at gcc dot gnu.org]

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

--- Comment #16 from Richard Earnshaw  ---
Author: rearnsha
Date: Tue Oct 23 10:19:15 2018
New Revision: 265420

URL: https://gcc.gnu.org/viewcvs?rev=265420&root=gcc&view=rev
Log:
[arm]  Update default CPUs during configure

There are a couple of places in config.gcc where the default CPU is
still arm6, but that was removed as a supported CPU earlier this year.
This patch fixes those entries.

The default CPU for configurations that do not explicitly set a
default is now arm7tdmi (so assumes thumb is available).  Given that
StrongArm is on the deprecated list, this is a better default than we
had previously.

For NetBSD the default is StrongArm; this is the only remaining port
that uses the old ABI and really still carries support for non-thumb
based targets.

PR target/86383
* config.gcc (arm*-*-netbsdelf*): Default to StrongARM if no CPU
specified to configure.
(arm*-*-*): Use ARM7TDMI as the target CPU if no default provided.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config.gcc

[Bug rtl-optimization/87703] New: UBSAN: poly-int.h:1941:12: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to

[marxin at gcc dot gnu.org]

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

Bug ID: 87703
   Summary: UBSAN: poly-int.h:1941:12: runtime error: negation of
-9223372036854775808 cannot be represented in type
'long int'; cast to an unsigned type to negate this
value to itself
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
Blocks: 63426
  Target Milestone: ---

Happens with UBSAN gcc compiler for:

$ cat overflow.i
int a;
unsigned long b;

void bar ();

void c() {
  if (__builtin_sub_overflow(0, a, &b))
bar();
}

$ UBSAN_OPTIONS=print_stacktrace=1 ./xgcc -B. overflow.i -O2 -c
../../gcc/poly-int.h:1941:12: runtime error: negation of -9223372036854775808
cannot be represented in type 'long int'; cast to an unsigned type to negate
this value to itself
#0 0xca1d18 in poly_result::coeff_type,
poly_int_traits::coeff_type,
poly_coeff_pair_traits::coeff_type,
poly_int_traits::coeff_type>::result_kind>::type known_alignment<1u,
long>(poly_int_pod<1u, long> const&) ../../gcc/poly-int.h:1941
#1 0x40085d7 in force_int_to_mode ../../gcc/combine.c:8868
#2 0x400711e in force_to_mode ../../gcc/combine.c:8721
#3 0x3ff15b6 in simplify_set ../../gcc/combine.c:6800
#4 0x3febb64 in combine_simplify_rtx ../../gcc/combine.c:6380
#5 0x3fe2615 in subst ../../gcc/combine.c:5652
#6 0x3fe0e8c in subst ../../gcc/combine.c:5515
#7 0x3fcabc6 in try_combine ../../gcc/combine.c:3385
#8 0x3fb9d2e in combine_instructions ../../gcc/combine.c:1301
#9 0x4046a70 in rest_of_handle_combine ../../gcc/combine.c:14994
#10 0x4046c30 in execute ../../gcc/combine.c:15039
#11 0x1c66de3 in execute_one_pass(opt_pass*) ../../gcc/passes.c:2428
#12 0x1c6783c in execute_pass_list_1 ../../gcc/passes.c:2517
#13 0x1c678f9 in execute_pass_list_1 ../../gcc/passes.c:2518
#14 0x1c679a3 in execute_pass_list(function*, opt_pass*)
../../gcc/passes.c:2528
#15 0xe6fc6d in cgraph_node::expand() ../../gcc/cgraphunit.c:2194
#16 0xe713a1 in expand_all_functions ../../gcc/cgraphunit.c:2332
#17 0xe73e23 in symbol_table::compile() ../../gcc/cgraphunit.c:2683
#18 0xe7497d in symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2861
#19 0x21076f2 in compile_file ../../gcc/toplev.c:480
#20 0x2110385 in do_compile ../../gcc/toplev.c:2172
#21 0x2110acb in toplev::main(int, char**) ../../gcc/toplev.c:2307
#22 0x460055e in main ../../gcc/main.c:39
#23 0x7608cfea in __libc_start_main ../csu/libc-start.c:308
#24 0x84e1a9 in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x84e1a9)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
[Bug 63426] [meta-bug] Issues found with -fsanitize=undefined

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[jozef.l at mittosystems dot com]

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

--- Comment #7 from Jozef Lawrynowicz  ---
(In reply to Richard Biener from comment #6)
> 
> I think it's better to, at this place, simply allow MODE_INT or
> MODE_PARTIAL_INT
> for unions.  Allowing MODE_INT is what we'd fall back to anyways and you
> want to allow MODE_PARTIAL_INT which is already allowed for RECORD_TYPEs.
> 
> What I'm not sure is if the target is happy about, say,
> 
> union U { float f; __int20 i; };
> 
> float foo()
> {
>   union U u;
>   u.i = 10;
>   return u.f;
> }
> 
> iff we were to put u into a MODE_PARTIAL_INT register are targets to be
> expected to be able to extract a MODE_FLOAT from it or are we going
> to spill here anyways?

I tweaked the above source a little:

float foo(union U u)
{
  u.i = u.i + 10;
  return u.f;
}

For this, GCC fills u.i then spills after modifying it. I therefore assume in
general that if u.f is alive then modifications to u.i will always be spilled
after.

> How is TYPE_SIZE / GET_MODE_BITSIZE of this union anyways?  The loop
> in stor-layout checks TYPE_SIZE vs. DECL_SIZE - is DECL_SIZE always
> matching GET_MODE_BITSIZE?

It actually depends on the order of the fields in the union, which is not good.
Since __int20 and float have the same BITSIZE, the mode of the last field in
the union will be used for the mode of the union. So for the above code with my
current patch, the union TYPE_MODE is PSImode. This causes wrong code to be
generated, as the function foo starts by only pushing the __int20 value of the
union onto the stack, rather than the full 32-bits.

I had the following additional patch which didn't seem to affect the
testresults, but fixes this issue so is clearly beneficial:

diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index 6449f16..3bb0bbc 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -1834,7 +1834,13 @@ compute_record_mode (tree type)
   /* If this field is the whole struct, remember its mode so
 that, say, we can put a double in a class into a DF
 register instead of forcing it to live in the stack.  */
-  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field)))
+  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field))
+ /* Partial int types (e.g. __int20) may have TYPE_SIZE equal to
+wider types (e.g. int32), despite precision being less.  Ensure
+that the TYPE_MODE of the struct does not get set to the partial
+int mode if there is a wider type also in the struct.  */
+ && known_gt (GET_MODE_PRECISION (DECL_MODE (field)),
+  GET_MODE_PRECISION (mode)))
mode = DECL_MODE (field);

   /* With some targets, it is sub-optimal to access an aligned

This fixes the above issue, so the union TYPE_MODE is always SFmode, regardless
of the ordering of the fields.

[Bug ada/87688] [9 regression] ACATS cb1010a cb1010d failure

[simon at pushface dot org]

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

--- Comment #4 from simon at pushface dot org ---
Eric is right: r264896 (OK), r264897 (FAIL).

[Bug c/87691] transparent_union attribute does not work with MODE_PARTIAL_INT

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Tue, 23 Oct 2018, jozef.l at mittosystems dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87691
> 
> --- Comment #7 from Jozef Lawrynowicz  ---
> (In reply to Richard Biener from comment #6)
> > 
> > I think it's better to, at this place, simply allow MODE_INT or
> > MODE_PARTIAL_INT
> > for unions.  Allowing MODE_INT is what we'd fall back to anyways and you
> > want to allow MODE_PARTIAL_INT which is already allowed for RECORD_TYPEs.
> > 
> > What I'm not sure is if the target is happy about, say,
> > 
> > union U { float f; __int20 i; };
> > 
> > float foo()
> > {
> >   union U u;
> >   u.i = 10;
> >   return u.f;
> > }
> > 
> > iff we were to put u into a MODE_PARTIAL_INT register are targets to be
> > expected to be able to extract a MODE_FLOAT from it or are we going
> > to spill here anyways?
> 
> I tweaked the above source a little:
> 
> float foo(union U u)
> {
>   u.i = u.i + 10;
>   return u.f;
> }
> 
> For this, GCC fills u.i then spills after modifying it. I therefore assume in
> general that if u.f is alive then modifications to u.i will always be spilled
> after.
> 
> > How is TYPE_SIZE / GET_MODE_BITSIZE of this union anyways?  The loop
> > in stor-layout checks TYPE_SIZE vs. DECL_SIZE - is DECL_SIZE always
> > matching GET_MODE_BITSIZE?
> 
> It actually depends on the order of the fields in the union, which is not 
> good.
> Since __int20 and float have the same BITSIZE, the mode of the last field in
> the union will be used for the mode of the union. So for the above code with 
> my
> current patch, the union TYPE_MODE is PSImode. This causes wrong code to be
> generated, as the function foo starts by only pushing the __int20 value of the
> union onto the stack, rather than the full 32-bits.
> 
> I had the following additional patch which didn't seem to affect the
> testresults, but fixes this issue so is clearly beneficial:
> 
> diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
> index 6449f16..3bb0bbc 100644
> --- a/gcc/stor-layout.c
> +++ b/gcc/stor-layout.c
> @@ -1834,7 +1834,13 @@ compute_record_mode (tree type)
>/* If this field is the whole struct, remember its mode so
>  that, say, we can put a double in a class into a DF
>  register instead of forcing it to live in the stack.  */
> -  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field)))
> +  if (simple_cst_equal (TYPE_SIZE (type), DECL_SIZE (field))
> + /* Partial int types (e.g. __int20) may have TYPE_SIZE equal to
> +wider types (e.g. int32), despite precision being less.  Ensure
> +that the TYPE_MODE of the struct does not get set to the partial
> +int mode if there is a wider type also in the struct.  */
> + && known_gt (GET_MODE_PRECISION (DECL_MODE (field)),
> +  GET_MODE_PRECISION (mode)))
> mode = DECL_MODE (field);
> 
>/* With some targets, it is sub-optimal to access an aligned
> 
> This fixes the above issue, so the union TYPE_MODE is always SFmode, 
> regardless
> of the ordering of the fields.

That makes sense.

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
  Component|rtl-optimization|target
  Known to work||4.9.4
Version|unknown |8.2.0
   Target Milestone|--- |6.5
Summary|[5/6/7/8 Regression]|[6/7/8/9 Regression]
   |Segfault in glibc if|Segfault in glibc if
   |compiled with   |compiled with
   |-march=amdfam10 -O2 (x86)   |-march=amdfam10 -O2 (x86)

[Bug libstdc++/87704] New: [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

Bug ID: 87704
   Summary: [6/7/8/9 Regression] unique_ptr(nullptr_t) requires
T to be complete
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

struct Incomplete;

void f(void* p)
{
  ::new (p) std::unique_ptr();  // OK

  ::new (p) std::unique_ptr(nullptr);   // ERROR
}

This fails because the unique_ptr(nullptr_t) constructor is implemented
precisely as specified in C++11 and C++14:

  constexpr unique_ptr(nullptr_t) noexcept
: unique_ptr() { }

The use of a delegating constructor means that the destructor is odr-used which
invokes default_delete::operator() which is ill-formed if T is incomplete.

The example compiled until r194651 but fails in all versions since 4.8.0

The same problem exists for the unique_ptr specialization, but not for
shared_ptr(nullptr) because that doesn't create a control block so doesn't
instantiate a deleter.

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-10-23
  Known to work||4.7.4
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.0, 4.8.5, 4.9.4, 5.5.0,
   ||6.4.0, 7.3.0, 8.2.0, 9.0

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
C++17 doesn't have the defect, it appears to have been fixed as an unintended
consequence of https://wg21.link/lwg2801

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 11:34:56 2018
New Revision: 265421

URL: https://gcc.gnu.org/viewcvs?rev=265421&root=gcc&view=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/87105
PR tree-optimization/87608
* passes.def (pass_all_early_optimizations): Add early phi-opt
after dce.
* tree-ssa-phiopt.c (value_replacement): Ignore NOPs and predicts in
addition to debug stmts.
(tree_ssa_phiopt_worker): Add early_p argument, do only min/max
and abs replacement early.
* tree-cfg.c (gimple_empty_block_p): Likewise.

* g++.dg/tree-ssa/phiopt-1.C: New testcase.
g++.dg/vect/slp-pr87105.cc: Likewise.
* g++.dg/tree-ssa/pr21463.C: Scan phiopt2 because this testcase
relies on phiprop run before.
* g++.dg/tree-ssa/pr30738.C: Likewise.
* g++.dg/tree-ssa/pr57380.C: Likewise.
* gcc.dg/tree-ssa/pr84859.c: Likewise.
* gcc.dg/tree-ssa/pr45397.c: Scan phiopt2 because phiopt1 is
confused by copies in the IL left by EVRP.
* gcc.dg/tree-ssa/phi-opt-5.c: Likewise, this time confused
by predictors.
* gcc.dg/tree-ssa/phi-opt-12.c: Scan phiopt2.
* gcc.dg/pr24574.c: Likewise.
* g++.dg/tree-ssa/pr86544.C: Scan phiopt4.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/phiopt-1.C
trunk/gcc/testsuite/g++.dg/vect/slp-pr87105.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr21463.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr30738.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr57380.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr86544.C
trunk/gcc/testsuite/gcc.dg/pr24574.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040514-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040518-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr84859.c
trunk/gcc/testsuite/gcc.dg/uninit-15.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-ssa-phiopt.c

[Bug tree-optimization/87608] Very slow swap operations

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Tue Oct 23 11:34:56 2018
New Revision: 265421

URL: https://gcc.gnu.org/viewcvs?rev=265421&root=gcc&view=rev
Log:
2018-10-23  Richard Biener  

PR tree-optimization/87105
PR tree-optimization/87608
* passes.def (pass_all_early_optimizations): Add early phi-opt
after dce.
* tree-ssa-phiopt.c (value_replacement): Ignore NOPs and predicts in
addition to debug stmts.
(tree_ssa_phiopt_worker): Add early_p argument, do only min/max
and abs replacement early.
* tree-cfg.c (gimple_empty_block_p): Likewise.

* g++.dg/tree-ssa/phiopt-1.C: New testcase.
g++.dg/vect/slp-pr87105.cc: Likewise.
* g++.dg/tree-ssa/pr21463.C: Scan phiopt2 because this testcase
relies on phiprop run before.
* g++.dg/tree-ssa/pr30738.C: Likewise.
* g++.dg/tree-ssa/pr57380.C: Likewise.
* gcc.dg/tree-ssa/pr84859.c: Likewise.
* gcc.dg/tree-ssa/pr45397.c: Scan phiopt2 because phiopt1 is
confused by copies in the IL left by EVRP.
* gcc.dg/tree-ssa/phi-opt-5.c: Likewise, this time confused
by predictors.
* gcc.dg/tree-ssa/phi-opt-12.c: Scan phiopt2.
* gcc.dg/pr24574.c: Likewise.
* g++.dg/tree-ssa/pr86544.C: Scan phiopt4.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/phiopt-1.C
trunk/gcc/testsuite/g++.dg/vect/slp-pr87105.cc
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/pr21463.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr30738.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr57380.C
trunk/gcc/testsuite/g++.dg/tree-ssa/pr86544.C
trunk/gcc/testsuite/gcc.dg/pr24574.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040514-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/20040518-1.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-12.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-5.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-6.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/phi-opt-8.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/popcount3.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr45397.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr84859.c
trunk/gcc/testsuite/gcc.dg/uninit-15.c
trunk/gcc/tree-cfg.c
trunk/gcc/tree-ssa-phiopt.c

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
On x86_64 it fails with -O1 -fstrict-aliasing -ftree-loop-vectorize

It still fails if every -fno-xxx option for -O1 is added except
-fno-tree-copy-prop so it seems to require:

 -fstrict-aliasing -ftree-loop-vectorize -ftree-copy-prop

On ppc64le it also fails with -O1 -fstrict-aliasing -ftree-loop-vectorize but
-ftree-copy-prop isn't the only -O1 pass that matters, several of the -O1
passes are needed to cause the bug (including at least -ftree-copy-prop 
-ftree-ch -ftree-forwprop but also others I haven't isolated).

[Bug tree-optimization/87608] Very slow swap operations

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/87105] Autovectorization [X86, SSE2, AVX2, DoublePrecision]

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
The code is now better but not vectorized due to mentioned issues.

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 CC||ville.voutilainen at gmail dot 
com

--- Comment #8 from Ville Voutilainen  ---
It seems that either -fno-strict-aliasing or -march=native makes it work. That
bears a *striking* similarity to the symptoms seen in
https://bugreports.qt.io/browse/QTBUG-69388 !

[Bug c++/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Correction, on both x86_64 and ppc64le it requires all of:

-fstrict-aliasing  -ftree-loop-vectorize -ftree-sra -ftree-ch -ftree-forwprop
-ftree-copy-prop

[Bug fortran/87705] New: Compilation error when dealing with sub derived types

[peter.gerkens at siemens dot com]

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

Bug ID: 87705
   Summary: Compilation error when dealing with sub derived types
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter.gerkens at siemens dot com
  Target Milestone: ---

Created attachment 44882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44882&action=edit
File "main.f90" contains the module with the dreived type declarations and the
main program containing some data statements.

When using nested derived types the order of the variables in the "sub" derived
type are important, otherwise a compiler error occurs:

mlhw7ahx: /home/gerke00p/Softwaredevelopment/Fortran/gfortran_error_10_2018 >
gfortran -v -save-temps -Wall -Wextra main.f90 -o main
Driving: gfortran -v -save-temps -Wall -Wextra main.f90 -o main -l gfortran -l
m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.2.0/configure
--prefix=/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin
Thread model: posix
gcc version 8.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-o' 'main'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'

/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/f951
main.f90 -quiet -dumpbase main.f90 -mtune=generic -march=x86-64 -auxbase main
-Wall -Wextra -version -fintrinsic-modules-path
/home/gerke00p/Softwaredevelopment/gcc/gcc-8.2.0_bin/lib/gcc/x86_64-pc-linux-gnu/8.2.0/finclude
-o main.s
GNU Fortran (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran2008 (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.0, MPFR version 3.1.4,
MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
main.f90:36:0:

 program main

internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148
0x5c5a3f gfc_conv_string_init(tree_node*, gfc_expr*)
../../gcc-8.2.0/gcc/fortran/trans-const.c:148
0x70a60f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:6958
0x70abb0 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:7818
0x70a627 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:6951
0x70abb0 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:7818
0x6ddcdd gfc_conv_array_initializer(tree_node*, gfc_expr*)
../../gcc-8.2.0/gcc/fortran/trans-array.c:5970
0x70a65a gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-8.2.0/gcc/fortran/trans-expr.c:6916
0x6f4bf2 gfc_get_symbol_decl(gfc_symbol*)
../../gcc-8.2.0/gcc/fortran/trans-decl.c:1835
0x6f7657 generate_local_decl
../../gcc-8.2.0/gcc/fortran/trans-decl.c:5595
0x6bd4c2 do_traverse_symtree
../../gcc-8.2.0/gcc/fortran/symbol.c:4179
0x6f824a generate_local_vars
../../gcc-8.2.0/gcc/fortran/trans-decl.c:5795
0x6f824a gfc_generate_function_code(gfc_namespace*)
../../gcc-8.2.0/gcc/fortran/trans-decl.c:6442
0x688e46 translate_all_program_units
../../gcc-8.2.0/gcc/fortran/parse.c:6125
0x688e46 gfc_parse_file()
../../gcc-8.2.0/gcc/fortran/parse.c:6328
0x6cf25f gfc_be_parse_file
../../gcc-8.2.0/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug ipa/87706] New: Inlined functions trigger invalid -Wmissing-profile warning

[marxin at gcc dot gnu.org]

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

Bug ID: 87706
   Summary: Inlined functions trigger invalid -Wmissing-profile
warning
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Considering following example:

$ cat sra-6.c
int g;

static
void cow (int a, int b)
{
  if (a)
g = 123;
}

int main(int argc, char **argv)
{
  cow (argc, 0);
  return 0;
}

One can see:

$ gcc sra-6.c  -O2 -fprofile-generate -Wall && ./a.out && gcc sra-6.c  -O2
-fprofile-use
sra-6.c: In function ‘cow’:
sra-6.c:4:6: warning: profile for function ‘cow’ not found in profile data
[-Wmissing-profile]
4 | void cow (int a, int b)
  |  ^~~

Problem is the function 'cow' is removed in IPA passes and as IPA profile
happens before it we see the warning.

One possible solution would be to mark all cgraph_nodes with missing profile
and emit warnings later after we have final symbols.

Honza?

[Bug ipa/87706] Inlined functions trigger invalid -Wmissing-profile warning

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Note that it causes bazillion of warnings for GCC PGO bootstrap.

[Bug tree-optimization/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|c++ |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |8.3

--- Comment #10 from Richard Biener  ---
--param vect-max-version-for-alias-checks=0 also avoids the issue.  So it's

/usr/include/c++/8/bits/stl_uninitialized.h:82:23: note: loop vectorized
/usr/include/c++/8/bits/stl_uninitialized.h:82:23: note: loop versioned for
vectorization because of possible aliasing

that breaks things.  This is vectorizing of

   [local count: 163894221]:
  # __first$_M_current_62 = PHI <_100(82), _84(86)>
  # __cur_12 = PHI 
  MEM[(struct  &)__cur_12] ={v} {CLOBBER};
  MEM[(struct  &)__cur_12] ={v} {CLOBBER};
  _82 = MEM[(int * const &)__first$_M_current_62];
  MEM[(int * &)__first$_M_current_62] = 0B;
  MEM[(struct  &)__cur_12] ={v} {CLOBBER};
  MEM[(struct _Head_base *)__cur_12]._M_head_impl = _82;
  _83 = __first$_M_current_62->second;
  __cur_12->second = _83;
  _84 = __first$_M_current_62 + 16;
  __cur_85 = __cur_12 + 16;
  if (_67 != _84)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 145865857]:
  goto ; [100.00%]

where we end up interchanging the read and write from/to MEM[(int * const
&)__first$_M_current_62].  There are SLP and non-SLP stmts here,
the SLP ones being

stl_uninitialized.h:82:23: note: Final SLP tree for instance:
stl_uninitialized.h:82:23: note: node
stl_uninitialized.h:82:23: note:stmt 0 MEM[(struct _Head_base
*)__cur_12]._M_head_impl = _82;
stl_uninitialized.h:82:23: note:stmt 1 __cur_12->second = _83;
stl_uninitialized.h:82:23: note: node
stl_uninitialized.h:82:23: note:stmt 0 _82 = MEM[(int * const
&)__first$_M_current_62];
stl_uninitialized.h:82:23: note:stmt 1 _83 =
__first$_M_current_62->second;

[Bug fortran/87705] Compilation error when dealing with sub derived types

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed from 4.8 up to trunk (9.0). The test compiles with 4.3.6.

Reduced test:

module test_mod

  implicit none

  type :: temp_val_prop
character(len=9):: qlevel ! gfortran compiler error
integer(4)  :: n
  end type temp_val_prop

  type material_data
type(temp_val_prop) :: emodul
  end type

end module test_mod

program main

  use :: test_mod
  implicit none

  type(material_data) :: mat(100)
  data mat(1)%emodul%n /  15 /

end program main

[Bug tree-optimization/87665] [8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener  ---
C testcase that is miscompiled:

struct X { long x; long y; };

struct X a[1024], b[1024];

void foo ()
{
  for (int i = 0; i < 1024; ++i)
{
  long tem = a[i].x;
  a[i].x = 0;
  b[i].x = tem;
  b[i].y = a[i].y;
}
}

int main()
{
  for (int i = 0; i < 1024; ++i)
a[i].x = i;
  foo ();
  for (int i = 0; i < 1024; ++i)
if (b[i].x != i)
  __builtin_abort();
  return 0;
}

[Bug tree-optimization/87665] [6/7/8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work|7.3.0   |5.4.0
   Target Milestone|8.3 |6.5
Summary|[8/9 Regression] gcc HEAD   |[6/7/8/9 Regression] gcc
   |(svn: 265340) breaks|HEAD (svn: 265340) breaks
   |elements on resize  |elements on resize

--- Comment #12 from Richard Biener  ---
GCC 5 works, the rest not.  Somebody bisect again please.

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Oct 23 13:10:26 2018
New Revision: 265423

URL: https://gcc.gnu.org/viewcvs?rev=265423&root=gcc&view=rev
Log:
PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors

Using a delegating constructor to implement these constructors means
that they instantiate the destructor, which requires the element_type to
be complete. In C++11 and C++14 they were specified to be delegating,
but that was changed as part of LWG 2801 so in C++17 they don't require
a complete type (as was intended all along).

PR libstdc++/87704
* include/bits/unique_ptr.h (unique_ptr::unique_ptr(nullptr_t)): Do
not delegate to default constructor.
(unique_ptr::unique_ptr(nullptr_t)): Likewise.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/unique_ptr/cons/incomplete.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/bits/unique_ptr.h

[Bug tree-optimization/87665] [6/7/8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
r229172.

[Bug tree-optimization/87665] [6/7/8/9 Regression] gcc HEAD (svn: 265340) breaks elements on resize

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
index 4b3711442e6..a24e1853e03 100644
--- a/gcc/tree-vect-data-refs.c
+++ b/gcc/tree-vect-data-refs.c
@@ -210,16 +210,26 @@ vect_preserves_scalar_order_p (dr_vec_info *dr_info_a,
dr_vec_info *dr_info_b)
 return true;

   /* STMT_A and STMT_B belong to overlapping groups.  All loads in a
- group are emitted at the position of the first scalar load and all
+ group are emitted at the position of the last scalar load and all
  stores in a group are emitted at the position of the last scalar store.
- Thus writes will happen no earlier than their current position
- (but could happen later) while reads will happen no later than their
- current position (but could happen earlier).  Reordering is therefore
- only possible if the first access is a write.  */
-  stmtinfo_a = vect_orig_stmt (stmtinfo_a);
-  stmtinfo_b = vect_orig_stmt (stmtinfo_b);
-  stmt_vec_info earlier_stmt_info = get_earlier_stmt (stmtinfo_a, stmtinfo_b);
-  return !DR_IS_WRITE (STMT_VINFO_DATA_REF (earlier_stmt_info));
+ Compute that position and check whether the resulting order matches
+ the current one.  */
+  stmt_vec_info last_a = DR_GROUP_FIRST_ELEMENT (stmtinfo_a);
+  if (last_a)
+for (stmt_vec_info s = DR_GROUP_NEXT_ELEMENT (last_a); s;
+s = DR_GROUP_NEXT_ELEMENT (s))
+  last_a = get_later_stmt (last_a, s);
+  else
+last_a = stmtinfo_a;
+  stmt_vec_info last_b = DR_GROUP_FIRST_ELEMENT (stmtinfo_b);
+  if (last_b)
+for (stmt_vec_info s = DR_GROUP_NEXT_ELEMENT (last_b); s;
+s = DR_GROUP_NEXT_ELEMENT (s))
+  last_b = get_later_stmt (last_b, s);
+  else
+last_b = stmtinfo_b;
+  return ((get_later_stmt (last_a, last_b) == last_a)
+ == (get_later_stmt (stmtinfo_a, stmtinfo_b) == stmtinfo_a));
 }

 /* A subroutine of vect_analyze_data_ref_dependence.  Handle

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
Please provide the (preferrably small) self contained runtime testcase that
exposes the bug. Some instructions can be found on [1].

[1] https://gcc.gnu.org/bugs/

[Bug libstdc++/87527] uniform_real_distribution can't generate the full range of finite floating point numbers

[fergus.henderson at gmail dot com]

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

Fergus Henderson  changed:

   What|Removed |Added

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

--- Comment #1 from Fergus Henderson  ---
It turns out that this example program is not conforming, because it violates a
requirement.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

29.6.8.2.2 Class template uniform_real_distribution [rand.dist.uni.real]

explicit uniform_real_distribution(RealType a = 0.0, RealType b = 1.0

Requires: a ≤ b and b − a ≤ numeric_limits::max().

The requirement "b − a ≤ numeric_limits::max()." is violated.

[Bug fortran/87707] New: actual argument to assumed type dummy argument (i.e. type(*)) cannot have type-bound procedures

[m.diehl at mpie dot de]

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

Bug ID: 87707
   Summary: actual argument to assumed type dummy argument (i.e.
type(*)) cannot have type-bound procedures
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.diehl at mpie dot de
  Target Milestone: ---

gfortran (confirmed for 6.3.0 and 8.2.1) rejects passing in a derived type to a
subroutine with a type(*) dummy argument with the following message:

Error: Actual argument at (1) to assumed-type dummy is of derived type with
type-bound or FINAL procedures

The documentation on
https://www.ibm.com/support/knowledgecenter/SSAT4T_15.1.4/com.ibm.xlf1514.lelinux.doc/language_ref/assumedtypeobj.html
implies that this is the expected behavior (An assumed-type dummy argument
cannot correspond to an actual argument of a derived type that has type
parameters, type-bound procedures, or final subroutines.). However, I cannot
confirm this from https://j3-fortran.org/doc/year/18/18-007r1.pdf. See also the
discussion in the Intel developer zone:
https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/798744
(Intel Fortran accepts the code). Probably this restriction was part of an
earlier draft.
I compile with '-std=f2008ts' or '-std=f2018'.

This is my test code (need to be split into 2 files)
program main
  use context_module
  implicit none
  type(context_type) :: context

  call test(context) 

end program main

module context_module

  implicit none

  type ::  context_type
integer, private :: foo

contains
  procedure, public :: init => context_init
   end type context_type

contains

  subroutine context_init(self, foo)
   implicit none
class(context_type), intent(in out) :: self
integer, intent(in) :: foo
self%foo = foo
  end subroutine context_init


 subroutine test(context)
   implicit none
   type(*) :: context
   write(6,*) 'hello world'   
 end subroutine

end module context_module

[Bug rtl-optimization/87708] New: ira-shrinkwrap-prep-[12].c testcases fail after r265398

[segher at gcc dot gnu.org]

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

Bug ID: 87708
   Summary: ira-shrinkwrap-prep-[12].c testcases fail after
r265398
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

These fail on many targets, and simply because the
split_live_ranges_for_shrink_wrap code can only move direct copies from the
hard argument registers, but they now usually are move to a pseudo first.

Ideally this code will improve, but in the meantime, maybe we should xfail
the test?

[Bug c++/87709] New: c++17 class template argument deduction not working in a very specific case

[bmburstein at gmail dot com]

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

Bug ID: 87709
   Summary: c++17 class template argument deduction not working in
a very specific case
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bmburstein at gmail dot com
  Target Milestone: ---

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

The test case is attached. It has no includes and so I am attaching the *.cpp
file as per https://gcc.gnu.org/bugs/

I am compiling with -std=c++17

Output of g++ -v:

# g++ -v
Using built-in specs.
COLLECT_GCC=C:\MyProgs\msys64\mingw64\bin\g++.exe
COLLECT_LTO_WRAPPER=C:/MyProgs/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-8.2.0/configure --prefix=/mingw64
--with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include
--libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64
--with-tune=generic --enable-languages=ada,c,lto,c++,objc,obj-c++,fortran
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts=yes --enable-libstdcxx-time=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check
--enable-lto --enable-libgomp --disable-multilib --enable-checking=release
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64
--with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64
--with-pkgversion='Rev3, Built by MSYS2 project'
--with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 8.2.0 (Rev3, Built by MSYS2 project)


I tried with another build and got the same results. This one gave:

# g++ -v
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-8.2.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-8.2.0/configure --prefix=/opt/wandbox/gcc-8.2.0
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-8.2.0/lib,-rpath,/opt/wandbox/gcc-8.2.0/lib64,-rpath,/opt/wandbox/gcc-8.2.0/lib32
--enable-lto
Thread model: posix
gcc version 8.2.0 (GCC)

Welcome to Keystone Secure Email

[SecureMailer1]

Secure Messaging Password Notification


This is a password notification message for the Keystone Human Services Secure 
Messaging service.

You received this notification for one of the following reasons:

1. You have been sent a secure message.
2. The system administrator has arranged access to the Secure Messaging service 
for you.
3. The system administrator has reset your password.
4. You requested a password reminder.

Please connect to the Secure Messaging service by clicking 
https://protect-us.mimecast.com/s/jlI6CjROnRUPz1MtW8NRi. You may be required to 
change your password immediately following login.

You may be required to change your password immediately following login.

Secure Messaging:
https://protect-us.mimecast.com/s/jlI6CjROnRUPz1MtW8NRi

Login Information:

Email Address: gcc-bugs@gcc.gnu.org

Password: iTRWBVo8

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #15 from Tom de Vries  ---
Author: vries
Date: Tue Oct 23 15:01:12 2018
New Revision: 265426

URL: https://gcc.gnu.org/viewcvs?rev=265426&root=gcc&view=rev
Log:
backport "[c++] Fix DECL_BY_REFERENCE of clone parms"

Consider test.C compiled at -O0 -g:
...
class string {
public:
  string (const char *p) { this->p = p ; }
  string (const string &s) { this->p = s.p; }

private:
  const char *p;
};

class foo {
public:
  foo (string dir_hint) {}
};

int
main (void)
{
  std::string s = "This is just a string";
  foo bar(s);
  return 0;
}
...

When parsing foo::foo, the dir_hint parameter gets a DECL_ARG_TYPE of
'struct string & restrict'.  Then during finish_struct, we call
clone_constructors_and_destructors and create clones for foo::foo, and
set the DECL_ARG_TYPE in the same way.

Later on, during finish_function, cp_genericize is called for the original
foo::foo, which sets the type of parm dir_hint to DECL_ARG_TYPE, and sets
DECL_BY_REFERENCE of dir_hint to 1.

After that, during maybe_clone_body update_cloned_parm is called with:
...
(gdb) call debug_generic_expr (parm.typed.type)
struct string & restrict
(gdb) call debug_generic_expr (cloned_parm.typed.type)
struct string
...
The type of the cloned_parm is then set to the type of parm, but
DECL_BY_REFERENCE is not set.

When doing cp_genericize for the clone later on,
TREE_ADDRESSABLE (TREE_TYPE ()) is no longer true for the updated type for
the parm, so DECL_BY_REFERENCE is not set there either.

The missing DECL_BY_REFERENCE on cloned_parm causes incorrect debug info to be
generated.

This patch fixes the problem by copying DECL_BY_REFERENCE in
update_cloned_parm.

Bootstrapped and reg-tested on x86_64.

2018-10-23  Tom de Vries  

backport from trunk:
2018-07-31  Tom de Vries  

PR debug/86687
* optimize.c (update_cloned_parm): Copy DECL_BY_REFERENCE.

* g++.dg/guality/pr86687.C: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/guality/pr86687.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/optimize.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #16 from Tom de Vries  ---
Author: vries
Date: Tue Oct 23 15:06:17 2018
New Revision: 265427

URL: https://gcc.gnu.org/viewcvs?rev=265427&root=gcc&view=rev
Log:
backport "[c++] Fix DECL_BY_REFERENCE of clone parms"

Consider test.C compiled at -O0 -g:
...
class string {
public:
  string (const char *p) { this->p = p ; }
  string (const string &s) { this->p = s.p; }

private:
  const char *p;
};

class foo {
public:
  foo (string dir_hint) {}
};

int
main (void)
{
  std::string s = "This is just a string";
  foo bar(s);
  return 0;
}
...

When parsing foo::foo, the dir_hint parameter gets a DECL_ARG_TYPE of
'struct string & restrict'.  Then during finish_struct, we call
clone_constructors_and_destructors and create clones for foo::foo, and
set the DECL_ARG_TYPE in the same way.

Later on, during finish_function, cp_genericize is called for the original
foo::foo, which sets the type of parm dir_hint to DECL_ARG_TYPE, and sets
DECL_BY_REFERENCE of dir_hint to 1.

After that, during maybe_clone_body update_cloned_parm is called with:
...
(gdb) call debug_generic_expr (parm.typed.type)
struct string & restrict
(gdb) call debug_generic_expr (cloned_parm.typed.type)
struct string
...
The type of the cloned_parm is then set to the type of parm, but
DECL_BY_REFERENCE is not set.

When doing cp_genericize for the clone later on,
TREE_ADDRESSABLE (TREE_TYPE ()) is no longer true for the updated type for
the parm, so DECL_BY_REFERENCE is not set there either.

The missing DECL_BY_REFERENCE on cloned_parm causes incorrect debug info to be
generated.

This patch fixes the problem by copying DECL_BY_REFERENCE in
update_cloned_parm.

Bootstrapped and reg-tested on x86_64.

2018-10-23  Tom de Vries  

backport from trunk:
2018-07-31  Tom de Vries  

PR debug/86687
* optimize.c (update_cloned_parm): Copy DECL_BY_REFERENCE.

* g++.dg/guality/pr86687.C: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/guality/pr86687.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/optimize.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug fortran/87707] actual argument to assumed type dummy argument (i.e. type(*)) cannot have type-bound procedures

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
Confirmed. AFAIU the standards this requires f2018 and is not yet implemented
in gfortran. The code compiles if I replace type(*) with class(*).

RE: Secure Messaging !!

[Hutson, Victoria]

Secure Messaging Notification


You have been sent a secure message by Keystone Human Services.

It has been classified as sensitive and may only be accessed from within this 
Secure Messaging service.

View the message by clicking here:

https://protect-us.mimecast.com/s/P8GbCyPJmPtkM4XTZrW6j


If this is the first time you have received a secure message from this company, 
a password will be emailed to you separately.

If you did not receive your password or are experiencing trouble logging in, 
click here to request a new password:

https://protect-us.mimecast.com/s/fIihCzpxnpU92rghXgKAl

[Bug c++/87697] Casting a base class to derived gives no warning

[jynelson at email dot sc.edu]

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

--- Comment #2 from jynelson at email dot sc.edu ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to jynelson from comment #0)
> > Casting a base class to a derived class gives no warning, even with -Wall
> > -Werror enabled. I've been told on IRC that this sort of cast is undefined
> > behaviour according to spec if neither class is virtual.
> 
> It has nothing to do with whether anything is virtual or not. The relevant
> standard wording is:
> 
>If the object of type “cv1 B” is actually a base class subobject of an
>object of type D, the result refers to the enclosing object of type D.
>Otherwise, the behavior is undefined.

Found this at http://www.open-std.org/jtc1/sc22/open/n2356/expr.html, good to
know it's undefined for sure.

> 
> > If that is the
> > case, it would be nice to have a warning.
> 
> It's only possible to warn when the compiler can statically prove that the
> pointer really isn't pointing to a derived. That's possible in your example
> because it was created right there by the 'new c1' expression, but that is a
> very silly thing to do and surely nobody does it in real code. Generally a
> function just gets passed a pointer to a base class, and can't see its
> construction, so can't tell if the cast is valid or not.

I would argue the compiler is in the best place to statically prove an invalid
downcast,
since it knows the types of every object. I'm not sure how functions relate to
this,
but if it's easier to go by a function's type signature, I think it would be
better
to warn on *any* downcast, and make the developer specifically override that
warning.
Part of the reason I opened the bug is I didn't know this was illegal at first.

> 
> > If that isn't the case, there are several more questions that arise, like
> > `why does c1 have access to c2` and `why can the const value c2::x be
> > accessed without be initialized`?
> 
> It doesn't, because there's no c2 object constructed. Obviously the code is
> silly and broken.

Of course it's silly and broken, it's an example.
In a larger project, where there's an intermediary object defined many lines
away
from this assignment, it would be much easier for this to slip by even with
code review
on the assumption that the original was the correct class.
something like this:

```
c1 original;
// ... a bunch of code ...
// looks reasonable
derived *obj = static_cast( &original );
```

This is exacerbated by static cast never giving a warning.
This is OK for integers and floats where downcasts are well-defined,
but for undefined behaviour there should at least be a warning.

I would actually argue it should be an error, the same way
casting completely different types is an error
(https://stackoverflow.com/questions/14380275).
I'll attach some code that compiles (except for the error) as an example.

> 
> I don't think a compiler warning would be worthwhile, because it would only
> warn about code which is obviously wrong by inspection i.e. which should be
> caught by the most cursory code review.

I disagree that that it would have to be cursory.

> The general case can be diagnosed through runtime instrumentation but
> -fsanitize=undefined only gives a runtime error for an invalid static_cast
> involving polymorphic types (because the type identification is linked to
> the vtable).
> 
> -fsanitize=address does diagnose that accessing members of c2 performs an
> out-of-bounds read:
> 

This is useful, but a little obscure, I doubt it's widely used.

[Bug c++/87697] Casting a base class to derived gives no warning

[jynelson at email dot sc.edu]

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

--- Comment #3 from jynelson at email dot sc.edu ---
Created attachment 44884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44884&action=edit
Casting unrelated types gives an error

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Author: redi
Date: Tue Oct 23 15:29:03 2018
New Revision: 265428

URL: https://gcc.gnu.org/viewcvs?rev=265428&root=gcc&view=rev
Log:
PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors

Using a delegating constructor to implement these constructors means
that they instantiate the destructor, which requires the element_type to
be complete. In C++11 and C++14 they were specified to be delegating,
but that was changed as part of LWG 2801 so in C++17 they don't require
a complete type (as was intended all along).

PR libstdc++/87704
* include/bits/unique_ptr.h (unique_ptr::unique_ptr(nullptr_t)): Do
not delegate to default constructor.
(unique_ptr::unique_ptr(nullptr_t)): Likewise.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: New test.

Added:
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/unique_ptr/cons/incomplete.cc
Modified:
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/bits/unique_ptr.h

[Bug libstdc++/87527] uniform_real_distribution can't generate the full range of finite floating point numbers

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
$ g++ -D_GLIBCXX_ASSERTIONS uniform_real.cc 
$ ./a.out
a.out: uniform_real.cc:13: int main(): Assertion `x >= low && x < high' failed.

[Bug libstdc++/87527] uniform_real_distribution can't generate the full range of finite floating point numbers

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Oh sorry, you provided that message yourself. That assertion is there to
enforce the precondition you found.

[Bug c/87710] New: Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[dilyan.palauzov at aegee dot org]

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

Bug ID: 87710
   Summary: Explicitly mentioned libraries by -lx are not in the
DT_NEEDED list
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

Calling “make install” without DESTDIR after building libc-2.28 calls
eventually glibc-2.28/srcribts/test-installation.pl . It creates the file
test-prg7044.c with content:

#include 
#include 
int main(void) {
  printf ("Your new glibc installation seems to be ok.\n");
  exit (0);
}

Then calls “gcc /src/glibc228/test-prg7044.c -lc -lBrokenLocale -lpthread
-lcrypt -ldl -lgcc_s -lnsl -lutil -lnss_dns -lnss_compat -lmvec -lresolv
-lnss_db -lm -lnss_files -lrt -lnss_hesiod -lanl -o
/src/glibc228/test-prg7044“, and chechs whether „ldd test-prg7044” contains
BrokenLocale.  On my system the comman above invoked with -v prints:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --enable-threads=posix --enable-nls
--disable-multilib --enable-interpreter --with-system-zlib
--enable-libgcj-multifile --enable-languages=all --enable-targets=all
--with-system-unwind --without-x --with-linker-hash-style=gnu --enable-shared
--with-build-config='bootstrap-lto bootstrap-O3'
Thread model: posix
gcc version 7.3.1 20181013 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/cc1 -quiet -v -imultiarch
x86_64-linux-gnu /src/glibc228//test-prg7044.c -quiet -dumpbase test-prg7044.c
-mtune=generic -march=x86-64 -auxbase test-prg7044 -version -o /tmp/ccDutEqy.s
GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C11 (GCC) version 7.3.1 20181013 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20181013, GMP version 6.1.2, MPFR
version 4.0.0, MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8ff192ae53ef780b032a40b890e7c233
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'

/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/as
-v --64 -o /tmp/ccZTddK3.o /tmp/ccDutEqy.s
GNU assembler version 2.31.51 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.31.51.20181019
COMPILER_PATH=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/libexec/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/bin/
LIBRARY_PATH=/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../x86_64-linux-gnu/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/lib/:/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' '/src/glibc228//test-prg7044' '-mtune=generic'
'-march=x86-64'
 /usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/collect2 -plugin
/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/liblto_plugin.so
-plugin-opt=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccLuMS4y.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -o /src/glibc228//test-prg7044
/usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o
/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/crtbegin.o
-L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1
-L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../x86_64-linux-gnu
-L/usr/local/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib6

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed, reduced:

template 
struct lit {
  lit(T) { }
};

template 
int operator+(lit, lit) {
  return 0;
}

auto r2 = (lit(0)) + lit(0);



11 | auto r2 = (lit(0)) + lit(0);
   |^~~
ctad.cc:2:8: note: 'template struct lit' declared here
2 | struct lit {
  |^~~

[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations

[romain.geissler at amadeus dot com]

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

--- Comment #5 from Romain Geissler  ---
Reduced test case:

> cat test.c
void f() {}

> cat test2.c
void f();

void g()
{
f();
}

> cat test.ver
{
local: *;
};

> gcc -g -flto -ffat-lto-objects -fPIC -o test.fat-objects.o -c test.c
> gcc -g -flto -ffat-lto-objects -fPIC -o test2.fat-objects.o -c test2.c
> gcc -g -flto -ffat-lto-objects -fPIC -shared -o test.fat-objects.so 
> test.fat-objects.o test2.fat-objects.o -Wl,-version-script=test.ver
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test.slim-objects.o -c test.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -o test2.slim-objects.o -c test2.c
> gcc -g -flto -fno-fat-lto-objects -fPIC -shared -o test.slim-objects.so 
> test.slim-objects.o test2.slim-objects.o -Wl,-version-script=test.ver


> readelf -a test.fat-objects.so|grep ABS
5:  0 NOTYPE  GLOBAL DEFAULT  ABS f  <--- unexpected
symbol here
29:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
37:  0 FILELOCAL  DEFAULT  ABS
40:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
42:  0 FILELOCAL  DEFAULT  ABS
77:  0 FILELOCAL  DEFAULT  ABS

> readelf -a test.slim-objects.so|grep ABS
29:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
37:  0 FILELOCAL  DEFAULT  ABS
40:  0 FILELOCAL  DEFAULT  ABS crtstuff.c
42:  0 FILELOCAL  DEFAULT  ABS
65:  0 FILELOCAL  DEFAULT  ABS

[Bug lto/87698] [lto] Shared library build with -ffat-lto-objects generates extra global absolute symbol relocations

[romain.geissler at amadeus dot com]

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

--- Comment #6 from Romain Geissler  ---
Versions of gcc and ld:

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

> ld --version
GNU ld (GNU Binutils) 2.31.1.20181011
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

[Bug c++/86439] CTAD with deleted copy constructor fails due to deduction-guide taking by value

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-10-23
 Ever confirmed|0   |1

[Bug c++/87709] c++17 class template argument deduction not working in a very specific case

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Oops, I missed the first line of the diagnostic. The error from trunk is:


ctad.cc:11:12: error: missing template arguments after 'lit'
11 | auto r2 = (lit(0)) + lit(0);
   |^~~
ctad.cc:2:8: note: 'template struct lit' declared here
2 | struct lit {
  |^~~

[Bug libstdc++/87704] [6/7/8/9 Regression] unique_ptr(nullptr_t) requires T to be complete

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Author: redi
Date: Tue Oct 23 15:55:05 2018
New Revision: 265429

URL: https://gcc.gnu.org/viewcvs?rev=265429&root=gcc&view=rev
Log:
PR libstdc++/87704 fix unique_ptr(nullptr_t) constructors

Using a delegating constructor to implement these constructors means
that they instantiate the destructor, which requires the element_type to
be complete. In C++11 and C++14 they were specified to be delegating,
but that was changed as part of LWG 2801 so in C++17 they don't require
a complete type (as was intended all along).

PR libstdc++/87704
* include/bits/unique_ptr.h (unique_ptr::unique_ptr(nullptr_t)): Do
not delegate to default constructor.
(unique_ptr::unique_ptr(nullptr_t)): Likewise.
* testsuite/20_util/unique_ptr/cons/incomplete.cc: New test.

Added:
   
branches/gcc-7-branch/libstdc++-v3/testsuite/20_util/unique_ptr/cons/incomplete.cc
Modified:
branches/gcc-7-branch/libstdc++-v3/ChangeLog
branches/gcc-7-branch/libstdc++-v3/include/bits/unique_ptr.h

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The linker is part of binutils. not gcc.

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[dilyan.palauzov at aegee dot org]

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

--- Comment #2 from Дилян Палаузов  ---
I tried this with -fuse-ld=gold and -fuse-ld=bfd .

If you mean the problem is in both ld.bfd and ld.gold, I will report it there.

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #3 from Jonathan Wakely  ---
GCC has nothing to do with adding DT_NEEDED tags, the linker is responsible for
it (whether ld.bfd or ld.gold).

[Bug c/87710] Explicitly mentioned libraries by -lx are not in the DT_NEEDED list

[dilyan.palauzov at aegee dot org]

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

--- Comment #4 from Дилян Палаузов  ---
Moved to 

for ld.bfd: https://sourceware.org/bugzilla/show_bug.cgi?id=23811
for ld.gold: https://sourceware.org/bugzilla/show_bug.cgi?id=23812

[Bug fortran/40678] Using a function as variable: ICE with 4.3, accepts invalid with 4.4/4.5

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #4 from G. Steinmetz  ---

No ICE with versions configured with --enable-checking=yes or =release.


$ cat z1.f90
module m
   implicit none
contains
   subroutine s
  logical :: f
  f = g !()
   end
   logical function g()
  g = .true.
   end
end


$ gfortran-9-20181021-chk -c z1.f90

[Bug fortran/40678] Using a function as variable: ICE with 4.3, accepts invalid with 4.4/4.5

[gs...@t-online.de]

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

--- Comment #5 from G. Steinmetz  ---


Following program compiles smoothly and runs ...
Invocations of function h need obligatoric parenthesis, and a dummy.
On the other hand, "implicit none" would force variable h to be
explicitly declared.


$ cat z2.f90
module m
   implicit none
contains
   logical function f()
  f = h
   end function
   logical function g()
  g = .not. h
   end function
   logical function h(x)
  logical, intent(in) :: x
  h = .not. x
   end function
end
program p
   use m
   print *, f()
   print *, g()  ! .not. f()
end


$ gfortran-9-20181021-chk -Wall -Wextra -fcheck=all -static-libgfortran -g
z2.f90
$ a.out
 F
 F

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[gs...@t-online.de]

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

--- Comment #18 from G. Steinmetz  ---

Update and simplified a bit, ICEs down to at least version 5 :


$ cat z1.f90
module m
   type t
  sequence
  real :: a
  real :: b = 2.0
   end type
   type(t) :: z
   data z%a /3.0/
end


$ cat z2.f90
program p
   type t
  real :: a
  real :: b = 2.0
   end type
   type(t) :: z
   data z%a /3.0/
end


$ gfortran-9-20181021 -c z2.f90
z2.f90:1:0:

1 | program p
  |
internal compiler error: Segmentation fault
0xb1c86f crash_signal
../../gcc/toplev.c:325
0x6ec0cd gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.c:7865
0x6fca91 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:7027
0x6e1647 gfc_get_symbol_decl(gfc_symbol*)
../../gcc/fortran/trans-decl.c:1824
0x6e3ec7 generate_local_decl
../../gcc/fortran/trans-decl.c:5596
0x6a80f2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x6e4fe4 generate_local_vars
../../gcc/fortran/trans-decl.c:5796
0x6e4fe4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6440
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization

[gs...@t-online.de]

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

--- Comment #19 from G. Steinmetz  ---

Adding a "parameter" attribute :


$ cat z8.f90
program p
   type t
  real :: a
  real :: b = 2.0
   end type
   type(t), parameter :: z = t(4.0, 5.0)
   data z%a /3.0/
end


$ cat z9.f90
program p
   type t
  real :: a
   end type
   type(t), parameter :: z = t(4.0)
   data z%a /3.0/
end


$ gfortran-9-20181021 -c z9.f90
z9.f90:7:0:

7 | end
  |
internal compiler error: Segmentation fault
0xb1c86f crash_signal
../../gcc/toplev.c:325
0x6d9481 check_constant_initializer
../../gcc/fortran/trans-decl.c:5198
0x6d9ef4 gfc_emit_parameter_debug_info
../../gcc/fortran/trans-decl.c:5262
0x6a80f2 do_traverse_symtree
../../gcc/fortran/symbol.c:4151
0x6e53fa gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6671
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204


Adding "pointer" instead of "parameter" gives pr50410 comment 0.

[Bug fortran/87711] New: ICE in gfc_trans_transfer, at fortran/trans-io.c:2676

[gs...@t-online.de]

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

Bug ID: 87711
   Summary: ICE in gfc_trans_transfer, at fortran/trans-io.c:2676
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least 5 :


$ cat z1.f90
program p
   character(3) :: c(2) = ['abc', 'xyz']
   print *, len_trim(c, 4)
end


$ cat z2.f90
program p
   character(3) :: c(2) = ['abc', 'xyz']
   print *, len_trim(c, 8)
end


$ gfortran-9-20181021 -c z1.f90
z1.f90:3:0:

3 |print *, len_trim(c, 4)
  |
internal compiler error: in gfc_trans_transfer, at fortran/trans-io.c:2676
0x718686 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.c:2676
0x6bdbc7 trans_code
../../gcc/fortran/trans.c:2038
0x715dae build_dt
../../gcc/fortran/trans-io.c:2026
0x6bdba7 trans_code
../../gcc/fortran/trans.c:2010
0x6e51c4 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6505
0x673426 translate_all_program_units
../../gcc/fortran/parse.c:6125
0x673426 gfc_parse_file()
../../gcc/fortran/parse.c:6328
0x6ba3ff gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug target/87702] [6/7/8/9 Regression] Segfault in glibc if compiled with -march=amdfam10 -O2 (x86)

[mihail.zenkov at gmail dot com]

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

--- Comment #2 from Mihail Zenkov  ---
I'm not sure how to reproduce this regressions without rebuilding glibc. But I
can provide prebuilded glibc for test.

http://www.knk.uwebweb.com/glibc-segfault.tar.xz

To reproduce just unpack and run ./test.sh. You should see:

./test.sh
Regression 1
busybox   ld.so libc_regression_1.so 
libc_regression_2.so  test.sh
BusyBox v1.29.3 (2018-10-18 20:28:02 BY) multi-call binary.

Usage: rm [-irf] FILE...

Remove (unlink) FILEs

-i  Always prompt before removing
-f  Never prompt
-R,-r   Recurse
Segmentation fault


Regression 2
busybox   ld.so libc_regression_1.so 
libc_regression_2.so  test.sh
Segmentation fault

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

--- Comment #17 from Tom de Vries  ---
Author: vries
Date: Tue Oct 23 17:16:55 2018
New Revision: 265431

URL: https://gcc.gnu.org/viewcvs?rev=265431&root=gcc&view=rev
Log:
backport "[c++] Fix DECL_BY_REFERENCE of clone parms"

Consider test.C compiled at -O0 -g:
...
class string {
public:
  string (const char *p) { this->p = p ; }
  string (const string &s) { this->p = s.p; }

private:
  const char *p;
};

class foo {
public:
  foo (string dir_hint) {}
};

int
main (void)
{
  std::string s = "This is just a string";
  foo bar(s);
  return 0;
}
...

When parsing foo::foo, the dir_hint parameter gets a DECL_ARG_TYPE of
'struct string & restrict'.  Then during finish_struct, we call
clone_constructors_and_destructors and create clones for foo::foo, and
set the DECL_ARG_TYPE in the same way.

Later on, during finish_function, cp_genericize is called for the original
foo::foo, which sets the type of parm dir_hint to DECL_ARG_TYPE, and sets
DECL_BY_REFERENCE of dir_hint to 1.

After that, during maybe_clone_body update_cloned_parm is called with:
...
(gdb) call debug_generic_expr (parm.typed.type)
struct string & restrict
(gdb) call debug_generic_expr (cloned_parm.typed.type)
struct string
...
The type of the cloned_parm is then set to the type of parm, but
DECL_BY_REFERENCE is not set.

When doing cp_genericize for the clone later on,
TREE_ADDRESSABLE (TREE_TYPE ()) is no longer true for the updated type for
the parm, so DECL_BY_REFERENCE is not set there either.

The missing DECL_BY_REFERENCE on cloned_parm causes incorrect debug info to be
generated.

This patch fixes the problem by copying DECL_BY_REFERENCE in
update_cloned_parm.

Bootstrapped and reg-tested on x86_64.

2018-10-23  Tom de Vries  

backport from trunk:
2018-07-31  Tom de Vries  

PR debug/86687
* optimize.c (update_cloned_parm): Copy DECL_BY_REFERENCE.

* g++.dg/guality/pr86687.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/guality/pr86687.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/optimize.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug debug/86687] Wrong debug information for string types passed as parameters

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #18 from Tom de Vries  ---
patch with test-case committed to trunk, backported to release branches 6,7,8.

Marking resolved-fixed.