Re: [RFC] Run pass_sink_code once more after ivopts/fre

[Richard Biener]

On Wed, 14 Apr 2021, Xionghu Luo wrote:

> Hi,
> 
> On 2021/3/26 15:35, Xionghu Luo via Gcc-patches wrote:
> >> Also we already have a sinking pass on RTL which even computes
> >> a proper PRE on the reverse graph - -fgcse-sm aka store-motion.c.
> >> I'm not sure whether this deals with non-stores but the
> >> LCM machinery definitely can handle arbitrary expressions.  I wonder
> >> if it makes more sense to extend this rather than inventing a new
> >> ad-hoc sinking pass?
> >  From the literal, my pass doesn't handle or process store instructions
> > like store-motion..  Thanks, will check it.
> 
> Store motion only processes store instructions with data flow equations,
> generating 4 inputs(st_kill, st_avloc, st_antloc, st_transp) and solve it
> by Lazy Code Motion API(5 DF compute call) with 2 outputs (st_delete_map,
> st_insert_map) globally, each store place is independently represented in
> the input bitmap vectors. Output is which should be delete and where to
> insert, current code does what you said "emit copies to a new pseudo at
> the original insn location and use it in followed bb", actually it is
> "store replacement" instead of "store move", why not save one pseudo by
> moving the store instruction to target edge directly?

It probably simply saves the pass from doing analysis whether the
stored value is clobbered on the sinking path, enabling more store
sinking.  For stores that might be even beneficial, for non-stores
it becomes more of a cost issue, yes.

> There are many differences between the newly added rtl-sink pass and
> store-motion pass. 
> 1. Store motion moves only store instructions, rtl-sink ignores store
> instructions. 
> 2. Store motion is a global DF problem solving, rtl-sink only processes
> loop header reversely with dependency check in loop, take the below RTL
> as example,
> "#538,#235,#234,#233" will all be sunk from bb 35 to bb 37 by rtl-sink,
> but it moves #538 first, then #235, there is strong dependency here. It
> seemsdoesn't like the LCM framework that could solve all and do the
> delete-insert in one iteration. 

So my question was whether we want to do both within the LCM store
sinking framework.  The LCM dataflow is also used by RTL PRE which
handles both loads and non-loads so in principle it should be able
to handle stores and non-stores for the sinking case (PRE on the
reverse CFG).

A global dataflow is more powerful than any local ad-hoc method.

Richard.

> However, there are still some common methods could be shared, like the
> def-use check(though store-motion is per bb, rtl-sink is per loop),
> insert_store, commit_edge_insertions etc.
> 
> 
>   508: L508:
>   507: NOTE_INSN_BASIC_BLOCK 34
>12: r139:DI=r140:DI
>   REG_DEAD r140:DI
>   240: L240:
>   231: NOTE_INSN_BASIC_BLOCK 35
>   232: r142:DI=zero_extend(r139:DI#0)
>   233: r371:SI=r142:DI#0-0x1
>   234: r243:DI=zero_extend(r371:SI)
>   REG_DEAD r371:SI
>   235: r452:DI=r262:DI+r139:DI
>   538: r194:DI=r452:DI
>   236: r372:CCUNS=cmp(r142:DI#0,r254:DI#0)
>   237: pc={(geu(r372:CCUNS,0))?L246:pc}
>   REG_DEAD r372:CCUNS
>   REG_BR_PROB 59055804
>   238: NOTE_INSN_BASIC_BLOCK 36
>   239: r140:DI=r139:DI+0x1
>   241: r373:DI=r251:DI-0x1
>   242: r374:SI=zero_extend([r262:DI+r139:DI])
>   REG_DEAD r139:DI
>   243: r375:SI=zero_extend([r373:DI+r140:DI])
>   REG_DEAD r373:DI
>   244: r376:CC=cmp(r374:SI,r375:SI)
>   REG_DEAD r375:SI
>   REG_DEAD r374:SI
>   245: pc={(r376:CC==0)?L508:pc}
>   REG_DEAD r376:CC
>   REG_BR_PROB 1014686028
>   246: L246:
>   247: NOTE_INSN_BASIC_BLOCK 37
>   248: r377:SI=r142:DI#0-0x2
>   REG_DEAD r142:DI
>   249: r256:DI=zero_extend(r377:SI)
> 
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

[PATCH] Fix freestanding cstdint which fails to detect stdint.h [PR100057]

[sotrdg sotrdg via Gcc-patches]

>From 609cef6c863633711418c6b23401069062ac5df8 Mon Sep 17 00:00:00 2001
From: expnkx 
Date: Wed, 14 Apr 2021 01:48:38 -0400
Subject: [PATCH] Fix freestanding cstdint which fails to detect
stdint.h [PR100057]

Configure script cannot find cstdint when we build in freestanding
environment since there are no stdint.h header file.

However when we try to #include directly, it works by
indirectly #include which has been fixed by me if
the _GLIBCXX_HOSTED_ is defined as 0

The last patch is still required, this is to fix another issue.

libstdc++-v3/ChangeLog;
PR libstdc++/100057
* libstdc++/include/c_global/cstdint:
Always #include if _GLIBCXX_HOSTED_ 
== 0.
---
libstdc++-v3/include/c_global/cstdint | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/include/c_global/cstdint 
b/libstdc++-v3/include/c_global/cstdint
index fa4d0fb900c..cb88e21db17 100644
--- a/libstdc++-v3/include/c_global/cstdint
+++ b/libstdc++-v3/include/c_global/cstdint
@@ -37,7 +37,7 @@
 #include 
-#if _GLIBCXX_HAVE_STDINT_H
+#if !_GLIBCXX_HOSTED || _GLIBCXX_HAVE_STDINT_H
# include 
#endif
--
2.25.1

[PATCH] Fix build errors on several platforms. [PR100057,PR100012,PR99499,PR99306]

[unlvsur unlvsur via Gcc-patches]

>From 71e6b5bcf5564ecc59a96fdf2939537e4ccf0004 Mon Sep 17 00:00:00 2001
From: expnkx 
Date: Wed, 14 Apr 2021 00:17:53 -0400
Subject: [PATCH] Fix build errors on several platforms. 
[PR100057,PR100012,PR99499,PR99306]

[PATCH] libstdc++: Fix build errors with --disable-hosted-libstdcxx [PR100057]
[PATCH] Fix build errors with MSDOS djgpp hosted [PR100012]
[PATCH] Fix build errors with MSDOS djgpp target [PR99306]
[PATCH] Fix build errors for Android Bionic target [PR99499]
[PATCH] Add no red-zone multilib support for x86_64-elf target [PR100057]

1. The script of --disable-hosted-libstdcxx does not work correctly
since libstdc++ always assumes the header file like stdio.h exists
even in freestanding environment.

This patch is to fix C++ freestanding, to make C++ being self-host.

By the way, I add red-zone multilib support by default since OSdev
has done that for a very long time.
See:https://wiki.osdev.org/Libgcc_without_red_zone
We just add this target by default.

2. Fix libcody and resolver on DOS host because djgpp always defines
unix macro even it is not unix.

3. Fix Android Bionic build. Though Google does not support GCC any more,
some of us still want to use GCC to write android programs. This patch
fixes build error on bionic too by defining macros like _GLIBCXX_U by
ourselves.

The patch has been tested on target x86_64-elf and bootstrapped
successfully on x86_64-linux-gnu with all languages enabled.


gcc/ChangeLog:
  PR gcc/100057
  * gcc/config.gcc, gcc/config/i386/t-x86_64-elf: Add x86_64-elf redzone 
multilib
  * gcc/ginclude/stdint-wrap.h: Force #include"stdint-gcc.h" when 
_GLIBCXX_HOSTED == 0
  * gcc/ggc-common.c: Fix build errors with MSDOS host

libcody/ChangeLog:
  PR gcc/100012
  * libcody/cody.hh: Fix build errors with MSDOS host

libstdc++-v3/ChangeLog:
  PR libstdc++/100057
  * libstdc++-v3/configure: Fix build errors with --disable-hosted-libstdcxx
  PR gcc/99306
  * libstdc++-v3/config/os/djgpp/os_defines.h: Fix build errors with MSDOS 
target
  * libstdc++-v3/src/c++11/shared_ptr.cc: Fix build errors with MSDOS target
  PR gcc/99499
  * libstdc++-v3/config/os/bionic/ctype_base.h: Fix build errors for Android 
Bionic target

Sent from Mail for Windows 10



builderror.patch
Description: builderror.patch

[pushed] c++: lambda in non-type template parm type [PR99478]

[Jason Merrill via Gcc-patches]

In this testcase, the non-type template parameter has the type of a
lambda-expression.  This makes no sense because a lambda in template context
is specified to be distinct between different specializations of the
template, even if the lambda is non-dependent, but here which specialization
we are dealing with depends on which lambda we have, and vice versa.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/99478
* parser.c (cp_parser_lambda_expression): Reject lambda
in template parameter type.

gcc/testsuite/ChangeLog:

PR c++/99478
* g++.dg/cpp2a/lambda-uneval14.C: New test.
---
 gcc/cp/parser.c  | 16 +++-
 gcc/testsuite/g++.dg/cpp2a/lambda-uneval14.C |  6 ++
 2 files changed, 21 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/lambda-uneval14.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index aec3aa3587f..3a107206318 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -10796,7 +10796,21 @@ cp_parser_lambda_expression (cp_parser* parser)
   LAMBDA_EXPR_LOCATION (lambda_expr) = token->location;
 
   if (cxx_dialect >= cxx20)
-/* C++20 allows lambdas in unevaluated context.  */;
+{
+  /* C++20 allows lambdas in unevaluated context, but one in the type of a
+non-type parameter is nonsensical.
+
+Distinguish a lambda in the parameter type from a lambda in the
+default argument by looking at local_variables_forbidden_p, which is
+only set in default arguments.  */
+  if (processing_template_parmlist && !parser->local_variables_forbidden_p)
+   {
+ error_at (token->location,
+   "lambda-expression in template parameter type");
+ token->error_reported = true;
+ ok = false;
+   }
+}
   else if (cp_unevaluated_operand)
 {
   if (!token->error_reported)
diff --git a/gcc/testsuite/g++.dg/cpp2a/lambda-uneval14.C 
b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval14.C
new file mode 100644
index 000..a18035954e1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/lambda-uneval14.C
@@ -0,0 +1,6 @@
+// PR c++/99478
+// { dg-do compile { target c++20 } }
+
+template  auto f() {} // { dg-error "lambda" }
+
+int main() { f<{}>(); }// { dg-prune-output "no match" }

base-commit: 0589be0c59767cf4cbb0ef0e7d918cf6aa3d606c
-- 
2.27.0

Re: [PATCH wwwdoc] Mention Rocketlake [GCC11]

[Hongtao Liu via Gcc-patches]

On Mon, Apr 12, 2021 at 6:20 PM Cui, Lili via Gcc-patches
 wrote:
>
>
> Updated wwwdocs for Rocketlake [GCC11], thanks.
>
>  [PATCH] Mention Rocketlake
> ---
>  htdocs/gcc-11/changes.html | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
> index a7fa4e1b..38725abc 100644
> --- a/htdocs/gcc-11/changes.html
> +++ b/htdocs/gcc-11/changes.html
> @@ -634,6 +634,10 @@ a work-in-progress.
>  The switch enables the CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, KEYLOCKER,
>  AVX-VNNI, and HRESET ISA extensions.
>
> +  GCC now supports the Intel CPU named Rocketlake through
> +-march=rocketlake.
> +Rocket Lake is based on Icelake client and minus SGX.
> +  
>  
>
> --
> 2.17.1
> Thanks,
> Lili.

Committed.

-- 
BR,
Hongtao

Re: [RFC] Run pass_sink_code once more after ivopts/fre

[Xionghu Luo via Gcc-patches]

Hi,

On 2021/3/26 15:35, Xionghu Luo via Gcc-patches wrote:
>> Also we already have a sinking pass on RTL which even computes
>> a proper PRE on the reverse graph - -fgcse-sm aka store-motion.c.
>> I'm not sure whether this deals with non-stores but the
>> LCM machinery definitely can handle arbitrary expressions.  I wonder
>> if it makes more sense to extend this rather than inventing a new
>> ad-hoc sinking pass?
>  From the literal, my pass doesn't handle or process store instructions
> like store-motion..  Thanks, will check it.

Store motion only processes store instructions with data flow equations,
generating 4 inputs(st_kill, st_avloc, st_antloc, st_transp) and solve it
by Lazy Code Motion API(5 DF compute call) with 2 outputs (st_delete_map,
st_insert_map) globally, each store place is independently represented in
the input bitmap vectors. Output is which should be delete and where to
insert, current code does what you said "emit copies to a new pseudo at
the original insn location and use it in followed bb", actually it is
"store replacement" instead of "store move", why not save one pseudo by
moving the store instruction to target edge directly?

There are many differences between the newly added rtl-sink pass and
store-motion pass. 
1. Store motion moves only store instructions, rtl-sink ignores store
instructions. 
2. Store motion is a global DF problem solving, rtl-sink only processes
loop header reversely with dependency check in loop, take the below RTL
as example,
"#538,#235,#234,#233" will all be sunk from bb 35 to bb 37 by rtl-sink,
but it moves #538 first, then #235, there is strong dependency here. It
seemsdoesn't like the LCM framework that could solve all and do the
delete-insert in one iteration. 

However, there are still some common methods could be shared, like the
def-use check(though store-motion is per bb, rtl-sink is per loop),
insert_store, commit_edge_insertions etc.


  508: L508:
  507: NOTE_INSN_BASIC_BLOCK 34
   12: r139:DI=r140:DI
  REG_DEAD r140:DI
  240: L240:
  231: NOTE_INSN_BASIC_BLOCK 35
  232: r142:DI=zero_extend(r139:DI#0)
  233: r371:SI=r142:DI#0-0x1
  234: r243:DI=zero_extend(r371:SI)
  REG_DEAD r371:SI
  235: r452:DI=r262:DI+r139:DI
  538: r194:DI=r452:DI
  236: r372:CCUNS=cmp(r142:DI#0,r254:DI#0)
  237: pc={(geu(r372:CCUNS,0))?L246:pc}
  REG_DEAD r372:CCUNS
  REG_BR_PROB 59055804
  238: NOTE_INSN_BASIC_BLOCK 36
  239: r140:DI=r139:DI+0x1
  241: r373:DI=r251:DI-0x1
  242: r374:SI=zero_extend([r262:DI+r139:DI])
  REG_DEAD r139:DI
  243: r375:SI=zero_extend([r373:DI+r140:DI])
  REG_DEAD r373:DI
  244: r376:CC=cmp(r374:SI,r375:SI)
  REG_DEAD r375:SI
  REG_DEAD r374:SI
  245: pc={(r376:CC==0)?L508:pc}
  REG_DEAD r376:CC
  REG_BR_PROB 1014686028
  246: L246:
  247: NOTE_INSN_BASIC_BLOCK 37
  248: r377:SI=r142:DI#0-0x2
  REG_DEAD r142:DI
  249: r256:DI=zero_extend(r377:SI)


-- 
Thanks,
Xionghu

Re: [PATCH] [GCC-9] backport -march=tigerlake to GCC9 [PR target/100009]

[Hongtao Liu via Gcc-patches]

On Tue, Apr 13, 2021 at 6:38 PM Uros Bizjak  wrote:
>
> On Tue, Apr 13, 2021 at 12:18 PM Hongtao Liu  wrote:
> >
> > Hi:
> >   As described in PR, we introduced tigerlake string in driver-i386.c
> > by r9-8652 w/o support -march/tune=tigerlake which causes an error
> > when using -march/tune=native with GCC9 on tigerlake machine.
> >   Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
> >   Ok for GCC9?
> >
> > gcc/
> > * common/config/i386/i386-common.c
> > (processor_names): Add tigerlake.
> > (processor_alias_table): Ditto.
> > * config.gcc: Document -march=tigerlake.
>
> Nope. Better.
>
> (x86_64_archs): Ditto.
>
> > * config/i386/driver-i386.c
> > (host_detect_local_cpu): Detect tigerlake, add "has_avx" to
> > classify processor.
> > * config/i386/i386-c.c (ix86_target_macros_internal): Handle
> > tigerlake.
>
> Handle PROCESSOR_TIGERLAKE.
>
> > * config/i386/i386.c (m_TIGERLAKE)  : Define.
> > (m_CORE_AVX512): Ditto.
>
> You don't define this macro, but you add m_TIGERLAKE to m_CORE_AVX512.
> Please correct this confusion.
>
> > (processor_cost_table): Add tigerlake.
>
> Please correct the above. You added skylake_cost.
>
> > (ix86_option_override_internal): Handle PTA_MOVDIRI, PTA_MOVDIR64B.
>
> Where?
>
> > (processor_model): Add M_INTEL_COREI7_TIGERLAKE.
> > (arch_names_table): Add tigerlake.
> > (get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE.
> > * config/i386/i386.h (TARGET_TIGERLAKE): Define.
> > (processor_type) : Add PROCESSOR_TIGERLAKE.
>
> (enum processor_type)
>
> > (PTA_TIGERLAKE)  : Ditto.
>
> Ditto what? This is a new define.
>
> > * doc/extend.texi: Add tigerlake.
> > * doc/invoke.texi: Add tigerlake.
>
> Added where? To which section?
>
> > gcc/testsuite/
> > * gcc.target/i386/funcspec-56.inc: Handle new march.
> > * g++.target/i386/mv16.C: Handle new march
>
> Dot.
>
> >
> > libgcc/
> > * config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE.
>
> (enum processor_subtypes)
> >
> > From-SVN: r274693
>
> Please repost with improved/corrected ChangeLog.
>
> Uros.
>
> > --
> > BR,
> > Hongtao

updated.

gcc/
* common/config/i386/i386-common.c
(processor_names): Add tigerlake.
(processor_alias_table): Ditto.
* config.gcc (x86_64_archs): Ditto.
* config/i386/driver-i386.c
(host_detect_local_cpu): Detect tigerlake, add "has_avx" to
classify processor.
* config/i386/i386-c.c (ix86_target_macros_internal): Handle
PROCESSOR_TIGERLAKE.
* config/i386/i386.c (m_TIGERLAKE): Define.
(m_CORE_AVX512): Add m_TIGERLAKE.
(processor_cost_table): Add skylake_cost for tigerlake.
(processor_model): Add M_INTEL_COREI7_TIGERLAKE.
(arch_names_table): Add tigerlake.
(get_builtin_code_for_version): Handle PROCESSOR_TIGERLAKE.
* config/i386/i386.h (TARGET_TIGERLAKE): Define.
(enum processor_type): Add PROCESSOR_TIGERLAKE.
(PTA_TIGERLAKE): Define.
* doc/extend.texi (__builtin_cpu_is): Add tigerlake.
* doc/invoke.texi (-march=cpu-type): Ditto.

gcc/testsuite/
* gcc.target/i386/funcspec-56.inc: Handle new march.
* g++.target/i386/mv16.C: Handle new march.

libgcc/
* config/i386/cpuinfo.h (enum processor_subtypes): Add
INTEL_COREI7_TIGERLAKE.


-- 
BR,
Hongtao
From 0ab46895773076c388aa7aca34345041cd2ff694 Mon Sep 17 00:00:00 2001
From: Hongtao Liu 
Date: Tue, 20 Aug 2019 07:06:03 +
Subject: [PATCH] backport TIGERLAKE part to GCC9.

2019-08-20  Lili Cui  

gcc/
	* common/config/i386/i386-common.c
	(processor_names): Add tigerlake.
	(processor_alias_table): Ditto.
	* config.gcc (x86_64_archs): Ditto.
	* config/i386/driver-i386.c
	(host_detect_local_cpu): Detect tigerlake, add "has_avx" to
	classify processor.
	* config/i386/i386-c.c (ix86_target_macros_internal): Handle
	PROCESSOR_TIGERLAKE.
	* config/i386/i386.c (m_TIGERLAKE): Define.
	(m_CORE_AVX512): Add m_TIGERLAKE.
	(processor_cost_table): Add skylake_cost for tigerlake.
	(processor_model): Add M_INTEL_COREI7_TIGERLAKE.
	(arch_names_table): Add tigerlake.
	(get_builtin_code_for_version): Handle PROCESSOR_TIGERLAKE.
	* config/i386/i386.h (TARGET_TIGERLAKE): Define.
	(enum processor_type): Add PROCESSOR_TIGERLAKE.
	(PTA_TIGERLAKE): Define.
	* doc/extend.texi (__builtin_cpu_is): Add tigerlake.
	* doc/invoke.texi (-march=cpu-type): Ditto.

gcc/testsuite/
	* gcc.target/i386/funcspec-56.inc: Handle new march.
	* g++.target/i386/mv16.C: Handle new march.

libgcc/
	* config/i386/cpuinfo.h (enum processor_subtypes): Add
	INTEL_COREI7_TIGERLAKE.

	From-SVN: r274693
---
 gcc/common/config/i386/i386-common.c  |  2 +
 gcc/config.gcc|  3 +-
 gcc/config/i386/driver-i386.c | 62 ++-
 gcc/config/i386/i386-c.c 

Re: [PATCH] c++: Fix deduction with reference NTTP [PR83476]

[Jason Merrill via Gcc-patches]

On 4/13/21 6:36 PM, Patrick Palka wrote:

In the testcase ref11.C below, during deduction for the call f(a),
uses_deducible_template_parms returns false for the dependent
specialization A because V is wrapped in an implicit INDIRECT_REF
(formed from template_parm_to_arg), and this causes unify_one_argument
to exit early, causing deduction to fail.  This patch fixes this
by making deducible_expression look through such implicit INDIRECT_REFs.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?


OK.


gcc/cp/ChangeLog:

PR c++/83476
PR c++/99885
* pt.c (deducible_expression): Look through implicit
INDIRECT_REFs as well.

gcc/testsuite/ChangeLog:

PR c++/83476
PR c++/99885
* g++.dg/cpp1z/class-deduction85.C: New test.
* g++.dg/template/ref11.C: New test.
---
  gcc/cp/pt.c|  6 --
  gcc/testsuite/g++.dg/cpp1z/class-deduction85.C | 16 
  gcc/testsuite/g++.dg/template/ref11.C  |  9 +
  3 files changed, 29 insertions(+), 2 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction85.C
  create mode 100644 gcc/testsuite/g++.dg/template/ref11.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 59df79484bf..f488a5a8c12 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21902,8 +21902,10 @@ static bool uses_deducible_template_parms (tree type);
  static bool
  deducible_expression (tree expr)
  {
-  /* Strip implicit conversions.  */
-  while (CONVERT_EXPR_P (expr) || TREE_CODE (expr) == VIEW_CONVERT_EXPR)
+  /* Strip implicit conversions and implicit INDIRECT_REFs.  */
+  while (CONVERT_EXPR_P (expr)
+|| TREE_CODE (expr) == VIEW_CONVERT_EXPR
+|| REFERENCE_REF_P (expr))
  expr = TREE_OPERAND (expr, 0);
return (TREE_CODE (expr) == TEMPLATE_PARM_INDEX);
  }
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction85.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction85.C
new file mode 100644
index 000..0b22f8eb982
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction85.C
@@ -0,0 +1,16 @@
+// PR c++/99885
+// { dg-do compile { target c++17 } }
+
+template 
+struct Foo {};
+
+template 
+struct Bar {
+constexpr auto foo() const -> Foo {
+return {};
+}
+};
+
+constexpr int a = 1;
+constexpr Bar bar;
+Foo foo = bar.foo(); // <-- CTAD failure
diff --git a/gcc/testsuite/g++.dg/template/ref11.C 
b/gcc/testsuite/g++.dg/template/ref11.C
new file mode 100644
index 000..ef29fb72bef
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/ref11.C
@@ -0,0 +1,9 @@
+// PR c++/83476
+
+template  struct A {};
+template  void f(A);
+int n;
+int main() {
+  A a;
+  f(a);
+}

[pushed] c++: DWARF ICE with defaulted specialization [PR90674]

[Jason Merrill via Gcc-patches]

Here when we merged the specialization with the implicit instantiation
declaration, we wrongly kept the value of DECL_INITIALIZED_IN_CLASS_P from
the latter.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/90674
* decl.c (duplicate_decls): Don't propagate
DECL_INITIALIZED_IN_CLASS_P to a specialization.

gcc/testsuite/ChangeLog:

PR c++/90674
* g++.dg/debug/defaulted1.C: New test.
---
 gcc/cp/decl.c   |  5 +++--
 gcc/testsuite/g++.dg/debug/defaulted1.C | 10 ++
 2 files changed, 13 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/defaulted1.C

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index ec05ee1f0b4..1cb47313923 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -2556,8 +2556,9 @@ duplicate_decls (tree newdecl, tree olddecl, bool hiding, 
bool was_hidden)
  if (!DECL_USE_TEMPLATE (newdecl))
DECL_USE_TEMPLATE (newdecl) = DECL_USE_TEMPLATE (olddecl);
 
- DECL_INITIALIZED_IN_CLASS_P (newdecl)
-   |= DECL_INITIALIZED_IN_CLASS_P (olddecl);
+ if (!DECL_TEMPLATE_SPECIALIZATION (newdecl))
+   DECL_INITIALIZED_IN_CLASS_P (newdecl)
+ |= DECL_INITIALIZED_IN_CLASS_P (olddecl);
}
 
   /* Don't really know how much of the language-specific
diff --git a/gcc/testsuite/g++.dg/debug/defaulted1.C 
b/gcc/testsuite/g++.dg/debug/defaulted1.C
new file mode 100644
index 000..3ea7ae72b96
--- /dev/null
+++ b/gcc/testsuite/g++.dg/debug/defaulted1.C
@@ -0,0 +1,10 @@
+// PR c++/90674
+// { dg-do compile { target c++11 } }
+
+template
+struct C {
+C() {}
+};
+
+template<>
+C::C() = default;

base-commit: 006783f4b165dff25aae3697920fcf547544
-- 
2.27.0

[pushed] c++: debug location of variable cleanups [PR88742]

[Jason Merrill via Gcc-patches]

PR49951 complained about the debugger jumping back to the declaration of a
local variable when we run its destructor.  That was fixed in 4.7, but broke
again in 4.8.  PR58123 fixed an inconsistency in the behavior, but not the
jumping around.  This patch addresses the issue by setting EXPR_LOCATION on
a cleanup destructor call to the location of the closing brace of the
compound-statement, or whatever token ends the scope of the variable.

The change to cp_parser_compound_statement is so input_location is the }
rather than the ; of the last substatement.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/88742
PR c++/49951
PR c++/58123
* semantics.c (set_cleanup_locs): New.
(do_poplevel): Call it.
* parser.c (cp_parser_compound_statement): Consume the }
before finish_compound_stmt.

gcc/testsuite/ChangeLog:

PR c++/88742
* g++.dg/debug/cleanup1.C: New test.
* c-c++-common/Wimplicit-fallthrough-6.c: Adjust diagnostic line.
* c-c++-common/Wimplicit-fallthrough-7.c: Likewise.
* g++.dg/cpp2a/constexpr-dtor3.C: Likewise.
* g++.dg/ext/constexpr-attr-cleanup1.C: Likewise.
* g++.dg/tm/inherit2.C: Likewise.
* g++.dg/tm/unsafe1.C: Likewise.
* g++.dg/warn/Wimplicit-fallthrough-1.C: Likewise.
* g++.dg/gcov/gcov-2.C: Adjust coverage counts.
---
 gcc/cp/parser.c   |  5 ++-
 gcc/cp/semantics.c| 19 +
 .../c-c++-common/Wimplicit-fallthrough-6.c| 16 
 .../c-c++-common/Wimplicit-fallthrough-7.c|  4 +-
 gcc/testsuite/g++.dg/cpp2a/constexpr-dtor3.C  |  4 +-
 gcc/testsuite/g++.dg/debug/cleanup1.C | 41 +++
 .../g++.dg/ext/constexpr-attr-cleanup1.C  |  4 +-
 gcc/testsuite/g++.dg/gcov/gcov-2.C|  4 +-
 gcc/testsuite/g++.dg/tm/inherit2.C|  4 +-
 gcc/testsuite/g++.dg/tm/unsafe1.C |  4 +-
 .../g++.dg/warn/Wimplicit-fallthrough-1.C |  4 +-
 11 files changed, 85 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/cleanup1.C

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 8b7801b2be7..aec3aa3587f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12126,11 +12126,12 @@ cp_parser_compound_statement (cp_parser *parser, tree 
in_statement_expr,
   if (function_body)
 maybe_splice_retval_cleanup (compound_stmt);
 
-  /* Finish the compound-statement.  */
-  finish_compound_stmt (compound_stmt);
   /* Consume the `}'.  */
   braces.require_close (parser);
 
+  /* Finish the compound-statement.  */
+  finish_compound_stmt (compound_stmt);
+
   return compound_stmt;
 }
 
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 8eaaaefe2d6..125772238d3 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -602,6 +602,22 @@ add_decl_expr (tree decl)
   add_stmt (r);
 }
 
+/* Set EXPR_LOCATION of the cleanups of any CLEANUP_STMT in STMTS to LOC.  */
+
+static void
+set_cleanup_locs (tree stmts, location_t loc)
+{
+  if (TREE_CODE (stmts) == CLEANUP_STMT)
+{
+  protected_set_expr_location (CLEANUP_EXPR (stmts), loc);
+  set_cleanup_locs (CLEANUP_BODY (stmts), loc);
+}
+  else if (TREE_CODE (stmts) == STATEMENT_LIST)
+for (tree_stmt_iterator i = tsi_start (stmts);
+!tsi_end_p (i); tsi_next (&i))
+  set_cleanup_locs (tsi_stmt (i), loc);
+}
+
 /* Finish a scope.  */
 
 tree
@@ -614,6 +630,9 @@ do_poplevel (tree stmt_list)
 
   stmt_list = pop_stmt_list (stmt_list);
 
+  /* input_location is the last token of the scope, usually a }.  */
+  set_cleanup_locs (stmt_list, input_location);
+
   if (!processing_template_decl)
 {
   stmt_list = c_build_bind_expr (input_location, block, stmt_list);
diff --git a/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-6.c 
b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-6.c
index 32d5febda83..9593f670709 100644
--- a/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-6.c
+++ b/gcc/testsuite/c-c++-common/Wimplicit-fallthrough-6.c
@@ -121,8 +121,8 @@ L1:
int j = 0;
bar (j);
if (j == 8)
- return; /* { dg-warning "statement may fall through" "" { target c++ 
} } */
-  }
+ return;
+  } /* { dg-warning "statement may fall through" "" { target c++ } } */
 case 2:
   bar (99);
 }
@@ -151,8 +151,8 @@ L1:
if (j == 8)
  bar (1);
else
- return; /* { dg-warning "statement may fall through" "" { target c++ 
} } */
-  }
+ return;
+  } /* { dg-warning "statement may fall through" "" { target c++ } } */
 case 2:
   bar (99);
 }
@@ -181,8 +181,8 @@ L1:
if (j == 8)
  bar (1);
else
- bar (2); /* { dg-warning "statement may fall through" "" { target c++ 
} } */
-  }
+ bar (2);
+  } /* { dg-warning "statement may fall through" "" { target c++ } } */
 case 2:
   bar (99);
 }
@

[PATCH] c++: Fix deduction with reference NTTP [PR83476]

[Patrick Palka via Gcc-patches]

In the testcase ref11.C below, during deduction for the call f(a),
uses_deducible_template_parms returns false for the dependent
specialization A because V is wrapped in an implicit INDIRECT_REF
(formed from template_parm_to_arg), and this causes unify_one_argument
to exit early, causing deduction to fail.  This patch fixes this
by making deducible_expression look through such implicit INDIRECT_REFs.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?

gcc/cp/ChangeLog:

PR c++/83476
PR c++/99885
* pt.c (deducible_expression): Look through implicit
INDIRECT_REFs as well.

gcc/testsuite/ChangeLog:

PR c++/83476
PR c++/99885
* g++.dg/cpp1z/class-deduction85.C: New test.
* g++.dg/template/ref11.C: New test.
---
 gcc/cp/pt.c|  6 --
 gcc/testsuite/g++.dg/cpp1z/class-deduction85.C | 16 
 gcc/testsuite/g++.dg/template/ref11.C  |  9 +
 3 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/class-deduction85.C
 create mode 100644 gcc/testsuite/g++.dg/template/ref11.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 59df79484bf..f488a5a8c12 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21902,8 +21902,10 @@ static bool uses_deducible_template_parms (tree type);
 static bool
 deducible_expression (tree expr)
 {
-  /* Strip implicit conversions.  */
-  while (CONVERT_EXPR_P (expr) || TREE_CODE (expr) == VIEW_CONVERT_EXPR)
+  /* Strip implicit conversions and implicit INDIRECT_REFs.  */
+  while (CONVERT_EXPR_P (expr)
+|| TREE_CODE (expr) == VIEW_CONVERT_EXPR
+|| REFERENCE_REF_P (expr))
 expr = TREE_OPERAND (expr, 0);
   return (TREE_CODE (expr) == TEMPLATE_PARM_INDEX);
 }
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction85.C 
b/gcc/testsuite/g++.dg/cpp1z/class-deduction85.C
new file mode 100644
index 000..0b22f8eb982
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction85.C
@@ -0,0 +1,16 @@
+// PR c++/99885
+// { dg-do compile { target c++17 } }
+
+template 
+struct Foo {};
+
+template 
+struct Bar {
+constexpr auto foo() const -> Foo {
+return {};
+}
+};
+
+constexpr int a = 1;
+constexpr Bar bar;
+Foo foo = bar.foo(); // <-- CTAD failure
diff --git a/gcc/testsuite/g++.dg/template/ref11.C 
b/gcc/testsuite/g++.dg/template/ref11.C
new file mode 100644
index 000..ef29fb72bef
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/ref11.C
@@ -0,0 +1,9 @@
+// PR c++/83476
+
+template  struct A {};
+template  void f(A);
+int n;
+int main() {
+  A a;
+  f(a);
+}
-- 
2.31.1.272.g89b43f80a5

Re: [PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC

[Segher Boessenkool]

Hi!

On Fri, Apr 09, 2021 at 10:42:50AM -0400, Michael Meissner wrote:
> Since then the patch seems to have gone into a limbo state.

Patches I cannot immediately handle take time, and if they aren't
pinged, they can fall off the map.  So a) ping your patches, once a week
for example; and b) write patches that are simpler to review (do not
cost many hours each).

> gcc/
> 2021-04-09  Michael Meissner  
> 
>   * config/rs6000/rs6000.c (rs6000_emit_minmax): Add support for ISA
>   3.1 IEEE 128-bit floating point xsmaxcqp and xsmincqp instructions.
>   * config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New macro.

As said in the other mail, don't do the macro; just write its expansion
in the single place it is used.

>   * config/rs6000/rs6000.md (s3): Add support for the
>   ISA 3.1 IEEE 128-bit minimum and maximum instructions.

And rephrase this, just "New" something.

So please resend, taking into account all comments.


Segher

[committed] add test for PR 82800

[Martin Sebor via Gcc-patches]

The bug was fixed years ago. r11-8162 adds the test case to the test
suite.

  https://gcc.gnu.org/g:af7128621e54f04b90589bb0c3e1ef271c239265

Martin

[committed] add test for PR 86058

[Martin Sebor via Gcc-patches]

The issue has been fixed so r11-8161 just adds the test case:
  https://gcc.gnu.org/g:8084ab15a3e300e3b2c537e56e0f3a1b00778aec

Martin

Re: [PATCH] c++: Reject alias CTAD in C++17 [PR99008]

[Patrick Palka via Gcc-patches]

On Tue, 13 Apr 2021, Jason Merrill wrote:

> On 4/13/21 8:41 AM, Jason Merrill wrote:
> > On 4/12/21 6:24 PM, Patrick Palka wrote:
> > > On Mon, 12 Apr 2021, Jason Merrill wrote:
> > > 
> > > > On 4/10/21 3:57 PM, Patrick Palka wrote:
> > > > > Here, in C++17 mode, we only pedwarn about the use of alias CTAD and
> > > > > then later ICE from alias_ctad_tweaks when attempting to add a
> > > > > constraint to one of the guides.  Since the construction of the guides
> > > > > of an alias template effectively relies on concepts, we shouldn't be
> > > > > permissive about alias CTAD in C++17 mode, so this patch turns the
> > > > > pertinent pedwarn in do_class_deduction into an error.
> > > > 
> > > > Sounds good.
> > > > 
> > > > > In order to get a consistent diagnostic for B() vs the other forms in
> > > > > the added testcase, I had to remove the special handling of CTAD with
> > > > > empty initializer in build_functional_cast_1 so that we always pass
> > > > > 'complain' to do_auto_deduction.
> > > > 
> > > > Did you compare the resulting diagnostics when deduction fails other
> > > > than for
> > > > trying to do alias deduction in C++17 mode?
> > > 
> > > For plain CTAD, e.g. for
> > > 
> > >    template  struct A { };
> > >    auto a = A();
> > > 
> > > we previously emitted
> > > 
> > > test.C:2:10: error: cannot deduce template arguments for ‘A<...auto...>’
> > > from ‘()’
> > >  2 | auto a = A();
> > >    |  ^~~
> > > 
> > > and now we emit
> > > 
> > > test.C:2:12: error: class template argument deduction failed:
> > >  2 | auto a = A();
> > >    |    ^
> > > test.C:2:12: error: no matching function for call to ‘A()’
> > > test.C:1:27: note: candidate: ‘template A()-> A’
> > >  1 | template  struct A { };
> > >    |   ^
> > > test.C:1:27: note:   template argument deduction/substitution failed:
> > > test.C:2:12: note:   couldn’t deduce template parameter ‘T’
> > >  2 | auto a = A();
> > >    |    ^
> > > test.C:1:27: note: candidate: ‘template A(A)-> A’
> > >  1 | template  struct A { };
> > >    |   ^
> > > test.C:1:27: note:   template argument deduction/substitution failed:
> > > test.C:2:12: note:   candidate expects 1 argument, 0 provided
> > >  2 | auto a = A();
> > >    |    ^
> > > 
> > > which is consistent with what we already emit for failed CTAD of the
> > > form A{}, A(args) and A{args}.
> > 
> > Thanks, that's fine.  The patch is OK.
> 
> Looks like you still need to adjust three testcases in g++.old-deja:
> g++.ns/crash3.C, g++.ns/template7.C, g++.pt/crash8.C.

Drat, sorry about that.  Not sure how I missed these.  Fixed thusly
after testing on x86_64-pc-linux-gnu.

-- >8 --

Subject: [committed] c++: Adjust expected diagnostics for old-deja tests 
[PR99008]

I missed adjusting these tests in the recently committed r11-8155.

gcc/testsuite/ChangeLog:

PR c++/99008
* g++.old-deja/g++.ns/crash3.C: Adjust expected diagnostic.
* g++.old-deja/g++.ns/template7.C: Likewise.
* g++.old-deja/g++.pt/crash8.C: Likewise.
---
 gcc/testsuite/g++.old-deja/g++.ns/crash3.C| 2 +-
 gcc/testsuite/g++.old-deja/g++.ns/template7.C | 2 +-
 gcc/testsuite/g++.old-deja/g++.pt/crash8.C| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/testsuite/g++.old-deja/g++.ns/crash3.C 
b/gcc/testsuite/g++.old-deja/g++.ns/crash3.C
index 189298de6c5..b5e6323dba9 100644
--- a/gcc/testsuite/g++.old-deja/g++.ns/crash3.C
+++ b/gcc/testsuite/g++.old-deja/g++.ns/crash3.C
@@ -6,6 +6,6 @@ namespace N {
 
 void f()
 {
-  N::S(); // { dg-error "6:cannot deduce template arguments" "" { target c++17 
} } invalid use of template
+  N::S(); // { dg-error "8:class template argument deduction failed|no match" 
"" { target c++17 } } invalid use of template
   // { dg-error "7:missing template arguments" "" { target c++14_down } .-1 }
 }
diff --git a/gcc/testsuite/g++.old-deja/g++.ns/template7.C 
b/gcc/testsuite/g++.old-deja/g++.ns/template7.C
index 71366b79d02..441a41249d1 100644
--- a/gcc/testsuite/g++.old-deja/g++.ns/template7.C
+++ b/gcc/testsuite/g++.old-deja/g++.ns/template7.C
@@ -8,6 +8,6 @@ namespace foo {
 }
 
 void baz() {
-  foo::bar(); // { dg-error "8:cannot deduce template arguments" "" { target 
c++17 } } template used as expression
+  foo::bar(); // { dg-error "12:class template argument deduction failed|no 
match" "" { target c++17 } } template used as expression
   // { dg-error "11:missing template arguments" "" { target c++14_down } .-1 }
 }
diff --git a/gcc/testsuite/g++.old-deja/g++.pt/crash8.C 
b/gcc/testsuite/g++.old-deja/g++.pt/crash8.C
index 7b4eff595bf..678a728f352 100644
--- a/gcc/testsuite/g++.old-deja/g++.pt/crash8.C
+++ b/gcc/testsuite/g++.old-deja/g++.pt/crash8.C
@@ -21,11 +21,11 @@ void doit(T x) {
   q2 = TestClass2();
 
   TestClass1 p1;
-  p1 = TestClass1(); // { dg-error "8:cannot deduce template arguments" "" { 
ta

[r11-8155 Regression] FAIL: g++.old-deja/g++.pt/crash8.C -std=c++2a (test for excess errors) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

8913b2c2bcded39427ff27e6dfc276ae8555f6b8 is the first bad commit
commit 8913b2c2bcded39427ff27e6dfc276ae8555f6b8
Author: Patrick Palka 
Date:   Tue Apr 13 12:35:33 2021 -0400

c++: Reject alias CTAD in C++17 [PR99008]

caused

FAIL: g++.old-deja/g++.ns/crash3.C  -std=c++17  (test for errors, line 9)
FAIL: g++.old-deja/g++.ns/crash3.C  -std=c++17 (test for excess errors)
FAIL: g++.old-deja/g++.ns/crash3.C  -std=c++2a  (test for errors, line 9)
FAIL: g++.old-deja/g++.ns/crash3.C  -std=c++2a (test for excess errors)
FAIL: g++.old-deja/g++.ns/template7.C  -std=c++17  (test for errors, line 11)
FAIL: g++.old-deja/g++.ns/template7.C  -std=c++17 (test for excess errors)
FAIL: g++.old-deja/g++.ns/template7.C  -std=c++2a  (test for errors, line 11)
FAIL: g++.old-deja/g++.ns/template7.C  -std=c++2a (test for excess errors)
FAIL: g++.old-deja/g++.pt/crash8.C  -std=c++17  (test for errors, line 24)
FAIL: g++.old-deja/g++.pt/crash8.C  -std=c++17  (test for errors, line 28)
FAIL: g++.old-deja/g++.pt/crash8.C  -std=c++17 (test for excess errors)
FAIL: g++.old-deja/g++.pt/crash8.C  -std=c++2a  (test for errors, line 24)
FAIL: g++.old-deja/g++.pt/crash8.C  -std=c++2a  (test for errors, line 28)
FAIL: g++.old-deja/g++.pt/crash8.C  -std=c++2a (test for excess errors)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-8155/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/crash3.C 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/crash3.C 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/crash3.C 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/crash3.C 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/template7.C 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/template7.C 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/template7.C 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.ns/template7.C 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.pt/crash8.C 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.pt/crash8.C 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.pt/crash8.C 
--target_board='unix{-m64}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="old-deja.exp=g++.old-deja/g++.pt/crash8.C 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

[pushed] c++: alias template equivalence and cv-quals [PR100032]

[Jason Merrill via Gcc-patches]

We also need to check that the cv-qualifiers are the same.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/100032
* pt.c (get_underlying_template): Compare TYPE_QUALS.

gcc/testsuite/ChangeLog:

PR c++/100032
* g++.dg/cpp0x/alias-decl-equiv1.C: New test.
---
 gcc/cp/pt.c|  4 
 gcc/testsuite/g++.dg/cpp0x/alias-decl-equiv1.C | 13 +
 2 files changed, 17 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-equiv1.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 106dfe556f7..59df79484bf 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -6584,6 +6584,10 @@ get_underlying_template (tree tmpl)
  != num_innermost_template_parms (underlying)))
break;
 
+  /* Does the alias add cv-quals?  */
+  if (TYPE_QUALS (TREE_TYPE (underlying)) != TYPE_QUALS (TREE_TYPE (tmpl)))
+   break;
+
   tree alias_args = INNERMOST_TEMPLATE_ARGS (generic_targs_for (tmpl));
   if (!comp_template_args (TI_ARGS (tinfo), alias_args))
break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/alias-decl-equiv1.C 
b/gcc/testsuite/g++.dg/cpp0x/alias-decl-equiv1.C
new file mode 100644
index 000..ae27c43bc0a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/alias-decl-equiv1.C
@@ -0,0 +1,13 @@
+// PR c++/100032
+// { dg-do compile { target c++11 } }
+
+template  class> struct X { };
+template  struct Y { };
+template  using Z = const Y;
+
+template  using W = Z;
+using U = X;
+using U = X;
+
+using T = X;
+using T = X;// { dg-error "conflicting declaration" 
}

base-commit: 4df918798b445e86305b63f86f5312a18e4017c5
-- 
2.27.0

Re: [PATCH] c++: Reject alias CTAD in C++17 [PR99008]

[Jason Merrill via Gcc-patches]

On 4/13/21 8:41 AM, Jason Merrill wrote:

On 4/12/21 6:24 PM, Patrick Palka wrote:

On Mon, 12 Apr 2021, Jason Merrill wrote:


On 4/10/21 3:57 PM, Patrick Palka wrote:

Here, in C++17 mode, we only pedwarn about the use of alias CTAD and
then later ICE from alias_ctad_tweaks when attempting to add a
constraint to one of the guides.  Since the construction of the guides
of an alias template effectively relies on concepts, we shouldn't be
permissive about alias CTAD in C++17 mode, so this patch turns the
pertinent pedwarn in do_class_deduction into an error.


Sounds good.


In order to get a consistent diagnostic for B() vs the other forms in
the added testcase, I had to remove the special handling of CTAD with
empty initializer in build_functional_cast_1 so that we always pass
'complain' to do_auto_deduction.


Did you compare the resulting diagnostics when deduction fails other 
than for

trying to do alias deduction in C++17 mode?


For plain CTAD, e.g. for

   template  struct A { };
   auto a = A();

we previously emitted

test.C:2:10: error: cannot deduce template arguments for 
‘A<...auto...>’ from ‘()’

 2 | auto a = A();
   |  ^~~

and now we emit

test.C:2:12: error: class template argument deduction failed:
 2 | auto a = A();
   |    ^
test.C:2:12: error: no matching function for call to ‘A()’
test.C:1:27: note: candidate: ‘template A()-> A’
 1 | template  struct A { };
   |   ^
test.C:1:27: note:   template argument deduction/substitution failed:
test.C:2:12: note:   couldn’t deduce template parameter ‘T’
 2 | auto a = A();
   |    ^
test.C:1:27: note: candidate: ‘template A(A)-> A’
 1 | template  struct A { };
   |   ^
test.C:1:27: note:   template argument deduction/substitution failed:
test.C:2:12: note:   candidate expects 1 argument, 0 provided
 2 | auto a = A();
   |    ^

which is consistent with what we already emit for failed CTAD of the
form A{}, A(args) and A{args}.


Thanks, that's fine.  The patch is OK.


Looks like you still need to adjust three testcases in g++.old-deja: 
g++.ns/crash3.C, g++.ns/template7.C, g++.pt/crash8.C.


Jason

[PATCH] testsuite: Add testcase for already fixed PR97121

[Jakub Jelinek via Gcc-patches]

Hi!

This was fixed by r11-5866 aka PR96299 fix.
This just adds a testcase for it into the testsuite, tested
on x86_64-linux -m32/-m64, committed to trunk.

2021-04-13  Jakub Jelinek  

PR c++/97121
* g++.dg/cpp2a/spaceship-err6.C: New test.

--- gcc/testsuite/g++.dg/cpp2a/spaceship-err6.C.jj  2021-04-13 
20:33:40.206442108 +0200
+++ gcc/testsuite/g++.dg/cpp2a/spaceship-err6.C 2021-04-13 20:38:23.740283353 
+0200
@@ -0,0 +1,20 @@
+// PR c++/97121
+// { dg-do compile { target c++20 } }
+
+#include 
+
+class MyClass
+{
+  int mValue;  // { dg-error "three-way comparison of 'MyClass::mValue' has 
type 'std::strong_ordering', which does not convert to 'bool'" }
+
+public:
+  MyClass(int value): mValue(value) {}
+
+  bool operator<=>(const MyClass&) const = default;
+};
+
+int main()
+{
+  MyClass a = 10, b = 15;
+  return (a < b);  // { dg-error "use of deleted function 'constexpr bool 
MyClass::operator<=>\\\(const MyClass&\\\) const'" }
+}

Jakub

Re: [committed] gimple UIDs, LTO and -fanalyzer [PR98599]

[David Malcolm via Gcc-patches]

On Tue, 2021-04-13 at 14:21 -0400, David Malcolm via Gcc-patches wrote:
> On Tue, 2021-04-13 at 08:08 +0200, Jan Hubicka wrote:
> > Hi,
> > stepping through the streaming process it turns out to be funny
> > difference between gimple_has_body and node->has_gimple_body_p.
> > While the first tests whether gimple body really exists in memory
> > (by
> > looking for DECL_STRUCT_FUNCTION) the second tests if gimple body
> > can
> > be
> > made available via node->get_body (so gimple_body_p returns 1).
> > 
> > Now what happens is that function clone is created and the original
> > function becomes dead and thus is marked as external declaration.
> > At
> > this point we can not get the body via node->get_body, but body is
> > still
> > around since analyzer read it. This makes the renumbering loop to
> > miss
> > this particular body.  Since for node->clone_of we have
> >  gimple_body_p (node->clone_of->decl) == true
> > and
> >  node->has_gimple_body_p (node->clone_of) == false
> > While for node we have
> >  node->has_gimple_body_p (node) == true
> > 
> > This is both correct but next stage1 we really ought to rename one
> > of
> > predicates. Sadly I can not think of much better names though.
> > 
> > I am testing. 
> > 
> > diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> > index ceb61bb300b..5903f75ac23 100644
> > --- a/gcc/lto/lto.c
> > +++ b/gcc/lto/lto.c
> > @@ -306,7 +306,7 @@ lto_wpa_write_files (void)
> >    cgraph_node *node;
> >    /* Do body modifications needed for streaming before we fork out
> >   worker processes.  */
> > -  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
> > +  FOR_EACH_FUNCTION (node)
> >  if (!node->clone_of && gimple_has_body_p (node->decl))
> >    lto_prepare_function_for_streaming (node);
> > 
> 
> Thanks for digging into it.
> 
> 
> FWIW the above patch seems to fix my reproducer (if I remove the uid
> restoration logic from my patch).  But maybe leave it to next stage
> 1,
> and keep my workaround for now?
> 
> On the subject of the analyzer and LTO, I should note that the
> analyzer
> somewhat abuses the framework by doing all of the analysis together
> in
> WPA, rather than trying to storing summaries from WPA to allow
> sharding
> of the analysis in LTRANS.  The analyzer currently only has a
> placeholder implementation of call summarization; it's something I
> hope
> to look at for GCC 12:

FWIW I meant to paste:
  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=99390
here, ("[meta-bug] tracker bug for call summaries in -fanalyzer")

> Updating it further to properly split things between WPA and LTRANS
> would be additional work on top of that.
> 
> Dave
> 

Re: [committed] gimple UIDs, LTO and -fanalyzer [PR98599]

[David Malcolm via Gcc-patches]

On Tue, 2021-04-13 at 08:08 +0200, Jan Hubicka wrote:
> Hi,
> stepping through the streaming process it turns out to be funny
> difference between gimple_has_body and node->has_gimple_body_p.
> While the first tests whether gimple body really exists in memory (by
> looking for DECL_STRUCT_FUNCTION) the second tests if gimple body can
> be
> made available via node->get_body (so gimple_body_p returns 1).
> 
> Now what happens is that function clone is created and the original
> function becomes dead and thus is marked as external declaration. At
> this point we can not get the body via node->get_body, but body is
> still
> around since analyzer read it. This makes the renumbering loop to
> miss
> this particular body.  Since for node->clone_of we have
>  gimple_body_p (node->clone_of->decl) == true
> and
>  node->has_gimple_body_p (node->clone_of) == false
> While for node we have
>  node->has_gimple_body_p (node) == true
> 
> This is both correct but next stage1 we really ought to rename one of
> predicates. Sadly I can not think of much better names though.
> 
> I am testing. 
> 
> diff --git a/gcc/lto/lto.c b/gcc/lto/lto.c
> index ceb61bb300b..5903f75ac23 100644
> --- a/gcc/lto/lto.c
> +++ b/gcc/lto/lto.c
> @@ -306,7 +306,7 @@ lto_wpa_write_files (void)
>    cgraph_node *node;
>    /* Do body modifications needed for streaming before we fork out
>   worker processes.  */
> -  FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
> +  FOR_EACH_FUNCTION (node)
>  if (!node->clone_of && gimple_has_body_p (node->decl))
>    lto_prepare_function_for_streaming (node);
> 

Thanks for digging into it.


FWIW the above patch seems to fix my reproducer (if I remove the uid
restoration logic from my patch).  But maybe leave it to next stage 1,
and keep my workaround for now?

On the subject of the analyzer and LTO, I should note that the analyzer
somewhat abuses the framework by doing all of the analysis together in
WPA, rather than trying to storing summaries from WPA to allow sharding
of the analysis in LTRANS.  The analyzer currently only has a
placeholder implementation of call summarization; it's something I hope
to look at for GCC 12:

Updating it further to properly split things between WPA and LTRANS
would be additional work on top of that.

Dave

[pushed] c++: generic lambda in template fn with DMI [PR100054]

[Jason Merrill via Gcc-patches]

get_nsdmi instantiates default member initializers on demand.  It tries to
push into the context of the class before doing so, so access checking works
properly, but since my patch for 90479 not for local classes.  We should
only be doing this when any template parameters have arguments.  But in this
case, we get here while regenerating a generic lambda, so
processing_template_decl is true, even though the class and its DMI are
non-dependent at this point.  And so we crashed.  So let's do more of the
pushing into the context of the class even for local classes.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/100054
PR c++/90479
* init.c (get_nsdmi): Do more context adjustment for local classes.

gcc/testsuite/ChangeLog:

PR c++/100054
* g++.dg/cpp1y/lambda-generic-local-class1.C: New test.
---
 gcc/cp/init.c   | 17 +++--
 .../g++.dg/cpp1y/lambda-generic-local-class1.C  | 10 ++
 2 files changed, 21 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1y/lambda-generic-local-class1.C

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 91b45a1a695..a85f4d50750 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -586,17 +586,21 @@ get_nsdmi (tree member, bool in_ctor, tsubst_flags_t 
complain)
 
  bool pushed = false;
  tree ctx = DECL_CONTEXT (member);
- if (!currently_open_class (ctx)
- && !LOCAL_CLASS_P (ctx))
+
+ processing_template_decl_sentinel ptds (/*reset*/false);
+ if (!currently_open_class (ctx))
{
- push_to_top_level ();
+ if (!LOCAL_CLASS_P (ctx))
+   push_to_top_level ();
+ else
+   /* push_to_top_level would lose the necessary function context,
+  just reset processing_template_decl.  */
+   processing_template_decl = 0;
  push_nested_class (ctx);
  push_deferring_access_checks (dk_no_deferred);
  pushed = true;
}
 
- gcc_checking_assert (!processing_template_decl);
-
  inject_this_parameter (ctx, TYPE_UNQUALIFIED);
 
  start_lambda_scope (member);
@@ -619,7 +623,8 @@ get_nsdmi (tree member, bool in_ctor, tsubst_flags_t 
complain)
{
  pop_deferring_access_checks ();
  pop_nested_class ();
- pop_from_top_level ();
+ if (!LOCAL_CLASS_P (ctx))
+   pop_from_top_level ();
}
 
  input_location = sloc;
diff --git a/gcc/testsuite/g++.dg/cpp1y/lambda-generic-local-class1.C 
b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-local-class1.C
new file mode 100644
index 000..7498327981b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/lambda-generic-local-class1.C
@@ -0,0 +1,10 @@
+// PR c++/100054
+// { dg-do compile { target c++14 } }
+
+template 
+void f() {
+  struct A { T m{}; };
+  [](auto){ return A{}; };
+}
+
+template void f();

base-commit: 0851ac6df0596df1e3b640e58094cf94ebb790b8
-- 
2.27.0

Re: [PATCH 1/2] Add IEEE 128-bit min/max support on PowerPC

[Segher Boessenkool]

Hi!

On Fri, Apr 09, 2021 at 11:54:57AM -0500, will schmidt wrote:
> On Fri, 2021-04-09 at 10:42 -0400, Michael Meissner wrote:
> > * config/rs6000/rs6000.c (rs6000_emit_minmax): Add support for ISA
> > 3.1 IEEE 128-bit floating point xsmaxcqp and xsmincqp instructions.
> 
> I don't see any direct reference to xsmaxcqp or xsmincqp with respect
> to this change below. 
> 
> It looks like this change adds the FLOAT128_MIN_MAX_FPMASK_P (mode)
> check
> as criteria for emitting some form of a SET instruction. 
>emit_insn (gen_rtx_SET (dest, gen_rtx_fmt_ee (code, mode, op0, op1)));
> 
> Ok, I see it now,  the instructions are mildly obfuscated by
> "xscqp" as part of the rs6000.md change below.

Yeah, that is the downside of using iterators and the like in the
machine description.  But the upsides of that far outweigh these
downsides :-)

> > * config/rs6000/rs6.h (FLOAT128_MIN_MAX_FPMASK_P): New macro.
> 
> which is
> #define FLOAT128_MIN_MAX_FPMASK_P(MODE)   \
>   (TARGET_POWER10 && TARGET_FLOAT128_HW && FLOAT128_IEEE_P (MODE))
> 
> Are there any non MIN_MAX scenarios that will require the combination
> of POWER10,FLOAT128_HW,FLOAT128_IEEE(mode)?  I'd wonder if there is a name
> not specific to *_MIN_MAX_* that would be a better naming choice.
> But, naming is hard. :-)

Yes, and for every new macro, the reader will have to understand what it
does, what it is for.  If you cannot come up with a good name for it
(one for which it is immediately obvious to the reader what it *means*),
often a good tradeoff is to not make a macro at all, just write out the
few words where you need them.

> > * config/rs6000/rs6000.md (s3): Add support for the
> > ISA 3.1 IEEE 128-bit minimum and maximum instructions.
> 
> I'd move the "xsmaxcqp,xsmincqp" instruction references from the rs6000.c 
> changelog blurb to this changelog blurb.

It should say "New." or "New define_insns." or "New instructions." or
similar.  The changelog says *what*, not *why*.  And it is important
that you can find stuff in it using grep or similar.

Here it should say "s3 for IEEE128".  We actually have
some patterns that just say "3", not too useful in a
changelog if you do not say what code and mode are!  (In this case, it
does not help to say what "minmax" is from, it stand for just "min" and
"max" after all :-) )


Segher

Re: [PATCH] propagate attributes to local redeclaration (PR 99420)

[Martin Sebor via Gcc-patches]

On 4/13/21 10:07 AM, Jeff Law wrote:


On 4/8/2021 4:15 PM, Martin Sebor via Gcc-patches wrote:

The C front end ordinarily merges function type attributes upon
the redeclaration of a function but it doesn't do that for those
at local scope, unless the declaration refers to a built-in.

Because the new -Warray-parameter warning relies on the internal
access attribute on the type of the function added by the C front
end for parameters declared using the array notation, it triggers
when it sees a redeclaration of a function in a local scope even
when both declarations use the same array form, issuing a false
positive.

The same problem affects other similar redeclarations involving
attributes, such as unused_result, causing false negatives there.
(Clang and ICC behave as I expect.)

The attached patch lets the front end propagate the type attributes
for all redeclarations, resolving this class of problems for all
affected attributes.

There's another similar piece of code in pushdecl() that I didn't
touch, although  I couldn't come up with a test case showing it's
necessary.  Both hunks go back ages so I wonder if they might have
been obviated by other improvements.


What I'd want to know is why the code didn't copy the attributes to the 
redeclarations.  Did the git history provide any hints? Does the hunk of 
code post-date creation of the public lists?  If so, was there any 
discussion in the public lists of the change that might give insights?


The conditional the patch removes was added by Joseph in r86636 to
fix PR c/13801.  The bug deals with extern declarations in nested
scopes.  This issue is about declarations in unrelated scopes.

The (very long) discussion of the changes is below but I couldn't
find anything relevant to the problem(s) my change tries to solve:
https://gcc.gnu.org/legacy-ml/gcc-patches/2004-08/msg00085.html

FWIW, with or without my patch, GCC still isn't entirely consistent
in how it handles attributes on extern redeclarations in different
scopes, either with itself or with other compilers.

Martin

[committed] libstdc++: Fix to work freestanding [PR 100060]

[Jonathan Wakely via Gcc-patches]

libstdc++-v3/ChangeLog:

PR libstdc++/100060
* include/std/bit: Only include  for
hosted build, use  otherwise.

Tested powerpc64le-linux. Committed to trunk.

This needs to be backported to gcc-10 too.


commit 474cb5a0a404c5de7c1cd21aac8b1b7e7ce95d9b
Author: Jonathan Wakely 
Date:   Tue Apr 13 16:55:37 2021

libstdc++: Fix  to work freestanding [PR 100060]

libstdc++-v3/ChangeLog:

PR libstdc++/100060
* include/std/bit: Only include  for
hosted build, use  otherwise.

diff --git a/libstdc++-v3/include/std/bit b/libstdc++-v3/include/std/bit
index fb78578448c..c5aae8bab03 100644
--- a/libstdc++-v3/include/std/bit
+++ b/libstdc++-v3/include/std/bit
@@ -34,7 +34,23 @@
 #if __cplusplus >= 201402L
 
 #include 
-#include 
+
+#if _GLIBCXX_HOSTED
+# include 
+#else
+# include 
+/// @cond undocumented
+namespace __gnu_cxx
+{
+  template
+struct __int_traits
+{
+  static constexpr int __digits = std::numeric_limits<_Tp>::digits;
+  static constexpr _Tp __max = std::numeric_limits<_Tp>::max();
+};
+}
+/// @endcond
+#endif
 
 namespace std _GLIBCXX_VISIBILITY(default)
 {

Re: fix a couple of typos (PR 99883)

[Jeff Law via Gcc-patches]

On 4/7/2021 5:46 PM, Martin Sebor via Gcc-patches wrote:

The attached patch fixes a couple of typos.  Not sure they qualify
as regressions but it seems like a trivial fix worth making even
now.  I'll go ahead and commit it as obvious if no-one objects.


Yea, this kind of diagnostic message fix is fine now.


Jeff

Re: [PATCH] propagate attributes to local redeclaration (PR 99420)

[Jeff Law via Gcc-patches]

On 4/8/2021 4:15 PM, Martin Sebor via Gcc-patches wrote:

The C front end ordinarily merges function type attributes upon
the redeclaration of a function but it doesn't do that for those
at local scope, unless the declaration refers to a built-in.

Because the new -Warray-parameter warning relies on the internal
access attribute on the type of the function added by the C front
end for parameters declared using the array notation, it triggers
when it sees a redeclaration of a function in a local scope even
when both declarations use the same array form, issuing a false
positive.

The same problem affects other similar redeclarations involving
attributes, such as unused_result, causing false negatives there.
(Clang and ICC behave as I expect.)

The attached patch lets the front end propagate the type attributes
for all redeclarations, resolving this class of problems for all
affected attributes.

There's another similar piece of code in pushdecl() that I didn't
touch, although  I couldn't come up with a test case showing it's
necessary.  Both hunks go back ages so I wonder if they might have
been obviated by other improvements.


What I'd want to know is why the code didn't copy the attributes to the 
redeclarations.  Did the git history provide any hints? Does the hunk of 
code post-date creation of the public lists?  If so, was there any 
discussion in the public lists of the change that might give insights?


Jeff

Re: Patch ping for PR95176 fix

[Jeff Law via Gcc-patches]

On 4/12/2021 11:45 AM, Victor Tong via Gcc-patches wrote:

Hello,

I'd like to ping this patch. It contains two new tree-opt patterns in match.pd.

[PATCH] tree-optimization: Optimize division followed by multiply [PR95176] 
(gnu.org)


We're currently working towards the gcc-11 release, in particular we're 
only fixing regression bugs at this point.  So this patch will be 
re-considered once gcc-12 development opens, hopefully within the next 
few weeks.



jeff

Re: [GCC 12] [PATCH v2] Add inline_ignore_target function attribute

[Martin Sebor via Gcc-patches]

On 4/12/21 7:03 PM, H.J. Lu wrote:

On Mon, Apr 12, 2021 at 4:55 PM Martin Sebor  wrote:


On 4/12/21 3:53 PM, H.J. Lu via Gcc-patches wrote:

On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
 wrote:


On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
 wrote:


Add inline_ignore_target function attribute to inform the compiler that
target specific option mismatch on functions with the always_inline
attribute may be ignored.  On x86 targets, this attribute can be used on
integer functions to ignore target non-integer option mismatch.


I'm not sure I like such attribute but please adjust default_target_can_inline_p
accordingly (only few targets override this hook).

Richard.



Like this?

Thanks.


diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 1ddafb3ff2c..44588566f2d 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -3187,6 +3187,14 @@ int S::interface (int) __attribute__ ((ifunc
("_ZN1S8resolverEv")));
   Indirect functions cannot be weak.  Binutils version 2.20.1 or higher
   and GNU C Library version 2.11.1 are required to use this feature.

+@item inline_ignore_target
+@cindex @code{inline_ignore_target} function attribute
+The @code{inline_ignore_target} attribute on functions is used to
+inform the compiler that target specific option mismatch on functions
+with the @code{always_inline} attribute may be ignored.  On x86 targets,
+this attribute can be used on integer functions to ignore target
+non-integer option mismatch.
+
   @item interrupt
   @itemx interrupt_handler
   Many GCC back ends support attributes to indicate that a function is

I'm having a hard time understanding the description above (or
the attribute's name for that matter).


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

has a testcase.


Thanks.  My overall point is that GCC users should be able to answer
these questions from reading the documentation of the attribute in
the manual.




The inline_ignore_target function attribute informs the compiler
that "target specific option mismatch on functions with the
@code{always_inline} attribute" may be ignored.

What does "target specific option mismatch" mean?  Is it a mismatch


This refers to the message from GCC:

/usr/gcc-11.0.0-x32/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include/ia32intrin.h:112:1:
error: inlining failed in call to ‘always_inline’ ‘__rdtsc’: target
specific option mismatch
   112 | __rdtsc (void)
   | ^~~


But what exactly does the target-specific option refer to, and what
does it fail to match?  Presumably, it refers to the option in
the attribute on the function declaration in the PR:

 __attribute__ ((target("general-regs-only")))

and the inability to use the rdtsc instruction with a GPR.

But unless the error either mentions the -mgeneral-regs-only option
by name or is followed by a note that points to the option in
the function declaration, the words "target specific option" alone
aren't enough to understand what the error means, and the text in
the manual doesn't help.

I would suggest to improve the message and the manual.




between target-specific optimization options added to a function by
attribute optimize vs other target-specific optimization options of
the function callers (e.g., added to them by another instance of
attribue optimize, or by #pragma GCC optimize), into which a function
with the attribute may be inlined, and where the conflict between
the two sets of options needs to be reconciled?  And if so, should


It is added to support integer functions with always_inline attribute.
Currently x86 integer functions with always_inline attribute fail to
compile when caller has general-regs-only target attribute and
SSE is enabled by default.


Thanks.  I would suggest to also explain this in the manual.




it be provided as a generic attribute for all targets?


I'm still wondering if this should be a generic attribute.  Besides
x86, I see -mgeneral-regs-only also provided by ARM and Aarch64, so
I would expect the attribute to be useful to those targets as well,
and to all other targets that add the option or one like it in
the future.  I believe it's better for portability to add a generic
attribute even if it's not universally supported, than a target-
specific one.



Different targets can have different sets of conflict target specific
options.


Also, what's "integer functions" supposed to mean?  Functions that
return integers?


An integer function can be compiled with -mgeneral-regs-only.


I don't think that answers my question.  It sounds like a property
of something you call an /integer function/.  My question is: what
is [the definition of] an integer function?  In other words, how can
one tell whether or not an arbitrary function is an integer function?

The manual should either define the term /integer function/ or it
should describe what it means so that readers won't have to ask this
question.  If the definition is "an integer function is one that can
be compiled without error

Re: libstdc++-v3/doc/xml/manual/backwards_compatibility.xml

[Jonathan Wakely via Gcc-patches]

On 13/04/21 16:37 +0100, Jonathan Wakely wrote:

On 13/04/21 16:19 +0100, Jonathan Wakely via Libstdc++ wrote:

Sorry for the slow reply ...

On Mon, 1 Feb 2021 at 22:59, Gerald Pfeifer wrote:


I noticed this section on "Backwards Compatibility" in the libstdc++
docs that talks about

- glibc 2.0.x
- GCC 3.2 (August 2002)
- GCC 4.1 (February 2006)

and links to "Migrating to GCC 4.1" and "Migration guide for GCC-3.2"
documents.

Does this still make sense (and serve real users or developers) or
should this be trimmed quite a bit?


Yeah, that (and a lot more) should be trimmed from the libstdc++
manual. It's just time consuming to do it.


It turned out to be pretty easy in this case, as the ancient text was
so obviously useless now that it can just be ripped out.

The remaining parts of the page should probably be evaluated too, but
at least the truly prehistoric stuff is gone with this patch.

Pushed to trunk.


Oops, I meant to change gcc@ to gcc-patches@ before sending, sorry for
the noise on the main list.



commit 989e512f719a44fafca0030d7b8a1f5bf5f1baf7
Author: Jonathan Wakely 
Date:   Tue Apr 13 16:30:16 2021

   libstdc++: Remove outdated docs on libg++ and libstdc++-v2
   
   The libstdc++-v3 manual doesn't need to document how to use its

   predecessors.
   
   libstdc++-v3/ChangeLog:
   
   * doc/xml/manual/backwards_compatibility.xml: Remove porting

   notes for libg++ and libstdc++-v2, and bibliography.
   * doc/html/*: Regenerated.

diff --git a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml 
b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
index cce553380e1..6a4a5ccedfb 100644
--- a/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
+++ b/libstdc++-v3/doc/xml/manual/backwards_compatibility.xml
@@ -22,7 +22,7 @@ dinosaur.

Some background: libg++ was designed and created when there was no
ISO standard to provide guidance.  Classes like linked lists are now
-provided for by list and do not need to be
+provided for by std::list and do not need to be
created by genclass.  (For that matter, templates exist
now and are well-supported, whereas genclass (mostly) predates them.)

@@ -34,41 +34,13 @@ Committee couldn't include everything, and so a lot of those
obvious classes didn't get included.


-Known Issues include many of the limitations of its immediate 
ancestor.
-
-Portability notes and known implementation limitations are as 
follows.
-
-No 
ios_base
-
-
- At least some older implementations don't have std::ios_base, so you should use 
std::ios::badbit, std::ios::failbit and std::ios::eofbit and 
std::ios::goodbit.
+That project is no longer maintained or supported, and the sources
+archived. For the desperate, the
+http://www.w3.org/1999/xlink"; 
xlink:href="https://ftp.gnu.org/old-gnu/libg++/";>ftp.gnu.org
+server still has the libg++ source.



-No cout in , no cin in 
-
-
-
-   In earlier versions of the standard,
-   ,
-   
-   and 
-   used to define
-   cout, cin and so on. ISO C++ specifies that 
one needs to include
-   
-   explicitly to get the required definitions.
- 
- Some include adjustment may be required.
-
-This project is no longer maintained or supported, and the sources
-archived. For the desperate,
-the http://www.w3.org/1999/xlink"; 
xlink:href="http://gcc.gnu.org/extensions.html";>GCC extensions
-page describes where to find the last libg++ source. The code is
-considered replaced and rewritten.
-
-
-
-
Second


@@ -80,504 +52,14 @@ considered replaced and rewritten.



-  The STL portions of this library are based on SGI/HP STL release 3.11.
+  The STL portions of that library are based on SGI/HP STL release 3.11.



-  This project is no longer maintained or supported, and the sources
-  archived.  The code is considered replaced and rewritten.
+  That project is no longer maintained or supported, and the sources
+  archived.  The code was replaced and rewritten for libstdc++-v3.


-
-  Portability notes and known implementation limitations are as follows.
-
-
-Namespace std:: not 
supported
-
-
-  
-Some care is required to support C++ compiler and or library
-implementation that do not have the standard library in
-namespace std.
-  
-
-  
-The following sections list some possible solutions to support compilers
-that cannot ignore std::-qualified names.
-  
-
-  
-First, see if the compiler has a flag for this. Namespace
-back-portability-issues are generally not a problem for g++
-compilers that do not have libstdc++ in std::, as the
-compilers use -fno-honor-std (ignore
-std::, :: = std::) by default. That is,
-the responsibility for enabling or disabling std:: is
-on the user; the maintainer does not have to care about it. This
-probably applies to some other compilers as well.
-  
-
-  
-Second, experiment with a variety of pre-processor tricks.
-  
-

Re: [PATCH] analyzer: enabling Modula-2 Storage/ALLOCATE/DEALLOCATE

[David Malcolm via Gcc-patches]

On Tue, 2021-04-13 at 10:52 +0100, Gaius Mulley wrote:
> 
> 
> Hello David and fellow GCC developers,
> 
> [the proposed patches for GCC trunk are at the end of the email]
> 
> I've been having way too much fun with your -fanalyzer code and
> here are four patches which give the analyzer the ability to
> understand the Modula-2 Storage API.
> 
>   http://www.nongnu.org/gm2/gm2-libs-isostorage.html
>   http://www.nongnu.org/gm2/gm2-libsstorage.html
>   http://www.nongnu.org/gm2/gm2-libssysstorage.html
> 
> Here it is in action - these short tests have all been added to the
> gm2 regression testsuite.  Many are from your C examples - rewritten
> in Modula-2.  Ignoring a few poor token position subexpressions from
> the front end, which I'm currently improving, it appears to work!

Excellent!  I'm glad you're enjoying it.

Caveat: The last time I did any Modula-2 coding was a MUD I wrote at
school, which I realize to my horror is now over 30 years ago; I wonder
if the disks are still readable :)

Various comments inline below throughout...

> I've rebuilt GCC trunk 10/04/2021 with these patches and no new
> regressions are introduced.  I ran a build of: c,c++,go,d,fortran,lto
> and checked the before and after regression tests.  The new code is by
> default disabled - hence the langhook patches.
> 
> While it is true that this is the cart before the horse (the gm2 front
> end is still to arrive in the gcc tree).  I thought it might be useful
> to post the patches - just in case others might benefit from the code
> or point out bugs/flaws in the code!
> 
> Anyway thanks for the analyzer - it is great fun reading the code and
> addictive trying to improve the accuracy of the error messages.  The
> four patches follow after the examples below.
> 
> Examples of it in use:
> 
> $ cat badlistfree.mod
> MODULE badlistfree ;
> 
> FROM Storage IMPORT ALLOCATE, DEALLOCATE ;
> 
> TYPE
>    list = POINTER TO RECORD
>     value: CARDINAL ;
>     next : list ;
>  END ;
> VAR
>    head: list ;
> 
> PROCEDURE badfree (l: list) ;
> BEGIN
>    DISPOSE (l) ;
>    WHILE l^.next # NIL DO
>   l := l^.next ;
>   DISPOSE (l)
>    END
> END badfree ;
> 
> 
> BEGIN
>    NEW (head) ;
>    badfree (head) ;
> END badlistfree.
> $ gm2 -g -c -fanalyzer badlistfree.mod
> badlistfree.mod: In function ‘badfree’:
> badlistfree.mod:16:24: warning: use after ‘DISPOSE’ of ‘l’ [CWE-416] [-
> Wanalyzer-use-after-free]
>    16 |    WHILE l^.next # NIL DO
>   |    ^~
>   ‘badfree’: events 1-2
>     |
>     |   15 |    DISPOSE (l) ;
>     |  |    ^~
>     |  |    |
>     |  |    (1) deallocated here
>     |   16 |    WHILE l^.next # NIL DO
>     |  |    ~~
>     |  |    |
>     |  |    (2) use after ‘DISPOSE’ of ‘l’;
> deallocated at (1)
>     |

Excellent.

Do you actually need the NEW(head); to trigger the warning?

Given:

BEGIN
  NEW (head) ;

  (* "head" is now explicitly in state "unchecked" *)

  badfree (head) ;
END badlistfree.

whereas, assuming that "head" is being passed in, say, as a param:

BEGIN

  (* "head" is implicitly in state "start" *)

  badfree (head) ;  
END badlistfree.

so if you're thinking about unit test coverage, it may be an idea to
have both cases.

Your patch doesn't seem to have any test cases, but presumably that
would be part of the gm2 frontend and thus would be merged with that,
rather than as this patch.  I went poking around in your repo, and see:
http://git.savannah.gnu.org/cgit/gm2.git/commit/?id=bd9e38fcebf5c063370bec9a69331037005b15de

I don't see any DejaGnu directives on the files; should there be
something like

  (* dg-warning "use after 'DISPOSE' of 'l'" */

on the pertinent line, or do your tests work a different way?



> $ cat disposenoalloc.mod
> MODULE disposenoalloc ;
> 
> FROM Storage IMPORT ALLOCATE, DEALLOCATE ;
> FROM SYSTEM IMPORT ADR ;
> 
> TYPE
>    list = POINTER TO RECORD
>     value: CARDINAL ;
>     next : list ;
>  END ;
> VAR
>    head: list ;
> 
> BEGIN
>    head := ADR (head) ;
>    DISPOSE (head)
> END disposenoalloc.
> $ gm2 -g -c -fanalyzer disposenoalloc.mod
> disposenoalloc.mod: In function ‘_M2_disposenoalloc_init’:
> disposenoalloc.mod:16:4: warning: ‘DISPOSE’ of ‘head’ which points to
> memory not on the heap [CWE-590] [-Wanalyzer-free-of-non-heap]
>    16 |    DISPOSE (head)
>   |    ^
>   ‘_M2_disposenoalloc_init’: events 1-3
>     |
>     |   15 |    head := ADR (head) ;
>     |  |   ^
>     |  |   |
>     |  |   (1) pointer is from here
>     |   16 |    DISPOSE (head)
>     |  |    ~   
>     |  |    |    |
>     |  |    |    (2) pointer is from here
>     |  |    (3) call to ‘DISPOSE’ here
>     |

I had

Re: [ping] Fix thinko in libcpp preparation patch for modules

[Eric Botcazou]

> OK

Thanks.  And it turns out that the limit on the size of accepted Ada files had 
been already lowered earlier, namely when location ranges had been introduced.  
Now we do not make use of location ranges in Ada, so we can recoup the loss.

Tested on x86-64/Linux, applied on the mainline, 10 and 9 branches.


2021-04-13  Eric Botcazou  

* gcc-interface/misc.c (gnat_init): Set default range bits to 0.
* gcc-interface/trans.c (extract_encoding): Delete.
(decode_name): Likewise.
(File_Name_to_gnu): New function.
(gigi): Call it to translate file names.  Replace assertion on
1-1 mapping between files and line maps with conditional error.

-- 
Eric Botcazoudiff --git a/gcc/ada/gcc-interface/misc.c b/gcc/ada/gcc-interface/misc.c
index d0867e00c85..16bccb917ee 100644
--- a/gcc/ada/gcc-interface/misc.c
+++ b/gcc/ada/gcc-interface/misc.c
@@ -370,6 +370,9 @@ gnat_init (void)
   sbitsize_one_node = sbitsize_int (1);
   sbitsize_unit_node = sbitsize_int (BITS_PER_UNIT);
 
+  /* In Ada, we do not use location ranges.  */
+  line_table->default_range_bits = 0;
+
   /* Register our internal error function.  */
   global_dc->internal_error = &internal_error_function;
 
diff --git a/gcc/ada/gcc-interface/trans.c b/gcc/ada/gcc-interface/trans.c
index ae7a52f3ca2..5a55ca4f29e 100644
--- a/gcc/ada/gcc-interface/trans.c
+++ b/gcc/ada/gcc-interface/trans.c
@@ -251,17 +251,27 @@ static tree build_raise_check (int, enum exception_info_kind);
 static tree create_init_temporary (const char *, tree, tree *, Node_Id);
 static bool maybe_make_gnu_thunk (Entity_Id gnat_thunk, tree gnu_thunk);
 
-/* Hooks for debug info back-ends, only supported and used in a restricted set
-   of configurations.  */
-static const char *extract_encoding (const char *) ATTRIBUTE_UNUSED;
-static const char *decode_name (const char *) ATTRIBUTE_UNUSED;
-
 /* This makes gigi's file_info_ptr visible in this translation unit,
so that Sloc_to_locus can look it up when deciding whether to map
decls to instances.  */
 
 static struct File_Info_Type *file_map;
 
+/* Return the string of the identifier allocated for the file name Id.  */
+
+static const char*
+File_Name_to_gnu (Name_Id Id)
+{
+  /* __gnat_to_canonical_file_spec translates file names from pragmas
+ Source_Reference that contain host style syntax not understood by GDB.  */
+  const char *name = __gnat_to_canonical_file_spec (Get_Name_String (Id));
+
+  /* Use the identifier table to make a permanent copy of the file name as
+ the name table gets reallocated after Gigi returns but before all the
+ debugging information is output.  */
+  return IDENTIFIER_POINTER (get_identifier (name));
+}
+
 /* This is the main program of the back-end.  It sets up all the table
structures and then generates code.  */
 
@@ -315,23 +325,18 @@ gigi (Node_Id gnat_root,
 
   for (i = 0; i < number_file; i++)
 {
-  /* Use the identifier table to make a permanent copy of the filename as
-	 the name table gets reallocated after Gigi returns but before all the
-	 debugging information is output.  The __gnat_to_canonical_file_spec
-	 call translates filenames from pragmas Source_Reference that contain
-	 host style syntax not understood by gdb.  */
-  const char *filename
-	= IDENTIFIER_POINTER
-	   (get_identifier
-	(__gnat_to_canonical_file_spec
-	 (Get_Name_String (file_info_ptr[i].File_Name;
-
   /* We rely on the order isomorphism between files and line maps.  */
-  gcc_assert ((int) LINEMAPS_ORDINARY_USED (line_table) == i);
+  if ((int) LINEMAPS_ORDINARY_USED (line_table) != i)
+	{
+	  gcc_assert (i > 0);
+	  error ("%s contains too many lines",
+		 File_Name_to_gnu (file_info_ptr[i - 1].File_Name));
+	}
 
   /* We create the line map for a source file at once, with a fixed number
 	 of columns chosen to avoid jumping over the next power of 2.  */
-  linemap_add (line_table, LC_ENTER, 0, filename, 1);
+  linemap_add (line_table, LC_ENTER, 0,
+		   File_Name_to_gnu (file_info_ptr[i].File_Name), 1);
   linemap_line_start (line_table, file_info_ptr[i].Num_Source_Lines, 252);
   linemap_position_for_column (line_table, 252 - 1);
   linemap_add (line_table, LC_LEAVE, 0, NULL, 0);
@@ -10401,27 +10406,6 @@ set_end_locus_from_node (tree gnu_node, Node_Id gnat_node)
 }
 }
 
-/* Return a colon-separated list of encodings contained in encoded Ada
-   name.  */
-
-static const char *
-extract_encoding (const char *name)
-{
-  char *encoding = (char *) ggc_alloc_atomic (strlen (name));
-  get_encoding (name, encoding);
-  return encoding;
-}
-
-/* Extract the Ada name from an encoded name.  */
-
-static const char *
-decode_name (const char *name)
-{
-  char *decoded = (char *) ggc_alloc_atomic (strlen (name) * 2 + 60);
-  __gnat_decode (name, decoded, 0);
-  return decoded;
-}
-
 /* Post an error message.  MSG is the error message, properly annotated.
NODE is the node at which to post the

Re: [GCC][Patch] arm: Fix the mve multilib for the broken cmse support (pr99939).

[Richard Earnshaw via Gcc-patches]

On 12/04/2021 14:04, Srinath Parvathaneni via Gcc-patches wrote:

Hi,

The current CMSE support in the multilib build for "-march=armv8.1-m.main+mve 
-mfloat-abi=hard -mfpu=auto"
is broken as specified in PR99939 and this patch fixes the issue.

Regression tested on arm-none-eabi and found no regressions.

Ok for master? and Ok for GCC-10 branch?

Regards,
Srinath.

gcc/testsuite/ChangeLog:

2021-04-12  Srinath Parvathaneni  

PR target/99939
* gcc.target/arm/cmse/cmse-20.c: New test.

libgcc/ChangeLog:

2021-04-12  Srinath Parvathaneni  

PR target/99939
* config/arm/t-arm: Make changes to use cmse.c for all the
armv8.1-m.main mulitlibs.



### Attachment also inlined for ease of reply###


diff --git a/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c 
b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
new file mode 100644
index 
..7e2739e14792624adf5b4280ca58a5d8320acbf0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/cmse/cmse-20.c
@@ -0,0 +1,28 @@
+/* { dg-do run } */
+/* { dg-additional-options "-mcmse 
-Wl,--section-start,.gnu.sgstubs=0x0019" } */
+
+#include 
+#include 
+#include 
+
+void __attribute__((cmse_nonsecure_entry))
+secure_fun (int a, int *p)
+{
+  void *b = cmse_check_address_range ((void *)p, a, 1);
+
+  if (b == NULL)
+   __builtin_abort ();
+  printf("%d", *((int *)b));
+}
+
+int
+main (void)
+{
+  int *ptr;
+  int size = 1;
+  ptr = (int *) calloc (1, sizeof(int *));
+  *ptr = 1315852292;
+  secure_fun (size, ptr);
+  free (ptr);
+  return 0;
+}
diff --git a/libgcc/config/arm/t-arm b/libgcc/config/arm/t-arm
index 
3625a2590beec4e4e0e0881be9ad284c595c7190..949e2ee06653680211ff2dcf0b55a41a6aedc31c
 100644
--- a/libgcc/config/arm/t-arm
+++ b/libgcc/config/arm/t-arm
@@ -9,11 +9,12 @@ CMSE_OPTS:=-mcmse
  endif
  
  ifdef HAVE_CMSE

-ifndef HAVE_V81M
-libgcc-objects += cmse.o cmse_nonsecure_call.o
+libgcc-objects += cmse.o
  
  cmse.o: $(srcdir)/config/arm/cmse.c

$(gcc_compile) -c $(CMSE_OPTS) $<
+ifndef HAVE_V81M
+libgcc-objects += cmse_nonsecure_call.o
  cmse_nonsecure_call.o: $(srcdir)/config/arm/cmse_nonsecure_call.S
   $(gcc_compile) -c $<
  endif



So if I have two object files using CMSE and one is built with v8m, but 
the other with v8.1m, when I link them, the needed additional support 
for the v8m object file will be missing the library support.


Wouldn't it be better to just build the cmse_nonsecure_call code 
unconditionally?  It won't be called if it's not needed, but will be 
there if something does require it.


R.

[PATCH] aarch64: Avoid duplicating bti j insns for jump tables [PR99988]

[Alex Coplan via Gcc-patches]

Hi all,

This patch fixes PR99988 which shows us generating large (> 250)
sequences of back-to-back bti j instructions.

The fix is simply to avoid inserting bti j instructions at the target of
a jump table if we've already inserted one for a given label.

Testing:
 * Bootstrapped and regtested on aarch64-linux-gnu (with and without
 -mbranch-protection=standard), no regressions.

Presumably this is stage 1 material since the bug isn't a regression? If
so, OK for GCC 12 stage 1?

Thanks,
Alex

gcc/ChangeLog:

PR target/99988
* config/aarch64/aarch64-bti-insert.c (aarch64_bti_j_insn_p): New.
(rest_of_insert_bti): Avoid inserting duplicate bti j insns for
jump table targets.

gcc/testsuite/ChangeLog:

PR target/99988
* gcc.target/aarch64/pr99988.c: New test.
diff --git a/gcc/config/aarch64/aarch64-bti-insert.c 
b/gcc/config/aarch64/aarch64-bti-insert.c
index 936649769c7..943fa3c1097 100644
--- a/gcc/config/aarch64/aarch64-bti-insert.c
+++ b/gcc/config/aarch64/aarch64-bti-insert.c
@@ -120,6 +120,13 @@ aarch64_pac_insn_p (rtx x)
   return false;
 }
 
+static bool
+aarch64_bti_j_insn_p (rtx_insn *insn)
+{
+  rtx pat = PATTERN (insn);
+  return GET_CODE (pat) == UNSPEC_VOLATILE && XINT (pat, 1) == UNSPECV_BTI_J;
+}
+
 /* Insert the BTI instruction.  */
 /* This is implemented as a late RTL pass that runs before branch
shortening and does the following.  */
@@ -165,6 +172,9 @@ rest_of_insert_bti (void)
  for (j = GET_NUM_ELEM (vec) - 1; j >= 0; --j)
{
  label = as_a  (XEXP (RTVEC_ELT (vec, j), 0));
+ if (aarch64_bti_j_insn_p (next_nonnote_insn (label)))
+   continue;
+
  bti_insn = gen_bti_j ();
  emit_insn_after (bti_insn, label);
}
diff --git a/gcc/testsuite/gcc.target/aarch64/pr99988.c 
b/gcc/testsuite/gcc.target/aarch64/pr99988.c
new file mode 100644
index 000..2d87f41a717
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr99988.c
@@ -0,0 +1,66 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mbranch-protection=standard" } */
+/* { dg-final { scan-assembler-times {bti j} 13 } } */
+int a;
+int c();
+int d();
+int e();
+int f();
+int g();
+void h() {
+  switch (a) {
+  case 0:
+  case 56:
+  case 57:
+break;
+  case 58:
+  case 59:
+  case 61:
+  case 62:
+c();
+  case 64:
+  case 63:
+d();
+  case 66:
+  case 65:
+d();
+  case 68:
+  case 67:
+d();
+  case 69:
+  case 70:
+d();
+  case 71:
+  case 72:
+  case 88:
+  case 87:
+d();
+  case 90:
+  case 89:
+d();
+  case 92:
+  case 1:
+d();
+  case 93:
+  case 73:
+  case 4:
+e();
+  case 76:
+  case 5:
+f();
+  case 7:
+  case 8:
+  case 84:
+  case 85:
+break;
+  case 6:
+  case 299:
+  case 9:
+  case 80:
+  case 2:
+  case 3:
+e();
+  default:
+g();
+  }
+}

[wwwdocs] Add znver3 support to changes.html

[Martin Jambor]

Hi,

Martin Liška correctly observed that the newly added support for AMD
zenver3 in GCC 11 and 10.3 is not reflected in the changes.html files.

Would the following be OK?

Thanks,

Martin


diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index d5166879..d9971ffb 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -1144,6 +1144,12 @@ are not listed here).
   makes the code specific to 512-bit SVE.
 
 
+x86-64
+
+  GCC 10.3 supports AMD CPUs based on znver3 core
+  through -march=znver3.
+  
+
 
 
 
diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index a7fa4e1b..97a622f4 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -634,6 +634,9 @@ a work-in-progress.
 The switch enables the CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, KEYLOCKER,
 AVX-VNNI, and HRESET ISA extensions.
   
+  GCC now supports AMD CPUs based on znver3 core
+  through -march=znver3.
+  
 
 
 

Re: [PATCH] c++: Reject alias CTAD in C++17 [PR99008]

[Jason Merrill via Gcc-patches]

On 4/12/21 6:24 PM, Patrick Palka wrote:

On Mon, 12 Apr 2021, Jason Merrill wrote:


On 4/10/21 3:57 PM, Patrick Palka wrote:

Here, in C++17 mode, we only pedwarn about the use of alias CTAD and
then later ICE from alias_ctad_tweaks when attempting to add a
constraint to one of the guides.  Since the construction of the guides
of an alias template effectively relies on concepts, we shouldn't be
permissive about alias CTAD in C++17 mode, so this patch turns the
pertinent pedwarn in do_class_deduction into an error.


Sounds good.


In order to get a consistent diagnostic for B() vs the other forms in
the added testcase, I had to remove the special handling of CTAD with
empty initializer in build_functional_cast_1 so that we always pass
'complain' to do_auto_deduction.


Did you compare the resulting diagnostics when deduction fails other than for
trying to do alias deduction in C++17 mode?


For plain CTAD, e.g. for

   template  struct A { };
   auto a = A();

we previously emitted

test.C:2:10: error: cannot deduce template arguments for ‘A<...auto...>’ from 
‘()’
 2 | auto a = A();
   |  ^~~

and now we emit

test.C:2:12: error: class template argument deduction failed:
 2 | auto a = A();
   |^
test.C:2:12: error: no matching function for call to ‘A()’
test.C:1:27: note: candidate: ‘template A()-> A’
 1 | template  struct A { };
   |   ^
test.C:1:27: note:   template argument deduction/substitution failed:
test.C:2:12: note:   couldn’t deduce template parameter ‘T’
 2 | auto a = A();
   |^
test.C:1:27: note: candidate: ‘template A(A)-> A’
 1 | template  struct A { };
   |   ^
test.C:1:27: note:   template argument deduction/substitution failed:
test.C:2:12: note:   candidate expects 1 argument, 0 provided
 2 | auto a = A();
   |^

which is consistent with what we already emit for failed CTAD of the
form A{}, A(args) and A{args}.


Thanks, that's fine.  The patch is OK.


I think this change should have no diagnostic/functional impact in other
deduction situations because the code path is guarded by a
CLASS_PLACEHOLDER_TEMPLATE check (and we create template placeholders
only in C++17 mode).


Jason

[PATCH] tree-optimization/100051 - disambiguate access size vs decl

[Richard Biener]

This adds disambiguation of the access size vs. the decl size
in the pointer based vs. decl based disambiguator.  We have
a TBAA based check like this already but that's fend off when
seeing alias-sets of zero or when -fno-strict-aliasing is in
effect.  Also the perceived dynamic type could be smaller than
the actual access.

Bootstrapped and tested on x86_64-unknown-linux-gnu, queued for stage1.

2021-04-13  Richard Biener  

PR tree-optimization/100051
* tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Add
disambiguator based on access size vs. decl size.

* gcc.dg/tree-ssa/ssa-fre-92.c: New testcase.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-92.c | 21 +
 gcc/tree-ssa-alias.c   | 11 +++
 2 files changed, 32 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-92.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-92.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-92.c
new file mode 100644
index 000..c67fcea5e93
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-92.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-fre1" } */
+
+extern void foo(void);
+int a, c, *f, **d = &f;
+char b;
+int main()
+{
+  if (a) {
+b = 0;
+int *g = &c;
+*g = 0;
+f = *d;
+*d = f;
+if ((2 ^ b) == 0)
+  foo();
+  }
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump-not "foo" "fre1" } } */
diff --git a/gcc/tree-ssa-alias.c b/gcc/tree-ssa-alias.c
index ebb3f49c86c..6c7d2f1b7e0 100644
--- a/gcc/tree-ssa-alias.c
+++ b/gcc/tree-ssa-alias.c
@@ -2034,6 +2034,17 @@ indirect_ref_may_alias_decl_p (tree ref1 
ATTRIBUTE_UNUSED, tree base1,
   if (TREE_CODE (base1) != TARGET_MEM_REF
   && !ranges_maybe_overlap_p (offset1 + moff, -1, offset2, max_size2))
 return false;
+
+  /* If the pointer based access is bigger than the variable they cannot
+ alias.  This is similar to the check below where we use TBAA to
+ increase the size of the pointer based access based on the dynamic
+ type of a containing object we can infer from it.  */
+  poly_int64 dsize2;
+  if (known_size_p (size1)
+  && poly_int_tree_p (DECL_SIZE (base2), &dsize2)
+  && known_lt (dsize2, size1))
+return false;
+
   /* They also cannot alias if the pointer may not point to the decl.  */
   if (!ptr_deref_may_alias_decl_p (ptr1, base2))
 return false;
-- 
2.26.2

[PATCH] tree-optimization/100053 - fix predication in VN

[Richard Biener]

This avoids doing optimistic dominance queries involving
non-executable backedges when validating recorded predicated values
in VN because we have no way to force re-evaluating validity when
optimistically not executable edges become executable later.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed to trunk.

2021-04-13  Richard Biener  

PR tree-optimization/100053
* tree-ssa-sccvn.c (vn_nary_op_get_predicated_value): Do
not use optimistic dominance queries for backedges to validate
predicated values.
(dominated_by_p_w_unex): Add parameter to ignore executable
state on backedges.
(rpo_elim::eliminate_avail): Adjust.

* gcc.dg/torture/pr100053.c: New testcase.
* gcc.dg/tree-ssa/ssa-fre-93.c: Likewise.
---
 gcc/testsuite/gcc.dg/torture/pr100053.c| 25 ++
 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-93.c | 21 ++
 gcc/tree-ssa-sccvn.c   | 21 +++---
 3 files changed, 59 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/torture/pr100053.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-93.c

diff --git a/gcc/testsuite/gcc.dg/torture/pr100053.c 
b/gcc/testsuite/gcc.dg/torture/pr100053.c
new file mode 100644
index 000..3d1767513f3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/torture/pr100053.c
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+
+int __attribute__((returns_twice,noipa)) x() { return 0; }
+void __attribute__((noipa)) ar() {}
+void __attribute__((noipa)) as() { __builtin_abort (); }
+int a1, a2, a3;
+void __attribute__((noipa)) v(int init)
+{
+  if (!init) {
+as();
+if (a1)
+  goto aq;
+x ();
+  }
+  ar();
+aq:
+  if (!init)
+as();
+}
+
+int main()
+{
+  v(1);
+  return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-93.c 
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-93.c
new file mode 100644
index 000..7f66b7ee3f4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-fre-93.c
@@ -0,0 +1,21 @@
+/* { dg-do compile } */
+/* { dg-options "-O -fdump-tree-fre1" } */
+
+void bar ();
+void foo (int pred, int *other)
+{
+  *other = 0;
+  if (*other)
+goto cnt;
+  if (pred)
+{
+  *other = 1;
+cnt:
+  if (!pred)
+bar ();
+}
+}
+
+/* The first VN pass should figure that if (!pred) is false because
+   if (*other) is and thus the predicate test is redundant.  */
+/* { dg-final { scan-tree-dump-not "bar" "fre1" } } */
diff --git a/gcc/tree-ssa-sccvn.c b/gcc/tree-ssa-sccvn.c
index 16e75b518b0..ca0974d72b8 100644
--- a/gcc/tree-ssa-sccvn.c
+++ b/gcc/tree-ssa-sccvn.c
@@ -4171,7 +4171,7 @@ vn_nary_op_insert_pieces_predicated (unsigned int length, 
enum tree_code code,
 }
 
 static bool
-dominated_by_p_w_unex (basic_block bb1, basic_block bb2);
+dominated_by_p_w_unex (basic_block bb1, basic_block bb2, bool);
 
 static tree
 vn_nary_op_get_predicated_value (vn_nary_op_t vno, basic_block bb)
@@ -4180,9 +4180,12 @@ vn_nary_op_get_predicated_value (vn_nary_op_t vno, 
basic_block bb)
 return vno->u.result;
   for (vn_pval *val = vno->u.values; val; val = val->next)
 for (unsigned i = 0; i < val->n; ++i)
-  if (dominated_by_p_w_unex (bb,
- BASIC_BLOCK_FOR_FN
-   (cfun, val->valid_dominated_by_p[i])))
+  /* Do not handle backedge executability optimistically since
+when figuring out whether to iterate we do not consider
+changed predication.  */
+  if (dominated_by_p_w_unex
+   (bb, BASIC_BLOCK_FOR_FN (cfun, val->valid_dominated_by_p[i]),
+false))
return val->result;
   return NULL_TREE;
 }
@@ -4482,10 +4485,11 @@ vn_phi_insert (gimple *phi, tree result, bool 
backedges_varying_p)
 
 
 /* Return true if BB1 is dominated by BB2 taking into account edges
-   that are not executable.  */
+   that are not executable.  When ALLOW_BACK is false consider not
+   executable backedges as executable.  */
 
 static bool
-dominated_by_p_w_unex (basic_block bb1, basic_block bb2)
+dominated_by_p_w_unex (basic_block bb1, basic_block bb2, bool allow_back)
 {
   edge_iterator ei;
   edge e;
@@ -4502,7 +4506,8 @@ dominated_by_p_w_unex (basic_block bb1, basic_block bb2)
 {
   edge prede = NULL;
   FOR_EACH_EDGE (e, ei, bb1->preds)
-   if (e->flags & EDGE_EXECUTABLE)
+   if ((e->flags & EDGE_EXECUTABLE)
+   || (!allow_back && (e->flags & EDGE_DFS_BACK)))
  {
if (prede)
  {
@@ -6901,7 +6906,7 @@ rpo_elim::eliminate_avail (basic_block bb, tree op)
 may also be able to "pre-compute" (bits of) the next immediate
 (non-)dominator during the RPO walk when marking edges as
 executable.  */
- if (dominated_by_p_w_unex (bb, abb))
+ if (dominated_by_p_w_unex (bb, abb, true))
{
  tree leader = ssa_name (av->leader);
  /* Prevent eliminations that break loop-closed SSA.  

[pushed] c++: constexpr, inheritance, and local class [PR91933]

[Jason Merrill via Gcc-patches]

Here we complained about referring to nm3 from the local class member
function because referring to the base class subobject involved taking the
variable's address.  Let's shortcut this case to avoid that.

Tested x86_64-pc-linux-gnu, applying to trunk.

gcc/cp/ChangeLog:

PR c++/91933
* class.c (build_base_path): Shortcut simple non-pointer case.

gcc/testsuite/ChangeLog:

PR c++/91933
* g++.dg/cpp0x/constexpr-base7.C: New test.
---
 gcc/cp/class.c   | 13 ++---
 gcc/testsuite/g++.dg/cpp0x/constexpr-base7.C | 15 +++
 2 files changed, 25 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-base7.C

diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 4bffec4a707..90b343803a0 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -330,6 +330,15 @@ build_base_path (enum tree_code code,
   return error_mark_node;
 }
 
+  bool uneval = (cp_unevaluated_operand != 0
+|| processing_template_decl
+|| in_template_function ());
+
+  /* For a non-pointer simple base reference, express it as a COMPONENT_REF
+ without taking its address (and so causing lambda capture, 91933).  */
+  if (code == PLUS_EXPR && !v_binfo && !want_pointer && !has_empty && !uneval)
+return build_simple_base_path (expr, binfo);
+
   if (!want_pointer)
 {
   rvalue = !lvalue_p (expr);
@@ -357,9 +366,7 @@ build_base_path (enum tree_code code,
  template (even in instantiate_non_dependent_expr), we don't have vtables
  set up properly yet, and the value doesn't matter there either; we're
  just interested in the result of overload resolution.  */
-  if (cp_unevaluated_operand != 0
-  || processing_template_decl
-  || in_template_function ())
+  if (uneval)
 {
   expr = build_nop (ptr_target_type, expr);
   goto indout;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-base7.C 
b/gcc/testsuite/g++.dg/cpp0x/constexpr-base7.C
new file mode 100644
index 000..14e026ec202
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-base7.C
@@ -0,0 +1,15 @@
+// PR c++/91933
+// { dg-do compile { target c++11 } }
+
+struct NoMut1 { int a, b; };
+struct NoMut3 : NoMut1 {
+  constexpr NoMut3(int a, int b) : NoMut1{a, b} {}
+};
+void mutable_subobjects() {
+  constexpr NoMut3 nm3 = {1, 2};
+  struct A {
+void f() {
+  static_assert(nm3.a == 1, "");
+}
+  };
+}

base-commit: 89e95ad2e7679322b2f5ee9070ff2721d5ca1d6d
-- 
2.27.0

preprocessor: Fix column adjustment [PR 99446]

[Nathan Sidwell]

This ICE was because when adjusting a column offset we could advance 
into a linemap for a different file.  We only checked the next line map 
was not for a line further advanced in any file, forgetting that it 
could be for an earlier line in a different file.  The testcase needed 
adjusting as column 512 was unrepresentable, once that was taken into 
consideration.


PR preprocessor/99446
libcpp/
* line-map.c (line-map.c): Do not advance to linemaps for
different files.
gcc/testsuite/
* g++.dg/diagnostic/pr72803.C: Adjust expected column.

--
Nathan Sidwell
diff --git c/gcc/testsuite/g++.dg/diagnostic/pr72803.C w/gcc/testsuite/g++.dg/diagnostic/pr72803.C
index 0a9a390b9c3..ca522b74bad 100644
--- c/gcc/testsuite/g++.dg/diagnostic/pr72803.C
+++ w/gcc/testsuite/g++.dg/diagnostic/pr72803.C
@@ -5,5 +5,6 @@ class test {
 // The line directive appears to be necessary to trigger the ICE
 // { dg-error "style of line directive is a GCC extension" "" { target *-*-* } .-2 }
 
-/* Verify that we get the correct line and column for the diagnostic.  */
-// { dg-error "512: expected .;. after class definition" "" { target *-*-* } 3 }
+/* Verify that we get the best line and column for the diagnostic.
+   512 is not representable in the line-maps created for this test.  */
+// { dg-error "511: expected .;. after class definition" "" { target *-*-* } 3 }
diff --git c/libcpp/line-map.c w/libcpp/line-map.c
index 1bf0e8211f2..2f5e7d2 100644
--- c/libcpp/line-map.c
+++ w/libcpp/line-map.c
@@ -981,16 +981,15 @@ linemap_position_for_loc_and_offset (line_maps *set,
  (loc + offset) should be less than the first location encoded by
  the next line map of the set.  Otherwise, we try to encode the
  location in the next map.  */
-  while (map != LINEMAPS_LAST_ORDINARY_MAP (set)
-	 && (loc + (column_offset << map->m_range_bits)
-	 >= MAP_START_LOCATION (&map[1])))
-{
-  map = &map[1];
-  /* If the next map starts in a higher line, we cannot encode the
-	 location there.  */
-  if (line < ORDINARY_MAP_STARTING_LINE_NUMBER (map))
-	return loc;
-}
+  for (; map != LINEMAPS_LAST_ORDINARY_MAP (set)
+	 && (loc + (column << map->m_range_bits)
+	 >= MAP_START_LOCATION (map + 1)); map++)
+/* If the next map is a different file, or starts in a higher line, we
+   cannot encode the location there.  */
+if ((map + 1)->reason != LC_RENAME
+	|| line < ORDINARY_MAP_STARTING_LINE_NUMBER (map + 1)
+	|| 0 != strcmp (LINEMAP_FILE (map + 1), LINEMAP_FILE (map)))
+  return loc;
 
   column += column_offset;
 

Re: [PATCH] [GCC-9] backport -march=tigerlake to GCC9 [PR target/100009]

[Uros Bizjak via Gcc-patches]

On Tue, Apr 13, 2021 at 12:18 PM Hongtao Liu  wrote:
>
> Hi:
>   As described in PR, we introduced tigerlake string in driver-i386.c
> by r9-8652 w/o support -march/tune=tigerlake which causes an error
> when using -march/tune=native with GCC9 on tigerlake machine.
>   Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
>   Ok for GCC9?
>
> gcc/
> * common/config/i386/i386-common.c
> (processor_names): Add tigerlake.
> (processor_alias_table): Ditto.
> * config.gcc: Document -march=tigerlake.

Nope. Better.

(x86_64_archs): Ditto.

> * config/i386/driver-i386.c
> (host_detect_local_cpu): Detect tigerlake, add "has_avx" to
> classify processor.
> * config/i386/i386-c.c (ix86_target_macros_internal): Handle
> tigerlake.

Handle PROCESSOR_TIGERLAKE.

> * config/i386/i386.c (m_TIGERLAKE)  : Define.
> (m_CORE_AVX512): Ditto.

You don't define this macro, but you add m_TIGERLAKE to m_CORE_AVX512.
Please correct this confusion.

> (processor_cost_table): Add tigerlake.

Please correct the above. You added skylake_cost.

> (ix86_option_override_internal): Handle PTA_MOVDIRI, PTA_MOVDIR64B.

Where?

> (processor_model): Add M_INTEL_COREI7_TIGERLAKE.
> (arch_names_table): Add tigerlake.
> (get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE.
> * config/i386/i386.h (TARGET_TIGERLAKE): Define.
> (processor_type) : Add PROCESSOR_TIGERLAKE.

(enum processor_type)

> (PTA_TIGERLAKE)  : Ditto.

Ditto what? This is a new define.

> * doc/extend.texi: Add tigerlake.
> * doc/invoke.texi: Add tigerlake.

Added where? To which section?

> gcc/testsuite/
> * gcc.target/i386/funcspec-56.inc: Handle new march.
> * g++.target/i386/mv16.C: Handle new march

Dot.

>
> libgcc/
> * config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE.

(enum processor_subtypes)
>
> From-SVN: r274693

Please repost with improved/corrected ChangeLog.

Uros.

> --
> BR,
> Hongtao

Re: [GCC 12] [PATCH v2] Add inline_ignore_target function attribute

[Richard Biener via Gcc-patches]

On Mon, Apr 12, 2021 at 11:53 PM H.J. Lu  wrote:
>
> On Mon, Apr 12, 2021 at 2:21 AM Richard Biener
>  wrote:
> >
> > On Sat, Apr 10, 2021 at 5:11 PM H.J. Lu via Gcc-patches
> >  wrote:
> > >
> > > Add inline_ignore_target function attribute to inform the compiler that
> > > target specific option mismatch on functions with the always_inline
> > > attribute may be ignored.  On x86 targets, this attribute can be used on
> > > integer functions to ignore target non-integer option mismatch.
> >
> > I'm not sure I like such attribute but please adjust 
> > default_target_can_inline_p
> > accordingly (only few targets override this hook).
> >
> > Richard.
> >
>
> Like this?

Hmm, so

 bool
 default_target_can_inline_p (tree caller, tree callee)
 {
-  tree callee_opts = DECL_FUNCTION_SPECIFIC_TARGET (callee);
-  tree caller_opts = DECL_FUNCTION_SPECIFIC_TARGET (caller);
-  if (! callee_opts)
+  tree callee_opts;
+  if (lookup_attribute ("inline_ignore_target",
+   DECL_ATTRIBUTES (callee)))
 callee_opts = target_option_default_node;
+  else
+{
+  callee_opts = DECL_FUNCTION_SPECIFIC_TARGET (callee);
+  if (! callee_opts)
+   callee_opts = target_option_default_node;
+}

this means the attribute will "not work" for

statici inline void __attribute__((always_inline,inline_ignore_target))
foo() {}

void __attribute__((target("-mfoo")))
bar() { foo(); }

because while it ignores the target attribute on 'foo',
target_option_default_node
will still conflict with the target attribute of 'bar'.

Is that the intended behavior?  Ignore 'foo's target attribute for the
inlining decision, but not 'bar's?

What about __attribute__((optimization)) mismatches?

It might be more sensible to have a separate always-inline
attribute, say __attribute__((force_inline)) that does what I think
always-inline should do (inline, no matter what)?

Now, I still believe always-inline should behave and this new attribute
is totally unnecessary.

Richard.

> Thanks.
>
> --
> H.J.

[PATCH] [GCC-9] backport -march=tigerlake to GCC9 [PR target/100009]

[Hongtao Liu via Gcc-patches]

Hi:
  As described in PR, we introduced tigerlake string in driver-i386.c
by r9-8652 w/o support -march/tune=tigerlake which causes an error
when using -march/tune=native with GCC9 on tigerlake machine.
  Bootstrapped and regtested on x86-64_iinux-gnu{-m32,}.
  Ok for GCC9?

gcc/
* common/config/i386/i386-common.c
(processor_names): Add tigerlake.
(processor_alias_table): Ditto.
* config.gcc: Document -march=tigerlake.
* config/i386/driver-i386.c
(host_detect_local_cpu): Detect tigerlake, add "has_avx" to
classify processor.
* config/i386/i386-c.c (ix86_target_macros_internal): Handle
tigerlake.
* config/i386/i386.c (m_TIGERLAKE)  : Define.
(m_CORE_AVX512): Ditto.
(processor_cost_table): Add tigerlake.
(ix86_option_override_internal): Handle PTA_MOVDIRI, PTA_MOVDIR64B.
(processor_model): Add M_INTEL_COREI7_TIGERLAKE.
(arch_names_table): Add tigerlake.
(get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE.
* config/i386/i386.h (TARGET_TIGERLAKE): Define.
(processor_type) : Add PROCESSOR_TIGERLAKE.
(PTA_TIGERLAKE)  : Ditto.
* doc/extend.texi: Add tigerlake.
* doc/invoke.texi: Add tigerlake.

gcc/testsuite/
* gcc.target/i386/funcspec-56.inc: Handle new march.
* g++.target/i386/mv16.C: Handle new march

libgcc/
* config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE.

From-SVN: r274693

-- 
BR,
Hongtao
From 89a130f2e626d9e7d92ec8d51956a4ae0d10d277 Mon Sep 17 00:00:00 2001
From: Hongtao Liu 
Date: Tue, 20 Aug 2019 07:06:03 +
Subject: [PATCH] backport TIGERLAKE part to GCC9.

2019-08-20  Lili Cui  

gcc/
	* common/config/i386/i386-common.c
	(processor_names): Add tigerlake.
	(processor_alias_table): Ditto.
	* config.gcc: Document -march=tigerlake.
	* config/i386/driver-i386.c
	(host_detect_local_cpu): Detect tigerlake, add "has_avx" to
	classify processor.
	* config/i386/i386-c.c (ix86_target_macros_internal): Handle
	tigerlake.
	* config/i386/i386.c (m_TIGERLAKE)  : Define.
	(m_CORE_AVX512): Ditto.
	(processor_cost_table): Add tigerlake.
	(processor_model): Add M_INTEL_COREI7_TIGERLAKE.
	(arch_names_table): Add tigerlake.
	(get_builtin_code_for_version) : Handle PROCESSOR_TIGERLAKE.
	* config/i386/i386.h (TARGET_TIGERLAKE): Define.
	(processor_type) : Add PROCESSOR_TIGERLAKE.
	(PTA_TIGERLAKE)  : Ditto.
	* doc/extend.texi: Add tigerlake.
	* doc/invoke.texi: Add tigerlake.

gcc/testsuite/
	* gcc.target/i386/funcspec-56.inc: Handle new march.
	* g++.target/i386/mv16.C: Handle new march

libgcc/
	* config/i386/cpuinfo.h: Add INTEL_COREI7_TIGERLAKE.

	From-SVN: r274693
---
 gcc/common/config/i386/i386-common.c  |  2 +
 gcc/config.gcc|  3 +-
 gcc/config/i386/driver-i386.c | 62 ++-
 gcc/config/i386/i386-c.c  |  7 +++
 gcc/config/i386/i386.c| 12 +++-
 gcc/config/i386/i386.h|  4 ++
 gcc/doc/extend.texi   |  3 +
 gcc/doc/invoke.texi   |  8 +++
 gcc/testsuite/g++.target/i386/mv16.C  |  6 ++
 gcc/testsuite/gcc.target/i386/funcspec-56.inc |  1 +
 libgcc/config/i386/cpuinfo.h  |  1 +
 11 files changed, 78 insertions(+), 31 deletions(-)

diff --git a/gcc/common/config/i386/i386-common.c b/gcc/common/config/i386/i386-common.c
index c7841939e89..11960300bfc 100644
--- a/gcc/common/config/i386/i386-common.c
+++ b/gcc/common/config/i386/i386-common.c
@@ -1509,6 +1509,7 @@ const char *const processor_names[] =
   "icelake-client",
   "icelake-server",
   "cascadelake",
+  "tigerlake",
   "intel",
   "geode",
   "k6",
@@ -1591,6 +1592,7 @@ const pta processor_alias_table[] =
 PTA_ICELAKE_SERVER},
   {"cascadelake", PROCESSOR_CASCADELAKE, CPU_HASWELL,
 PTA_CASCADELAKE},
+  {"tigerlake", PROCESSOR_TIGERLAKE, CPU_HASWELL, PTA_TIGERLAKE},
   {"bonnell", PROCESSOR_BONNELL, CPU_ATOM, PTA_BONNELL},
   {"atom", PROCESSOR_BONNELL, CPU_ATOM, PTA_BONNELL},
   {"silvermont", PROCESSOR_SILVERMONT, CPU_SLM, PTA_SILVERMONT},
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 82f80d4c748..94885c7d758 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -667,7 +667,8 @@ bdver3 bdver4 znver1 znver2 btver1 btver2 k8 k8-sse3 opteron \
 opteron-sse3 nocona core2 corei7 corei7-avx core-avx-i core-avx2 atom \
 slm nehalem westmere sandybridge ivybridge haswell broadwell bonnell \
 silvermont knl knm skylake-avx512 cannonlake icelake-client icelake-server \
-skylake goldmont goldmont-plus tremont cascadelake x86-64 native"
+skylake goldmont goldmont-plus tremont cascadelake tigerlake x86-64 \
+native"
 
 # Additional x86 processors supported by --with-cpu=.  Each processor
 # MUST be separated by exactly one space.
diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c
index db8b4fa8aab..26c1ec1fda9 100644
--- a/gcc/co

Re: [PATCH] aarch64: Restore bfxil optimization [PR100028]

[Richard Sandiford via Gcc-patches]

Jakub Jelinek  writes:
> Hi!
>
> Similarly to PR87763 for bfi, the GCC 9 combiner changes to not combine
> moves from hard registers regressed the following testcase where we no
> longer recognize bfxil and emit 3 instructions instead.
>
> The following patch adds define_insn patterns that match what the combiner
> is trying to match in these cases.  I haven't been able to see patterns
> with the other order of the IOR operands, seems the IL is canonicalized this
> way no matter what is written in the source.

Thanks for doing this.  LGTM with one nit…

> Bootstrapped/regtested on aarch64-linux, ok for trunk?
>
> 2021-04-12  Jakub Jelinek  
>
>   PR target/100028
>   * config/aarch64/aarch64.md (*aarch64_bfxil_extr,
>   *aarch64_bfxilsi_extrdi): New define_insn patterns.
>
>   * gcc.target/aarch64/pr100028.c: New test.
>
> --- gcc/config/aarch64/aarch64.md.jj  2021-04-10 12:45:40.702654372 +0200
> +++ gcc/config/aarch64/aarch64.md 2021-04-12 17:46:03.610503988 +0200
> @@ -5601,6 +5601,38 @@ (define_insn "*aarch64_bfi4_no
>[(set_attr "type" "bfm")]
>  )
>  
> +(define_insn "*aarch64_bfxil_extr"
> +  [(set (match_operand:GPI 0 "register_operand" "=r")
> +(ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0")
> +   (match_operand:GPI 2 "const_int_operand" "n"))
> +  (zero_extract:GPI
> +(match_operand:GPI 3 "register_operand" "r")
> +(match_operand:GPI 4 "aarch64_simd_shift_imm_" "n")
> +(match_operand:GPI 5 "aarch64_simd_shift_imm_" "n"]
> +  "UINTVAL (operands[2]) == HOST_WIDE_INT_M1U << INTVAL (operands[4])
> +   && INTVAL (operands[4])
> +   && (UINTVAL (operands[4]) + UINTVAL (operands[5])
> +   <= GET_MODE_BITSIZE (mode))"
> +  "bfxil\t%0, %3, %5, %4"
> +  [(set_attr "type" "bfm")]
> +)
> +
> +(define_insn "*aarch64_bfxilsi_extrdi"
> +  [(set (match_operand:SI 0 "register_operand" "=r")
> +(ior:SI (and:SI (match_operand:SI 1 "register_operand" "0")
> + (match_operand:SI 2 "const_int_operand" "n"))
> + (match_operator:SI 6 "subreg_lowpart_operator"
> +   [(zero_extract:DI
> +  (subreg:DI (match_operand:SI 3 "register_operand" "r") 0)

I don't think we need to restrict this to subregs.  It should be OK
to have any DI register_operand, since the C condition ensures that the
extracted bits come from the low 32 bits specified by the %w3 operand.

OK with that change, thanks.

Richard

> +  (match_operand:SI 4 "aarch64_simd_shift_imm_si" "n")
> +  (match_operand:SI 5 "aarch64_simd_shift_imm_si" "n"))])))]
> +  "UINTVAL (operands[2]) == HOST_WIDE_INT_M1U << INTVAL (operands[4])
> +   && INTVAL (operands[4])
> +   && UINTVAL (operands[4]) + UINTVAL (operands[5]) <= 32"
> +  "bfxil\t%w0, %w3, %5, %4"
> +  [(set_attr "type" "bfm")]
> +)
> +
>  (define_insn "*extr_insv_lower_reg"
>[(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r")
> (match_operand 1 "const_int_operand" "n")
> --- gcc/testsuite/gcc.target/aarch64/pr100028.c.jj2021-04-12 
> 17:38:38.665472799 +0200
> +++ gcc/testsuite/gcc.target/aarch64/pr100028.c   2021-04-12 
> 17:38:18.470698594 +0200
> @@ -0,0 +1,22 @@
> +/* PR target/100028 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2" } */
> +
> +#define W3
> +#define L11
> +
> +int
> +foo (int d, int s)
> +{
> +  int wmask = (1 << W) - 1;
> +  return (d & ~wmask) | ((s >> L) & wmask);
> +}
> +
> +long long int
> +bar (long long int d, long long int s)
> +{
> +  long long int wmask = (1LL << W) - 1;
> +  return (d & ~wmask) | ((s >> L) & wmask);
> +}
> +
> +/* { dg-final { scan-assembler-times {\tbfxil\t} 2 } } */
>
>   Jakub

[PATCH] analyzer: enabling Modula-2 Storage/ALLOCATE/DEALLOCATE

[Gaius Mulley via Gcc-patches]

Hello David and fellow GCC developers,

[the proposed patches for GCC trunk are at the end of the email]

I've been having way too much fun with your -fanalyzer code and
here are four patches which give the analyzer the ability to
understand the Modula-2 Storage API.

  http://www.nongnu.org/gm2/gm2-libs-isostorage.html
  http://www.nongnu.org/gm2/gm2-libsstorage.html
  http://www.nongnu.org/gm2/gm2-libssysstorage.html

Here it is in action - these short tests have all been added to the
gm2 regression testsuite.  Many are from your C examples - rewritten
in Modula-2.  Ignoring a few poor token position subexpressions from
the front end, which I'm currently improving, it appears to work!

I've rebuilt GCC trunk 10/04/2021 with these patches and no new
regressions are introduced.  I ran a build of: c,c++,go,d,fortran,lto
and checked the before and after regression tests.  The new code is by
default disabled - hence the langhook patches.

While it is true that this is the cart before the horse (the gm2 front
end is still to arrive in the gcc tree).  I thought it might be useful
to post the patches - just in case others might benefit from the code
or point out bugs/flaws in the code!

Anyway thanks for the analyzer - it is great fun reading the code and
addictive trying to improve the accuracy of the error messages.  The
four patches follow after the examples below.

Examples of it in use:

$ cat badlistfree.mod
MODULE badlistfree ;

FROM Storage IMPORT ALLOCATE, DEALLOCATE ;

TYPE
   list = POINTER TO RECORD
value: CARDINAL ;
next : list ;
 END ;
VAR
   head: list ;

PROCEDURE badfree (l: list) ;
BEGIN
   DISPOSE (l) ;
   WHILE l^.next # NIL DO
  l := l^.next ;
  DISPOSE (l)
   END
END badfree ;


BEGIN
   NEW (head) ;
   badfree (head) ;
END badlistfree.
$ gm2 -g -c -fanalyzer badlistfree.mod
badlistfree.mod: In function ‘badfree’:
badlistfree.mod:16:24: warning: use after ‘DISPOSE’ of ‘l’ [CWE-416] 
[-Wanalyzer-use-after-free]
   16 |WHILE l^.next # NIL DO
  |^~
  ‘badfree’: events 1-2
|
|   15 |DISPOSE (l) ;
|  |^~
|  ||
|  |(1) deallocated here
|   16 |WHILE l^.next # NIL DO
|  |~~
|  ||
|  |(2) use after ‘DISPOSE’ of ‘l’; deallocated 
at (1)
|
$ cat disposenoalloc.mod
MODULE disposenoalloc ;

FROM Storage IMPORT ALLOCATE, DEALLOCATE ;
FROM SYSTEM IMPORT ADR ;

TYPE
   list = POINTER TO RECORD
value: CARDINAL ;
next : list ;
 END ;
VAR
   head: list ;

BEGIN
   head := ADR (head) ;
   DISPOSE (head)
END disposenoalloc.
$ gm2 -g -c -fanalyzer disposenoalloc.mod
disposenoalloc.mod: In function ‘_M2_disposenoalloc_init’:
disposenoalloc.mod:16:4: warning: ‘DISPOSE’ of ‘head’ which points to memory 
not on the heap [CWE-590] [-Wanalyzer-free-of-non-heap]
   16 |DISPOSE (head)
  |^
  ‘_M2_disposenoalloc_init’: events 1-3
|
|   15 |head := ADR (head) ;
|  |   ^
|  |   |
|  |   (1) pointer is from here
|   16 |DISPOSE (head)
|  |~   
|  |||
|  ||(2) pointer is from here
|  |(3) call to ‘DISPOSE’ here
|
$ cat testdoubledispose.mod
MODULE testdoubledispose ;

FROM Storage IMPORT ALLOCATE, DEALLOCATE ;

TYPE
   list = POINTER TO RECORD
value: CARDINAL ;
next : list ;
 END ;
VAR
   head: list ;
BEGIN
   NEW (head) ;
   DISPOSE (head) ;
   DISPOSE (head) ;
END testdoubledispose.
$ gm2 -g -c -fanalyzer testdoubledispose.mod
testdoubledispose.mod: In function ‘_M2_testdoubledispose_init’:
testdoubledispose.mod:15:4: warning: double-‘DISPOSE’ of ‘head’ [CWE-415] 
[-Wanalyzer-double-free]
   15 |DISPOSE (head) ;
  |^
  ‘_M2_testdoubledispose_init’: events 1-3
|
|   13 |NEW (head) ;
|  |^
|  ||
|  |(1) allocated here
|   14 |DISPOSE (head) ;
|  |~
|  ||
|  |(2) first ‘DISPOSE’ here
|   15 |DISPOSE (head) ;
|  |~
|  ||
|  |(3) second ‘DISPOSE’ here; first ‘DISPOSE’ was at (2)
|
$ cat testdoublefree.mod
MODULE testdoublefree ;

FROM libc IMPORT malloc, free ;
FROM SYSTEM IMPORT ADDRESS ;

VAR
   a: ADDRESS ;
BEGIN
   a := malloc (100) ;
   free (a) ;
   free (a)
END testdoublefree.
$ gm2 -g -c -fanalyzer testdoublefree.mod
testdoublefree.mod: In function ‘_M2_testdoublefree_init’:
testdoublefree.mod:11:4: warning: double-‘free’ of ‘a’ [CWE-415] 
[-Wanalyzer-double-free]
   11 |free (a)
  |^~~~
  ‘_M2_testdoubl

Re: [PATCH] mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables

[Jonathan Yong via Gcc-patches]

On 4/9/21 11:46 AM, Martin Storsjö wrote:

This is similar to what was done in
eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to
STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and
BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and
BOOT_CFLAGS).

2021-04-09  Martin Storsjö  

config/ChangeLog:
* mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags
variables
---
  config/mh-mingw | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/config/mh-mingw b/config/mh-mingw
index a795096f038..e91367a7112 100644
--- a/config/mh-mingw
+++ b/config/mh-mingw
@@ -1,7 +1,9 @@
  # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows
  # Vista (see PR33281 for details).
  BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
+BOOT_CXXFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
  CFLAGS += -D__USE_MINGW_ACCESS
+CXXFLAGS += -D__USE_MINGW_ACCESS
  STAGE1_CXXFLAGS += -D__USE_MINGW_ACCESS
  STAGE2_CXXFLAGS += -D__USE_MINGW_ACCESS
  STAGE3_CXXFLAGS += -D__USE_MINGW_ACCESS



Pushed to master branch, thanks.


OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags variables

[Jonathan Yong via Gcc-patches]

On 4/9/21 11:46 AM, Martin Storsjö wrote:

This is similar to what was done in
eea4e2ff0a3f5e7f37df204c070cc5d9ef339e6e (where it was added to
STAGE*_CXXFLAGS), but this adds the flag to the CXXFLAGS and
BOOT_CXXFLAGS variables too (as it's already added to CFLAGS and
BOOT_CFLAGS).

2021-04-09  Martin Storsjö  

config/ChangeLog:
* mh-mingw: Set __USE_MINGW_ACCESS in missed C++ flags
variables
---
  config/mh-mingw | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/config/mh-mingw b/config/mh-mingw
index a795096f038..e91367a7112 100644
--- a/config/mh-mingw
+++ b/config/mh-mingw
@@ -1,7 +1,9 @@
  # Add -D__USE_MINGW_ACCESS to enable the built compiler to work on Windows
  # Vista (see PR33281 for details).
  BOOT_CFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
+BOOT_CXXFLAGS += -D__USE_MINGW_ACCESS -Wno-pedantic-ms-format
  CFLAGS += -D__USE_MINGW_ACCESS
+CXXFLAGS += -D__USE_MINGW_ACCESS
  STAGE1_CXXFLAGS += -D__USE_MINGW_ACCESS
  STAGE2_CXXFLAGS += -D__USE_MINGW_ACCESS
  STAGE3_CXXFLAGS += -D__USE_MINGW_ACCESS



Patch looks good to me, will push to master branch soon.


OpenPGP_0x713B5FE29C145D45_and_old_rev.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Gcc

[rebecca button]

Hi,
I am following up to confirm if you (Gcc) are interested in acquiring the 
Visitors/Registrants List.
Salon De L' Immobilier
28 - 30 May 2021
Rennes, France
Registrants Counts:4200
Each record of the list contains: Contact Name, Email Address, Company Name, 
URL/Website, Phone No, Title/Designation.
Currently the best way to grow your business is through digital. This list will 
help you pass information about your organization and products directly and 
digitally to the buyer. This list will help you to acquire many potential 
clients / leads.
If you are interested in acquiring the list, we can provide you the cost and 
additional details.
I look forward to hearing from you.

Thanks & Regards
Rebecca  Button   -   Business Analyst

[PATCH] aarch64: Restore bfxil optimization [PR100028]

[Jakub Jelinek via Gcc-patches]

Hi!

Similarly to PR87763 for bfi, the GCC 9 combiner changes to not combine
moves from hard registers regressed the following testcase where we no
longer recognize bfxil and emit 3 instructions instead.

The following patch adds define_insn patterns that match what the combiner
is trying to match in these cases.  I haven't been able to see patterns
with the other order of the IOR operands, seems the IL is canonicalized this
way no matter what is written in the source.

Bootstrapped/regtested on aarch64-linux, ok for trunk?

2021-04-12  Jakub Jelinek  

PR target/100028
* config/aarch64/aarch64.md (*aarch64_bfxil_extr,
*aarch64_bfxilsi_extrdi): New define_insn patterns.

* gcc.target/aarch64/pr100028.c: New test.

--- gcc/config/aarch64/aarch64.md.jj2021-04-10 12:45:40.702654372 +0200
+++ gcc/config/aarch64/aarch64.md   2021-04-12 17:46:03.610503988 +0200
@@ -5601,6 +5601,38 @@ (define_insn "*aarch64_bfi4_no
   [(set_attr "type" "bfm")]
 )
 
+(define_insn "*aarch64_bfxil_extr"
+  [(set (match_operand:GPI 0 "register_operand" "=r")
+(ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0")
+ (match_operand:GPI 2 "const_int_operand" "n"))
+(zero_extract:GPI
+  (match_operand:GPI 3 "register_operand" "r")
+  (match_operand:GPI 4 "aarch64_simd_shift_imm_" "n")
+  (match_operand:GPI 5 "aarch64_simd_shift_imm_" "n"]
+  "UINTVAL (operands[2]) == HOST_WIDE_INT_M1U << INTVAL (operands[4])
+   && INTVAL (operands[4])
+   && (UINTVAL (operands[4]) + UINTVAL (operands[5])
+   <= GET_MODE_BITSIZE (mode))"
+  "bfxil\t%0, %3, %5, %4"
+  [(set_attr "type" "bfm")]
+)
+
+(define_insn "*aarch64_bfxilsi_extrdi"
+  [(set (match_operand:SI 0 "register_operand" "=r")
+(ior:SI (and:SI (match_operand:SI 1 "register_operand" "0")
+   (match_operand:SI 2 "const_int_operand" "n"))
+   (match_operator:SI 6 "subreg_lowpart_operator"
+ [(zero_extract:DI
+(subreg:DI (match_operand:SI 3 "register_operand" "r") 0)
+(match_operand:SI 4 "aarch64_simd_shift_imm_si" "n")
+(match_operand:SI 5 "aarch64_simd_shift_imm_si" "n"))])))]
+  "UINTVAL (operands[2]) == HOST_WIDE_INT_M1U << INTVAL (operands[4])
+   && INTVAL (operands[4])
+   && UINTVAL (operands[4]) + UINTVAL (operands[5]) <= 32"
+  "bfxil\t%w0, %w3, %5, %4"
+  [(set_attr "type" "bfm")]
+)
+
 (define_insn "*extr_insv_lower_reg"
   [(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r")
  (match_operand 1 "const_int_operand" "n")
--- gcc/testsuite/gcc.target/aarch64/pr100028.c.jj  2021-04-12 
17:38:38.665472799 +0200
+++ gcc/testsuite/gcc.target/aarch64/pr100028.c 2021-04-12 17:38:18.470698594 
+0200
@@ -0,0 +1,22 @@
+/* PR target/100028 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+#define W  3
+#define L  11
+
+int
+foo (int d, int s)
+{
+  int wmask = (1 << W) - 1;
+  return (d & ~wmask) | ((s >> L) & wmask);
+}
+
+long long int
+bar (long long int d, long long int s)
+{
+  long long int wmask = (1LL << W) - 1;
+  return (d & ~wmask) | ((s >> L) & wmask);
+}
+
+/* { dg-final { scan-assembler-times {\tbfxil\t} 2 } } */

Jakub