Re: [PATCH v3] [aarch64] Add CPU support for Ampere Computing's eMAG.

[Andrew Pinski]

One small comment.

On Tue, Nov 20, 2018 at 10:01 AM Christoph Muellner
 wrote:
>
> Tested with "make check" and no regressions found.
>
> This patch depends on the struct xgene1_prefetch_tune,
> which has been acknowledged already:
> https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00985.html
>
> *** gcc/ChangeLog ***
>
> 2018-xx-xx  Christoph Muellner 
>
> * config/aarch64/aarch64-cores.def: Define emag.
> * config/aarch64/aarch64-tune.md: Regenerated with emag.
> * config/aarch64/aarch64.c (emag_tunings): New struct.
> * doc/invoke.texi: Document mtune value.
>
> Signed-off-by: Christoph Muellner 
> ---
>  gcc/config/aarch64/aarch64-cores.def |  3 +++
>  gcc/config/aarch64/aarch64-tune.md   |  2 +-
>  gcc/config/aarch64/aarch64.c | 25 +
>  gcc/doc/invoke.texi  |  2 +-
>  4 files changed, 30 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/config/aarch64/aarch64-cores.def 
> b/gcc/config/aarch64/aarch64-cores.def
> index 1f3ac56..68cca00 100644
> --- a/gcc/config/aarch64/aarch64-cores.def
> +++ b/gcc/config/aarch64/aarch64-cores.def
> @@ -61,6 +61,9 @@ AARCH64_CORE("thunderxt88",   thunderxt88,   thunderx,  8A, 
>  AARCH64_FL_FOR_ARCH
>  AARCH64_CORE("thunderxt81",   thunderxt81,   thunderx,  8A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
> 0x0a2, -1)
>  AARCH64_CORE("thunderxt83",   thunderxt83,   thunderx,  8A,  
> AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx,  0x43, 
> 0x0a3, -1)
>
> +/* Ampere Computing cores. */
> +AARCH64_CORE("emag",emag,  xgene1,8A,  AARCH64_FL_FOR_ARCH8 
> | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, emag, 0x50, 0x000, 3)

I think you should add a comment to say why this order is required
like above for thunderxt88p1.

Thanks,
Andrew Pinski

> +
>  /* APM ('P') cores. */
>  AARCH64_CORE("xgene1",  xgene1,xgene1,8A,  AARCH64_FL_FOR_ARCH8, 
> xgene1, 0x50, 0x000, -1)
>
> diff --git a/gcc/config/aarch64/aarch64-tune.md 
> b/gcc/config/aarch64/aarch64-tune.md
> index fade1d4..2fc7f03 100644
> --- a/gcc/config/aarch64/aarch64-tune.md
> +++ b/gcc/config/aarch64/aarch64-tune.md
> @@ -1,5 +1,5 @@
>  ;; -*- buffer-read-only: t -*-
>  ;; Generated automatically by gentune.sh from aarch64-cores.def
>  (define_attr "tune"
> -   
> "cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,thunderxt81,thunderxt83,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,ares,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
> +   
> "cortexa35,cortexa53,cortexa57,cortexa72,cortexa73,thunderx,thunderxt88p1,thunderxt88,thunderxt81,thunderxt83,emag,xgene1,falkor,qdf24xx,exynosm1,phecda,thunderx2t99p1,vulcan,thunderx2t99,cortexa55,cortexa75,cortexa76,ares,tsv110,saphira,cortexa57cortexa53,cortexa72cortexa53,cortexa73cortexa35,cortexa73cortexa53,cortexa75cortexa55,cortexa76cortexa55"
> (const (symbol_ref "((enum attr_tune) aarch64_tune)")))
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index f7f88a9..995aafe 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -957,6 +957,31 @@ static const struct tune_params xgene1_tunings =
>_prefetch_tune
>  };
>
> +static const struct tune_params emag_tunings =
> +{
> +  _extra_costs,
> +  _addrcost_table,
> +  _regmove_cost,
> +  _vector_cost,
> +  _branch_cost,
> +  _approx_modes,
> +  6, /* memmov_cost  */
> +  4, /* issue_rate  */
> +  AARCH64_FUSE_NOTHING, /* fusible_ops  */
> +  "16",/* function_align.  */
> +  "16",/* jump_align.  */
> +  "16",/* loop_align.  */
> +  2,   /* int_reassoc_width.  */
> +  4,   /* fp_reassoc_width.  */
> +  1,   /* vec_reassoc_width.  */
> +  2,   /* min_div_recip_mul_sf.  */
> +  2,   /* min_div_recip_mul_df.  */
> +  17,  /* max_case_values.  */
> +  tune_params::AUTOPREFETCHER_OFF, /* autoprefetcher_model.  */
> +  (AARCH64_EXTRA_TUNE_NO_LDP_STP_QREGS),   /* tune_flags.  */
> +  _prefetch_tune
> +};
> +
>  static const struct tune_params qdf24xx_tunings =
>  {
>_extra_costs,
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index e016dce..ac81fb2 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -15288,7 +15288,7 @@ Specify the name of the target processor for which 
> GCC should tune the
>  performance of the code.  Permissible values for this option are:
>  @samp{generic}, @samp{cortex-a35}, @samp{cortex-a53}, @samp{cortex-a55},
>  @samp{cortex-a57}, @samp{cortex-a72}, @samp{cortex-a73}, @samp{cortex-a75},
> -@samp{cortex-a76}, @samp{ares}, @samp{exynos-m1}, @samp{falkor},
> +@samp{cortex-a76}, @samp{ares}, @samp{exynos-m1}, @samp{emag}, @samp{falkor},
>  @samp{qdf24xx}, @samp{saphira}, @samp{phecda}, @samp{xgene1}, @samp{vulcan},
>  @samp{thunderx}, 

Re: [PATCH] x86: Add -march=cascadelake

[Wei Xiao]

Jakub,

Thanks for the comments!
I have addressed them as attached.

Wei

gcc/
* common/config/i386/i386-common.c (processor_names): Add cascadelake.
(processor_alias_table): Add cascadelake.
* config.gcc: Add -march=cascadelake.
* config/i386/driver-i386.c
(host_detect_local_cpu): Detect cascadelake.
* config/i386/i386-c.c (ix86_target_macros_internal): Handle
cascadelake.
* config/i386/i386.c (ix86_cost): Add m_CASCADELAKE.
(processor_cost_table): Add cascadelake.
(get_builtin_code_for_version): Handle cascadelake.
(fold_builtin_cpu): Ditto.
* config/i386/i386.h (TARGET_CASCADELAKE, PROCESSOR_CASCADELAKE): New.
(PTA_CASCADELAKE): Ditto.
* doc/invoke.texi: Add -march=cascadelake.
gcc/testsuite/
* g++.target/i386/mv16.C: Handle new march.
* gcc.target/i386/funcspec-56.inc" Ditto.
libgcc/
* config/i386/cpuinfo.h: Add INTEL_COREI7_CASCADELAKE.
Jakub Jelinek  于2018年11月21日周三 下午7:09写道：
>
> On Wed, Nov 21, 2018 at 06:23:41PM +0800, Wei Xiao wrote:
> > The attached patch added -march=cascadelake for x86.
> > Tested with bootstrap and regression tests on x86_64. No regressions.
> > Is it ok for trunk?
>
> Not a real review, just nits:
>
> index bff4dfb..f7c1c98 100644
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,18 @@
> +2018-11-21 Wei Xiao 
>
> Two spaces after date, two spaces before <.
>
> --- a/gcc/config/i386/driver-i386.c
> +++ b/gcc/config/i386/driver-i386.c
> @@ -857,6 +857,9 @@ const char *host_detect_local_cpu (int argc, const char 
> **argv)
>   /* Assume Ice Lake.  */
>   else if (has_gfni)
> cpu = "icelake-client";
> + /* Assume Cascade Lake.  */
> + if (has_avx512vnni)
> +   cpu = "cascadelake";
>   /* Assume Cannon Lake.  */
>   else if (has_avx512vbmi)
> cpu = "cannonlake";
>
> Doesn't this break handling of all the other CPUs?  I mean, it is a large
>   if (cond) ... else if (cond) ... else if (cond) ... else ...
> but you've added if without else before it into the middle.
>
> Jakub


cascadelake-v2.diff
Description: Binary data

[Bug d/87824] x86_64-linux multilib issues

[ibuclaw at gcc dot gnu.org]

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

--- Comment #14 from ibuclaw at gcc dot gnu.org ---
Author: ibuclaw
Date: Thu Nov 22 06:14:47 2018
New Revision: 266366

URL: https://gcc.gnu.org/viewcvs?rev=266366=gcc=rev
Log:
libphobos/ChangeLog:

2018-11-22  Johannes Pfau  

PR d/87824
* testsuite/libphobos.shared/shared.exp: Set proper path to phobos
library for multilib builds.

Modified:
trunk/libphobos/ChangeLog
trunk/libphobos/testsuite/libphobos.shared/shared.exp

Re: [PATCH, libphobos] Fix libphobos.shared testsuite for multilib tests

[Iain Buclaw]

On Sat, 17 Nov 2018 at 16:07, Johannes Pfau  wrote:
>
> Hi,
>
> the loadDR test in the libphobos.shared testsuite tries to dynamically load 
> the phobos library. The path for the library currently points to the main 
> multilib variant phobos library, causing other multilib variants to fail the 
> test. The attached patch uses $blddir instead of $objdir to fix this issue.
>
> ---
> libphobos/ChangeLog:
>
> 2018-11-17  Johannes Pfau  
>
> PR d/87824
> * testsuite/libphobos.shared/shared.exp: Set proper path to phobos 
> library for multilib builds.
>
> diff --git a/libphobos/testsuite/libphobos.shared/shared.exp 
> b/libphobos/testsuite/libphobos.shared/shared.exp
> index b3bdd..623e06259 100644
> --- a/libphobos/testsuite/libphobos.shared/shared.exp
> +++ b/libphobos/testsuite/libphobos.shared/shared.exp
> @@ -94,7 +94,7 @@ if { [is-effective-target dlopen] && [is-effective-target 
> pthread] } {
>  dg-test "$srcdir/$subdir/host.c" "-ldl -pthread" "$DEFAULT_CFLAGS"
>
>  # Test requires a command line argument to be passed to the program.
> -set libphobos_run_args "$objdir/../src/.libs/libgphobos.so"
> +set libphobos_run_args "${blddir}/src/.libs/libgphobos.${shlib_ext}"
>  dg-test "$srcdir/$subdir/loadDR.c" "-ldl -pthread -g" "$DEFAULT_CFLAGS"
>  set libphobos_run_args ""
>  }

OK.

I've checked and committed this, however perhaps we should get you
write after approval set-up.

-- 
Iain

[Bug c/88144] remove long-obsolete syntax for designated initializers

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> I think one of the reasons why it has not been removed is there is still
> code out there that uses this syntax.
> If anything we should add a warning about it first if we are going to remove
> it.

There's a warning from -Wpedantic at least:

$ /usr/local/bin/gcc -c -Wall -Wextra -pedantic 88144.c
88144.c:2:21: warning: obsolete use of designated initializer with ':'
[-Wpedantic]
2 | struct point p = { x: 69, y: 42 };
  | ^
88144.c:2:28: warning: obsolete use of designated initializer with ':'
[-Wpedantic]
2 | struct point p = { x: 69, y: 42 };
  |^
$

But maybe it should be moved to a different flag that's also enabled by -Wextra
or -Wall or maybe even by default, too, besides just -Wpedantic, though. And
also have a fix-it hint added to use the new (standard) syntax.

[Bug other/704] --help and --version

[egallager at gcc dot gnu.org]

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

--- Comment #16 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #15)
> Author: iains
> Date: Wed Aug 22 12:12:46 2018
> New Revision: 263768
> 
> URL: https://gcc.gnu.org/viewcvs?rev=263768=gcc=rev
> Log:
> Make the gcc-ar,nm, strip tools respond correctly to --help and --version
> when there's no plugin built.
> 
> gcc/
> 
>   PR other/704
>   * gcc-ar.c (main): Don’t try to invoke the plug-in if we’re not
>   building it.
> 
> 
> Modified:
> trunk/gcc/ChangeLog
> trunk/gcc/gcc-ar.c

So can this be closed now?

[Bug target/88145] New: ICE: unrecognizable insn (mffs) targeting 32-bit BE FPU-less powerpc CPUs

[asolokha at gmx dot com]

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

Bug ID: 88145
   Summary: ICE: unrecognizable insn (mffs) targeting 32-bit BE
FPU-less powerpc CPUs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: powerpc-*-linux-gnu

gcc-9.0.0-alpha20181118 snapshot (r266255) ICEs when compiling
gcc/testsuite/gcc.target/powerpc/test_mffsl.c for 32-bit powerpc cores that
don't include a FPU:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -mcpu=e300c2 -c
gcc/testsuite/gcc.target/powerpc/test_mffsl.c -o /dev/null  
gcc/testsuite/gcc.target/powerpc/test_mffsl.c: In function 'main':
gcc/testsuite/gcc.target/powerpc/test_mffsl.c:20:3: error: impossible
constraint in 'asm'
   20 |   __asm __volatile ("mffs %0" : "=f"(f14));
  |   ^
gcc/testsuite/gcc.target/powerpc/test_mffsl.c:32:1: error: unrecognizable insn:
   32 | }
  | ^
(insn 9 8 10 2 (set (reg:DF 128)
(unspec_volatile:DF [
(const_int 0 [0])
] UNSPECV_MFFS))
"gcc/testsuite/gcc.target/powerpc/test_mffsl.c":23:21 -1
 (nil))
during RTL pass: vregs
gcc/testsuite/gcc.target/powerpc/test_mffsl.c:32:1: internal compiler error: in
extract_insn, at recog.c:2305
0x639917 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:108
0x639935 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:116
0x637d86 extract_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/recog.c:2305
0xa2dbf2 instantiate_virtual_regs_in_insn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1605
0xa2dbf2 instantiate_virtual_regs
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1975
0xa2dbf2 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:2024

gcc 4.9.4 correctly rejects it w/ "error: impossible constraint in 'asm'" and
w/o ICE, as does any version of the powerpcspe backend.

Also, shouldn't the rs6000 backend reject it when compiling for 85xx CPUs? I
see standard FPU instructions in the generated code which I believe shouldn't
be there. Maybe -mcpu=854[08] should be removed from the rs6000 backend
altogether, duplicating what was done in the powerpcspe backend previously w/
all non-SPE -mcpu's?

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[asolokha at gmx dot com]

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

--- Comment #5 from Arseny Solokha  ---
And if my guess that the problem is somehow related to the handling of FPU-less
cores in the rs6000 and powerpcspe backends is correct, than I see whan might
be another manifestation of that issue:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -mcpu=e300c2 --param
ggc-min-expand=3 --param ggc-min-heapsize=1024 -c
gcc/testsuite/gcc.dg/pr65345-3.c
gcc/testsuite/gcc.dg/pr65345-3.c:18:12: error: initializer element is not
constant
   18 | float c1 = i; /* { dg-error "initializer element is not constant" } */
  |^
gcc/testsuite/gcc.dg/pr65345-3.c:19:12: error: initializer element is not
constant
   19 | float c2 = (i ? 1 : 2); /* { dg-error "initializer element is not
constant" } */
  |^
gcc/testsuite/gcc.dg/pr65345-3.c:20:7: error: variably modified 'c3' at file
scope
   20 | float c3[(int) i]; /* { dg-error "variably modified" } */
  |   ^~
gcc/testsuite/gcc.dg/pr65345-3.c:21:12: error: initializer element is not
constant
   21 | float c4 = 0 || i; /* { dg-error "initializer element is not constant"
} */
  |^
gcc/testsuite/gcc.dg/pr65345-3.c:22:1: internal compiler error: Segmentation
fault
   22 | float c5 = (i += 10); /* { dg-error "initializer element is not
constant" } */
  | ^
0xd16576 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/toplev.c:325
0xfc99af contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree.h:3267
0xfc99af build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree.c:11278
0xfc9c11 build_call_expr(tree_node*, int, ...)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/tree.c:11328
0x10488e3 rs6000_atomic_assign_expand_fenv
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/config/rs6000/rs6000.c:38296
0x7a6a18 build_atomic_assign
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-typeck.c:4210
0x7b55e2 build_modify_expr(unsigned int, tree_node*, tree_node*, tree_code,
unsigned int, tree_node*, tree_node*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-typeck.c:6186
0x7cf936 c_parser_expr_no_commas
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6632
0x7cfa5e c_parser_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:9486
0x7c38fb c_parser_postfix_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:7991
0x7cd1fa c_parser_unary_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:7289
0x7cdf07 c_parser_cast_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:7133
0x7ce154 c_parser_binary_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6936
0x7cf07b c_parser_conditional_expression
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6670
0x7cf73b c_parser_expr_no_commas
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:6587
0x7d47bb c_parser_initializer
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:4547
0x7e1186 c_parser_declaration_or_fndef
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:2129
0x7e8c77 c_parser_external_declaration
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:1651
0x7e9341 c_parser_translation_unit
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:1532
0x7e9341 c_parse_file()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/c/c-parser.c:19609

[Bug c/88144] remove long-obsolete syntax for designated initializers

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I think one of the reasons why it has not been removed is there is still code
out there that uses this syntax.
If anything we should add a warning about it first if we are going to remove
it.

[Bug target/37760] internal compiler error: in extract_insn, at recog.c:1990

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #2 from Arseny Solokha  ---
Does it still ICE? I cannot reproduce it w/ gcc 5.4.0 or newer.

[Bug other/88141] Issues with texinfo when building GCC r266351 in MSYS2

[jmm4077 at rit dot edu]

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

--- Comment #1 from Joshua Morrison  ---
I should also add that my installation of MSYS2 is up-to-date, including the
installation of texinfo. This is what makeinfo outputs when you pass it -V:

$ makeinfo -V
texi2any (GNU texinfo) 6.5

Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[Bug target/88055] ICE in extract_insn, at recog.c:2305 on ppc64le

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
I also see it when compiling gcc/testsuite/gcc.dg/pr37353.c for 32-bit BE
powerpc:

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -O1 -ffinite-math-only
-fno-tree-forwprop -fno-tree-ter -c gcc/testsuite/gcc.dg/pr37353.c -o /dev/null 
gcc/testsuite/gcc.dg/pr37353.c: In function 'foo':
gcc/testsuite/gcc.dg/pr37353.c:15:1: error: unrecognizable insn:
   15 | }
  | ^
(insn 10 9 11 2 (set (reg:SI 127)
(unlt:SI (reg:CCFP 128)
(const_int 0 [0]))) -1
 (nil))
during RTL pass: vregs
gcc/testsuite/gcc.dg/pr37353.c:15:1: internal compiler error: in extract_insn,
at recog.c:2305
0x639917 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:108
0x639935 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/rtl-error.c:116
0x637d86 extract_insn(rtx_insn*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/recog.c:2305
0xa2dbf2 instantiate_virtual_regs_in_insn
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1605
0xa2dbf2 instantiate_virtual_regs
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:1975
0xa2dbf2 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/gcc/function.c:2024

(as of r266255).

[Bug c/88144] New: remove long-obsolete syntax for designated initializers

[sandra at gcc dot gnu.org]

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

Bug ID: 88144
   Summary: remove long-obsolete syntax for designated
initializers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

The GCC manual documents alternative syntax for designated initializers that it
describes as "obsolete since GCC 2.5".  It appears this syntax is still
accepted in both C and C++.

GCC 2.5 was released in 1993.  Why is this still a part of GCC?  Shouldn't
things that have been obsolete this long simply be removed?  Or, if the
alternative syntax is not obsolete after all, the docs should be fixed not to
say that it is.

Test case:

struct point { int x, y; };
struct point p = { x: 69, y: 42 };

[Bug c++/88123] [8/9 Regression] faulty qualified name lookup of overloaded operator within generic lambda via using-directive

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
The error started with r258502.

[Bug rtl-optimization/87485] [9 Regression] Compile time hog w/ -O2 -fschedule-insns -fno-guess-branch-probability -fno-isolate-erroneous-paths-dereference -fno-omit-frame-pointer -fno-split-wide-type

[vmakarov at gcc dot gnu.org]

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

--- Comment #17 from Vladimir Makarov  ---
  I've reproduced it.  Clearly, it is some bug in LRA conflict calculation.  I
will be working on it.

[Bug target/88134] ICE in create_component_ref_by_pieces_1, at tree-ssa-pre.c:2520

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
(In reply to rguent...@suse.de from comment #3)
> The 
> powerpc64[le]-linux crosses insist that -mcpu=860 requires a 64bit CPU...

Which is strange, as 860 is a 32-bit CPU w/o FPU (perhaps a key here?)
introduced in the 90s[1,2]. Other -mcpu values for reproduction of this ICE are
all 4xx and 8xx (not including their corresponding fp variants) and e300c2 and
ec603e, all of which also don't include a FPU. Additionally, the powerpcspe
target doesn't need to specify -mcpu at all, as it implements floating-point
and SIMD ISA with its specific non-standard SPE unit which reuses integer GPRs.

% powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118 -v   
Using built-in specs.
COLLECT_GCC=powerpc-e300c3-linux-gnu-gcc-9.0.0-alpha20181118
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/lto-wrapper
Target: powerpc-e300c3-linux-gnu
Configured with:
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20181118/work/gcc-9-20181118/configure
--host=x86_64-pc-linux-gnu --target=powerpc-e300c3-linux-gnu
--build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/powerpc-e300c3-linux-gnu/gcc-bin/9.0.0-alpha20181118
--includedir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/include
--datadir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118
--mandir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/man
--infodir=/usr/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/include/g++-v9
--with-python-dir=/share/gcc-data/powerpc-e300c3-linux-gnu/9.0.0-alpha20181118/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --disable-nls --enable-checking=yes --disable-esp
--enable-libstdcxx-time --enable-poison-system-directories
--with-sysroot=/usr/powerpc-e300c3-linux-gnu --disable-bootstrap
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec
--disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libmpx --disable-systemtap
--disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto
--with-isl --disable-isl-version-check --disable-libsanitizer
Thread model: posix
gcc version 9.0.0-alpha20181118 20181118 (experimental) (GCC)

[1] https://www.nxp.com/docs/en/data-sheet/MPC860.pdf
[2] https://www.nxp.com/docs/en/reference-manual/MPC860UM.pdf

Re: C++ PATCH to implement P1094R2, Nested inline namespaces

[Marek Polacek]

On Tue, Nov 20, 2018 at 04:59:46PM -0500, Jason Merrill wrote:
> On 11/19/18 5:12 PM, Marek Polacek wrote:
> > On Mon, Nov 19, 2018 at 10:33:17PM +0100, Jakub Jelinek wrote:
> > > On Mon, Nov 19, 2018 at 04:21:19PM -0500, Marek Polacek wrote:
> > > > 2018-11-19  Marek Polacek  
> > > > 
> > > > Implement P1094R2, Nested inline namespaces.
> > > > * g++.dg/cpp2a/nested-inline-ns1.C: New test.
> > > > * g++.dg/cpp2a/nested-inline-ns2.C: New test.
> > > > * g++.dg/cpp2a/nested-inline-ns3.C: New test.
> > > 
> > > Just a small testsuite comment.
> > > 
> > > > --- /dev/null
> > > > +++ gcc/testsuite/g++.dg/cpp2a/nested-inline-ns1.C
> > > > @@ -0,0 +1,26 @@
> > > > +// P1094R2
> > > > +// { dg-do compile { target c++2a } }
> > > 
> > > Especially because 2a testing isn't included by default, but also
> > > to make sure it works right even with -std=c++17, wouldn't it be better to
> > > drop the nested-inline-ns3.C test, make this test c++17 or
> > > even better always enabled, add dg-options "-Wpedantic" and
> > > just add dg-warning with c++17_down and c++14_down what should be
> > > warned on the 3 lines (with .-1 for c++14_down)?
> > > 
> > > Or if you want add some further testcases that will test how
> > > c++17 etc. will dg-error on those with -pedantic-errors etc.
> > 
> > Sure, I've made it { target c++11 } and dropped the third test:
> > 
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> > 
> > 2018-11-19  Marek Polacek  
> > 
> > Implement P1094R2, Nested inline namespaces.
> > * parser.c (cp_parser_namespace_definition): Parse the optional inline
> > keyword in a nested-namespace-definition.  Adjust push_namespace call.
> > Formatting fix.
> > 
> > * g++.dg/cpp2a/nested-inline-ns1.C: New test.
> > * g++.dg/cpp2a/nested-inline-ns2.C: New test.
> > 
> > diff --git gcc/cp/parser.c gcc/cp/parser.c
> > index 292cce15676..f39e9d753d2 100644
> > --- gcc/cp/parser.c
> > +++ gcc/cp/parser.c
> > @@ -18872,6 +18872,7 @@ cp_parser_namespace_definition (cp_parser* parser)
> > cp_ensure_no_oacc_routine (parser);
> > bool is_inline = cp_lexer_next_token_is_keyword (parser->lexer, 
> > RID_INLINE);
> > +  const bool topmost_inline_p = is_inline;
> > if (is_inline)
> >   {
> > @@ -18890,6 +18891,17 @@ cp_parser_namespace_definition (cp_parser* parser)
> >   {
> > identifier = NULL_TREE;
> > +  bool nested_inline_p = cp_lexer_next_token_is_keyword (parser->lexer,
> > +RID_INLINE);
> > +  if (nested_inline_p && nested_definition_count != 0)
> > +   {
> > + if (cxx_dialect < cxx2a)
> > +   pedwarn (cp_lexer_peek_token (parser->lexer)->location,
> > +OPT_Wpedantic, "nested inline namespace definitions only "
> > +"available with -std=c++2a or -std=gnu++2a");
> > + cp_lexer_consume_token (parser->lexer);
> > +   }
> 
> This looks like we won't get any diagnostic in lower conformance modes if
> there are multiple namespace scopes before the inline keyword.

If you mean something like
namespace A::B:C::inline D { }
then we do get a diagnostic.  nested-inline-ns1.C tests that.  Or do you
mean something else?
 
> > if (cp_lexer_next_token_is (parser->lexer, CPP_NAME))
> > {
> >   identifier = cp_parser_identifier (parser);
> > @@ -18904,7 +18916,12 @@ cp_parser_namespace_definition (cp_parser* parser)
> > }
> > if (cp_lexer_next_token_is_not (parser->lexer, CPP_SCOPE))
> > -   break;
> > +   {
> > + /* Don't forget that the innermost namespace might have been
> > +marked as inline.  */
> > + is_inline |= nested_inline_p;
> 
> This looks wrong: an inline namespace does not make its nested namespaces
> inline as well.

A nested namespace definition cannot be inline.  This is supposed to handle
cases such as
namespace A::B::inline C { ... }
because after 'C' we don't see :: so it breaks and we call push_namespace
outside the for loop.  So I still don't see a bug; do you have a test that
I got wrong?

Marek

[Bug c/53182] GNU C: attributes without underscores should be discouraged / no longer be documented e.g. as examples

[sandra at gcc dot gnu.org]

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
On this issue I'd like to get agreement from a broader community that it is a
good idea to deprecate the non-underscore names before implementing the
documentation changes.  I also think there are other compilers that have copied
the GCC attribute syntax; do they also recognize both the underscore and
non-underscore name variants?

The edits for this would be fairly mechanical, but I'm concerned that it won't
help readability of the manual, and would be confusing to people who have some
existing code with some attributes not using the __foo__ convention that they
want to look up.  At the very least we'd want to index both names.  

Also the optional underscore naming is currently explained in the attribute
syntax section, which appears after the sections where all the different
flavors of attributes are listed.  That would need to be moved to a more
prominent location.

Why?

[systemanalyst]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

Why?

[systemanalyst]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

Re: [PATCH][libbacktrace] Handle DW_FORM_GNU_strp_alt

[Tom de Vries]

On 21-11-18 02:03, Ian Lance Taylor wrote:
> On Wed, Nov 14, 2018 at 6:45 AM, Tom de Vries  wrote:
>> On 14-11-18 14:25, Jakub Jelinek wrote:
>>> On Wed, Nov 14, 2018 at 02:08:05PM +0100, Tom de Vries wrote:
> +btest_dwz_CFLAGS = $(AM_CFLAGS) -g -O0

 Hmm, I already discovered that specifying the -O0 doesn't work, since
 it's overridden by $(CFLAGS).

 With a hack like this:
 ...
 diff --git a/libbacktrace/Makefile.am b/libbacktrace/Makefile.am
 index 2fec9bbb4b6..8bdf13b3546 100644
 --- a/libbacktrace/Makefile.am
 +++ b/libbacktrace/Makefile.am
 @@ -99,11 +99,14 @@ check_PROGRAMS += btest
  if HAVE_DWZ

  btest_dwz_SOURCES = btest_dwz.c testlib.c
 -btest_dwz_CFLAGS = $(AM_CFLAGS) -g -O0
 +btest_dwz_CFLAGS = $(AM_CFLAGS) -g
  btest_dwz_LDADD = libbacktrace.la

  check_PROGRAMS += btest_dwz

 +btest_dwz-btest_dwz.o: btest_dwz.c
 +   $(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)
 $(AM_CPPFLAGS) $(CPPFLAGS) $(btest_dwz_CFLAGS) $(CFLAGS) -O0 -c -o
 btest_dwz-btest_dwz.o `test -f 'btest_dwz.c' || echo
 '$(srcdir)/'`btest_dwz.c
>>>
>>> Can't you instead do something like:
>>> btest_dwz.o: CFLAGS += -g -O0
>>> or something similar
>>
>> Hi,
>>
>> yes, that works, thanks.
>>
>>> (whatever the corresponding goal is)?
>>
>> The goal is to run the testcase with a setting lower than -O2, such that
>> we can successfully run a substantial portion of the test without
>> needing support for DW_FORM_GNU_ref_alt.
>>
>> [ At O2 we get constprop versions of some functions, which have an
>> abstract origin, which tends to be moved to the common debug file by dwz
>> -m, after which we need support for DW_FORM_GNU_ref_alt to get to the
>> name of the function. ]
>>
>>> Otherwise, the patch looks generally ok to me,
>>
>> Great.
>>
>>> but yes, I've been wondering
>>> how you can get away with DW_FORM_GNU_ref_alt not implemented properly.
>>>
>>
>> Indeed, DW_FORM_GNU_ref_alt support is required to make this work in
>> general.
>>
>> But I observed that implementing just DW_FORM_GNU_strp_alt improves on
>> the current situation, so I thought it was worthwhile submitting this as
>> a separate patch.
>>
>> Updated patch attached (which also rewrites btest_dwz.c to an include of
>> btest.c, while disabling the inline tests that require DW_FORM_GNU_ref_alt).
> 
> Unfortunately the tests don't pass for me.
> 
> rm -f btest_dwz.debug
> cp btest_dwz btest_dwz_2
> cp btest_dwz btest_dwz_3
> dwz -m btest_dwz.debug btest_dwz_2 btest_dwz_3
> FAIL: btest_dwz_2
> FAIL: btest_dwz_3
> 
>> libbacktrace/btest_dwz_2
> test1: [0]: missing file name or function name
> FAIL: backtrace_full noinline
> test3: [0]: missing file name or function name
> FAIL: backtrace_simple noinline
> PASS: backtrace_syminfo variable
> 
>> libbacktrace/btest_dwz_3
> test1: [0]: missing file name or function name
> FAIL: backtrace_full noinline
> test3: [0]: missing file name or function name
> FAIL: backtrace_simple noinline
> PASS: backtrace_syminfo variable
> 

Hmm, I can't reproduce that. I'm reworking this patch into a patch
series that includes also support for DW_FORM_GNU_ref_alt, so I'm hoping
that that will fix the failures you're seeing.

>> +#define INLINE_TESTS 0
>> +#include "btest.c"
> 
> Please avoid this kind of #include game.  If you need to skip some
> tests (why?) use a command line option.  If you need to compile with
> different options, use automake features.
> 

The patch series with DW_FORM_GNU_ref_alt support added no longer
requires this.

>> +elf_open_debugfile_by_debugaltlink (struct backtrace_state *state,
> 
> Do we need this function?  It seems to be the same as
> elf_find_debugfile_by_debuglink.

Hmm, that's right. I've now updated the patch in my patch series.

I'll resubmit once the fix for PR88063 is in trunk (I need the keeping
track of units that that patch adds, for DW_FORM_GNU_ref_alt support).

Thanks for the review,
- Tom

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #17 from Eric Botcazou  ---
>> Anybody should be able to reproduce this problem.  My guess is a logic error.
>
> I'm not sure whether we still support the native assembler on Solaris.  
> Rainer,
> do you still test it?

We do: I regularly test both as/ld, gas/ld, and gas/gld on Solaris/SPARC
and x86, even reporting /bin/as bugs upstream (and getting them fixed ;-)

Re: [C++ Patch] PR 84636 ("internal compiler error: Segmentation fault (identifier_p()/grokdeclarator())")

[Paolo Carlini]

... in fact I'm thinking that the below - which directly checks for 
unqualified_id to be non-null in both places - may be a better variant: 
among other things it means that for related testcases like:

typedef void a();
struct A
{ a a1: 1; };
we get the location of a1 right (we could also change the diagnostics in 
grokbitfield to use DECL_SOURCE_LOCATION and exploit it), and the 
testsuite doesn't need adjustments. Tested x86_64-linux.


Thanks, Paolo.


Index: cp/decl.c
===
--- cp/decl.c   (revision 266339)
+++ cp/decl.c   (working copy)
@@ -12165,7 +12165,8 @@ grokdeclarator (const cp_declarator *declarator,
 }
 
   if (ctype && TREE_CODE (type) == FUNCTION_TYPE && staticp < 2
-  && !(identifier_p (unqualified_id)
+  && !(unqualified_id
+  && identifier_p (unqualified_id)
   && IDENTIFIER_NEWDEL_OP_P (unqualified_id)))
 {
   cp_cv_quals real_quals = memfn_quals;
@@ -12245,8 +12246,7 @@ grokdeclarator (const cp_declarator *declarator,
error ("invalid use of %<::%>");
return error_mark_node;
  }
-   else if (TREE_CODE (type) == FUNCTION_TYPE
-|| TREE_CODE (type) == METHOD_TYPE)
+   else if (FUNC_OR_METHOD_TYPE_P (type) && unqualified_id)
  {
int publicp = 0;
tree function_context;
Index: testsuite/g++.dg/parse/bitfield6.C
===
--- testsuite/g++.dg/parse/bitfield6.C  (nonexistent)
+++ testsuite/g++.dg/parse/bitfield6.C  (working copy)
@@ -0,0 +1,6 @@
+// PR c++/84636
+
+typedef void a();
+struct A {
+a: 1;  // { dg-error "bit-field .\\. with non-integral type" }
+};

Re: [PATCH][libbacktrace] Factor out read_initial_length

[Ian Lance Taylor]

Tom de Vries  writes:

> [libbacktrace] Factor out read_initial_length
>
> 2018-11-22  Tom de Vries  
>
>   * dwarf.c (read_initial_length): Factor out of ...
>   (build_address_map, read_line_info): ... here.

This is OK.

Thanks.

Ian

[PATCH][libbacktrace] Factor out read_initial_length

[Tom de Vries]

Hi,

this patch factors out new function read_initial_length in dwarf.c.

Bootstrapped and reg-tested on x86_64.

OK for trunk?

Thanks,
- Tom

[libbacktrace] Factor out read_initial_length

2018-11-22  Tom de Vries  

* dwarf.c (read_initial_length): Factor out of ...
(build_address_map, read_line_info): ... here.

---
 libbacktrace/dwarf.c | 36 +---
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index c4f8732c7eb..4e93f120820 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -651,6 +651,25 @@ leb128_len (const unsigned char *p)
   return ret;
 }
 
+/* Read initial_length from BUF and advance the appropriate number of bytes.  
*/
+
+static uint64_t
+read_initial_length (struct dwarf_buf *buf, int *is_dwarf64)
+{
+  uint64_t len;
+
+  len = read_uint32 (buf);
+  if (len == 0x)
+{
+  len = read_uint64 (buf);
+  *is_dwarf64 = 1;
+}
+  else
+*is_dwarf64 = 0;
+
+  return len;
+}
+
 /* Free an abbreviations structure.  */
 
 static void
@@ -1463,14 +1482,7 @@ build_address_map (struct backtrace_state *state, 
uintptr_t base_address,
 
   unit_data_start = info.buf;
 
-  is_dwarf64 = 0;
-  len = read_uint32 ();
-  if (len == 0x)
-   {
- len = read_uint64 ();
- is_dwarf64 = 1;
-   }
-
+  len = read_initial_length (, _dwarf64);
   unit_buf = info;
   unit_buf.left = len;
 
@@ -2002,13 +2014,7 @@ read_line_info (struct backtrace_state *state, struct 
dwarf_data *ddata,
   line_buf.data = data;
   line_buf.reported_underflow = 0;
 
-  is_dwarf64 = 0;
-  len = read_uint32 (_buf);
-  if (len == 0x)
-{
-  len = read_uint64 (_buf);
-  is_dwarf64 = 1;
-}
+  len = read_initial_length (_buf, _dwarf64);
   line_buf.left = len;
 
   if (!read_line_header (state, u, is_dwarf64, _buf, hdr))

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #17 from Eric Botcazou  ---
> I have a clue now.  I built gcc-7 on OI-SPARC with the GNU assembler.  The
> build was successful.  xgcc worked, without the ICE.  Clearly the ICE only 
> happens when gcc-7 is configured with the native assembler.  This is the usual
> configuration on SPARC hardware.

Interesting, why is that usual for SPARC and unusual for x86?

> Anybody should be able to reproduce this problem.  My guess is a logic error.

I'm not sure whether we still support the native assembler on Solaris.  Rainer,
do you still test it?

[Bug fortran/88143] New: gfortran crashes with an internal compiler error

[andrew at fluidgravity dot co.uk]

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

Bug ID: 88143
   Summary: gfortran crashes with an internal compiler error
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at fluidgravity dot co.uk
  Target Milestone: ---

I get an internal compiler error when compiling the code below:

> gfortran -c code.f90
f951: internal compiler error: Segmentation fault: 11
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.


code.f90:
MODULE m
   IMPLICIT NONE
   TYPE t
  INTEGER, DIMENSION(:), ALLOCATABLE :: i
   END TYPE
   CONTAINS
  SUBROUTINE s(x)
 CLASS(*), DIMENSION(:), INTENT(IN), OPTIONAL :: x
 INTEGER :: k
 SELECT TYPE ( x )
 CLASS IS ( t )
ASSOCIATE ( j => x(1)%i )
   k = j(1)
END ASSOCIATE
 END SELECT
  END
END

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[vries at gcc dot gnu.org]

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

--- Comment #12 from Tom de Vries  ---
Created attachment 45063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45063=edit
combined patch

> Can you attach one single patch from trunk?

Patch combining:
- Updated patch
  https://gcc.gnu.org/bugzilla/attachment.cgi?id=45055=edit
- Followup patch
  https://gcc.gnu.org/bugzilla/attachment.cgi?id=45058=edit
- Second followup patch
  https://gcc.gnu.org/bugzilla/attachment.cgi?id=45059=edit

[Bug c++/88118] GCC keeps unnecessary calls to new

[tiagomacarios at gmail dot com]

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

--- Comment #6 from Tiago Macarios  ---
Related clang bug: https://bugs.llvm.org/show_bug.cgi?id=39731

[PATCH 7/7][v2][MSP430][TESTSUITE] Fix tests for msp430-elf large memory model

[Jozef Lawrynowicz]

On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz  wrote:

> Patch 7 fixes tests for msp430-elf in the large memory model.

Added missing documentation for new check_effective target procs in attached
patch.


>From 4cfb2ecd0e0580f69790fadd68b77e8a82992ef4 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Sat, 10 Nov 2018 16:08:44 +
Subject: [PATCH] [TESTSUITE] Fix tests for msp430-elf large memory model

2018-11-21  Jozef Lawrynowicz  

	gcc/ChangeLog:

	* doc/sourcebuild.texi: Document
	check_effective_target_msp430_large_mem.

	gcc/testsuite/ChangeLog:

	* gcc.c-torture/execute/991014-1.c: Fix bufsize definition for
	msp430 large memory model.
	* gcc.dg/Walloca-1.c: Don't expect warning for msp430 large memory
	model.
	* gcc.dg/Walloca-2.c: Likewise.
	* gcc.dg/c99-const-expr-2.c: Define ZERO macro for msp430 large memory
	model.
	* gcc.dg/format/format.h: Prefix typedefs using __SIZE_TYPE__ and
	__PTRDIFF_TYPE__ with __extension__.
	* gcc.dg/lto/20081210-1_0.c: Always typedef uintptr_t as
	__UINTPTR_TYPE__.
	* gcc.dg/pr36227.c: Likewise.
	* gcc.dg/pr42611.c: Use __INTPTR_MAX__ as the maximum object size if
	size_t and ptr_t are the same size.
	* gcc.dg/pr78973.c: dg-warning XFAIL for int16 but not msp430 large
	memory model.
	* gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Update dg-warning
	directives for msp430 large memory model.
	* gcc.dg/tree-ssa/pr66449.c: Always use __INTPTR_TYPE__ when integer
	type equal in size to ptr_t is required.
	* gcc.dg/tree-ssa/ssa-dom-thread-8.c: Extend pointer size checking
	macro for msp430.
	* lib/target-supports.exp (check_effective_target_msp430_large_mem):
	New. 
---
 gcc/doc/sourcebuild.texi   |  8 ++
 gcc/testsuite/gcc.c-torture/execute/991014-1.c |  7 -
 gcc/testsuite/gcc.dg/Walloca-1.c   |  4 +--
 gcc/testsuite/gcc.dg/Walloca-2.c   |  8 +++---
 gcc/testsuite/gcc.dg/c99-const-expr-2.c|  2 ++
 gcc/testsuite/gcc.dg/format/format.h   |  6 ++--
 gcc/testsuite/gcc.dg/lto/20081210-1_0.c|  8 +-
 gcc/testsuite/gcc.dg/pr36227.c | 10 +--
 gcc/testsuite/gcc.dg/pr42611.c |  3 +-
 gcc/testsuite/gcc.dg/pr78973.c |  2 +-
 .../gcc.dg/tree-ssa/builtin-sprintf-warn-3.c   | 32 +++---
 gcc/testsuite/gcc.dg/tree-ssa/pr66449.c|  8 ++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c   |  8 +++---
 gcc/testsuite/lib/target-supports.exp  | 13 +
 14 files changed, 66 insertions(+), 53 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index bfaa0fd..b5fac4e 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1941,6 +1941,14 @@ when using the new ABI.
 MIPS target supports @code{-mpaired-single}.
 @end table
 
+@subsubsection MSP430-specific attributes
+
+@table @code
+@item msp430_large_mem
+The MSP430 large memory model (enabled with @code{-mlarge} compiler flag)
+is in use.
+@end table
+
 @subsubsection PowerPC-specific attributes
 
 @table @code
diff --git a/gcc/testsuite/gcc.c-torture/execute/991014-1.c b/gcc/testsuite/gcc.c-torture/execute/991014-1.c
index e0bcd6d..95e38ce 100644
--- a/gcc/testsuite/gcc.c-torture/execute/991014-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/991014-1.c
@@ -1,11 +1,16 @@
-
 typedef __SIZE_TYPE__ Size_t;
 
+#ifdef __MSP430X_LARGE__
+/* size_t is __int20, so 20 bits, for __MSP430X_LARGE__, but __SIZEOF_POINTER__
+   returns the bytesize which is 4.  */
+#define bufsize ((1L << (20 - 2))-256)
+#else  /* !__MSP430X_LARGE__ */
 #if __SIZEOF_LONG__ < __SIZEOF_POINTER__
 #define bufsize ((1LL << (8 * sizeof(Size_t) - 2))-256)
 #else
 #define bufsize ((1L << (8 * sizeof(Size_t) - 2))-256)
 #endif
+#endif
 
 struct huge_struct
 {
diff --git a/gcc/testsuite/gcc.dg/Walloca-1.c b/gcc/testsuite/gcc.dg/Walloca-1.c
index 85e9160..c9a6c57 100644
--- a/gcc/testsuite/gcc.dg/Walloca-1.c
+++ b/gcc/testsuite/gcc.dg/Walloca-1.c
@@ -24,8 +24,8 @@ void foo1 (size_t len, size_t len2, size_t len3)
   char *s = alloca (123);
   useit (s);			// OK, constant argument to alloca
 
-  s = alloca (num);		// { dg-warning "large due to conversion" "" { target lp64 } }
-  // { dg-warning "unbounded use of 'alloca'" "" { target { ! lp64 } } .-1 }
+  s = alloca (num);		// { dg-warning "large due to conversion" "" { target { { lp64 } || { msp430_large_mem } } } }
+  // { dg-warning "unbounded use of 'alloca'" "" { target { { ! lp64 } && { ! msp430_large_mem } } } .-1 }
   useit (s);
 
   s = alloca (3);		/* { dg-warning "is too large" } */
diff --git a/gcc/testsuite/gcc.dg/Walloca-2.c b/gcc/testsuite/gcc.dg/Walloca-2.c
index 766ff8d..446c811 100644
--- a/gcc/testsuite/gcc.dg/Walloca-2.c
+++ b/gcc/testsuite/gcc.dg/Walloca-2.c
@@ -13,7 +13,7 @@ g1 (int n)
 // 32-bit targets because VRP is not giving us any range info for
 // the argument to __builtin_alloca.  This should be fixed by the
 // 

[Bug c++/88122] [9 Regression] g++ ICE: internal compiler error: Segmentation fault

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 22:42:09 2018
New Revision: 266360

URL: https://gcc.gnu.org/viewcvs?rev=266360=gcc=rev
Log:
PR c++/88122
* method.c (maybe_explain_implicit_delete): If
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL, set const_p to false
instead of ICEing.

* g++.dg/cpp0x/implicit15.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/implicit15.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/method.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/87386] [8/9 Regression] Error message for static_assert show wrong range

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 22:41:07 2018
New Revision: 266359

URL: https://gcc.gnu.org/viewcvs?rev=266359=gcc=rev
Log:
PR c++/87386
* parser.c (cp_parser_primary_expression): Use
id_expression.get_location () instead of id_expr_token->location.
Adjust the range from id_expr_token->location to
id_expressio.get_finish ().
(cp_parser_operator_function_id): Pass location of the operator
token down to cp_parser_operator.
(cp_parser_operator): Add start_loc argument, always construct a
location with caret at start_loc and range from start_loc to the
finish of the last token.
gcc/testsuite/
* g++.dg/diagnostic/pr87386.C: New test.
* g++.dg/parse/error17.C: Adjust expected diagnostics.
libstdc++-v3/
* testsuite/20_util/scoped_allocator/69293_neg.cc: Adjust expected
line.
* testsuite/20_util/uses_allocator/cons_neg.cc: Likewise.
* testsuite/20_util/uses_allocator/69293_neg.cc: Likewise.
* testsuite/experimental/propagate_const/requirements2.cc: Likewise.
* testsuite/experimental/propagate_const/requirements3.cc: Likewise.
* testsuite/experimental/propagate_const/requirements4.cc: Likewise.
* testsuite/experimental/propagate_const/requirements5.cc: Likewise.

Added:
trunk/gcc/testsuite/g++.dg/diagnostic/pr87386.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/parse/error17.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/20_util/scoped_allocator/69293_neg.cc
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/69293_neg.cc
trunk/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements2.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements3.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements4.cc
trunk/libstdc++-v3/testsuite/experimental/propagate_const/requirements5.cc

[PATCH 6/7][v2][MSP430][TESTSUITE] Fix tests requiring float printf support when GCC was configured with --enable-newlib-nano-formatted-io

[Jozef Lawrynowicz]

On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz  wrote:

> Patch 6 fixes tests expecting printf float support for targets which have been
> configured with "newlib-nano-formatted-io". When newlib is configured in this
> way, float printf is enabled at build time by registering _printf_float as an
> undefined symbol.

Added missing documentation for new check_effective target procs in attached
patch.

>From ad5c2e3684904f961938cfc0b50445013300c6e0 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Sat, 10 Nov 2018 16:02:25 +
Subject: [PATCH] [TESTSUITE] Fix tests requiring float printf support when GCC
 was configured with --enable-newlib-nano-formatted-io

2018-11-21  Jozef Lawrynowicz  

	gcc/ChangeLog:

	* doc/sourcebuild.texi: Document check_effective_target_newlib_nano_io.

	gcc/testsuite/ChangeLog:

	* lib/target-supports.exp (check_effective_target_newlib_nano_io): New. 
	* gcc.c-torture/execute/920501-8.c: Register undefined linker symbol
	_printf_float for newlib_nano_io target.
	* gcc.c-torture/execute/930513-1.c: Likewise.
	* gcc.dg/torture/builtin-sprintf.c: Likewise.
	* gcc.c-torture/execute/ieee/920810-1.x: New.
---
 gcc/doc/sourcebuild.texi| 4 
 gcc/testsuite/gcc.c-torture/execute/920501-8.c  | 2 ++
 gcc/testsuite/gcc.c-torture/execute/930513-1.c  | 2 ++
 gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x | 4 
 gcc/testsuite/gcc.dg/torture/builtin-sprintf.c  | 3 ++-
 gcc/testsuite/lib/target-supports.exp   | 4 
 6 files changed, 18 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 9c57226..bfaa0fd 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -2152,6 +2152,10 @@ Target supports @code{mmap}.
 @item newlib
 Target supports Newlib.
 
+@item newlib_nano_io
+GCC was configured with @code{--enable-newlib-nano-formatted-io}, which reduces
+the code size of Newlib formatted I/O functions.
+
 @item pow10
 Target provides @code{pow10} function.
 
diff --git a/gcc/testsuite/gcc.c-torture/execute/920501-8.c b/gcc/testsuite/gcc.c-torture/execute/920501-8.c
index 62780a0..7e4fa17 100644
--- a/gcc/testsuite/gcc.c-torture/execute/920501-8.c
+++ b/gcc/testsuite/gcc.c-torture/execute/920501-8.c
@@ -1,3 +1,5 @@
+/* { dg-additional-options "-Wl,-u,_printf_float" { target newlib_nano_io } } */
+
 #include 
 #include 
 
diff --git a/gcc/testsuite/gcc.c-torture/execute/930513-1.c b/gcc/testsuite/gcc.c-torture/execute/930513-1.c
index 4544471..f163007 100644
--- a/gcc/testsuite/gcc.c-torture/execute/930513-1.c
+++ b/gcc/testsuite/gcc.c-torture/execute/930513-1.c
@@ -1,3 +1,5 @@
+/* { dg-additional-options "-Wl,-u,_printf_float" { target newlib_nano_io } } */
+
 #include 
 char buf[2];
 
diff --git a/gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x b/gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x
new file mode 100644
index 000..8edec730
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/execute/ieee/920810-1.x
@@ -0,0 +1,4 @@
+if { [check_effective_target_newlib_nano_io] } {
+lappend additional_flags "-Wl,-u,_printf_float"
+}
+return 0
diff --git a/gcc/testsuite/gcc.dg/torture/builtin-sprintf.c b/gcc/testsuite/gcc.dg/torture/builtin-sprintf.c
index 6f8b7a9..5684fd7 100644
--- a/gcc/testsuite/gcc.dg/torture/builtin-sprintf.c
+++ b/gcc/testsuite/gcc.dg/torture/builtin-sprintf.c
@@ -1,6 +1,7 @@
 /* PR tree-optimization/86274 - SEGFAULT when logging std::to_string(NAN)
{ dg-do run }
-   { dg-options "-O2 -Wall" } */
+   { dg-options "-O2 -Wall" }
+   { dg-additional-options "-Wl,-u,_printf_float" { target newlib_nano_io } } */
 
 #define X"0xdeadbeef"
 #define nan(x)   __builtin_nan (x)
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index 7488653..d696fc6 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -6691,6 +6691,10 @@ proc check_effective_target_newlib {} {
 	#include 
 }]
 }
+# Return true if GCC was configured with --enable-newlib-nano-formatted-io
+proc check_effective_target_newlib_nano_io { } {
+return [check_configured_with "--enable-newlib-nano-formatted-io"]
+}
 
 # Some newlib versions don't provide a frexpl and instead depend
 # on frexp to implement long double conversions in their printf-like
-- 
2.7.4

[PATCH 3/7][v2][MSP430][TESTSUITE] Dynamically check if size_t is large enough for tests containing large structs/arrays

[Jozef Lawrynowicz]

On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz  wrote:

> Patch 3 sets up require-effective-target directives for tests which
> require the compilation of large arrays.
> Targets which have 16-bit or 20-bit size_t fail to compile tests with large
> arrays designed to test 32-bit or 64-bit behaviour. Rather than enumerating
> another target to skip, I've replaced the target selector in some tests with
> a size checking procedure:
> - size20plus (new)
> - size32plus
> size20plus checks to see if a 16-bit structure/array size is supported,
> similarly to how the existing size32plus checks to see if a 24-bit
> structure/array size is supported,

Added missing documentation for new check_effective target procs in attached
patch.

>From 1573a8392605a17e58c74be19ee5eb28950dc32d Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Thu, 8 Nov 2018 22:39:12 +
Subject: [PATCH] [TESTSUITE] Dynamically check if size_t is large enough for
 tests containing large structs/arrays

2018-11-21  Jozef Lawrynowicz  

	gcc/ChangeLog:

	* doc/sourcebuild.texi: Document check_effective_target_size20plus.
	Clarify documentation for check_effective_target_size32plus.

	gcc/testsuite/ChangeLog:

	* gcc.c-torture/compile/20151204.c: Add dg-require-effective-target
	size20plus.
	* gcc.dg/pr34225.c: Likewise.
	* gcc.dg/pr40971.c: Likewise.
	* gcc.dg/pr69071.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-10.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-2.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-3.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-5.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-6.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-7.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-8.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-9.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-11.c: Add dg-require-effective-target
	size32plus.
	* gcc.dg/Walloc-size-larger-than-4.c: Likewise.
	* gcc.dg/Walloc-size-larger-than-5.c: Likewise.
	* gcc.dg/Walloc-size-larger-than-6.c: Likewise.
	* gcc.dg/Walloc-size-larger-than-7.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-1.c: Likewise.
	* gcc.dg/tree-ssa/loop-interchange-1b.c: Likewise.
	* lib/target-supports.exp (check_effective_target_size20plus): New.
	(check_effective_target_size32plus): Update comment. 

---
 gcc/doc/sourcebuild.texi|  7 ++-
 gcc/testsuite/gcc.c-torture/compile/20151204.c  |  2 +-
 gcc/testsuite/gcc.dg/Walloc-size-larger-than-4.c|  2 +-
 gcc/testsuite/gcc.dg/Walloc-size-larger-than-5.c|  2 +-
 gcc/testsuite/gcc.dg/Walloc-size-larger-than-6.c|  2 +-
 gcc/testsuite/gcc.dg/Walloc-size-larger-than-7.c|  2 +-
 gcc/testsuite/gcc.dg/pr34225.c  |  1 +
 gcc/testsuite/gcc.dg/pr40971.c  |  1 +
 gcc/testsuite/gcc.dg/pr69071.c  |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-1.c  |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-10.c |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-11.c |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-1b.c |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-2.c  |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-3.c  |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-5.c  |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-6.c  |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-7.c  |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-8.c  |  3 ++-
 gcc/testsuite/gcc.dg/tree-ssa/loop-interchange-9.c  |  3 ++-
 gcc/testsuite/lib/target-supports.exp   | 18 +++---
 21 files changed, 51 insertions(+), 21 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index bca5db3..9c57226 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1375,8 +1375,13 @@ Target supports @code{long double} that is longer than @code{double}.
 @item ptr32plus
 Target has pointers that are 32 bits or longer.
 
+@item size20plus
+Target has a 20-bit or larger address space, so at least supports
+16-bit array and structure sizes.
+
 @item size32plus
-Target supports array and structure sizes that are 32 bits or longer.
+Target has a 32-bit or larger address space, so at least supports
+24-bit array and structure sizes.
 
 @item 4byte_wchar_t
 Target has @code{wchar_t} that is at least 4 bytes.
diff --git a/gcc/testsuite/gcc.c-torture/compile/20151204.c b/gcc/testsuite/gcc.c-torture/compile/20151204.c
index 6a46abf..e41f6c1 100644
--- a/gcc/testsuite/gcc.c-torture/compile/20151204.c
+++ b/gcc/testsuite/gcc.c-torture/compile/20151204.c
@@ -1,4 +1,4 @@
-/* { dg-skip-if "Array too big" { "avr-*-*" "pdp11-*-*" } } */
+/* { dg-require-effective-target size20plus } */
 
 typedef __SIZE_TYPE__ size_t;
 
diff --git a/gcc/testsuite/gcc.dg/Walloc-size-larger-than-4.c b/gcc/testsuite/gcc.dg/Walloc-size-larger-than-4.c
index 4b3a64b..54e43cd 100644
--- a/gcc/testsuite/gcc.dg/Walloc-size-larger-than-4.c
+++ 

Re: [C++ PATCH] Fix ICE in maybe_explain_implicit_delete (PR c++/88122)

[Jason Merrill]

On 11/21/18 5:16 PM, Jakub Jelinek wrote:

Hi!

On the following testcase we ICE in maybe_explain_implicit_delete, because
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL - there are no user parameters
and ...
 From what I understood, const_p is used only in certain cases like const vs.
non-const copy constructor or assignment operator, if the sfk has no user
parameters, usually parm_type is just the void_type terminating the argument
list and also not really interesting for const_p computation.
So, this patch just arranges to pass false as const_p in this case.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-11-21  Jakub Jelinek  

PR c++/88122
* method.c (maybe_explain_implicit_delete): If
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL, set const_p to false
instead of ICEing.

* g++.dg/cpp0x/implicit15.C: New test.


OK.

Jason

Re: [C++ PATCH] Improve locations of id-expressions and operator "" (PR c++/87386, take 3)

[Jason Merrill]

On 11/21/18 5:10 PM, Jakub Jelinek wrote:

On Wed, Nov 21, 2018 at 07:49:48PM +0100, Jakub Jelinek wrote:

So, do you suggest we should instead return
operator new
^~~~
operator delete []
^~
operator ==
^~~
operator "" _foo
^~~~
?
That would mean cp_parser_operator_function_id would need to pass
location_t start_loc (the start of the operator token) to cp_parser_operator and
let that create a range in all cases rather than just for operator
new/delete.


This version of the patch implements that.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK.

Jason

Re: [C++ PATCH] Improve locations of id-expressions and operator "" (PR c++/87386, take 2)

[Jason Merrill]

On 11/21/18 1:49 PM, Jakub Jelinek wrote:

On Wed, Nov 21, 2018 at 01:29:15PM -0500, Jason Merrill wrote:

similarly for operator"" _F the column is under _ rather than first o.


I disagree with this one: the name of the declaration is operator""_F, so I
think the caret should go at the first o.


Right now when cp_parser_operator_function_id is called, it returns locus like:
operator new
  ^~~
operator delete []
  ^
operator ==
  ^
operator "" _foo
UNKNOWN_LOCATION
The last one is because for others we do return cp_expr (id, start_loc);
but for operator "" just return id;

So, do you suggest we should instead return
operator new
^~~~
operator delete []
^~
operator ==
^~~
operator "" _foo
^~~~
?


Yes.


That would mean cp_parser_operator_function_id would need to pass
location_t start_loc (the start of the operator token) to cp_parser_operator and
let that create a range in all cases rather than just for operator
new/delete.


Sure.

Jason

Why?

[test]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

Re: [PATCH] Fix -fstack-protector* on darwin/mingw etc. (PR target/85644)

[Jakub Jelinek]

On Wed, Nov 21, 2018 at 11:21:18PM +0100, Jakub Jelinek wrote:
> As I wrote in the PR, before PR81708 commits,

Note, e.g. in 4.8, the stack_protector_* patterns weren't guarded with
something like TARGET_SSP_TLS_GUARD but with !TARGET_HAS_BIONIC,
which just means it was incorrectly implemented for Android initially
(should have been done by forcing there the non-*tls* insns for
!TARGET_HAS_BIONIC rather than failing the optab).

Jakub

[PATCH] Fix -fstack-protector* on darwin/mingw etc. (PR target/85644)

[Jakub Jelinek]

Hi!

As I wrote in the PR, before PR81708 commits,
while i386 defaulted to SSP_TLS rather than SSP_GLOBAL on everything but
Android, the -mstack-protector-guard= switch controlled pretty much
whether the i386.md special stack protector patterns are used (if tls)
or whether generic code is used (global).  These special stack protector
patterns did one thing if TARGET_THREAD_SSP_OFFSET macro was defined
(only defined on glibc targets) - code like:
movq%fs:40, %rax
movq%rax, -8(%rbp)
xorl%eax, %eax
in the prologue and
movq-8(%rbp), %rdx
xorq%fs:40, %rdx
je  .L4
in the epilogue.  If TARGET_THREAD_SSP_OFFSET macro wasn't defined, it would
do instead:
movq.refptr.__stack_chk_guard(%rip), %rax
movq(%rax), %rcx
movq%rcx, -8(%rbp)
xorl%ecx, %ecx
and
movq.refptr.__stack_chk_guard(%rip), %rdx
movq-8(%rbp), %rcx
xorq(%rdx), %rcx
je  .L4
(this is taken from 7.x cross to mingw).
Finally, for Android or when -mstack-protector-guard=global was used, it
emitted:
movq__stack_chk_guard(%rip), %rax
movq%rax, -8(%rbp)
and
movq__stack_chk_guard(%rip), %rdx
cmpq%rdx, %rcx
je  .L4
Note, apart from OS specific details, those =global sequences are similar
to the =tls ones when TARGET_THREAD_SSP_OFFSET is not defined, the main
difference is that the =tls ones are more secure as they clear registers
containing the guard as quickly as possible.  The PR81708 changes dropped
the non-tls special stack_protector_* patterns from i386.md and now =tls
implies really tls, but the default remained, so mingw32 or darwin still
default to tls and just use 0 offset by default.

So, this patch changes the default for mingw32, darwin and everything else
except gnu-user*.h to be =global, and just forces those special i386.md
more secure patterns unconditionally (slightly changing the generated code
on Android, but it is one extra insn in prologue and one fewer in the
epilogue).

With this patch -mstack-protector-guard=tls is really for tls and =global
for pure var access and user can override the defaults on non-glibc targets,
but they should get a default that works there.

Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested with a
cross to mingw, ok for trunk?

2018-11-21  Jakub Jelinek  

PR target/85644
PR target/86832
* config/i386/i386.c (ix86_option_override_internal): Default
ix86_stack_protector_guard to SSP_TLS only if TARGET_THREAD_SSP_OFFSET
is defined.
* config/i386/i386.md (stack_protect_set, stack_protect_set_,
stack_protect_test, stack_protect_test_): Use empty condition
instead of TARGET_SSP_TLS_GUARD.

--- gcc/config/i386/i386.c.jj   2018-11-20 21:39:00.905577452 +0100
+++ gcc/config/i386/i386.c  2018-11-21 18:02:49.448049161 +0100
@@ -4557,8 +4557,13 @@ ix86_option_override_internal (bool main
 
   /* Handle stack protector */
   if (!opts_set->x_ix86_stack_protector_guard)
-opts->x_ix86_stack_protector_guard
-  = TARGET_HAS_BIONIC ? SSP_GLOBAL : SSP_TLS;
+{
+  opts->x_ix86_stack_protector_guard = SSP_GLOBAL;
+#ifdef TARGET_THREAD_SSP_OFFSET
+  if (!TARGET_HAS_BIONIC)
+   opts->x_ix86_stack_protector_guard = SSP_TLS;
+#endif
+}
 
 #ifdef TARGET_THREAD_SSP_OFFSET
   ix86_stack_protector_guard_offset = TARGET_THREAD_SSP_OFFSET;
--- gcc/config/i386/i386.md.jj  2018-11-21 11:45:12.090721862 +0100
+++ gcc/config/i386/i386.md 2018-11-21 18:03:46.166119350 +0100
@@ -19010,7 +19010,7 @@ (define_insn "*prefetch_prefetchwt1"
 (define_expand "stack_protect_set"
   [(match_operand 0 "memory_operand")
(match_operand 1 "memory_operand")]
-  "TARGET_SSP_TLS_GUARD"
+  ""
 {
   rtx (*insn)(rtx, rtx);
 
@@ -19028,7 +19028,7 @@ (define_insn "stack_protect_set_"
UNSPEC_SP_SET))
(set (match_scratch:PTR 2 "=") (const_int 0))
(clobber (reg:CC FLAGS_REG))]
-  "TARGET_SSP_TLS_GUARD"
+  ""
   "mov{}\t{%1, %2|%2, %1}\;mov{}\t{%2, %0|%0, 
%2}\;xor{l}\t%k2, %k2"
   [(set_attr "type" "multi")])
 
@@ -19036,7 +19036,7 @@ (define_expand "stack_protect_test"
   [(match_operand 0 "memory_operand")
(match_operand 1 "memory_operand")
(match_operand 2)]
-  "TARGET_SSP_TLS_GUARD"
+  ""
 {
   rtx flags = gen_rtx_REG (CCZmode, FLAGS_REG);
 
@@ -19059,7 +19059,7 @@ (define_insn "stack_protect_test_"
 (match_operand:PTR 2 "memory_operand" "m")]
UNSPEC_SP_TEST))
(clobber (match_scratch:PTR 3 "="))]
-  "TARGET_SSP_TLS_GUARD"
+  ""
   "mov{}\t{%1, %3|%3, %1}\;xor{}\t{%2, %3|%3, %2}"
   [(set_attr "type" "multi")])
 

Jakub

Why?

[test]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

Why?

[test]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

Why?

[test]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware

[gary_mills at fastmail dot fm]

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

--- Comment #16 from Gary Mills  ---
I have a clue now.  I built gcc-7 on OI-SPARC with the GNU assembler.  The
build
was successful.  xgcc worked, without the ICE.  Clearly the ICE only happens
when gcc-7 is configured with the native assembler.  This is the usual
configuration on SPARC hardware.

Then I built gcc-7 on OI-x86 with the native assembler.  This is the opposite
of
the normal configuration.  It failed with the ICE.  xgcc by itself gets the
same
ICE.

My conclusion is that the ICE only occurs when gcc-7 is configured with the
native
assembler.  It doesn't matter if the hardware is SPARC or x86.  The fatal
configuration is with:

--without-gnu-as --with-as=/usr/bin/as

Something happens in that case that passes a null pointer to functions that
dereference it and cause the ICE.

Note that the assembler is not actually invoked.  My test uses the -S option
that causes the assembly output to be placed in a file.  xgcc still fails if
the
native assembler is configured.

Anybody should be able to reproduce this problem.  My guess is a logic error.

[C++ PATCH] Fix ICE in maybe_explain_implicit_delete (PR c++/88122)

[Jakub Jelinek]

Hi!

On the following testcase we ICE in maybe_explain_implicit_delete, because
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL - there are no user parameters
and ...
>From what I understood, const_p is used only in certain cases like const vs.
non-const copy constructor or assignment operator, if the sfk has no user
parameters, usually parm_type is just the void_type terminating the argument
list and also not really interesting for const_p computation.
So, this patch just arranges to pass false as const_p in this case.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-11-21  Jakub Jelinek  

PR c++/88122
* method.c (maybe_explain_implicit_delete): If
FUNCTION_FIRST_USER_PARMTYPE (decl) is NULL, set const_p to false
instead of ICEing.

* g++.dg/cpp0x/implicit15.C: New test.

--- gcc/cp/method.c.jj  2018-11-16 10:22:18.668258171 +0100
+++ gcc/cp/method.c 2018-11-21 15:42:08.441785625 +0100
@@ -1821,8 +1821,12 @@ maybe_explain_implicit_delete (tree decl
   if (!informed)
{
  tree parms = FUNCTION_FIRST_USER_PARMTYPE (decl);
- tree parm_type = TREE_VALUE (parms);
- bool const_p = CP_TYPE_CONST_P (non_reference (parm_type));
+ bool const_p = false;
+ if (parms)
+   {
+ tree parm_type = TREE_VALUE (parms);
+ const_p = CP_TYPE_CONST_P (non_reference (parm_type));
+   }
  tree raises = NULL_TREE;
  bool deleted_p = false;
  tree scope = push_scope (ctype);
--- gcc/testsuite/g++.dg/cpp0x/implicit15.C.jj  2018-11-21 15:59:29.849741499 
+0100
+++ gcc/testsuite/g++.dg/cpp0x/implicit15.C 2018-11-21 15:58:00.912197089 
+0100
@@ -0,0 +1,11 @@
+// PR c++/88122
+// { dg-do compile { target c++11 } }
+
+struct A {
+  A (...); // { dg-message "candidate" }
+  A ();// { dg-message "candidate" }
+};
+struct B : A {
+  using A::A;  // { dg-error "is ambiguous" }
+   // { dg-message "is implicitly deleted because the default 
definition would be ill-formed" "" { target *-*-* } .-1 }
+} b{3};// { dg-error "use of deleted function" }

Jakub

[C++ PATCH] Improve locations of id-expressions and operator "" (PR c++/87386, take 3)

[Jakub Jelinek]

On Wed, Nov 21, 2018 at 07:49:48PM +0100, Jakub Jelinek wrote:
> So, do you suggest we should instead return
> operator new
> ^~~~
> operator delete []
> ^~
> operator ==
> ^~~
> operator "" _foo
> ^~~~
> ?
> That would mean cp_parser_operator_function_id would need to pass
> location_t start_loc (the start of the operator token) to cp_parser_operator 
> and
> let that create a range in all cases rather than just for operator
> new/delete.

This version of the patch implements that.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2018-11-21  Jakub Jelinek  

PR c++/87386
* parser.c (cp_parser_primary_expression): Use
id_expression.get_location () instead of id_expr_token->location.
Adjust the range from id_expr_token->location to
id_expressio.get_finish ().
(cp_parser_operator_function_id): Pass location of the operator
token down to cp_parser_operator.
(cp_parser_operator): Add start_loc argument, always construct a
location with caret at start_loc and range from start_loc to the
finish of the last token.
gcc/testsuite/
* g++.dg/diagnostic/pr87386.C: New test.
* g++.dg/parse/error17.C: Adjust expected diagnostics.
libstdc++-v3/
* testsuite/20_util/scoped_allocator/69293_neg.cc: Adjust expected
line.
* testsuite/20_util/uses_allocator/cons_neg.cc: Likewise.
* testsuite/20_util/uses_allocator/69293_neg.cc: Likewise.
* testsuite/experimental/propagate_const/requirements2.cc: Likewise.
* testsuite/experimental/propagate_const/requirements3.cc: Likewise.
* testsuite/experimental/propagate_const/requirements4.cc: Likewise.
* testsuite/experimental/propagate_const/requirements5.cc: Likewise.

--- gcc/cp/parser.c.jj  2018-11-21 17:42:18.003216049 +0100
+++ gcc/cp/parser.c 2018-11-21 20:56:43.694344258 +0100
@@ -2312,7 +2312,7 @@ static tree cp_parser_mem_initializer_id
 static cp_expr cp_parser_operator_function_id
   (cp_parser *);
 static cp_expr cp_parser_operator
-  (cp_parser *);
+  (cp_parser *, location_t);
 
 /* Templates [gram.temp] */
 
@@ -5604,7 +5604,7 @@ cp_parser_primary_expression (cp_parser
  /*is_namespace=*/false,
  /*check_dependency=*/true,
  _decls,
- id_expr_token->location);
+ id_expression.get_location ());
/* If the lookup was ambiguous, an error will already have
   been issued.  */
if (ambiguous_decls)
@@ -5675,7 +5675,7 @@ cp_parser_primary_expression (cp_parser
if (parser->local_variables_forbidden_p
&& local_variable_p (decl))
  {
-   error_at (id_expr_token->location,
+   error_at (id_expression.get_location (),
  "local variable %qD may not appear in this context",
  decl.get_value ());
return error_mark_node;
@@ -5694,7 +5694,8 @@ cp_parser_primary_expression (cp_parser
 id_expression.get_location ()));
if (error_msg)
  cp_parser_error (parser, error_msg);
-   decl.set_location (id_expr_token->location);
+   decl.set_location (id_expression.get_location ());
+   decl.set_range (id_expr_token->location, id_expression.get_finish ());
return decl;
   }
 
@@ -15011,11 +15012,12 @@ cp_parser_mem_initializer_id (cp_parser*
 static cp_expr
 cp_parser_operator_function_id (cp_parser* parser)
 {
+  location_t start_loc = cp_lexer_peek_token (parser->lexer)->location;
   /* Look for the `operator' keyword.  */
   if (!cp_parser_require_keyword (parser, RID_OPERATOR, RT_OPERATOR))
 return error_mark_node;
   /* And then the name of the operator itself.  */
-  return cp_parser_operator (parser);
+  return cp_parser_operator (parser, start_loc);
 }
 
 /* Return an identifier node for a user-defined literal operator.
@@ -15049,7 +15051,7 @@ cp_literal_operator_id (const char* name
human-readable spelling of the identifier, e.g., `operator +'.  */
 
 static cp_expr
-cp_parser_operator (cp_parser* parser)
+cp_parser_operator (cp_parser* parser, location_t start_loc)
 {
   tree id = NULL_TREE;
   cp_token *token;
@@ -15058,7 +15060,7 @@ cp_parser_operator (cp_parser* parser)
   /* Peek at the next token.  */
   token = cp_lexer_peek_token (parser->lexer);
 
-  location_t start_loc = token->location;
+  location_t end_loc = token->location;
 
   /* Figure out which operator we have.  */
   enum tree_code op = ERROR_MARK;
@@ -15077,7 +15079,7 @@ cp_parser_operator (cp_parser* parser)
  break;
 
/* Consume the `new' or `delete' token.  */
-   location_t end_loc = cp_lexer_consume_token (parser->lexer)->location;
+   end_loc = 

Why?

[test]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

Why?

[test]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

Why?

[test]

Hi,
Please can you reply to my previous enquiry.
Thanks
Wayne.

[Bug libstdc++/80506] Wrong magic number in std::gamma_distribution

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from emsr at gcc dot gnu.org ---
2018-05-07  Edward Smith-Rowland  <3dw...@verizon.net>

Moar PR libstdc++/80506
* include/bits/random.tcc (gamma_distribution::__generate_impl()):
Fix magic number used in loop condition.

[Bug libstdc++/83140] assoc_legendre returns negated value when m is odd

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from emsr at gcc dot gnu.org ---
2018-05-10  Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/83140 - assoc_legendre returns negated value when m is odd
* include/tr1/legendre_function.tcc (__assoc_legendre_p): Add __phase
argument defaulted to +1.  Doxy comments on same.
* testsuite/special_functions/02_assoc_legendre/
check_value.cc: Regen.
* testsuite/tr1/5_numerical_facilities/special_functions/
02_assoc_legendre/check_value.cc: Regen.

[Bug libstdc++/83566] cyl_bessel_j returns wrong result for x>1000 for high orders.

[emsr at gcc dot gnu.org]

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

emsr at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from emsr at gcc dot gnu.org ---
2018-11-16  Michele Pezzutti 
Edward Smith-Rowland  <3dw...@verizon.net>

PR libstdc++/83566 - cyl_bessel_j returns wrong result for x>1000
for high orders.
* include/tr1/bessel_function.tcc: Perform no fewer than nu/2
iterations
of the asymptotic series (nu is the Bessel order).
* testsuite/tr1/5_numerical_facilities/special_functions/
09_cyl_bessel_j/check_value.cc: Add tests at nu=100, 1000<=x<=2000.
* testsuite/tr1/5_numerical_facilities/special_functions/   
11_cyl_neumann/check_value.cc: Ditto.
* testsuite/special_functions/08_cyl_bessel_j/check_value.cc: Ditto.
* testsuite/special_functions/10_cyl_neumann/check_value.cc: Ditto.

[Bug preprocessor/44317] ,##__VA_ARGS__ comma not eaten with -std=c++0x

[emsr at gcc dot gnu.org]

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

--- Comment #10 from emsr at gcc dot gnu.org ---
I'll look at updating the pedantic warn patch.

Re: [PATCH, LRA]: Revert the revert of removal of usless move insns.

[Vladimir Makarov]

On 11/21/2018 02:33 PM, Uros Bizjak wrote:

Hello!

Before the recent patch to post-reload mode switching, vzeroupper
insertion depended on the existence of the return copy instructions
pair in functions that return a value. The first instruction in the
pair represents a move to a function return hard register, and the
second was a USE of the function return hard register. Sometimes a nop
move was generated (e.g. %eax->%eax) for the first instruction of the
return copy instructions pair and the patch [1] teached LRA  to remove
these useless instructions on the fly.

The removal caused optimize mode switching to trigger the assert,
since the first instruction of a return pair was not found. The
relevant part of the patch was later reverted. With the recent
optimize mode switching patch, this is no longer necessary for
vzeroupper insertion pass, so attached patch reverts the revert.

2018-11-21  Uros Bizjak  

 Revert the revert:
 2013-10-26  Vladimir Makarov  

 Revert:
 2013-10-25  Vladimir Makarov  

 * lra-spills.c (lra_final_code_change): Remove useless move insns.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

OK for mainline?

Sure. Thank you, Uros.

[1] https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02208.html

Uros.

[Bug lto/88142] [9 Regression] ICE in lto_warn at ipa-devirt.c:1020 since r265519

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-21
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

[Bug lto/88142] New: [9 Regression] ICE in lto_warn at ipa-devirt.c:1020 since r265519

[marxin at gcc dot gnu.org]

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

Bug ID: 88142
   Summary: [9 Regression] ICE in lto_warn at ipa-devirt.c:1020
since r265519
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ cat ice1.ii
struct wiimote_t {
  const int unid;
} * a;

$ cat ice2.ii
struct wiimote_t;
class a {
  wiimote_t *b;
  a();
};
struct wiimote_t {
  int unid;
};
a::a() { b = __null; }

$ g++ ice1.ii ice2.ii -flto
lto1: internal compiler error: tree check: expected tree that contains ‘decl
minimal’ structure, have ‘integer_type’ in warn_odr, at ipa-devirt.c:1020
0x6b79c0 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.c:9924
0x6171ca contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/marxin/Programming/gcc/gcc/tree.h:3268
0x6171ca warn_odr
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:1020
0xa064ce type_variants_equivalent_p
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:651
0xa0c389 odr_subtypes_equivalent_p
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:701
0xa0d4e2 odr_types_equivalent_p
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:1591
0xa0a290 add_type_duplicate
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:1894
0xa0a290 get_odr_type(tree_node*, bool)
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2075
0xa0e8d9 register_odr_type(tree_node*)
/home/marxin/Programming/gcc/gcc/ipa-devirt.c:2180
0x78c176 lto_read_decls
/home/marxin/Programming/gcc/gcc/lto/lto.c:1900
0x78d42e lto_file_finalize
/home/marxin/Programming/gcc/gcc/lto/lto.c:2134
0x78d42e lto_create_files_from_ids
/home/marxin/Programming/gcc/gcc/lto/lto.c:2144
0x78d42e lto_file_read
/home/marxin/Programming/gcc/gcc/lto/lto.c:2185
0x78d42e read_cgraph_and_symbols
/home/marxin/Programming/gcc/gcc/lto/lto.c:2865
0x78d42e lto_main()
/home/marxin/Programming/gcc/gcc/lto/lto.c:3401

[PING^3] Re: [PATCH 1/3] Support instrumenting returns of instrumented functions

[Andi Kleen]

Andi Kleen  writes:

Ping^3!

> Andi Kleen  writes:
>
> Ping!^2
>
>> Andi Kleen  writes:
>>
>> Ping!
>>
>>> From: Andi Kleen 
>>>
>>> When instrumenting programs using __fentry__ it is often useful
>>> to instrument the function return too. Traditionally this
>>> has been done by patching the return address on the stack
>>> frame on entry. However this is fairly complicated (trace
>>> function has to emulate a stack) and also slow because
>>> it causes a branch misprediction on every return.
>>>
>>> Add an option to generate call or nop instrumentation for
>>> every return instead, including patch sections.
>>>
>>> This will increase the program size slightly, but can be a
>>> lot faster and simpler.
>>>
>>> This version only instruments true returns, not sibling
>>> calls or tail recursion. This matches the semantics of the
>>> original stack.
>>>
>>> gcc/:
>>>
>>> 2018-11-04  Andi Kleen  
>>>
>>> * config/i386/i386-opts.h (enum instrument_return): Add.
>>> * config/i386/i386.c (output_return_instrumentation): Add.
>>> (ix86_output_function_return): Call output_return_instrumentation.
>>> (ix86_output_call_insn): Call output_return_instrumentation.
>>> * config/i386/i386.opt: Add -minstrument-return=.
>>> * doc/invoke.texi (-minstrument-return): Document.
>>>
>>> gcc/testsuite/:
>>>
>>> 2018-11-04  Andi Kleen  
>>>
>>> * gcc.target/i386/returninst1.c: New test.
>>> * gcc.target/i386/returninst2.c: New test.
>>> * gcc.target/i386/returninst3.c: New test.
>>> ---
>>>  gcc/config/i386/i386-opts.h |  6 
>>>  gcc/config/i386/i386.c  | 36 +
>>>  gcc/config/i386/i386.opt| 21 
>>>  gcc/doc/invoke.texi | 14 
>>>  gcc/testsuite/gcc.target/i386/returninst1.c | 14 
>>>  gcc/testsuite/gcc.target/i386/returninst2.c | 21 
>>>  gcc/testsuite/gcc.target/i386/returninst3.c |  9 ++
>>>  7 files changed, 121 insertions(+)
>>>  create mode 100644 gcc/testsuite/gcc.target/i386/returninst1.c
>>>  create mode 100644 gcc/testsuite/gcc.target/i386/returninst2.c
>>>  create mode 100644 gcc/testsuite/gcc.target/i386/returninst3.c
>>>
>>> diff --git a/gcc/config/i386/i386-opts.h b/gcc/config/i386/i386-opts.h
>>> index 46366cbfa72..35e9413100e 100644
>>> --- a/gcc/config/i386/i386-opts.h
>>> +++ b/gcc/config/i386/i386-opts.h
>>> @@ -119,4 +119,10 @@ enum indirect_branch {
>>>indirect_branch_thunk_extern
>>>  };
>>>  
>>> +enum instrument_return {
>>> +  instrument_return_none = 0,
>>> +  instrument_return_call,
>>> +  instrument_return_nop5
>>> +};
>>> +
>>>  #endif
>>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>>> index f9ef0b4445b..f7cd94a8139 100644
>>> --- a/gcc/config/i386/i386.c
>>> +++ b/gcc/config/i386/i386.c
>>> @@ -28336,12 +28336,47 @@ ix86_output_indirect_jmp (rtx call_op)
>>>  return "%!jmp\t%A0";
>>>  }
>>>  
>>> +/* Output return instrumentation for current function if needed.  */
>>> +
>>> +static void
>>> +output_return_instrumentation (void)
>>> +{
>>> +  if (ix86_instrument_return != instrument_return_none
>>> +  && flag_fentry
>>> +  && !DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (cfun->decl))
>>> +{
>>> +  if (ix86_flag_record_return)
>>> +   fprintf (asm_out_file, "1:\n");
>>> +  switch (ix86_instrument_return)
>>> +   {
>>> +   case instrument_return_call:
>>> + fprintf (asm_out_file, "\tcall\t__return__\n");
>>> + break;
>>> +   case instrument_return_nop5:
>>> + /* 5 byte nop: nopl 0(%[re]ax,%[re]ax,1)  */
>>> + fprintf (asm_out_file, ASM_BYTE "0x0f, 0x1f, 0x44, 0x00, 0x00\n");
>>> + break;
>>> +   case instrument_return_none:
>>> + break;
>>> +   }
>>> +
>>> +  if (ix86_flag_record_return)
>>> +   {
>>> + fprintf (asm_out_file, "\t.section __return_loc, \"a\",@progbits\n");
>>> + fprintf (asm_out_file, "\t.%s 1b\n", TARGET_64BIT ? "quad" : "long");
>>> + fprintf (asm_out_file, "\t.previous\n");
>>> +   }
>>> +}
>>> +}
>>> +
>>>  /* Output function return.  CALL_OP is the jump target.  Add a REP
>>> prefix to RET if LONG_P is true and function return is kept.  */
>>>  
>>>  const char *
>>>  ix86_output_function_return (bool long_p)
>>>  {
>>> +  output_return_instrumentation ();
>>> +
>>>if (cfun->machine->function_return_type != indirect_branch_keep)
>>>  {
>>>char thunk_name[32];
>>> @@ -28454,6 +28489,7 @@ ix86_output_call_insn (rtx_insn *insn, rtx call_op)
>>>  
>>>if (SIBLING_CALL_P (insn))
>>>  {
>>> +  output_return_instrumentation ();
>>>if (direct_p)
>>> {
>>>   if (ix86_nopic_noplt_attribute_p (call_op))
>>> diff --git a/gcc/config/i386/i386.opt b/gcc/config/i386/i386.opt
>>> index e7fbf9b6f99..5925b75244f 100644
>>> --- a/gcc/config/i386/i386.opt
>>> +++ b/gcc/config/i386/i386.opt
>>> @@ -1063,3 +1063,24 @@ Support WAITPKG built-in functions and code 
>>> generation.
>>>  mcldemote

Re: Question about make_extraction() in combine.c

[Michael Eager]

On 11/21/18 11:47, Segher Boessenkool wrote:

On Wed, Nov 21, 2018 at 08:52:21AM -0800, Michael Eager wrote:

On 11/21/2018 08:33 AM, Segher Boessenkool wrote:

On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:

The internal RTL should not be dictating what the target arch can or
cannot implement.  Reload should insert any needed conversions,
especially ones which narrow the size.


Well, that depends.  A zero_extract of mem is only defined for byte_mode,
just like SET is only defined for VOIDmode (on the SET itself, not its
args).  Because this is guaranteed, nothing in GCC ever needs to check
this.  That is the theory of course; in reality quite a few targets have
used other modes for the mem in a zero_extract, and this seems to have
mostly worked.


This restriction on zero_extract MEM args (and only MEM) seems to be
completely arbitrary.  What is it about the operation of extracting a
bit field which makes it dependent on the memory access size?


If the mode is required to be byte_mode, then all code dealing with it
can assume it to be byte_mode.  Without first having to check it, and
without having to handle other modes.


Essentially all other RTL operations place no restriction on mode.
If there are no arbitrary mode restrictions, then no checking is
required.




The value of SET is VOIDmode, in that it has no value.   Not sure what
your point is here.


See above.


As another example, closer by, an extract length of 0 is not allowed
either, for zero_extract.  And this *did* cause problems recently.


This is a restriction which does make sense.  It isn't clear what
the value of a zero length field is, or how to represent it.  If
something is undefined, then there is a strong argument for making is
invalid.  (Are there architectures which have instructions which extract
a zero length bit field?  I doubt it.)


It doesn't matter if you (or I, or anyone) think it makes sense; the rules
are the rules.  If you want to change the rules, then post a patch.


These are not immutable rules delivered by some deity.  Rules which
have no discernible value or purpose can and should be changed.

A patch is being tested.


Why was it documented as requiring byte mode?  Was this changed, just
the documentation was not updated?


Ancient history.  As Jeff said, perhaps an architectural requirement of
VAX or m68k.  This wasn't changed, as far as I'm aware.


So a mem in a *_extract is still required to be byte_mode you say? >
I don't think we can change this in the documentation without reviewing
all code that deals with *_extract to see if this will work :-/


Have at it.

--
Michael Eagerea...@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306

[Bug rtl-optimization/85925] [7/8/9 regression] compilation of masking with 257 goes wrong in combine at -02

[jakub at gcc dot gnu.org]

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

--- Comment #32 from Jakub Jelinek  ---
Author: jakub
Date: Wed Nov 21 20:45:59 2018
New Revision: 266357

URL: https://gcc.gnu.org/viewcvs?rev=266357=gcc=rev
Log:
PR rtl-optimization/85925
* gcc.c-torture/execute/20181120-1.c: Require effective target
int32plus.
(u): New variable.
(main): Compare d against u.f1 rather than 0x101.  Use 0x4030201
instead of 0x10101.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.c-torture/execute/20181120-1.c

Re: [PATCH 1/7][v2][MSP430][TESTSUITE] Tweak dg-directives for msp430-elf

[Jozef Lawrynowicz]

On Wed, 21 Nov 2018 20:19:29 +0100
Rainer Orth  wrote:

> new effective-target keywords always need documenting in
> gcc/doc/sourcebuild.texi.
> 
>   Rainer
> 

Whoops, thanks for the heads up, fixed in attached.

I'll add documentation for the keywords added in the other patches as well.

Jozef
>From be96391838c65b297589ac47ad6347f55ea713c0 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Thu, 8 Nov 2018 18:55:57 +
Subject: [PATCH] [TESTSUITE][MSP430] Tweak dg-directives for msp430-elf

2018-11-21  Jozef Lawrynowicz  

	gcc/ChangeLog:

	* doc/sourcebuild.texi: Document check_effective_target_int_eq_float
	and check_effective_target_ptr_eq_long.

	gcc/testsuite/ChangeLog:

	* lib/target-supports.exp
	(check_effective_target_logical_op_short_circuit): Add msp430.
	(check_effective_target_int_eq_float): New. 
	(check_effective_target_ptr_eq_long): New. 
	* c-c++-common/pr41779.c: Require int_eq_float for dg-warning tests.
	* c-c++-common/pr57371-2.c: XFAIL optimized dump scan when
	sizeof (float) != sizeof (int).
	* gcc.dg/pr84670-4.c: Require ptr_eq_long.
	* gcc.dg/pr85859.c: Likewise.
	* gcc.dg/Wno-frame-address.c: Skip for msp430-elf.
	* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise.
	* gcc.dg/ifcvt-4.c: Likewise.
	* gcc.dg/pr34856.c: Likewise.
	* gcc.dg/builtin-apply2.c: Likewise.
	* gcc.dg/tree-ssa/ssa-dse-26.c: Likewise.
	* gcc.dg/attr-alloc_size-11.c: Remove dg-warning XFAIL for msp430.
	* gcc.dg/tree-ssa/20040204-1.c: Likewise.
	* gcc.dg/compat/struct-by-value-16a_x.c: Build at -O1 for msp430
	so it fits.
	* gcc.dg/lto/20091013-1_0.c: Require ptr_eq_long.
	* gcc.dg/lto/20091013-1_1.c: Remove xfail-if for when
	sizeof(void *) != sizeof(long).
	* gcc.dg/lto/20091013-1_2.c: Likewise.
	* gcc.dg/tree-ssa/loop-1.c: Fix expected dg-final behaviour for msp430.
	* gcc.dg/tree-ssa/gen-vect-25.c: Likewise.
	* gcc.dg/tree-ssa/gen-vect-11.c: Likewise.
	* gcc.dg/tree-ssa/loop-35.c: Likewise.
	* gcc.dg/tree-ssa/pr23455.c: Likewise.
	* gcc.dg/weak/typeof-2.c: Likewise.
	* gcc.target/msp430/interrupt_fn_placement.c: Skip for 430 ISA.
	* gcc.target/msp430/pr78818-data-region.c: Fix scan-assembler text.
	* gcc.target/msp430/pr79242.c: Don't skip for -msmall.
	* gcc.target/msp430/special-regs.c: Use "__asm__" instead of "asm".
---
 gcc/doc/sourcebuild.texi   |  6 ++
 gcc/testsuite/c-c++-common/pr41779.c   |  6 +++---
 gcc/testsuite/c-c++-common/pr57371-2.c |  2 +-
 gcc/testsuite/gcc.dg/Wno-frame-address.c   |  2 +-
 gcc/testsuite/gcc.dg/attr-alloc_size-11.c  |  4 ++--
 gcc/testsuite/gcc.dg/builtin-apply2.c  |  2 +-
 .../gcc.dg/compat/struct-by-value-16a_x.c  |  2 ++
 gcc/testsuite/gcc.dg/ifcvt-4.c |  2 +-
 gcc/testsuite/gcc.dg/lto/20091013-1_0.c|  1 +
 gcc/testsuite/gcc.dg/lto/20091013-1_1.c|  1 -
 gcc/testsuite/gcc.dg/lto/20091013-1_2.c|  1 -
 gcc/testsuite/gcc.dg/pr34856.c |  1 +
 gcc/testsuite/gcc.dg/pr84670-4.c   |  1 +
 gcc/testsuite/gcc.dg/pr85859.c |  1 +
 .../gcc.dg/torture/stackalign/builtin-apply-2.c|  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11.c|  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c|  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/loop-1.c |  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/loop-35.c|  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/pr23455.c|  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c |  1 +
 gcc/testsuite/gcc.dg/weak/typeof-2.c   |  2 ++
 .../gcc.target/msp430/interrupt_fn_placement.c |  1 +
 .../gcc.target/msp430/pr78818-data-region.c|  3 ++-
 gcc/testsuite/gcc.target/msp430/pr79242.c  |  2 +-
 gcc/testsuite/gcc.target/msp430/special-regs.c |  8 
 gcc/testsuite/lib/target-supports.exp  | 24 ++
 28 files changed, 67 insertions(+), 28 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 7487977..bca5db3 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1360,6 +1360,12 @@ Target has @code{int} that is 16 bits or shorter.
 @item long_neq_int
 Target has @code{int} and @code{long} with different sizes.
 
+@item int_eq_float
+Target has @code{int} and @code{float} with the same size.
+
+@item ptr_eq_long
+Target has pointers (@code{void *}) and @code{long} with the same size.
+
 @item large_double
 Target supports @code{double} that is longer than @code{float}.
 
diff --git a/gcc/testsuite/c-c++-common/pr41779.c b/gcc/testsuite/c-c++-common/pr41779.c
index c42a0f5..a80bf78 100644
--- a/gcc/testsuite/c-c++-common/pr41779.c
+++ b/gcc/testsuite/c-c++-common/pr41779.c
@@ -1,6 +1,6 @@
 /* PR41779: Wconversion cannot see through real*integer promotions. */
 /* { dg-do compile } */
-/* { dg-skip-if "doubles are floats" { "avr-*-*" } } 

[Bug c++/86397] [7/8/9 Regression] g++ ICE at on valid code in nothrow_spec_p, at cp/except.c:1158

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva  changed:

   What|Removed |Added

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

--- Comment #2 from Alexandre Oliva  ---
Created attachment 45062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45062=edit
candidate patch

Re: [PATCH] Fix up 20181120-1.c testcase on big-endian (PR rtl-optimization/85925, take 2)

[Segher Boessenkool]

On Wed, Nov 21, 2018 at 08:12:44PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 21, 2018 at 12:07:51PM -0600, Segher Boessenkool wrote:
> > > Admittedly, it might be better if the initializer was 0x1010101 or say
> > > 0x4030201 because on big endian in particular 0x10101 has the top 15 bits
> > > all zero and thus that is what is in u.f1, so if the bug can be reproduced
> > > with the combine.c + rtlanal.c fix reverted with 0x4030201, it would be
> > > better to use that value (in both spots).
> > 
> > Yeah good point.
> 
> I've now managed to test this with a cross to armv7hl (scped to an arm box)
> with and without the rtlanal.c + combine.c change reverted and on
> powerpc64-linux as example of big-endian, on armv7hl it still fails with
> the changes reverted, otherwise it succeeds on both.  The test also needs
> 32-bit int target (previously just 17-bit or more, so I've added effective
> target).

It fixes the problem on powerpc64-linux {-m32,-m64}.  Thanks :-)


Segher

[Bug libbacktrace/88063] Libbacktrace leak on dwarf read failure

[ian at airs dot com]

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

--- Comment #11 from Ian Lance Taylor  ---
Sorry, I've gotten confused.  Can you attach one single patch from trunk? 
Thanks.

[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)

[segher at gcc dot gnu.org]

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

--- Comment #18 from Segher Boessenkool  ---
Your "trivial rewrite" does not work at all (you didn't modify "h").

It isn't trivial to avoid this warning at all, which was half of my point.

The other half is that we should not warn that the normal use of a GCC C
extension would be "bad" or a "security problem" when it is neither.  Yes,
marking the whole stack executable for the whole lifetime of a process when
something in your program may use a trampoline is less than optimal, may
make some exploits easier to pull off.  But that is all.

Making -Wall complain about it in all cases will only result in more people
not using nested functions, although those are a useful C language extension
(and required for some other languages, so GCC has to implement it *anyway*),
while not actually giving them any more security.

Nested functions are not insecure.  Trampolines are not insecure.  Executable
trampolines are not insecure.  Executable trampolines on the stack are not
insecure.  Executable *everything* on the stack is not insecure, on many
architectures.  The only thing is that having the whole stack executable makes
it easier to exploit other problems, on other architectures.

[Bug middle-end/88129] Two blockage insns are emited in the function epilogue

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #6)
> Fixed for gcc-9.0, no plan to backport.

Let's keep the PR open for the eventual removal of the remaining blockage
instruction for targets that emit unwind information in the epilogue.

[Bug middle-end/88129] Two blockage insns are emited in the function epilogue

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #6 from Uroš Bizjak  ---
Fixed for gcc-9.0, no plan to backport.

[Bug middle-end/88129] Two blockage insns are emited in the function epilogue

[uros at gcc dot gnu.org]

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

--- Comment #5 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 21 20:18:45 2018
New Revision: 266356

URL: https://gcc.gnu.org/viewcvs?rev=266356=gcc=rev
Log:
PR middle-end/88129
* function.c (expand_function_end): Do not emit extra blockage insn.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.c

[PATCH, i386]: Fix PR85667, ms_abi rules aren't followed when returning short structs with float values

[Uros Bizjak]

> We don't have the commit access ,can  someone please commit for us ?
>
> ~Umesh
>
> On Wed, Nov 21, 2018, 18:37 Jakub Jelinek 
> > On Wed, Nov 21, 2018 at 06:06:41PM +0530, Umesh Kalappa wrote:
> > > Thank you for the inputs and please find the attachment for the update
> > patch.
> >
> > LGTM.

Committed to mainline SVN.

Thanks,
Uros.

[Bug target/85667] (x86_64) ms_abi rules aren't followed when returning short structs with float values

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Nov 21 20:09:56 2018
New Revision: 266355

URL: https://gcc.gnu.org/viewcvs?rev=266355=gcc=rev
Log:
PR target/85667
* config/i386/i386.c (function_value_ms_64): Return AX_REG instead
of FIRST_SSE_REG for 4 or 8 byte modes.

testsuite/ChangeLog:

PR target/85667
* gcc.target/pr85667-1.c: New testcase.
* gcc.target/pr85667-2.c: New testcase.
* gcc.target/pr85667-3.c: New testcase.
* gcc.target/pr85667-4.c: New testcase.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr85667-1.c
trunk/gcc/testsuite/gcc.target/i386/pr85667-2.c
trunk/gcc/testsuite/gcc.target/i386/pr85667-3.c
trunk/gcc/testsuite/gcc.target/i386/pr85667-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH, middle-end]: Fix PR88129, Two blockage insns are emitted in the function epilogue

[Richard Biener]

On November 21, 2018 8:44:46 PM GMT+01:00, Uros Bizjak  
wrote:
>Hello!
>
>Attached patch removes extra blockage insn generation. For the
>software archaeology, please see the PR [1], where it was determined,
>that the removed part is probably a dataflow branch to trunk merge
>oversight.
>
>2018-11-21  Uros Bizjak  
>
>PR middle-end/88129
>   * function.c (expand_function_end): Do not emit extra blockage insn.
>
>Patch was bootstrapped and regression tested on x86_64-linux-gnu
>{,-m32} for all default languages, obj-c++ and go.
>
>OK for mainline?

OK. 

Richard. 

>[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129
>
>Uros.

Re: Question about make_extraction() in combine.c

[Segher Boessenkool]

On Wed, Nov 21, 2018 at 08:52:21AM -0800, Michael Eager wrote:
> On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
> >On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
> >>The internal RTL should not be dictating what the target arch can or
> >>cannot implement.  Reload should insert any needed conversions,
> >>especially ones which narrow the size.
> >
> >Well, that depends.  A zero_extract of mem is only defined for byte_mode,
> >just like SET is only defined for VOIDmode (on the SET itself, not its
> >args).  Because this is guaranteed, nothing in GCC ever needs to check
> >this.  That is the theory of course; in reality quite a few targets have
> >used other modes for the mem in a zero_extract, and this seems to have
> >mostly worked.
> 
> This restriction on zero_extract MEM args (and only MEM) seems to be
> completely arbitrary.  What is it about the operation of extracting a
> bit field which makes it dependent on the memory access size?

If the mode is required to be byte_mode, then all code dealing with it
can assume it to be byte_mode.  Without first having to check it, and
without having to handle other modes.

> The value of SET is VOIDmode, in that it has no value.   Not sure what
> your point is here.

See above.

> >As another example, closer by, an extract length of 0 is not allowed
> >either, for zero_extract.  And this *did* cause problems recently.
> 
> This is a restriction which does make sense.  It isn't clear what
> the value of a zero length field is, or how to represent it.  If
> something is undefined, then there is a strong argument for making is
> invalid.  (Are there architectures which have instructions which extract
> a zero length bit field?  I doubt it.)

It doesn't matter if you (or I, or anyone) think it makes sense; the rules
are the rules.  If you want to change the rules, then post a patch.

> >Why was it documented as requiring byte mode?  Was this changed, just
> >the documentation was not updated?
> 
> Ancient history.  As Jeff said, perhaps an architectural requirement of
> VAX or m68k.  This wasn't changed, as far as I'm aware.

So a mem in a *_extract is still required to be byte_mode you say?

I don't think we can change this in the documentation without reviewing
all code that deals with *_extract to see if this will work :-/


Segher

[PATCH, middle-end]: Fix PR88129, Two blockage insns are emitted in the function epilogue

[Uros Bizjak]

Hello!

Attached patch removes extra blockage insn generation. For the
software archaeology, please see the PR [1], where it was determined,
that the removed part is probably a dataflow branch to trunk merge
oversight.

2018-11-21  Uros Bizjak  

PR middle-end/88129
* function.c (expand_function_end): Do not emit extra blockage insn.

Patch was bootstrapped and regression tested on x86_64-linux-gnu
{,-m32} for all default languages, obj-c++ and go.

OK for mainline?

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88129

Uros.
diff --git a/gcc/function.c b/gcc/function.c
index 302438323c87..44ad57840440 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -5296,14 +5296,6 @@ expand_function_end (void)
   if (flag_exceptions)
sjlj_emit_function_exit_after (get_last_insn ());
 }
-  else
-{
-  /* We want to ensure that instructions that may trap are not
-moved into the epilogue by scheduling, because we don't
-always emit unwind information for the epilogue.  */
-  if (cfun->can_throw_non_call_exceptions)
-   emit_insn (gen_blockage ());
-}
 
   /* If this is an implementation of throw, do what's necessary to
  communicate between __builtin_eh_return and the epilogue.  */

Re: Improve relocation

[Marc Glisse]

ping?

On Fri, 26 Oct 2018, Marc Glisse wrote:


Hello,

here are some tweaks so that I can usefully mark deque as trivially 
relocatable. It includes more noexcept(auto) madness. For __relocate_a_1, I 
should also test if copying, ++ and != are noexcept, but I wanted to ask 
first because there might be restrictions on what iterators are allowed to 
do, even if I didn't see them. Also, the current code already ignores those, 
so it may as well be fixed in another patch.


Allocators are complicated. I specialized only for the default allocator, 
because that's by far the one that is used the most, and I have much less 
risk of getting it wrong. Some allocator expert is welcome to make a better 
test. I do not know in details how deque is implemented. A quick look seemed 
to show that trivial relocation should be fine, but I would appreciate a 
confirmation.


The extra parameter for __is_trivially_relocatable is not used, but I expect 
it will be as soon as the specializations of __is_trivially_relocatable 
become more advanced.


If I use or specialize __is_trivially_relocatable in many places, this forces 
to #include bits/stl_uninitialized.h in many places. I wonder if I should 
move some of that stuff. Since I may use it in std::swap, bits/move.h looks 
like a sensible place for the core pieces (__is_trivially_relocatable, and 
__relocate_object if I ever create that). That or type_traits.


Regtested on gcc112. I manually checked that there was a speed-up for 
operations on vector>, although doing any kind of benchmarking on 
gcc112 is hard, I'll test locally next time.


2018-10-26  Marc Glisse  

PR libstdc++/87106
* include/bits/stl_algobase.h: Include .
(__niter_base): Add noexcept specification.
* include/bits/stl_deque.h: Include .
(__is_trivially_relocatable): Specialize for deque.
* include/bits/stl_iterator.h: Include .
(__niter_base): Add noexcept specification.
* include/bits/stl_uninitialized.h (__is_trivially_relocatable):
Add parameter for meta-programming.
(__relocate_a_1, __relocate_a): Add noexcept specification.
* include/bits/stl_vector.h (__use_relocate): Test __relocate_a.


--
Marc Glisse

[Bug c++/88118] GCC keeps unnecessary calls to new

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse  ---
"An implementation is allowed to omit a call to a replaceable global allocation
function" (not any operator new) so I am not sure DECL_IS_OPERATOR_NEW is the
right test.

[Bug fortran/88124] Wrong results with procedure in seperate file

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-11-21
 Ever confirmed|0   |1

--- Comment #10 from Thomas Koenig  ---
(In reply to Steve Kargl from comment #8)
> On Wed, Nov 21, 2018 at 08:49:55AM +, tkoenig at gcc dot gnu.org wrote:
> > 
> > --- Comment #6 from Thomas Koenig  ---
> > The type has SEQUENCE, so I think this should actually work... or did I miss
> > something here?
> > 
> 
> Remove the INCLUDE from the problem, and consider
> 
> program foo
>type aaa
>   integer i
>end type aaa
>type(aaa) a
>call bar(a)
>print *, a%i
> end program foo
> 
> subroutine foo(a)
>type aaa
>   character(4) i
>end type aaa
>type(aaa) a
>a%i = 'abcd'
> end subroutine foo
> 
> Put each unit in its own file, compile each separately, and link.
> type aaa is clearly not the same both unit.

Correct.

> Do you expect to link 
> and execute the program?

No.

> You can now change character(4) to integer.
> How is the compiler to know that the types are the same as the types
> are in different namespaces.

Not for your example.

However, the original test case had SEQUENCE in the type
definition.

Here is 4.5.2.4 from F2008:

4.5.2.4 Determination of derived types

Derived-type definitions with the same type name may appear in different
scoping units, in which case they might be independent and describe different
derived types or they might describe the same type.

Two data entities have the same type if they are declared with reference to the
same derived-type definition. Data entities also have the same type if they are
declared with reference to different derived-type definitions that specify the
same type name, all have the SEQUENCE attribute or all have the BIND attribute,
have no components with PRIVATE accessibility, and have type parameters and
components that agree in order, name, and attributes. Otherwise, they are of
different derived types. [Rest about PRIVATE elided]

So, the original test case fulfilled the condition of 4.5.2.4, and the two
types in the different scoping unit did indeed describe the same type.


> Sure, it may compile, link, and execute
> but I think that is undefined behavior.  I also think SEQUENCE is a
> red herring here, as its only purpose is to restrict a compiler from
> re-ordering components in a type with multiple components. 

> The fix for the person in fortran@ is trivially stupid.  Use a module.

It certainly is a workaround, and the definitely preferred way to do
it, but what he showed was correct.

[PATCH, LRA]: Revert the revert of removal of usless move insns.

[Uros Bizjak]

Hello!

Before the recent patch to post-reload mode switching, vzeroupper
insertion depended on the existence of the return copy instructions
pair in functions that return a value. The first instruction in the
pair represents a move to a function return hard register, and the
second was a USE of the function return hard register. Sometimes a nop
move was generated (e.g. %eax->%eax) for the first instruction of the
return copy instructions pair and the patch [1] teached LRA  to remove
these useless instructions on the fly.

The removal caused optimize mode switching to trigger the assert,
since the first instruction of a return pair was not found. The
relevant part of the patch was later reverted. With the recent
optimize mode switching patch, this is no longer necessary for
vzeroupper insertion pass, so attached patch reverts the revert.

2018-11-21  Uros Bizjak  

Revert the revert:
2013-10-26  Vladimir Makarov  

Revert:
2013-10-25  Vladimir Makarov  

* lra-spills.c (lra_final_code_change): Remove useless move insns.

Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

OK for mainline?

[1] https://gcc.gnu.org/ml/gcc-patches/2013-10/msg02208.html

Uros.
diff --git a/gcc/lra-spills.c b/gcc/lra-spills.c
index 33caf9f45649..008d7399687d 100644
--- a/gcc/lra-spills.c
+++ b/gcc/lra-spills.c
@@ -740,6 +740,7 @@ lra_final_code_change (void)
   int i, hard_regno;
   basic_block bb;
   rtx_insn *insn, *curr;
+  rtx set;
   int max_regno = max_reg_num ();
 
   for (i = FIRST_PSEUDO_REGISTER; i < max_regno; i++)
@@ -818,5 +819,19 @@ lra_final_code_change (void)
  }
  if (insn_change_p)
lra_update_operator_dups (id);
+
+ if ((set = single_set (insn)) != NULL
+ && REG_P (SET_SRC (set)) && REG_P (SET_DEST (set))
+ && REGNO (SET_SRC (set)) == REGNO (SET_DEST (set)))
+   {
+ /* Remove an useless move insn.  IRA can generate move
+insns involving pseudos.  It is better remove them
+earlier to speed up compiler a bit.  It is also
+better to do it here as they might not pass final RTL
+check in LRA, (e.g. insn moving a control register
+into itself).  */
+ lra_invalidate_insn_data (insn);
+ delete_insn (insn);
+   }
}
 }

Re: Patch ping (Re: [PATCH] Fortran include line fixes and -fdec-include support)

[Thomas Koenig]

Hi Jakub,


Before 9.0 is released, we should also document the flag
(and the extension it supports) in the manual, and note it
in changes.html and on the Wiki.  Would you also do that?

Like this?  Ok for trunk/wwwdocs?


OK for trunk (and I don't think you need my OK for wwwdocs, but
you have it anyway :-)

Regards

Thomas

Re: [PATCH] Replace sync builtins with atomic builtins

[Thomas Koenig]

Hi Janne,


PING!


OK.

Thanks for the patch!

Regards

Thomas

Re: [PATCH 1/7][v2][MSP430][TESTSUITE] Tweak dg-directives for msp430-elf

[Rainer Orth]

Hi Jozef,

> On Wed, 14 Nov 2018 15:41:00 +
> Jozef Lawrynowicz  wrote:
>
>> Patch 1 tweaks dg directives in tests specifically for msp430. Many of
>> these are extensions to existing target selectors in dg directives.
>
> Made some modifications to patch 1 based on suggestions.
> Added int_eq_float and ptr_eq_long effective target procedures.
>
> Re-tested on avr, x86_64-pc-linux-gnu and msp430-elf.
>
> Ok for trunk?

new effective-target keywords always need documenting in
gcc/doc/sourcebuild.texi.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[Bug other/88141] New: Issues with texinfo when building GCC r266351 in MSYS2

[jmm4077 at rit dot edu]

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

Bug ID: 88141
   Summary: Issues with texinfo when building GCC r266351 in MSYS2
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jmm4077 at rit dot edu
  Target Milestone: ---
  Host: x86_64-w64-mingw32
Target: x86_64-w64-mingw32
 Build: x86_64-w64-mingw32

I'm experiencing a problem with texinfo while attempting to build the latest
trunk revision of GCC in MSYS2 (r266351 at the time of writing this report). I
am building GCC with the latest release versions of GMP, MPC, MPFR, and ISL
(6.1.2, 1.1.0, 4.0.1, and 0.20, respectively).

This is the configure command I'm using for GCC:

../src/configure --build=$TARGET --host=$TARGET --target=$TARGET \
--prefix=$X_WORKDIR_ROOT/dest --with-sysroot=$X_WORKDIR_ROOT/dest \
--disable-multilib --disable-shared --disable-nls --enable-libgomp \
--disable-libstdcxx-pch --disable-libstdcxx-verbose --with-tune=native \
--enable-languages=c,c++,fortran --enable-threads=posix \
--disable-win32-registry "MAKEINFO=missing"

where TARGET is x86_64-w64-mingw32. This is the make call I'm using:

make $MAKE_JOBS bootstrap "CFLAGS=-g0 -O3" "CXXFLAGS=-g0 -O3" \
"CFLAGS_FOR_TARGET=-g0 -O3" "CXXFLAGS_FOR_TARGET=-g0 -O3" \
"BOOT_CXXFLAGS=-g0 -O3"

With MAKEINFO=missing, I get this error during the first stage of the
bootstrap:

make[3]: Entering directory '/d/mingw-distro-setup/build/gcc'
if [ xinfo = xinfo ]; then \
/d/mingw-distro-setup/src/missing makeinfo --split-size=500
--split-size=500 --split-size=500 --no-split -I . -I ../../src/gcc/doc
\
-I ../../src/gcc/doc/include -o doc/cpp.info
../../src/gcc/doc/cpp.texi; \
fi
../../src/gcc/doc/cpp.texi:4375: table requires an argument: the formatter for
@item
../../src/gcc/doc/cppopts.texi:493: table requires an argument: the formatter
for @item
make[3]: *** [Makefile:3226: doc/cpp.info] Error 1
make[3]: Leaving directory '/d/mingw-distro-setup/build/gcc'
make[3]: *** Waiting for unfinished jobs

A similar error occurs (i.e., the "table requires an argument" message) if I
don't include MAKEINFO=missing in the configure call.

I'm not sure if this is an issue with the distribution of texinfo provided by
MSYS2, or if it's an issue with GCC itself. I figured it would be a good idea
to inform the GCC developers first, though.

[PATCH] Fix up 20181120-1.c testcase on big-endian (PR rtl-optimization/85925, take 2)

[Jakub Jelinek]

Hi!

On Wed, Nov 21, 2018 at 12:07:51PM -0600, Segher Boessenkool wrote:
> > Admittedly, it might be better if the initializer was 0x1010101 or say
> > 0x4030201 because on big endian in particular 0x10101 has the top 15 bits
> > all zero and thus that is what is in u.f1, so if the bug can be reproduced
> > with the combine.c + rtlanal.c fix reverted with 0x4030201, it would be
> > better to use that value (in both spots).
> 
> Yeah good point.

I've now managed to test this with a cross to armv7hl (scped to an arm box)
with and without the rtlanal.c + combine.c change reverted and on
powerpc64-linux as example of big-endian, on armv7hl it still fails with
the changes reverted, otherwise it succeeds on both.  The test also needs
32-bit int target (previously just 17-bit or more, so I've added effective
target).

Ok for trunk and release branches?

2018-11-21  Jakub Jelinek  

PR rtl-optimization/85925
* gcc.c-torture/execute/20181120-1.c: Require effective target
int32plus.
(u): New variable.
(main): Compare d against u.f1 rather than 0x101.  Use 0x4030201
instead of 0x10101.

--- gcc/testsuite/gcc.c-torture/execute/20181120-1.c.jj 2018-11-21 
17:39:47.963671708 +0100
+++ gcc/testsuite/gcc.c-torture/execute/20181120-1.c2018-11-21 
20:07:45.804556443 +0100
@@ -1,4 +1,5 @@
 /* PR rtl-optimization/85925 */
+/* { dg-require-effective-target int32plus } */
 /* Testcase by  */
 
 int a, c, d;
@@ -9,17 +10,18 @@ union U1 {
   unsigned f0;
   unsigned f1 : 15;
 };
+volatile union U1 u = { 0x4030201 };
 
 int main (void)
 {
   for (c = 0; c <= 1; c++) {
-union U1 f = {0x10101};
+union U1 f = {0x4030201};
 if (c == 1)
   b;
 *e = f.f1;
   }
 
-  if (d != 0x101)
+  if (d != u.f1)
 __builtin_abort ();
 
   return 0;


Jakub

[PATCH 1/7][v2][MSP430][TESTSUITE] Tweak dg-directives for msp430-elf

[Jozef Lawrynowicz]

On Wed, 14 Nov 2018 15:41:00 +
Jozef Lawrynowicz  wrote:

> Patch 1 tweaks dg directives in tests specifically for msp430. Many of
> these are extensions to existing target selectors in dg directives.

Made some modifications to patch 1 based on suggestions.
Added int_eq_float and ptr_eq_long effective target procedures.

Re-tested on avr, x86_64-pc-linux-gnu and msp430-elf.

Ok for trunk?
>From 1f31a27ab7cf5b7de0c1cfc7e33a39a66cd61146 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz 
Date: Thu, 8 Nov 2018 18:55:57 +
Subject: [PATCH] [TESTSUITE][MSP430] Tweak dg-directives for msp430-elf

2018-11-21  Jozef Lawrynowicz  

	gcc/testsuite/ChangeLog:

	* lib/target-supports.exp
	(check_effective_target_logical_op_short_circuit): Add msp430.
	(check_effective_target_int_eq_float): New. 
	(check_effective_target_ptr_eq_long): New. 
	* c-c++-common/pr41779.c: Require int_eq_float for dg-warning tests.
	* c-c++-common/pr57371-2.c: XFAIL optimized dump scan when
	sizeof (float) != sizeof (int).
	* gcc.dg/pr84670-4.c: Require ptr_eq_long.
	* gcc.dg/pr85859.c: Likewise.
	* gcc.dg/Wno-frame-address.c: Skip for msp430-elf.
	* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise.
	* gcc.dg/ifcvt-4.c: Likewise.
	* gcc.dg/pr34856.c: Likewise.
	* gcc.dg/builtin-apply2.c: Likewise.
	* gcc.dg/tree-ssa/ssa-dse-26.c: Likewise.
	* gcc.dg/attr-alloc_size-11.c: Remove dg-warning XFAIL for msp430.
	* gcc.dg/tree-ssa/20040204-1.c: Likewise.
	* gcc.dg/compat/struct-by-value-16a_x.c: Build at -O1 for msp430
	so it fits.
	* gcc.dg/lto/20091013-1_0.c: Require ptr_eq_long.
	* gcc.dg/lto/20091013-1_1.c: Remove xfail-if for when
	sizeof(void *) != sizeof(long).
	* gcc.dg/lto/20091013-1_2.c: Likewise.
	* gcc.dg/tree-ssa/loop-1.c: Fix expected dg-final behaviour for msp430.
	* gcc.dg/tree-ssa/gen-vect-25.c: Likewise.
	* gcc.dg/tree-ssa/gen-vect-11.c: Likewise.
	* gcc.dg/tree-ssa/loop-35.c: Likewise.
	* gcc.dg/tree-ssa/pr23455.c: Likewise.
	* gcc.dg/weak/typeof-2.c: Likewise.
	* gcc.target/msp430/interrupt_fn_placement.c: Skip for 430 ISA.
	* gcc.target/msp430/pr78818-data-region.c: Fix scan-assembler text.
	* gcc.target/msp430/pr79242.c: Don't skip for -msmall.
	* gcc.target/msp430/special-regs.c: Use "__asm__" instead of "asm".
---
 gcc/testsuite/c-c++-common/pr41779.c   |  6 +++---
 gcc/testsuite/c-c++-common/pr57371-2.c |  2 +-
 gcc/testsuite/gcc.dg/Wno-frame-address.c   |  2 +-
 gcc/testsuite/gcc.dg/attr-alloc_size-11.c  |  4 ++--
 gcc/testsuite/gcc.dg/builtin-apply2.c  |  2 +-
 .../gcc.dg/compat/struct-by-value-16a_x.c  |  2 ++
 gcc/testsuite/gcc.dg/ifcvt-4.c |  2 +-
 gcc/testsuite/gcc.dg/lto/20091013-1_0.c|  1 +
 gcc/testsuite/gcc.dg/lto/20091013-1_1.c|  1 -
 gcc/testsuite/gcc.dg/lto/20091013-1_2.c|  1 -
 gcc/testsuite/gcc.dg/pr34856.c |  1 +
 gcc/testsuite/gcc.dg/pr84670-4.c   |  1 +
 gcc/testsuite/gcc.dg/pr85859.c |  1 +
 .../gcc.dg/torture/stackalign/builtin-apply-2.c|  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/20040204-1.c |  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11.c|  2 +-
 gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c|  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/loop-1.c |  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/loop-35.c|  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/pr23455.c|  4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dse-26.c |  1 +
 gcc/testsuite/gcc.dg/weak/typeof-2.c   |  2 ++
 .../gcc.target/msp430/interrupt_fn_placement.c |  1 +
 .../gcc.target/msp430/pr78818-data-region.c|  3 ++-
 gcc/testsuite/gcc.target/msp430/pr79242.c  |  2 +-
 gcc/testsuite/gcc.target/msp430/special-regs.c |  8 
 gcc/testsuite/lib/target-supports.exp  | 24 ++
 27 files changed, 61 insertions(+), 28 deletions(-)

diff --git a/gcc/testsuite/c-c++-common/pr41779.c b/gcc/testsuite/c-c++-common/pr41779.c
index c42a0f5..a80bf78 100644
--- a/gcc/testsuite/c-c++-common/pr41779.c
+++ b/gcc/testsuite/c-c++-common/pr41779.c
@@ -1,6 +1,6 @@
 /* PR41779: Wconversion cannot see through real*integer promotions. */
 /* { dg-do compile } */
-/* { dg-skip-if "doubles are floats" { "avr-*-*" } } */
+/* { dg-skip-if "doubles are floats" { avr-*-* } } */
 /* { dg-options "-std=c99 -Wconversion" { target c } } */
 /* { dg-options "-Wconversion" { target c++ } } */
 /* { dg-require-effective-target large_double } */
@@ -27,7 +27,7 @@ float f4(float x, unsigned char y)
 
 float f5(float x, int y)
 {
-  return x * y; /* { dg-warning "conversion" } */
+  return x * y; /* { dg-warning "conversion" "" { target int_eq_float } } */
 }
 
 double c1(float x, unsigned short y, int z)
@@ -52,5 +52,5 @@ double c4(float x, unsigned char y, int z)
 
 double c5(float x, int y, int z)
 {
-  return z ? x + x : y; /* { dg-warning "conversion" } */
+  return z ? x + x : y; /* { 

Re: [C++ PATCH] Improve locations of id-expressions and operator "" (PR c++/87386, take 2)

[Jakub Jelinek]

On Wed, Nov 21, 2018 at 01:29:15PM -0500, Jason Merrill wrote:
> > similarly for operator"" _F the column is under _ rather than first o.
> 
> I disagree with this one: the name of the declaration is operator""_F, so I
> think the caret should go at the first o.

Right now when cp_parser_operator_function_id is called, it returns locus like:
operator new
 ^~~
operator delete []
 ^
operator ==
 ^
operator "" _foo
UNKNOWN_LOCATION
The last one is because for others we do return cp_expr (id, start_loc);
but for operator "" just return id;

So, do you suggest we should instead return
operator new
^~~~
operator delete []
^~
operator ==
^~~
operator "" _foo
^~~~
?
That would mean cp_parser_operator_function_id would need to pass
location_t start_loc (the start of the operator token) to cp_parser_operator and
let that create a range in all cases rather than just for operator
new/delete.

Jakub

[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #6 from Jonathan Wakely  ---
This should be fixed now.

If you're able to run the tests for these components that would be very much
appreciated. To run just the  tests, run the following in the
$objdir/$target/libstdc++-v3 directory:

make check RUNTESTFLAGS=conformance.exp=20_util/*_resource/*

Re: [PATCH] C++: show namespaces for enum values (PR c++/88121)

[Jason Merrill]

On 11/21/18 8:35 AM, David Malcolm wrote:

Consider this test case:

namespace json
{
   enum { JSON_OBJECT };
}

void test ()
{
   JSON_OBJECT;
}

which erroneously accesses an enum value in another namespace without
qualifying the access.

GCC 6 through 8 issue a suggestion that doesn't mention the namespace:

: In function 'void test()':
:8:3: error: 'JSON_OBJECT' was not declared in this scope
JSON_OBJECT;
^~~
:8:3: note: suggested alternative:
:3:10: note:   'JSON_OBJECT'
enum { JSON_OBJECT };
   ^~~

which is suboptimal.

I made the problem worse with r265610, as gcc 9 now consolidates
the single suggestion into the error, and emits:

: In function 'void test()':
:8:3: error: 'JSON_OBJECT' was not declared in this scope; did
you mean 'JSON_OBJECT'?
 8 |   JSON_OBJECT;
   |   ^~~
   |   JSON_OBJECT
:3:10: note: 'JSON_OBJECT' declared here
 3 |   enum { JSON_OBJECT };
   |  ^~~

where the message:
   'JSON_OBJECT' was not declared in this scope; did you mean 'JSON_OBJECT'?
is nonsensical.

The root cause is that dump_scope doesn't print anything when called for
CONST_DECL in a namespace: the scope is an ENUMERAL_TYPE, rather than
a namespace.


Although that's only true for unscoped enums.


This patch tweaks dump_scope to detect ENUMERAL_TYPE, and to use the
enclosing namespace, so that the CONST_DECL is dumped as
"json::JSON_OBJECT".



@@ -182,6 +182,12 @@ dump_scope (cxx_pretty_printer *pp, tree scope, int flags)
if (scope == NULL_TREE)
  return;
  
+  /* Enum values will be CONST_DECL with an ENUMERAL_TYPE as their

+ "scope".  Use CP_TYPE_CONTEXT of the ENUMERAL_TYPE, so as to
+ print the enclosing namespace.  */
+  if (TREE_CODE (scope) == ENUMERAL_TYPE)
+scope = CP_TYPE_CONTEXT (scope);


This needs to handle scoped enums differently.


diff --git a/gcc/testsuite/g++.dg/lookup/suggestions-scoped-enums.C 
b/gcc/testsuite/g++.dg/lookup/suggestions-scoped-enums.C
new file mode 100644
index 000..2bf3ed6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/lookup/suggestions-scoped-enums.C
@@ -0,0 +1,13 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-fdiagnostics-show-caret" }
+
+enum class vegetable { CARROT, TURNIP };
+
+void misspelled_value_in_scoped_enum ()
+{
+  vegetable::TURNUP; // { dg-error "'TURNUP' is not a member of 'vegetable'" }
+  /* { dg-begin-multiline-output "" }
+   vegetable::TURNUP;
+  ^~
+ { dg-end-multiline-output "" } */
+}


I don't see any suggestion in the expected output, and would hope for it 
to suggest vegetable::TURNIP.


Jason

[Bug lto/88140] [9 Regression] ICE: verify_gimple failed since r266325

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-11-21
  Known to work||8.2.0
   Assignee|unassigned at gcc dot gnu.org  |hubicka at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1
  Known to fail||9.0

[Bug libstdc++/88111] libstdc++-v3 FTB for 16-bit int: memory_resource.cc pool_sizes expects >16-bit int/size_t

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 21 18:40:55 2018
New Revision: 266353

URL: https://gcc.gnu.org/viewcvs?rev=266353=gcc=rev
Log:
PR libstdc++/88111 Make maximum block size depend on size_t width

PR libstdc++/88111
* include/std/memory_resource (pool_options): Add Doxygen comments.
* src/c++17/memory_resource.cc (pool_sizes): Only use suitable values
on targets with 16-bit or 20-bit size_t type.
(munge_options): Make default values depend on width of size_t type.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/memory_resource
trunk/libstdc++-v3/src/c++17/memory_resource.cc

[Bug libstdc++/88113] Woverflow warning in memory_resource.cc (struct bitset), for 16-bit size_t

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |9.0

--- Comment #3 from Jonathan Wakely  ---
This should be fixed now.

[Bug libstdc++/88113] Woverflow warning in memory_resource.cc (struct bitset), for 16-bit size_t

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Wed Nov 21 18:40:37 2018
New Revision: 266352

URL: https://gcc.gnu.org/viewcvs?rev=266352=gcc=rev
Log:
PR libstdc++/88113 use size_type consistently instead of size_t

On 16-bit msp430-elf size_t is either 16 bits or 20 bits, and so can't
represent all values of the uint32_t type used for bitset::size_type.
Using the smaller of size_t and uint32_t for size_type ensures it fits
in size_t.

PR libstdc++/88113
* src/c++17/memory_resource.cc (bitset::size_type): Use the smaller
of uint32_t and size_t.
(bitset::size(), bitset::free(), bitset::update_next_word())
(bitset::max_blocks_per_chunk(), bitset::max_word_index()): Use
size_type consistently instead of size_t.
(chunk): Adjust static_assert checking sizeof(chunk).

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/src/c++17/memory_resource.cc

[Bug lto/88140] New: [9 Regression] ICE: verify_gimple failed since r266325

[marxin at gcc dot gnu.org]

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

Bug ID: 88140
   Summary: [9 Regression] ICE: verify_gimple failed since r266325
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Following is causing ICE:

$ cat ice.i
typedef struct {
} a;

typedef struct {
  a *b[0];
} c;

void d() { ((c *)0)->b[0] = 0; }

$ gcc ice.i  -c -flto
typedef struct {
} a;

typedef struct {
  a *b[0];
} c;

void d() { ((c *)0)->b[0] = 0; }
ice.i: In function ‘d’:
ice.i:8:1: error: type mismatch in component reference
8 | void d() { ((c *)0)->b[0] = 0; }
  | ^~~~
struct a *[0:]

struct a *[0:]

_1->b[0] = 0B;
during IPA pass: *free_lang_data
ice.i:8:1: internal compiler error: verify_gimple failed
0xd53697 verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5422
0xc2cbef execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:1977
0xc2dac1 do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1645
0xc2db1e execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2031

[PATCH] libstdc++/88111 and libstdc++/88113 fix src/c++17/memory_resource.cc for 16-bit targets

[Jonathan Wakely]

Two patches to fix the build on msp430-elf which has 16-bit or 20-bit
pointers.

The patch for 88111 also affects other targets, by changing the
default values that are used when pool_options members are zero. The
new default values depend on the number of bits in size_t.

Bootstrapped on msp430-elf, tested on powerpc64le-linux.

commit b5ba0a7b875c3524d447452531416eabf218e6e9
Author: Jonathan Wakely 
Date:   Wed Nov 21 18:16:45 2018 +

PR libstdc++/88111 Make maximum block size depend on size_t width

PR libstdc++/88111
* include/std/memory_resource (pool_options): Add Doxygen comments.
* src/c++17/memory_resource.cc (pool_sizes): Only use suitable values
on targets with 16-bit or 20-bit size_t type.
(munge_options): Make default values depend on width of size_t type.

diff --git a/libstdc++-v3/include/std/memory_resource b/libstdc++-v3/include/std/memory_resource
index 87ad25d60f3..e9a46a3b455 100644
--- a/libstdc++-v3/include/std/memory_resource
+++ b/libstdc++-v3/include/std/memory_resource
@@ -299,13 +299,25 @@ namespace pmr
 { return !(__a == __b); }
 
 
+  /// Parameters for tuning a pool resource's behaviour.
   struct pool_options
   {
+/** @brief Upper limit on number of blocks in a chunk.
+ *
+ * A lower value prevents allocating huge chunks that could remain mostly
+ * unused, but means pools will need to replenished more frequently.
+ */
 size_t max_blocks_per_chunk = 0;
+
+/* @brief Largest block size (in bytes) that should be served from pools.
+ *
+ * Larger allocations will be served directly by the upstream resource,
+ * not from one of the pools managed by the pool resource.
+ */
 size_t largest_required_pool_block = 0;
   };
 
-  // Common implementation details for unsynchronized/synchronized pool resources.
+  // Common implementation details for un-/synchronized pool resources.
   class __pool_resource
   {
 friend class synchronized_pool_resource;
diff --git a/libstdc++-v3/src/c++17/memory_resource.cc b/libstdc++-v3/src/c++17/memory_resource.cc
index 6198e6b68ca..929df93233c 100644
--- a/libstdc++-v3/src/c++17/memory_resource.cc
+++ b/libstdc++-v3/src/c++17/memory_resource.cc
@@ -825,10 +825,15 @@ namespace pmr
   128, 192,
   256, 320, 384, 448,
   512, 768,
+#if __SIZE_WIDTH__ > 16
   1024, 1536,
   2048, 3072,
-  1<<12, 1<<13, 1<<14, 1<<15, 1<<16, 1<<17,
+#if __SIZE_WIDTH__ > 20
+  1<<12, 1<<13, 1<<14,
+  1<<15, 1<<16, 1<<17,
   1<<20, 1<<21, 1<<22 // 4MB should be enough for anybody
+#endif
+#endif
   };
 
   pool_options
@@ -839,10 +844,13 @@ namespace pmr
 // replaced with implementation-defined defaults, and sizes may be
 // rounded to unspecified granularity.
 
-// Absolute maximum. Each pool might have a smaller maximum.
+// max_blocks_per_chunk sets the absolute maximum for the pool resource.
+// Each pool might have a smaller maximum, because pools for very large
+// objects might impose  smaller limit.
 if (opts.max_blocks_per_chunk == 0)
   {
-	opts.max_blocks_per_chunk = 1024 * 10; // TODO a good default?
+	// Pick a default that depends on the number of bits in size_t.
+	opts.max_blocks_per_chunk = __SIZE_WIDTH__ << 8;
   }
 else
   {
@@ -854,10 +862,15 @@ namespace pmr
 	opts.max_blocks_per_chunk = chunk::max_blocks_per_chunk();
   }
 
-// Absolute minimum. Likely to be much larger in practice.
+// largest_required_pool_block specifies the largest block size that will
+// be allocated from a pool. Larger allocations will come directly from
+// the upstream resource and so will not be pooled.
 if (opts.largest_required_pool_block == 0)
   {
-	opts.largest_required_pool_block = 4096; // TODO a good default?
+	// Pick a sensible default that depends on the number of bits in size_t
+	// (pools with larger block sizes must be explicitly requested by
+	// using a non-zero value for largest_required_pool_block).
+	opts.largest_required_pool_block = __SIZE_WIDTH__ << 6;
   }
 else
   {

commit 14974318adc5e9d56e827cdfa39207e7c7be9e6d
Author: Jonathan Wakely 
Date:   Wed Nov 21 17:39:51 2018 +

PR libstdc++/88113 use size_type consistently instead of size_t

On 16-bit msp430-elf size_t is either 16 bits or 20 bits, and so can't
represent all values of the uint32_t type used for bitset::size_type.
Using the smaller of size_t and uint32_t for size_type ensures it fits
in size_t.

PR libstdc++/88113
* src/c++17/memory_resource.cc (bitset::size_type): Use the smaller
of uint32_t and size_t.
(bitset::size(), bitset::free(), bitset::update_next_word())
(bitset::max_blocks_per_chunk(), bitset::max_word_index()): Use
size_type consistently instead of size_t.
(chunk): Adjust static_assert checking sizeof(chunk).

diff --git 

Re: [C++ PATCH] Remove useless tokens from cp_parser_linkage_specification (PR c++/87393)

[Jason Merrill]

On 11/21/18 10:59 AM, Jakub Jelinek wrote:

Hi!

David's r251026 change added a weird trailing ->location.
It doesn't seem to be useful for anything, matching_braces has its own code
to track locations, so no need to do anything in the caller (and no other
spot does something like that).

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?


OK.

Jason

Re: [C++ PATCH] Improve locations of id-expressions and operator "" (PR c++/87386, take 2)

[Jason Merrill]

On 11/21/18 10:55 AM, Jakub Jelinek wrote:

Hi!

On Tue, Nov 20, 2018 at 04:32:26PM -0500, David Malcolm wrote:

This makes the fix-it hint wrong: after the fix-it is applied, it will
become
   return color;
(which won't compile), rather than
   return O::color;
which will.


Here is an updated version of the patch, which still uses the whole
range of the id-expression when it is parsed as primary expression, but does
so not in cp_parser_id_expression, but in cp_parser_primary_expression after
all the diagnostics.  Thus all the spell-checking etc. tests behave as
previously, they underline only the part after the last ::, and just
what uses the expression later on uses whole range.

The remaining needed tweeks in the testcases are minor and look correct to
me, e.g. for D::Bar the column is not at D but at B,


Sounds good.


similarly for operator"" _F the column is under _ rather than first o.


I disagree with this one: the name of the declaration is operator""_F, 
so I think the caret should go at the first o.



The libstdc++ changes are because there are several large expressions like:
   something::value
and we used to diagnose on the something line (column of s)
but now we warn on value line (column of v).


Makes sense.

Jason

[Bug sanitizer/86899] [8/9 regression] TSAN incorrect warning: control reaches end of non-void function

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
block_may_fallthru on:
  try
{
  return  = 0;
  if (0)
{
  return  = 0;
}
}
  finally
{
  A::~A ();
}
suggests that it may fall thru, because generally it looks at the last stmt, it
is way too early for dce.  Even for the if (0), it would need to prove there
are no labels in the block and would need to decide to look at stmts before
last too.
In *.ehopt we have:
  try
{
  A::A ();
  try
{
  D.2328 = 0;
  goto ;
  if (0 != 0) goto ; else goto ;
  :
  D.2328 = 0;
  // predicted unlikely by early return (on trees) predictor.
  goto ;
  :
}
  finally
{
  A::~A ();
}
}
  finally
{
  a = {CLOBBER};
}
  return;
  :
  return D.2328;
and even here the if (0) stuff makes gimple_stmt_may_fallthru think it might
fall thru, because it ends with a label (D.2330).
Because of this the eh lowering decides to use a finally_tmp temporary to track
where it should continue after the cleanup:
  finally_tmp.0 = 0;
  goto ;
  :
  finally_tmp.0 = 1;
  :
  A::~A ();
  switch (finally_tmp.0) , case 1: >
Now, cfg construct with its cleanup makes
   :
  A::A ();

   :
  D.2328 = 0;
  finally_tmp.0 = 0;

   :
  A::~A ();
  if (finally_tmp.0 == 1)
goto ; [INV]
  else
goto ; [INV]

   :
  a = {CLOBBER};
  return;

   :
  a = {CLOBBER};

   :
:
  return D.2328;

   :
:
  a = {CLOBBER};
  resx 1
out of this, which is unfortunately not good enough for the -Wreturn-type pass
that follows - we aren't in SSA form, so there is no easy way during the cfg
cleanup to figure out that finally_tmp.0 is ever stored only 0 and do further
cfg cleanup.

[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression

[joseph at codesourcery dot com]

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

--- Comment #23 from joseph at codesourcery dot com  ---
And, yes, at least one extra bit in emin is needed for that sticky 
rounding code to work (because the user's source code may have a decimal 
constant that is slightly over half the least subnormal, and mpfr_strtofr 
needs to return a nonzero value for that code to work, meaning a value 
whose exponent is one smaller than the smallest exponent of any subnormal 
value that is actually representable in the floating-point format).

[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression

[joseph at codesourcery dot com]

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

--- Comment #22 from joseph at codesourcery dot com  ---
On Wed, 21 Nov 2018, rguenther at suse dot de wrote:

>   /* Nonzero value, possibly overflowing or underflowing.  */
>   mpfr_init2 (m, SIGNIFICAND_BITS);
>   inexact = mpfr_strtofr (m, str, NULL, 10, GMP_RNDZ);
> 
> we return true and the rounding mode is GMP_RNDZ?  Indeed when changing
> the above to use GMP_RNDN it works OK.  The whole thing is also a bit

Note that using RNDZ is required there for correctness (this is 
round-to-odd / sticky rounding).

Re: Stream TREE_TYPE of TYPE_DECLs again

[Jan Hubicka]

> 
> OK if you put a comment ...

I have adde comments to both free_lang_data referring that some fields
are freed late and comment to the new freeing pass.
While testing I noticed stupid bug in need_assembler_name_p which in
case TYPE_DECL does not satisfy the elaborate conditional for type to be
ODR it falls into "return true" rather than false.  Fixing that
uncovered bug in -fno-odr-type-merging path of ipa-devirt where vtable
hash was no longer initialized. Fixed thus.

lto-bootstrapped/regtested x86_64-linux, comitted.

PR lto/87957
* tree.c (fld_decl_context): Break out from ...
(free_lang_data_in_decl): ... here; free TREE_PUBLIC, TREE_PRIVATE
DECL_ARTIFICIAL of TYPE_DECL; do not free TREE_TYPE of TYPE_DECL.
(fld_incomplete_type_of): Build copy of TYP_DECL.
* ipa-devirt.c (free_enum_values): Rename to ...
(free_odr_warning_data): ... this one; free also duplicated TYPE_DECLs
and TREE_TYPEs of TYPE_DECLs.
(get_odr_type): Initialize odr_vtable_hash if needed.

Index: ipa-devirt.c
===
--- ipa-devirt.c(revision 266334)
+++ ipa-devirt.c(working copy)
@@ -2025,6 +2025,8 @@ get_odr_type (tree type, bool insert)
   if ((!slot || !*slot) && in_lto_p && can_be_vtable_hashed_p (type))
 {
   hash = hash_odr_vtable (type);
+  if (!odr_vtable_hash)
+odr_vtable_hash = new odr_vtable_hash_type (23);
   vtable_slot = odr_vtable_hash->find_slot_with_hash (type, hash,
   insert ? INSERT : NO_INSERT);
 }
@@ -2289,27 +2291,43 @@ dump_type_inheritance_graph (FILE *f)
   "%i duplicates overall\n", num_all_types, num_types, num_duplicates);
 }
 
-/* Save some WPA->ltrans streaming by freeing enum values.  */
+/* Save some WPA->ltrans streaming by freeing stuff needed only for good
+   ODR warnings.
+   We free TYPE_VALUES of enums and also make TYPE_DECLs to not point back
+   to the type (which is needed to keep them in the same SCC and preserve
+   location information to output warnings) and subsequently we make all
+   TYPE_DECLS of same assembler name equivalent.  */
 
 static void
-free_enum_values ()
+free_odr_warning_data ()
 {
-  static bool enum_values_freed = false;
-  if (enum_values_freed || !flag_wpa || !odr_types_ptr)
+  static bool odr_data_freed = false;
+
+  if (odr_data_freed || !flag_wpa || !odr_types_ptr)
 return;
-  enum_values_freed = true;
-  unsigned int i;
-  for (i = 0; i < odr_types.length (); i++)
+
+  odr_data_freed = true;
+
+  for (unsigned int i = 0; i < odr_types.length (); i++)
 if (odr_types[i])
   {
-   if (TREE_CODE (odr_types[i]->type) == ENUMERAL_TYPE)
- TYPE_VALUES (odr_types[i]->type) = NULL;
+   tree t = odr_types[i]->type;
+
+   if (TREE_CODE (t) == ENUMERAL_TYPE)
+ TYPE_VALUES (t) = NULL;
+   TREE_TYPE (TYPE_NAME (t)) = void_type_node;
+
if (odr_types[i]->types)
   for (unsigned int j = 0; j < odr_types[i]->types->length (); j++)
-   if (TREE_CODE ((*odr_types[i]->types)[j]) == ENUMERAL_TYPE)
- TYPE_VALUES ((*odr_types[i]->types)[j]) = NULL;
+   {
+ tree td = (*odr_types[i]->types)[j];
+
+ if (TREE_CODE (td) == ENUMERAL_TYPE)
+   TYPE_VALUES (td) = NULL;
+ TYPE_NAME (td) = TYPE_NAME (t);
+   }
   }
-  enum_values_freed = true;
+  odr_data_freed = true;
 }
 
 /* Initialize IPA devirt and build inheritance tree graph.  */
@@ -2323,7 +2341,7 @@ build_type_inheritance_graph (void)
 
   if (odr_hash)
 {
-  free_enum_values ();
+  free_odr_warning_data ();
   return;
 }
   timevar_push (TV_IPA_INHERITANCE);
@@ -2370,7 +2388,7 @@ build_type_inheritance_graph (void)
   dump_type_inheritance_graph (inheritance_dump_file);
   dump_end (TDI_inheritance, inheritance_dump_file);
 }
-  free_enum_values ();
+  free_odr_warning_data ();
   timevar_pop (TV_IPA_INHERITANCE);
 }
 
Index: tree.c
===
--- tree.c  (revision 266325)
+++ tree.c  (working copy)
@@ -5206,6 +5206,24 @@ fld_process_array_type (tree t, tree t2,
   return array;
 }
 
+/* Return CTX after removal of contexts that are not relevant  */
+
+static tree
+fld_decl_context (tree ctx)
+{
+  /* Variably modified types are needed for tree_is_indexable to decide
+ whether the type needs to go to local or global section.
+ This code is semi-broken but for now it is easiest to keep contexts
+ as expected.  */
+  if (ctx && TYPE_P (ctx)
+  && !variably_modified_type_p (ctx, NULL_TREE))
+ {
+   while (ctx && TYPE_P (ctx))
+ctx = TYPE_CONTEXT (ctx);
+ }
+  return ctx;
+}
+
 /* For T being aggregate type try to turn it into a incomplete variant.
Return T if no simplification is possible.  */
 
@@ -5267,6 +5285,28 @@ 

Re: [PATCH] Fix up 20181120-1.c testcase on big-endian (PR rtl-optimization/85925)

[Segher Boessenkool]

On Wed, Nov 21, 2018 at 06:31:43PM +0100, Jakub Jelinek wrote:
> > > As mentioned in the PR, the testcase fails on big-endian targets.
> > > The following patch tweaks it so that it does not fail there and still
> > > checks for the original bug.
> > 
> > It relies on a certain bitfield layout, not just on LE.  I think the
> > testcase should run only on those specific targets where it works.  I don't
> > see how this patch would fix the problem for BE, btw.
> 
> With the patch, it doesn't rely on anything, it compares if what you get at
> runtime from the code combiner would optimize is equal to what is read from
> a volatile union.

Oh, I think I misread it, sorry :-)

> Admittedly, it might be better if the initializer was 0x1010101 or say
> 0x4030201 because on big endian in particular 0x10101 has the top 15 bits
> all zero and thus that is what is in u.f1, so if the bug can be reproduced
> with the combine.c + rtlanal.c fix reverted with 0x4030201, it would be
> better to use that value (in both spots).

Yeah good point.


Segher

[Bug sanitizer/86899] [8/9 regression] TSAN incorrect warning: control reaches end of non-void function

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Doesn't seem to be a real regression to me, we've only stopped warning about
this with -Wreturn-type -fsanitize=thread in r254437 and started again in
r255403, that is less than month and no releases have been released with that.
We weren't warning before r219202 though.

Note, it is the same warning you get with e.g.
struct A { A (); ~A (); };
int foo()
{
A a;
return 0;
if(0) {
return 0;
}
}
or anything that needs a cleanup, -Wreturn-type is a simple warning and if you
try hard to screw it up, you'll manage to do it.  Any reason why we shouldn't
warn on this though?  It is clearly useless dead code that is better removed
when the compiler warns about it...

Re: [PATCH, ARM, ping3] PR85434: Prevent spilling of stack protector guard's address on ARM

[Segher Boessenkool]

On Fri, Nov 16, 2018 at 02:56:46PM +, Thomas Preudhomme wrote:
> In case of high register pressure in PIC mode, address of the stack
> protector's guard can be spilled on ARM targets as shown in PR85434,
> thus allowing an attacker to control what the canary would be compared
> against. ARM does lack stack_protect_set and stack_protect_test insn
> patterns, defining them does not help as the address is expanded
> regularly and the patterns only deal with the copy and test of the
> guard with the canary.
> 
> This problem does not occur for x86 targets because the PIC access and
> the test can be done in the same instruction. Aarch64 is exempt too
> because PIC access insn pattern are mov of UNSPEC which prevents it from
> the second access in the epilogue being CSEd in cse_local pass with the
> first access in the prologue.

The unspecs are not CSEd because they are *different* unspecs (UNSPEC_SP_SET
vs. UNSPEC_SP_TEST; they have different args too, different number of args
even).  Two the same unspecs can be CSEd just fine.


Segher