Re: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299

2022-12-06 Thread Kewen.Lin via Gcc-patches
Hi Mike,

on 2022/12/7 14:44, Michael Meissner wrote:
> On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
>> Hi Mike,
>>
>> Thanks for fixing this!
>>
>> Could you help to elaborate why we need to disable it during libgcc building?
> 
> When you are building libgcc, you are building the __mulkc3, __divkc3
> functions.  The mapping in the compiler interferes with those functions,
> because at the moment, libgcc uses an alternate IEEE 128-bit type.
> 

But I'm still confused.  For __mulkc3 (__divkc3 is similar),

1) with -mabi=ieeelongdouble (TARGET_IEEEQUAD true, define 
__LONG_DOUBLE_IEEE128__),
   the used types are:

   typedef float TFtype __attribute__ ((mode (TF)));
   typedef __complex float TCtype __attribute__ ((mode (TC)));

2) with -mabi=ibmlongdouble (TARGET_IEEEQUAD false, not __LONG_DOUBLE_IEEE128__ 
defined),
   the used types are:

   typedef float TFtype __attribute__ ((mode (KF)));
   typedef __complex float TCtype __attribute__ ((mode (KC)));

The proposed mapping in the current patch is:

+
+  if (id == complex_multiply_builtin_code (KCmode))
+   newname = "__mulkc3";
+
+  else if (id == complex_multiply_builtin_code (ICmode))
+   newname = "__multc3";
+
+  else if (id == complex_multiply_builtin_code (TCmode))
+   newname = (TARGET_IEEEQUAD) ? "__mulkc3" : "__multc3";

for 1), TCmode && TARGET_IEEEQUAD => "__mulkc3"
for 2), KCmode => "__mulkc3"

Both should be still with name "__mulkc3", do I miss anything?

BR,
Kewen

> I have a patch for making libgcc use the 'right' type that I haven't submitted
> yet.  This is because the more general fix that these 3 patches do impacts 
> other
> functions (due to __float128 and _Float128 being different in the current
> compiler when -mabi=ieeelongdouble).
> 


Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC

2022-12-06 Thread Sebastian Huber




On 07.12.22 08:10, Thomas Schwinge wrote:

Hi!

On 2022-12-07T07:04:10+0100, Sebastian Huber 
 wrote:

On 06.12.22 22:06, Thomas Schwinge wrote:
I suppose I just fail to see some detail here, but:


On 2022-11-21T08:25:25+0100, Sebastian 
Huber  wrote:

gcc/ChangeLog:

* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
(cc1_spec): Append SUBTARGET_CC1_SPEC.
---
v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC.
  This avoids having to modify all the CC1_SPEC definitions in the targets.

   gcc/gcc.cc | 9 -
   1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 830ab88701f..4e1574a4df1 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -706,6 +706,13 @@ proper position among the other output files.  */
   #define CPP_SPEC ""
   #endif

+/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 and
+   cc1plus or extra switch-translations.  The SUBTARGET_CC1_SPEC is appended
+   to CC1_SPEC.  */
+#ifndef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC ""
+#endif
+
   /* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
  or extra switch-translations.  */
   #ifndef CC1_SPEC
@@ -1174,7 +1181,7 @@ proper position among the other output files.  */
   static const char *asm_debug = ASM_DEBUG_SPEC;
   static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
   static const char *cpp_spec = CPP_SPEC;
-static const char *cc1_spec = CC1_SPEC;
+static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC;
   static const char *cc1plus_spec = CC1PLUS_SPEC;
   static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
   static const char *link_ssp_spec = LINK_SSP_SPEC;


... doesn't this (at least potentially?) badly interact with any existing
'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to
'cc1_spec'?

  gcc/config/loongarch/gnu-user.h-   and provides this hook instead.  */
  gcc/config/loongarch/gnu-user.h:#undef SUBTARGET_CC1_SPEC
  gcc/config/loongarch/gnu-user.h:#define SUBTARGET_CC1_SPEC 
GNU_USER_TARGET_CC1_SPEC
  gcc/config/loongarch/gnu-user.h-
  --
  gcc/config/loongarch/loongarch.h-#define EXTRA_SPECS \
  gcc/config/loongarch/loongarch.h:  {"subtarget_cc1_spec", 
SUBTARGET_CC1_SPEC}, \
  gcc/config/loongarch/loongarch.h-  {"subtarget_cpp_spec", 
SUBTARGET_CPP_SPEC}, \
  --
  gcc/config/mips/gnu-user.h-   and provides this hook instead.  */
  gcc/config/mips/gnu-user.h:#undef SUBTARGET_CC1_SPEC
  gcc/config/mips/gnu-user.h:#define SUBTARGET_CC1_SPEC 
GNU_USER_TARGET_CC1_SPEC
  gcc/config/mips/gnu-user.h-
  --
  gcc/config/mips/linux-common.h-
  gcc/config/mips/linux-common.h:#undef  SUBTARGET_CC1_SPEC
  gcc/config/mips/linux-common.h:#define SUBTARGET_CC1_SPEC 
  \
  gcc/config/mips/linux-common.h-  LINUX_OR_ANDROID_CC 
(GNU_USER_TARGET_CC1_SPEC, \
  --
  gcc/config/mips/mips.h-
  gcc/config/mips/mips.h:/* SUBTARGET_CC1_SPEC is passed to the compiler 
proper.  It may be
  gcc/config/mips/mips.h-   overridden by subtargets.  */
  gcc/config/mips/mips.h:#ifndef SUBTARGET_CC1_SPEC
  gcc/config/mips/mips.h:#define SUBTARGET_CC1_SPEC ""
  gcc/config/mips/mips.h-#endif
  --
  gcc/config/mips/mips.h-#define EXTRA_SPECS
  \
  gcc/config/mips/mips.h:  { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },
  \
  gcc/config/mips/mips.h-  { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },
  \
  --
  gcc/config/mips/r3900.h-/* By default (if not mips-something-else) 
produce code for the r3900 */
  gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
  gcc/config/mips/r3900.h:#define SUBTARGET_CC1_SPEC "\
  gcc/config/mips/r3900.h-%{mhard-float:%e-mhard-float not supported} \


Oh, I came up with the name SUBTARGET_CC1_SPEC after a discussion on the
mailing list


I've put Iain in CC.


and I have to admit that I didn't check that it was
actually already in use.


Always one of the first things I do.  ;-)


What about renaming the loongarch/mips define
to LOONGARCH_CC1_SPEC and MIPS_CC1_SPEC?


Also in use are a number of other 'SUBTARGET_[...]_SPEC' and
corresponding 'subtarget_[...]_spec' in 'EXTRA_SPECS', for example:

 gcc/config/mips/mips.h-#define EXTRA_SPECS 
 \
 gcc/config/mips/mips.h:  { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC }, 
 \
 gcc/config/mips/mips.h:  { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC }, 
 \
 gcc/config/mips/mips.h:  { "subtarget_asm_debugging_spec", 
SUBTARGET_ASM_DEBUGGING_SPEC },  \
 gcc/config/mips/mips.h:  { "subtarget_asm_spec", SUBTARGET_ASM_SPEC }, 
 \
 gcc/config/mips/mips.h-  { 

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

2022-12-06 Thread clyon at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998

--- Comment #4 from Christophe Lyon  ---
Indeed my patch aimed at catching such inconsistencies.
I guess before that the build had a 'strange' behavior? (with a missing
dirname, some parts of the shell genmultilib shell script would expand into
empty values, probably leading to unintended behaviour)

[Bug analyzer/108003] [13 Regression] ICE in bitmap_check_index, at sbitmap.h:105

2022-12-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108003

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC

2022-12-06 Thread Thomas Schwinge
Hi!

On 2022-12-07T07:04:10+0100, Sebastian Huber 
 wrote:
> On 06.12.22 22:06, Thomas Schwinge wrote:
> I suppose I just fail to see some detail here, but:
>
>> On 2022-11-21T08:25:25+0100, Sebastian 
>> Huber  wrote:
>>> gcc/ChangeLog:
>>>
>>>* gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
>>>(cc1_spec): Append SUBTARGET_CC1_SPEC.
>>> ---
>>> v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC.
>>>  This avoids having to modify all the CC1_SPEC definitions in the 
>>> targets.
>>>
>>>   gcc/gcc.cc | 9 -
>>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
>>> index 830ab88701f..4e1574a4df1 100644
>>> --- a/gcc/gcc.cc
>>> +++ b/gcc/gcc.cc
>>> @@ -706,6 +706,13 @@ proper position among the other output files.  */
>>>   #define CPP_SPEC ""
>>>   #endif
>>>
>>> +/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 
>>> and
>>> +   cc1plus or extra switch-translations.  The SUBTARGET_CC1_SPEC is 
>>> appended
>>> +   to CC1_SPEC.  */
>>> +#ifndef SUBTARGET_CC1_SPEC
>>> +#define SUBTARGET_CC1_SPEC ""
>>> +#endif
>>> +
>>>   /* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
>>>  or extra switch-translations.  */
>>>   #ifndef CC1_SPEC
>>> @@ -1174,7 +1181,7 @@ proper position among the other output files.  */
>>>   static const char *asm_debug = ASM_DEBUG_SPEC;
>>>   static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
>>>   static const char *cpp_spec = CPP_SPEC;
>>> -static const char *cc1_spec = CC1_SPEC;
>>> +static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC;
>>>   static const char *cc1plus_spec = CC1PLUS_SPEC;
>>>   static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
>>>   static const char *link_ssp_spec = LINK_SSP_SPEC;
>>
>> ... doesn't this (at least potentially?) badly interact with any existing
>> 'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to
>> 'cc1_spec'?
>>
>>  gcc/config/loongarch/gnu-user.h-   and provides this hook instead.  */
>>  gcc/config/loongarch/gnu-user.h:#undef SUBTARGET_CC1_SPEC
>>  gcc/config/loongarch/gnu-user.h:#define SUBTARGET_CC1_SPEC 
>> GNU_USER_TARGET_CC1_SPEC
>>  gcc/config/loongarch/gnu-user.h-
>>  --
>>  gcc/config/loongarch/loongarch.h-#define EXTRA_SPECS \
>>  gcc/config/loongarch/loongarch.h:  {"subtarget_cc1_spec", 
>> SUBTARGET_CC1_SPEC}, \
>>  gcc/config/loongarch/loongarch.h-  {"subtarget_cpp_spec", 
>> SUBTARGET_CPP_SPEC}, \
>>  --
>>  gcc/config/mips/gnu-user.h-   and provides this hook instead.  */
>>  gcc/config/mips/gnu-user.h:#undef SUBTARGET_CC1_SPEC
>>  gcc/config/mips/gnu-user.h:#define SUBTARGET_CC1_SPEC 
>> GNU_USER_TARGET_CC1_SPEC
>>  gcc/config/mips/gnu-user.h-
>>  --
>>  gcc/config/mips/linux-common.h-
>>  gcc/config/mips/linux-common.h:#undef  SUBTARGET_CC1_SPEC
>>  gcc/config/mips/linux-common.h:#define SUBTARGET_CC1_SPEC   
>> \
>>  gcc/config/mips/linux-common.h-  LINUX_OR_ANDROID_CC 
>> (GNU_USER_TARGET_CC1_SPEC, \
>>  --
>>  gcc/config/mips/mips.h-
>>  gcc/config/mips/mips.h:/* SUBTARGET_CC1_SPEC is passed to the compiler 
>> proper.  It may be
>>  gcc/config/mips/mips.h-   overridden by subtargets.  */
>>  gcc/config/mips/mips.h:#ifndef SUBTARGET_CC1_SPEC
>>  gcc/config/mips/mips.h:#define SUBTARGET_CC1_SPEC ""
>>  gcc/config/mips/mips.h-#endif
>>  --
>>  gcc/config/mips/mips.h-#define EXTRA_SPECS  
>> \
>>  gcc/config/mips/mips.h:  { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },  
>> \
>>  gcc/config/mips/mips.h-  { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },  
>> \
>>  --
>>  gcc/config/mips/r3900.h-/* By default (if not mips-something-else) 
>> produce code for the r3900 */
>>  gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
>>  gcc/config/mips/r3900.h:#define SUBTARGET_CC1_SPEC "\
>>  gcc/config/mips/r3900.h-%{mhard-float:%e-mhard-float not supported} \
>
> Oh, I came up with the name SUBTARGET_CC1_SPEC after a discussion on the
> mailing list

I've put Iain in CC.

> and I have to admit that I didn't check that it was
> actually already in use.

Always one of the first things I do.  ;-)

> What about renaming the loongarch/mips define
> to LOONGARCH_CC1_SPEC and MIPS_CC1_SPEC?

Also in use are a number of other 'SUBTARGET_[...]_SPEC' and
corresponding 'subtarget_[...]_spec' in 'EXTRA_SPECS', for example:

gcc/config/mips/mips.h-#define EXTRA_SPECS  
\
gcc/config/mips/mips.h:  { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },  
\
gcc/config/mips/mips.h:  { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },  
\
gcc/config/mips/mips.h:  { 

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

2022-12-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |erozen at microsoft dot 
com
 Status|WAITING |ASSIGNED

Re: [PATCH] i386: Avoid fma_chain for -march=alderlake and sapphirerapids.

2022-12-06 Thread Uros Bizjak via Gcc-patches
On Wed, Dec 7, 2022 at 7:36 AM Hongyu Wang  wrote:
>
> For Alderlake there is similar issue like PR 81616, enable
> avoid_fma256_chain will also benefit on Intel latest platforms
> Alderlake and Sapphire Rapids.
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu{-m32,}.
>
> Ok for master?
>
> gcc/ChangeLog:
>
> * config/i386/x86-tune.def (X86_TUNE_AVOID_256FMA_CHAINS): Add
> m_SAPPHIRERAPIDS, m_ALDERLAKE and m_CORE_ATOM.

OK.

Thanks,
Uros.

> ---
>  gcc/config/i386/x86-tune.def | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def
> index cd66f335113..db85de20bae 100644
> --- a/gcc/config/i386/x86-tune.def
> +++ b/gcc/config/i386/x86-tune.def
> @@ -499,7 +499,8 @@ DEF_TUNE (X86_TUNE_AVOID_128FMA_CHAINS, 
> "avoid_fma_chains", m_ZNVER)
>
>  /* X86_TUNE_AVOID_256FMA_CHAINS: Avoid creating loops with tight 256bit or
> smaller FMA chain.  */
> -DEF_TUNE (X86_TUNE_AVOID_256FMA_CHAINS, "avoid_fma256_chains", m_ZNVER2 | 
> m_ZNVER3)
> +DEF_TUNE (X86_TUNE_AVOID_256FMA_CHAINS, "avoid_fma256_chains", m_ZNVER2 | 
> m_ZNVER3
> + | m_ALDERLAKE | m_SAPPHIRERAPIDS | m_CORE_ATOM)
>
>  /* X86_TUNE_V2DF_REDUCTION_PREFER_PHADDPD: Prefer haddpd
> for v2df vector reduction.  */
> --
> 2.18.1
>


[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

2022-12-06 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108002

--- Comment #5 from Richard Biener  ---
Btw, you can always try to bisect what GCC change fixed the issue and try
backporting this yourself.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

2022-12-06 Thread guihaoc at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004

--- Comment #3 from HaoChen Gui  ---
(In reply to Andrew Pinski from comment #2)
> Especially when it comes to signed comparisons.

>From the ISA,
For all fixed-point instructions in which Rc=1, and for
addic., andi., and andis., the first three bits of CR Field
0 (bits 32:34 of the Condition Register) are set by
signed comparison of the result to zero, and the fourth
bit of CR Field 0 (bit 35 of the Condition Register) is
copied from the SO field of the XER.

Re: [PATCH 1/3] Rework 128-bit complex multiply and divide, PR target/107299

2022-12-06 Thread Michael Meissner via Gcc-patches
On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote:
> Hi Mike,
> 
> Thanks for fixing this!
> 
> Could you help to elaborate why we need to disable it during libgcc building?

When you are building libgcc, you are building the __mulkc3, __divkc3
functions.  The mapping in the compiler interferes with those functions,
because at the moment, libgcc uses an alternate IEEE 128-bit type.

I have a patch for making libgcc use the 'right' type that I haven't submitted
yet.  This is because the more general fix that these 3 patches do impacts other
functions (due to __float128 and _Float128 being different in the current
compiler when -mabi=ieeelongdouble).

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meiss...@linux.ibm.com


[PATCH] i386: Avoid fma_chain for -march=alderlake and sapphirerapids.

2022-12-06 Thread Hongyu Wang via Gcc-patches
For Alderlake there is similar issue like PR 81616, enable
avoid_fma256_chain will also benefit on Intel latest platforms
Alderlake and Sapphire Rapids.

Bootstrapped/regtested on x86_64-pc-linux-gnu{-m32,}.

Ok for master?

gcc/ChangeLog:

* config/i386/x86-tune.def (X86_TUNE_AVOID_256FMA_CHAINS): Add
m_SAPPHIRERAPIDS, m_ALDERLAKE and m_CORE_ATOM.
---
 gcc/config/i386/x86-tune.def | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/config/i386/x86-tune.def b/gcc/config/i386/x86-tune.def
index cd66f335113..db85de20bae 100644
--- a/gcc/config/i386/x86-tune.def
+++ b/gcc/config/i386/x86-tune.def
@@ -499,7 +499,8 @@ DEF_TUNE (X86_TUNE_AVOID_128FMA_CHAINS, "avoid_fma_chains", 
m_ZNVER)
 
 /* X86_TUNE_AVOID_256FMA_CHAINS: Avoid creating loops with tight 256bit or
smaller FMA chain.  */
-DEF_TUNE (X86_TUNE_AVOID_256FMA_CHAINS, "avoid_fma256_chains", m_ZNVER2 | 
m_ZNVER3)
+DEF_TUNE (X86_TUNE_AVOID_256FMA_CHAINS, "avoid_fma256_chains", m_ZNVER2 | 
m_ZNVER3
+ | m_ALDERLAKE | m_SAPPHIRERAPIDS | m_CORE_ATOM)
 
 /* X86_TUNE_V2DF_REDUCTION_PREFER_PHADDPD: Prefer haddpd
for v2df vector reduction.  */
-- 
2.18.1



Re: GDC environment variable

2022-12-06 Thread Ankur Saini via Gcc
I do see make using ‘GDC' while building gcc compiler, maybe try changing that ?

- Ankur

> On 07-Dec-2022, at 11:42 AM, Dave Blanchard  wrote:
> 
> Is there an environment variable like 'CC' or 'CXX', which specifies the name 
> of the D compiler to use, which I might need to set when bootstrapping GCC? 
> Thanks.
> 
> -- 
> Dave Blanchard 



[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

2022-12-06 Thread ahmad at a3f dot at via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105523

Ahmad Fatoum  changed:

   What|Removed |Added

 CC||ahmad at a3f dot at

--- Comment #14 from Ahmad Fatoum  ---
Does param=min-pagesize=0 solely influence warnings or could it now or in the
future affect code generation/optimization?

I ask because barebox (https://barebox.org) also has this problem as on i.MX8,
where it calls into ROM code, which starts at address 0. After that's done, it
maps the NULL page there and normal accesses are unexpected. So if it's just
about the warning, I'd prefer hiding pointer value via a compiler barrier where
appliable instead of disabling the warning altogether.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004

--- Comment #2 from Andrew Pinski  ---
Especially when it comes to signed comparisons.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004

--- Comment #1 from Andrew Pinski  ---
>From what I remember and. Only sets eq bit correctly.

[Bug target/108004] New: x-form logical operations with dot instructions are not emitted.

2022-12-06 Thread guihaoc at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108004

Bug ID: 108004
   Summary: x-form logical operations with dot instructions are
not emitted.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guihaoc at gcc dot gnu.org
  Target Milestone: ---

//test case
int foo (int a, int b, int c, int d)
{
  return (a & b) > 0 ? c : d;
}

//assemble on P9
and 3,3,4
cmpwi 0,3,0
isel 5,5,6,1
extsw 3,5

The "and" and "cmpwi" can be optimized to "and." instruction. The same as "or"
and "xor".

GDC environment variable

2022-12-06 Thread Dave Blanchard
Is there an environment variable like 'CC' or 'CXX', which specifies the name 
of the D compiler to use, which I might need to set when bootstrapping GCC? 
Thanks.

-- 
Dave Blanchard 


Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC

2022-12-06 Thread Sebastian Huber

On 06.12.22 22:06, Thomas Schwinge wrote:

Hi!

I suppose I just fail to see some detail here, but:

On 2022-11-21T08:25:25+0100, Sebastian 
Huber  wrote:

gcc/ChangeLog:

   * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
   (cc1_spec): Append SUBTARGET_CC1_SPEC.
---
v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC.
 This avoids having to modify all the CC1_SPEC definitions in the targets.

  gcc/gcc.cc | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gcc/gcc.cc b/gcc/gcc.cc
index 830ab88701f..4e1574a4df1 100644
--- a/gcc/gcc.cc
+++ b/gcc/gcc.cc
@@ -706,6 +706,13 @@ proper position among the other output files.  */
  #define CPP_SPEC ""
  #endif

+/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 and
+   cc1plus or extra switch-translations.  The SUBTARGET_CC1_SPEC is appended
+   to CC1_SPEC.  */
+#ifndef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC ""
+#endif
+
  /* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
 or extra switch-translations.  */
  #ifndef CC1_SPEC
@@ -1174,7 +1181,7 @@ proper position among the other output files.  */
  static const char *asm_debug = ASM_DEBUG_SPEC;
  static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
  static const char *cpp_spec = CPP_SPEC;
-static const char *cc1_spec = CC1_SPEC;
+static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC;
  static const char *cc1plus_spec = CC1PLUS_SPEC;
  static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
  static const char *link_ssp_spec = LINK_SSP_SPEC;

... doesn't this (at least potentially?) badly interact with any existing
'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to
'cc1_spec'?

 gcc/config/loongarch/gnu-user.h-   and provides this hook instead.  */
 gcc/config/loongarch/gnu-user.h:#undef SUBTARGET_CC1_SPEC
 gcc/config/loongarch/gnu-user.h:#define SUBTARGET_CC1_SPEC 
GNU_USER_TARGET_CC1_SPEC
 gcc/config/loongarch/gnu-user.h-
 --
 gcc/config/loongarch/loongarch.h-#define EXTRA_SPECS \
 gcc/config/loongarch/loongarch.h:  {"subtarget_cc1_spec", 
SUBTARGET_CC1_SPEC}, \
 gcc/config/loongarch/loongarch.h-  {"subtarget_cpp_spec", 
SUBTARGET_CPP_SPEC}, \
 --
 gcc/config/mips/gnu-user.h-   and provides this hook instead.  */
 gcc/config/mips/gnu-user.h:#undef SUBTARGET_CC1_SPEC
 gcc/config/mips/gnu-user.h:#define SUBTARGET_CC1_SPEC 
GNU_USER_TARGET_CC1_SPEC
 gcc/config/mips/gnu-user.h-
 --
 gcc/config/mips/linux-common.h-
 gcc/config/mips/linux-common.h:#undef  SUBTARGET_CC1_SPEC
 gcc/config/mips/linux-common.h:#define SUBTARGET_CC1_SPEC  
 \
 gcc/config/mips/linux-common.h-  LINUX_OR_ANDROID_CC 
(GNU_USER_TARGET_CC1_SPEC, \
 --
 gcc/config/mips/mips.h-
 gcc/config/mips/mips.h:/* SUBTARGET_CC1_SPEC is passed to the compiler 
proper.  It may be
 gcc/config/mips/mips.h-   overridden by subtargets.  */
 gcc/config/mips/mips.h:#ifndef SUBTARGET_CC1_SPEC
 gcc/config/mips/mips.h:#define SUBTARGET_CC1_SPEC ""
 gcc/config/mips/mips.h-#endif
 --
 gcc/config/mips/mips.h-#define EXTRA_SPECS 
 \
 gcc/config/mips/mips.h:  { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC }, 
 \
 gcc/config/mips/mips.h-  { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC }, 
 \
 --
 gcc/config/mips/r3900.h-/* By default (if not mips-something-else) produce 
code for the r3900 */
 gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
 gcc/config/mips/r3900.h:#define SUBTARGET_CC1_SPEC "\
 gcc/config/mips/r3900.h-%{mhard-float:%e-mhard-float not supported} \


Oh, I came up with the name SUBTARGET_CC1_SPEC after a discussion on the 
mailing list and I have to admit that I didn't check that it was 
actually already in use. What about renaming the loongarch/mips define 
to LOONGARCH_CC1_SPEC and MIPS_CC1_SPEC?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/


Re: [PATCH v3, rs6000] Enable have_cbranchcc4 on rs6000

2022-12-06 Thread Kewen.Lin via Gcc-patches
on 2022/12/7 13:24, HAO CHEN GUI wrote:
> Hi Kewen,
>   Thanks so much for your review comments. I will fix them.
> 
> 在 2022/12/7 11:06, Kewen.Lin 写道:
>> Does this issue which relies on the fix for generic part make bootstrapping 
>> fail?
>> If no, how many failures it can cause?  I'm thinking if we can commit this 
>> firstly,
>> then in the commit log of the fix for generic part you can mention it can 
>> fix the
>> ICE exposed by this test case.
> 
> Yes, the bootstrapping fails if we enable cbranchcc4 without the generic 
> patch.
> Actually, the testcase comes from the ICE found in bootstrapping.

Ah, thanks for confirming, so the fix for the generic part should come first.
I just noticed Richi has approved it, you can mention this test case
gcc.target/powerpc/cbranchcc4-1.c in the commit log for a record when committing
it.  Thanks!

BR,
Kewen


Re: [PATCH v3, rs6000] Enable have_cbranchcc4 on rs6000

2022-12-06 Thread HAO CHEN GUI via Gcc-patches
Hi Kewen,
  Thanks so much for your review comments. I will fix them.

在 2022/12/7 11:06, Kewen.Lin 写道:
> Does this issue which relies on the fix for generic part make bootstrapping 
> fail?
> If no, how many failures it can cause?  I'm thinking if we can commit this 
> firstly,
> then in the commit log of the fix for generic part you can mention it can fix 
> the
> ICE exposed by this test case.

Yes, the bootstrapping fails if we enable cbranchcc4 without the generic patch.
Actually, the testcase comes from the ICE found in bootstrapping.


[PATCH v2] Add a new conversion for conditional ternary set into ifcvt [PR106536]

2022-12-06 Thread HAO CHEN GUI via Gcc-patches
Hi,
  This patch adds a new conversion to convert a certain branch to
conditional ternary set in ifcvt.

  The branch commonly has following insns.
  cond_jump ? pc : label
  setcc
  (neg/subreg)
  label: set a constant
  cond_jump and setcc use the same CC reg and neg/subreg is optional.

  The branch might be converted to a nested if-then-else insn to eliminate
the branch if the insn is supported on target.
 [(set (match_operand:SI 0 "gpc_reg_operand")
 (if_then_else:SI (lt (match_operand:CC 1 "cc_reg_operand")
  (const_int 0))
  (const_int -1)
  (if_then_else:SI (gt (match_dup 1)
   (const_int 0))
   (const_int 1)
   (const_int 0]

  The patch adds a new optab for the nested if-then-else insn, and adds
help functions in ifcvt.cc to detect the pattern and emit the insn by the
new optab.

  Compared to last version, this version uses a generic function to detect
the candidate branch instead of using a target hook. Also a new optab is
added. The insn is generated by the new optab instead of recog.

  Bootstrapped and tested on powerpc64-linux BE/LE and x86 with no
regressions. Is this okay for trunk? Any recommendations? Thanks a lot.

ChangeLog
2022-12-07  Haochen Gui 

gcc/
* ifcvt.cc (noce_emit_ternary_set): New function to emit a conditional
ternary set insn by ternary_set_optab.
(noce_try_ternary_set): Detect conditional ternary set pattern and
call noce_emit_ternary_set to emit the insn.
(noce_process_if_block): Call noce_try_ternary_set to do the
conversion.
* optabs.def (ternary_set_optab): New optab.

patch.diff
diff --git a/gcc/ifcvt.cc b/gcc/ifcvt.cc
index eb8efb89a89..8252d9c2dc5 100644
--- a/gcc/ifcvt.cc
+++ b/gcc/ifcvt.cc
@@ -1830,6 +1830,44 @@ noce_emit_cmove (struct noce_if_info *if_info, rtx x, 
enum rtx_code code,
 return NULL_RTX;
 }

+/*  Emit a conditional ternary set insn by its optab.  */
+
+static rtx
+noce_emit_ternary_set (rtx target, enum rtx_code outer_code,
+  enum rtx_code inner_code, rtx cc, int a, int b, int c)
+{
+  rtx outer_comp, inner_comp;
+  machine_mode mode;
+  machine_mode orig_mode = GET_MODE (target);
+  outer_comp = gen_rtx_fmt_ee (outer_code, VOIDmode, cc, const0_rtx);
+  inner_comp = gen_rtx_fmt_ee (inner_code, VOIDmode, cc, const0_rtx);
+
+  class expand_operand ops[7];
+  create_fixed_operand ([1], outer_comp);
+  create_fixed_operand ([3], inner_comp);
+  create_fixed_operand ([2], cc);
+  create_integer_operand ([4], a);
+  create_integer_operand ([5], b);
+  create_integer_operand ([6], c);
+
+  FOR_EACH_MODE_FROM (mode, orig_mode)
+{
+  enum insn_code icode;
+  icode = optab_handler (ternary_set_optab, mode);
+  if (icode != CODE_FOR_nothing)
+   {
+ create_output_operand ([0], target, mode);
+ if (maybe_expand_insn (icode, 7, ops))
+   {
+ if (ops[0].value != target)
+   convert_move (target, ops[0].value, false);
+ return target;
+   }
+   }
+}
+  return NULL_RTX;
+}
+
 /* Try only simple constants and registers here.  More complex cases
are handled in noce_try_cmove_arith after noce_try_store_flag_arith
has had a go at it.  */
@@ -2987,6 +3025,160 @@ noce_try_bitop (struct noce_if_info *if_info)
   return TRUE;
 }

+/* Try to find pattern "a < b ? -1 : (a > b ? 1 : 0)" and convert it to
+   a conditional ternary set insn.  It commonly has following pattern.
+   cond_jump
+   setcc
+   (neg/subreg)
+   label: const_set
+   cond_jump and setcc use the same CC reg.  There may be a neg insn after
+   the setcc insn to negative the result of setcc, and a subreg insn after
+   the setcc insn to convert the mode.
+
+   The pattern can't be optimized by combine pass due to the branch and
+   limitation on the number of insns.
+*/
+
+static int
+noce_try_ternary_set (struct noce_if_info *if_info)
+{
+  machine_mode orig_mode = GET_MODE (if_info->x);
+  machine_mode mode;
+  int have_ternary_set = 0;
+
+  FOR_EACH_MODE_FROM (mode, orig_mode)
+{
+  if (direct_optab_handler (ternary_set_optab, mode) != CODE_FOR_nothing)
+   {
+ have_ternary_set = 1;
+ break;
+   }
+}
+
+  if (!have_ternary_set)
+return FALSE;
+
+  if (!if_info->then_bb || !if_info->else_bb)
+return FALSE;
+
+  if (!if_info->then_simple && !if_info->else_simple)
+return FALSE;
+
+  rtx cc;
+  basic_block target_bb;
+  int int1, int2, int3;
+
+  cc = SET_DEST (PATTERN (if_info->cond_earliest));
+  if (GET_MODE_CLASS (GET_MODE (cc)) != MODE_CC)
+return FALSE;
+
+  /* One arm should be a constant set.  */
+
+  if (CONST_INT_P (if_info->a))
+{
+  int1 = INTVAL (if_info->a);
+  target_bb = if_info->else_bb;
+}
+  else if (CONST_INT_P 

[Bug testsuite/105095] gcc.dg/vect/complex/fast-math-complex-* tests are not executed

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105095

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.4
  Known to work||11.3.1, 12.0
  Known to fail||11.3.0

[Bug c/104822] -Wscalar-storage-order warning for initialization from NULL seems useless

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104822

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Mine, I think this patch will fix the issue:
Which is similar to the check above dealing with named address spaces.

[Bug c/104822] -Wscalar-storage-order warning for initialization from NULL seems useless

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104822

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Mine, I think this patch will fix the issue:
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index f1a1752782a..43b9793e339 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -7480,6 +7480,7 @@ convert_for_assignment (location_t location, location_t
expr_loc, tree type,

   /* See if the pointers point to incompatible scalar storage orders.  */
   if (warn_scalar_storage_order
+ && !null_pointer_constant_p (rhs)
  && (AGGREGATE_TYPE_P (ttl) && TYPE_REVERSE_STORAGE_ORDER (ttl))
 != (AGGREGATE_TYPE_P (ttr) && TYPE_REVERSE_STORAGE_ORDER (ttr)))
{

[Bug tree-optimization/105043] Documentation for __builtin_object_size and other Object Size checking builtin functions should mention - D_FORTIFY_SOURCE

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|MOVED   |---
Summary|Please document |Documentation for
   |-D_FORTIFY_SOURCE   |__builtin_object_size and
   ||other Object Size checking
   ||builtin functions should
   ||mention - D_FORTIFY_SOURCE
   Severity|normal  |enhancement
 Status|RESOLVED|NEW

--- Comment #7 from Andrew Pinski  ---
I do think we should mention in the section about __builtin_object_size that
this used in connection with the -D_FORTIFY_SOURCE feature of some libc's.

That is on this page:
https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html#Object-Size-Checking

Mention that the libc feature -D_FORTIFY_SOURCE uses these builtins.
I am not 100% sure on the exact wording but that should give a hint to the user
of GCC to look into glibc/libc documentation for -D_FORTIFY_SOURCE.

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

2022-12-06 Thread pefy19950714 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108002

--- Comment #4 from Grant Li  ---
(In reply to Andrew Pinski from comment #3)
> #  pragma GCC optimize("-O2")
> 
> The bugs that related to this pragma were fixed in GCC 4.8.0 (a few were
> fixed before).
> There were many changes that helped fix it.
> You could always build a newer GCC yourself but with an over 10 year release
> is not going to be really supported.
> There is nothing GCC bug report can do to help you.
> 
> RHEL5 is just not supported.

Thanks! I will discuss it with my team, appreciate your prompt reply.

[Bug analyzer/108003] New: [13 Regression] ICE in bitmap_check_index, at sbitmap.h:105

2022-12-06 Thread asolokha at gmx dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108003

Bug ID: 108003
   Summary: [13 Regression] ICE in bitmap_check_index, at
sbitmap.h:105
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20221204 snapshot (g:24b9337d1f1b5197b6498dceb9074319be003449) ICEs
when compiling the following testcase, reduced from
libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/wchar_t/9875_seekoff.cc, w/
-O1 -fanalyzer --param analyzer-max-svalue-depth=5:

struct locale {
  class _Impl;
  _Impl *_M_impl;

  template 
  locale (const locale &, _Facet *);

  static locale
  classic ();
};

struct locale::_Impl {
  _Impl (_Impl, int);
};

template 
locale::locale (const locale &, _Facet *)
{
  new _Impl (*_M_impl, 1);
}

struct codecvt {
  virtual void do_max_lengththrow ();
};

void
test01 ()
{
  locale (locale::classic (), new codecvt);
}

% g++-13 -O1 -fanalyzer --param analyzer-max-svalue-depth=5 -c nsbergsz.cc
during IPA pass: analyzer
nsbergsz.cc: In constructor 'locale::locale(const locale&, _Facet*) [with
_Facet = codecvt]':
nsbergsz.cc:19:3: internal compiler error: in bitmap_check_index, at
sbitmap.h:105
   19 |   new _Impl (*_M_impl, 1);
  |   ^~~
0x8a6707 bitmap_check_index
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/sbitmap.h:105
0x8a6707 bitmap_set_bit
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/sbitmap.h:133
0x8a6707 ana::region_model::get_referenced_base_regions(auto_sbitmap&) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model.cc:4908
0x15b0692 ana::region_model::get_or_create_region_for_heap_alloc(ana::svalue
const*, ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model.cc:4879
0x15c1a49 ana::kf_operator_new::impl_call_pre(ana::call_details const&) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model-impl-calls.cc:996
0x15ac579 ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model.cc:1477
0x157b634 ana::feasibility_state::maybe_update_for_edge(ana::logger*,
ana::exploded_edge const*, ana::rejected_constraint**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/engine.cc:4832
0x21e7ef1 ana::epath_finder::process_worklist_item(ana::feasible_worklist*,
ana::trimmed_graph const&, ana::feasible_graph*, ana::exploded_node const*,
unsigned int, std::unique_ptr >*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:498
0x21e8848 ana::epath_finder::explore_feasible_paths(ana::exploded_node const*,
char const*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:418
0x21e8f31 ana::epath_finder::get_best_epath(ana::exploded_node const*, char
const*, unsigned int, std::unique_ptr >*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:164
0x21e905c ana::saved_diagnostic::calc_best_epath(ana::epath_finder*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:811
0x21ed7cf ana::dedupe_winners::add(ana::logger*, ana::epath_finder*,
ana::saved_diagnostic*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:1178
0x21ea5a3 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:1328
0x15878ec ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/engine.cc:6112
0x15888c6 ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/engine.cc:6186
0x15771e8 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/analyzer-pass.cc:87

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108002

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=50602,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=47011
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Andrew Pinski  ---
#  pragma GCC optimize("-O2")

The bugs that related to this pragma were fixed in GCC 4.8.0 (a few were fixed
before).
There were many changes that helped fix it.
You could always build a newer GCC yourself but with an over 10 year release is
not going to be really supported.
There is nothing GCC bug report can do to help you.

RHEL5 is just not supported.

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

2022-12-06 Thread pefy19950714 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108002

--- Comment #2 from Grant Li  ---
(In reply to Andrew Pinski from comment #1)
> 4.4.3 is over 12 years old now. Is there any way to move to something newer?

I already tried gcc 4.4.7 and 4.4.4... but also had same error.
We need to compatible gcc with our RHEL5 environment, so it is the reason why I
can't move to more higher gcc version.
Can I know is it a known issue or is it fixed on any higher gcc version?

Re: [PATCH v3, rs6000] Enable have_cbranchcc4 on rs6000

2022-12-06 Thread Kewen.Lin via Gcc-patches
Hi Haochen,

on 2022/12/6 13:44, HAO CHEN GUI wrote:
> Hi,
>   This patch enables "have_cbranchcc4" on rs6000 by defining
> a "cbranchcc4" expander. "have_cbrnachcc4" is a flag in ifcvt.cc
> to indicate if branch by CC bits is invalid or not. With this
> flag enabled, some branches can be optimized to conditional
> moves.
> 
>   The patch relies on the former patch which is under review.
> https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607810.html
> 
>   Bootstrapped and tested on powerpc64-linux BE and LE with no
> regressions. Is this okay for trunk? Any recommendations? Thanks
> a lot.
> 
> Thanks
> Gui Haochen
> 
> ChangeLog
> 2022-12-06  Haochen Gui 
> 
> gcc/
>   * config/rs6000/rs6000.md (cbranchcc4): New expander.
> 
> gcc/testsuite
>   * gcc.target/powerpc/cbranchcc4.c: New.
>   * gcc.target/powerpc/cbranchcc4-1.c: New.

Nit: "cbranchcc4.c" -> "cbranchcc4-2.c" since we already number the cases.

> 
> 
> patch.diff
> diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
> index e9e5cd1e54d..d7ddd96cc70 100644
> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -11932,6 +11932,16 @@ (define_expand "cbranch4"
>DONE;
>  })
> 
> +(define_expand "cbranchcc4"
> +  [(set (pc)
> + (if_then_else (match_operator 0 "branch_comparison_operator"
> + [(match_operand 1 "cc_reg_operand")
> +  (match_operand 2 "zero_constant")])
> +   (label_ref (match_operand 3))
> +   (pc)))]
> +  ""
> +  "")
> +
>  (define_expand "cstore4_signed"
>[(use (match_operator 1 "signed_comparison_operator"
>   [(match_operand:P 2 "gpc_reg_operand")
> diff --git a/gcc/testsuite/gcc.target/powerpc/cbranchcc4-1.c 
> b/gcc/testsuite/gcc.target/powerpc/cbranchcc4-1.c
> new file mode 100644
> index 000..3c8286bf091
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/cbranchcc4-1.c
> @@ -0,0 +1,17 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2" */
> +

Missing one " }", typo from copy/paste?

> +/* This case should be successfully compiled after cbranchcc4 is enabled.  It
> +   generates a "*cbranch_2insn" insn which makes predicate check of 
> cbranchcc4
> +   failed and returns a NULL rtx from prepare_cmp_insn.  */

Nit: May be shorter like "Verify there is no ICE with cbranchcc4 enabled." and 
put
the details into commit logs.

Does this issue which relies on the fix for generic part make bootstrapping 
fail?
If no, how many failures it can cause?  I'm thinking if we can commit this 
firstly,
then in the commit log of the fix for generic part you can mention it can fix 
the
ICE exposed by this test case.

BR,
Kewen


[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108002

--- Comment #1 from Andrew Pinski  ---
4.4.3 is over 12 years old now. Is there any way to move to something newer?

[Bug c/108002] New: Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

2022-12-06 Thread pefy19950714 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108002

Bug ID: 108002
   Summary: Throwing exception when compiling third-parties(ZSTD)
libraries with optimization option
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pefy19950714 at gmail dot com
  Target Milestone: ---

I got below exception when I was compiling zstd libraries with any g++
optimization options(O1, O2, O3, etc).
But, the compilation can be passed if I remove the optimization option.
-
.//src/extern/zstd/src/zstd.c: In function ‘ZSTD_bounds 
ZSTD_cParam_getBounds(ZSTD_cParameter)’:
.//src/extern/zstd/src/zstd.c:18062: internal compiler error: in tree_nrv, at
tree-nrv.c:143
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-

There are some required information for your reference with gcc -v.
We are using redhat-release-5Client-5.9.0.2.

-

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../gcc-4.4.3/configure --prefix=/mu/dev/gcc/4.4.3-rhel5-64
--with-local-prefix=/mu/mtsdk/corplib/gcc443-rhel5-64 --with-as=/mu/bin/gas
--with-ar=/mu/bin/gar --with-ld=/mu/bin/gld --with-nm=/mu/bin/gnm
--enable-bootstrap --enable-targets=x86_64,i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.3 (GCC)

-

The command we used to compile zstd lib:
g++ -O3 zstd.c -c -o zstd.o

-

ZSTD lib can be downloaded from here: 
https://github.com/facebook/zstd

-
Thanks for your help, and hope I can get the updates soon!

[Bug go/107992] m68k-linux-gnu bootstap error in gofrontend

2022-12-06 Thread ian at airs dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107992

--- Comment #1 from Ian Lance Taylor  ---
Thanks.  This is happening because the data structures that Go's garbage
collector uses require that all pointers be aligned on their natural
boundaries.  Unfortunately m68k only provides 2-byte alignment for 4-byte
pointers, not 4-byte alignment.  I don't know if there will be a simple fix. 
We could probably adjust the alignment for data structures defined in Go, which
would fix this case, but that wouldn't help with C interoperability.

[Bug c++/108001] New: unamed struct extension is documented for C++

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108001

Bug ID: 108001
   Summary: unamed struct extension is documented for C++
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Even though this extension is documented for C
(https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Unnamed-Fields.html) . The
documentation there does not even say it works for C++.
There are other interactions with standard C++ which is not mentioned, See PR
105059 for that even.

[Bug c++/18474] Unary plus/minus lvalueness not diagnosed in templates

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18474

--- Comment #2 from Andrew Pinski  ---
Note this is only invalid as n (if declared correctly) was not depedent so the
operator lookup would be bound at definition time.

That is the following needs to be accepted still:
template 
void g(void)
{
  T n;
  -n = 0;
  +n = 0;
}

[Bug target/106708] [rs6000] 64bit constant generation with oris xoris

2022-12-06 Thread guojiufu at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106708

--- Comment #1 from Jiu Fu Guo  ---
PR93178 also mentioned the "li,oris" case.

[Bug c++/105059] Inconsistency between paren- and brace-initialization of a union with anonymous struct

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105059

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|accepts-invalid |documentation
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-07

--- Comment #1 from Andrew Pinski  ---
With -pedantic:
:2:12: warning: ISO C++ prohibits anonymous structs [-Wpedantic]
2 | struct {
  |^


So I think this is just a documentation issue of what anonymous struct means
with each of the initializers.

Yes there is an inconsitancy with respect to () vs {} here though.

Confirmed.

Re: Naming flag for specifying the output file name for Binary Module Interface files

2022-12-06 Thread chuanqi.xcq via Gcc
Hi Nathan,
> 1) 'save' -- does it *cause* the bmi to be saved, or is that actually 
> controlled 
by other options? (I suspect the latter)
Yes, it causes the bmi to be saved. In fact, when we add `-save-temps` option 
in clang and we compile a module unit, we'll see the preprocessed output, the 
bmi, the LLVM IR and the assembly code. So the semantics of the option 
`-fsave-std-cxx-module-file=` is to save the bmi to the specified output.
> 2) 'std' -- why is this there. There's only one C++ std, with different 
variants thereof being temporally selectable.
Since in clang we have clang c++ modules extension. It is not std one. And we 
have objective C modules in clang too. So we said `std-cxx`.
> 3) 'cxx' -- why not 'c++'? Let's not let this transliteration of + to x get 
into the options -- it hasn't in '-std=c++20' for example.
`c++` should be good advice.
> Might I suggest something more like '-fmodule-output='? That collates nicely 
> with other -fmodule-$FOO options, and the 'output' part is similar to the 
> mnemonic '-o' for the regular output file naming.
My previous concern was there were tons of `-fmodule-*` options in clang, which 
are not standard c++ modules. So I was afraid the name `-fmodule-output` may be 
confusing.
So I proposed `-fsave-std-cxx-module-file=`. But I didn't recognize we need to 
keep the option consistency between gcc and clang until Iain mentioned it.
It is obviously redundant for gcc to keep the `-std-cxx` prefix in the name. 
Personally, I feel the clearity of the option name is more important than the 
length.
Since I think such flags will be mainly used by build systems/build scripts so 
such flags wouldn't be typed frequently.
But command line interface consistency is very important too. I know tools 
writer will hate to write tons of codes like:
```
if compiler == gcc
 ...
elif compiler == clang
 ...
```
So I think the conclusion may be:
(1) If gcc can tolerate the lengthy `-fsave-std-c++-module-file=` name, it 
would be best for clang.
(2) If (1) is not acceptable and we love to keep the command line consistency, 
I think clang can use '-fmodule-output=' as long as we make it clear in the 
document. It will be confusing but it may be the cost clang need to pay for the 
extension (so I'll vote against strongly if someone want to add some other 
extensions)
>  (Incidentally, as clang 
treats the BMI as a step in the compilation pipeline, what do you do if you 
just 
want compilation to produce the BMI and no assembly artifact? Does '-o' name 
the BMI in that case?)
In this case, we can use `--precompile` option in the command line. For 
example, we can compile HelloWorld in clang in the following command lines now:
```
$ clang++ -std=c++20 Hello.cppm --precompile -o Hello.pcm
$ clang++ -std=c++20 -fprebuilt-module-path=. Hello.pcm -c -o Hello.o
```
If you are interested, you can take a look at: 
https://clang.llvm.org/docs/StandardCPlusPlusModules.html#quick-start
Thanks,
Chuanqi
--
From:Nathan Sidwell 
Send Time:2022年12月7日(星期三) 08:35
To:David Blaikie ; gcc Mailing List ; Iain 
Sandoe ; chuanqi.xcq 
Subject:Re: Naming flag for specifying the output file name for Binary Module 
Interface files
On 12/6/22 16:03, David Blaikie wrote:
> Over in https://reviews.llvm.org/D137059 we're discussing the naming
> of a clang flag - would be good to have it be consistent with GCC.
> 
> The functionality is to name the BMI (.pcm in Clang's parlance) output
> file when compiling a C++20 module.
> 
> Current proposal is to use `-fsave-std-cxx-module-file=` which is
> certainly precise, but maybe a bit verbose. Clang has some other flags
> related to modules that skip the std/cxx parts, and are just
> `-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.
> 
> Do GCC folks have any veto votes (is the currently proposed name
> especially objectionable/wouldn't be acceptable in GCC) or preferences
> (suggestions to add to the pool)?
I think the suggested option name is problematic for a number of additional 
reasons:
1) 'save' -- does it *cause* the bmi to be saved, or is that actually 
controlled 
by other options? (I suspect the latter)
2) 'std' -- why is this there. There's only one C++ std, with different 
variants thereof being temporally selectable.
3) 'cxx' -- why not 'c++'? Let's not let this transliteration of + to x get 
into the options -- it hasn't in '-std=c++20' for example.
Might I suggest something more like '-fmodule-output='? That collates nicely 
with other -fmodule-$FOO options, and the 'output' part is similar to the 
mnemonic '-o' for the regular output file naming. (Incidentally, as clang 
treats the BMI as a step in the compilation pipeline, what do you do if you 
just 
want compilation to produce the BMI and no assembly artifact? Does '-o' name 
the BMI in that case?)
nathan
-- 
Nathan Sidwell


[Bug middle-end/104975] ICE in execute, at gimple-harden-conditionals.cc:577 and returns_twice and pure attributes on the same function

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104975

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/105049] [12 Regression] ICE: in build_vector_from_val, at tree.cc:2119 with -O -fno-tree-forwprop

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105049

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|ICE: in |[12 Regression] ICE: in
   |build_vector_from_val, at   |build_vector_from_val, at
   |tree.cc:2119 with -O|tree.cc:2119 with -O
   |-fno-tree-forwprop  |-fno-tree-forwprop

Re: [PATCH] Fix aarch64 PR 99657: ICE with SVE types used without an error

2022-12-06 Thread Kewen.Lin via Gcc-patches
Hi,

In the recent discussion on how to make some built-in type only valid for
some target features efficiently[1], Andrew mentioned this patch which he
made previously (Thanks!).  I confirmed it can help rs6000 related issue,
and noticed PR99657 is still opened, so I think we still want this to
be reviewed.

Could some C/C++ FE experts help to review it?

Thanks in advance!

BR,
Kewen

[1] https://gcc.gnu.org/pipermail/gcc/2022-December/240220.html

on 2021/11/9 18:09, apinski--- via Gcc-patches wrote:
> From: Andrew Pinski 
> 
> This fixes fully where SVE types were being used without sve being enabled.
> Instead of trying to fix it such that we error out during RTL time, it is
> better to error out in front-ends.  This expands verify_type_context to
> have a context of auto storage decl which is used for both auto storage
> decls and for indirection context.
> 
> A few testcases needed to be updated for the new error message; they were
> already being rejected before hand.
> 
> OK? Bootstrapped and tested on aarch64-linux-gnu with no regressions.
> 
> PR target/99657
> gcc/c/ChangeLog:
> 
>   * c-decl.c (finish_decl): Call verify_type_context
>   for all decls and not just global_decls.
>   * c-typeck.c (build_indirect_ref): Call verify_type_context
>   to check to see if the type is ok to be used.
> 
> gcc/ChangeLog:
> 
>   * config/aarch64/aarch64-sve-builtins.cc (verify_type_context):
>   Add TXTC_AUTO_STORAGE support
>   * target.h (enum type_context_kind): Add TXTC_AUTO_STORAGE.
> 
> gcc/cp/ChangeLog:
> 
>   * decl.c (cp_finish_decl): Call verify_type_context
>   for all decls and not just global_decls.
>   * typeck.c (cp_build_indirect_ref_1): Call verify_type_context
>   to check to see if the type is ok to be used.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gcc.target/aarch64/sve/acle/general/nosve_1.c: Update test.
>   * gcc.target/aarch64/sve/acle/general/nosve_4.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general/nosve_5.c: Likewise.
>   * gcc.target/aarch64/sve/acle/general/nosve_6.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/nosve_2.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/nosve_3.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/nosve_4.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/nosve_5.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/nosve_6.c: Likewise.
>   * gcc.target/aarch64/sve/pcs/nosve_9.c: New test.
> ---
>  gcc/c/c-decl.c| 14 +++---
>  gcc/c/c-typeck.c  |  2 ++
>  gcc/config/aarch64/aarch64-sve-builtins.cc| 14 ++
>  gcc/cp/decl.c | 10 ++
>  gcc/cp/typeck.c   |  4 
>  gcc/target.h  |  3 +++
>  .../gcc.target/aarch64/sve/acle/general/nosve_1.c |  1 +
>  .../gcc.target/aarch64/sve/acle/general/nosve_4.c |  2 +-
>  .../gcc.target/aarch64/sve/acle/general/nosve_5.c |  2 +-
>  .../gcc.target/aarch64/sve/acle/general/nosve_6.c |  1 +
>  .../gcc.target/aarch64/sve/pcs/nosve_2.c  |  2 +-
>  .../gcc.target/aarch64/sve/pcs/nosve_3.c  |  2 +-
>  .../gcc.target/aarch64/sve/pcs/nosve_4.c  |  3 +--
>  .../gcc.target/aarch64/sve/pcs/nosve_5.c  |  3 +--
>  .../gcc.target/aarch64/sve/pcs/nosve_6.c  |  3 +--
>  .../gcc.target/aarch64/sve/pcs/nosve_9.c  | 15 +++
>  16 files changed, 60 insertions(+), 21 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pcs/nosve_9.c
> 
> diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
> index 186fa1692c1..b3583622475 100644
> --- a/gcc/c/c-decl.c
> +++ b/gcc/c/c-decl.c
> @@ -5441,19 +5441,19 @@ finish_decl (tree decl, location_t init_loc, tree 
> init,
>  
>if (VAR_P (decl))
>  {
> +  type_context_kind context = TCTX_AUTO_STORAGE;
>if (init && TREE_CODE (init) == CONSTRUCTOR)
>   add_flexible_array_elts_to_size (decl, init);
>  
>complete_flexible_array_elts (DECL_INITIAL (decl));
>  
>if (is_global_var (decl))
> - {
> -   type_context_kind context = (DECL_THREAD_LOCAL_P (decl)
> -? TCTX_THREAD_STORAGE
> -: TCTX_STATIC_STORAGE);
> -   if (!verify_type_context (input_location, context, TREE_TYPE (decl)))
> - TREE_TYPE (decl) = error_mark_node;
> - }
> + context = (DECL_THREAD_LOCAL_P (decl)
> +? TCTX_THREAD_STORAGE
> +: TCTX_STATIC_STORAGE);
> +
> +  if (!verify_type_context (input_location, context, TREE_TYPE (decl)))
> + TREE_TYPE (decl) = error_mark_node;
>  
>if (DECL_SIZE (decl) == NULL_TREE && TREE_TYPE (decl) != 
> error_mark_node
> && COMPLETE_TYPE_P (TREE_TYPE (decl)))
> diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c
> index 782414f8c8c..e926b7c1964 100644
> --- a/gcc/c/c-typeck.c
> +++ 

[Bug target/103302] wrong code with -fharden-compares

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103302

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

--- Comment #18 from Andrew Pinski  ---
(In reply to Alexandre Oliva from comment #17)
> The patch went in on 2022-03-02, commit
> 12f8dc0b642db5edc702f252af1a5231606b29db, but I failed to tag this PR in the
> commit message.

r12-7453-g12f8dc0b642db5edc702f

[Bug c++/105047] invalid non-dependent call to non-static member of the current instantiation not rejected ahead of time

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105047

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-07
   Keywords||diagnostic
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. Note clang only rejects the call in g.
MSVC acts like GCC here.

Re: Naming flag for specifying the output file name for Binary Module Interface files

2022-12-06 Thread Jonathan Wakely via Gcc
On Wed, 7 Dec 2022, 00:36 Nathan Sidwell via Gcc,  wrote:

> On 12/6/22 16:03, David Blaikie wrote:
> > Over in https://reviews.llvm.org/D137059 we're discussing the naming
> > of a clang flag - would be good to have it be consistent with GCC.
> >
> > The functionality is to name the BMI (.pcm in Clang's parlance) output
> > file when compiling a C++20 module.
> >
> > Current proposal is to use `-fsave-std-cxx-module-file=` which is
> > certainly precise, but maybe a bit verbose. Clang has some other flags
> > related to modules that skip the std/cxx parts, and are just
> > `-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.
> >
> > Do GCC folks have any veto votes (is the currently proposed name
> > especially objectionable/wouldn't be acceptable in GCC) or preferences
> > (suggestions to add to the pool)?
>
> I think the suggested option name is problematic for a number of
> additional reasons:
>
> 1) 'save' -- does it *cause* the bmi to be saved, or is that actually
> controlled
> by other options?  (I suspect the latter)
>
> 2) 'std' -- why is this there.  There's only one C++ std, with different
> variants thereof being temporally selectable.
>
> 3) 'cxx' -- why not 'c++'?  Let's not let this transliteration of + to x
> get
> into the options -- it hasn't in '-std=c++20' for example.
>
> Might I suggest something more like '-fmodule-output='?  That collates
> nicely
> with other -fmodule-$FOO options, and the 'output' part is similar to the
> mnemonic '-o' for the regular output file naming.
>

That's also much shorter and easier to remember than the five(!) words in
the original suggestion.


[PATCH] doc: Correct a clerical error in the document.

2022-12-06 Thread Lulu Cheng
gcc/ChangeLog:

* doc/rtl.texi: Correct a clerical error in the document.
---
 gcc/doc/rtl.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/doc/rtl.texi b/gcc/doc/rtl.texi
index 43c9ee8bffe..44858d12892 100644
--- a/gcc/doc/rtl.texi
+++ b/gcc/doc/rtl.texi
@@ -2142,7 +2142,7 @@ stores the lower 2 bytes of @var{y} in @var{x} and 
discards the upper
 (set @var{z} (subreg:SI (reg:HI @var{x}) 0))
 @end smallexample
 
-would set the lower two bytes of @var{z} to @var{y} and set the upper
+would set the lower two bytes of @var{z} to @var{x} and set the upper
 two bytes to an unknown value assuming @code{SUBREG_PROMOTED_VAR_P} is
 false.
 
-- 
2.31.1



[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

2022-12-06 Thread caiyinyu at loongson dot cn via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967

--- Comment #10 from caiyinyu  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 54029 [details]
> gcc13-pr107967.patch
> 
> Untested fix.  Deferring the mode_composite stuff for later.

There are still some fails and errors are almost all about "Exception "Divide
by zero" not set".

cat math/test-float64-lgamma.out:
testing _Float64 (without inline functions)
Failure: lgamma (-3): Exception "Divide by zero" not set
Failure: lgamma_downward (-3): Exception "Divide by zero" not set
Failure: lgamma_towardzero (-3): Exception "Divide by zero" not set
Failure: lgamma_upward (-3): Exception "Divide by zero" not set

Test suite completed:
  7880 test cases plus 5260 tests for exception flags and
5260 tests for errno executed.
  4 errors occurred.


FAIL: math/test-double-lgamma
FAIL: math/test-double-log1p
FAIL: math/test-float-lgamma
FAIL: math/test-float-log1p
FAIL: math/test-float128-catan
FAIL: math/test-float128-catanh
FAIL: math/test-float128-lgamma
FAIL: math/test-float128-log
FAIL: math/test-float128-log1p
FAIL: math/test-float128-y0
FAIL: math/test-float128-y1
FAIL: math/test-float32-lgamma
FAIL: math/test-float32-log1p
FAIL: math/test-float32x-lgamma
FAIL: math/test-float32x-log1p
FAIL: math/test-float64-lgamma
FAIL: math/test-float64-log1p
FAIL: math/test-float64x-lgamma
FAIL: math/test-ldouble-lgamma

RE: [EXTERNAL] Re: [PATCH] Fix count comparison in ipa-cp

2022-12-06 Thread Eugene Rozenfeld via Gcc-patches
I initially ran into this while reviving autoprofiledbootstrap build.

I was able to create a simple reliable test for this bug and captured it in 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000

I also included the test case in the updated patch below.

Eugene

=

The existing comparison was incorrect for non-PRECISE counts
(e.g., AFDO): we could end up with a 0 base_count, which could
lead to asserts, e.g., in good_cloning_opportunity_p.

Tested on x86_64-pc-linux-gnu.

gcc/ChangeLog:
PR ipa/108000
* ipa-cp.cc (ipcp_propagate_stage): Fix profile count comparison

gcc/testsuite
* gcc.dg/tree-prof/pr108000.c: Regression test
---
 gcc/ipa-cp.cc |  2 +-
 gcc/testsuite/gcc.dg/tree-prof/pr108000.c | 93 +++
 2 files changed, 94 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-prof/pr108000.c

diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index d5230c7c5e6..cc031ebed0f 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -4225,7 +4225,7 @@ ipcp_propagate_stage (class ipa_topo_info *topo)
for (cgraph_edge *cs = node->callees; cs; cs = cs->next_callee)
  {
profile_count count = cs->count.ipa ();
-   if (!(count > profile_count::zero ()))
+   if (!count.nonzero_p ())
  continue;
 
enum availability avail;
diff --git a/gcc/testsuite/gcc.dg/tree-prof/pr108000.c 
b/gcc/testsuite/gcc.dg/tree-prof/pr108000.c
new file mode 100644
index 000..c59ea799748
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-prof/pr108000.c
@@ -0,0 +1,93 @@
+/* { dg-options "-O2" } */
+
+#include 
+
+volatile int flag;
+const int array_size = 10;
+int* array;
+int iterations = 1000;
+
+#define BAR(num) \
+int __attribute__((noinline)) \
+bar##num (int i, int j) \
+{ \
+  if (i == 0) \
+return 2*num - 1; \
+  else \
+return 2*num; \
+}
+
+BAR(1)
+BAR(2)
+BAR(3)
+BAR(4)
+BAR(5)
+BAR(6)
+BAR(7)
+BAR(8)
+BAR(9)
+BAR(10)
+BAR(11)
+BAR(12)
+BAR(13)
+BAR(14)
+BAR(15)
+BAR(16)
+BAR(17)
+BAR(18)
+BAR(19)
+
+int __attribute__((noinline))
+foo ()
+{
+  switch (flag)
+  {
+   case 1:
+   return bar1 (0, 0);
+   case 2:
+   return bar2 (0, 0);
+   case 3:
+   return bar3 (0, 0);
+   case 4:
+   return bar4 (0, 0);
+   case 5:
+   return bar5 (0, 0);
+   case 6:
+   return bar6 (0, 0);
+   case 7:
+   return bar7 (0, 0);
+   case 8:
+   return bar8 (0, 0);
+   case 9:
+   return bar9 (0, 0);
+   case 10:
+   return bar10 (0, 0);
+   case 11:
+   return bar11 (0, 0);
+   case 12:
+   return bar12 (0, 0);
+   case 13:
+   return bar13 (0, 0);
+   case 14:
+   return bar14 (0, 0);
+   case 15:
+   return bar15 (0, 0);
+   case 16:
+   return bar16 (0, 0);
+   case 17:
+   return bar17 (0, 0);
+   case 18:
+   return bar18 (0, 0);
+   default:
+   return bar19(0, 0);
+  }
+}
+
+int
+main ()
+{
+  flag = 0;
+  array = calloc(array_size, sizeof(int));
+  for (int i = 0, j = 0; i < iterations; ++i, j = (j + 1) % 10)
+array[j] = foo ();
+}
-- 
2.25.1

-Original Message-
From: Jeff Law  
Sent: Tuesday, November 22, 2022 12:03 PM
To: Eugene Rozenfeld ; gcc-patches@gcc.gnu.org
Subject: [EXTERNAL] Re: [PATCH] Fix count comparison in ipa-cp

[You don't often get email from jeffreya...@gmail.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

On 11/21/22 14:26, Eugene Rozenfeld via Gcc-patches wrote:
> The existing comparison was incorrect for non-PRECISE counts (e.g., 
> AFDO): we could end up with a 0 base_count, which could lead to 
> asserts, e.g., in good_cloning_opportunity_p.
>
> gcc/ChangeLog:
>
>  * ipa-cp.cc (ipcp_propagate_stage): Fix profile count comparison.

OK.  Probably somewhat painful to pull together a reliable test for this, right?


Jeff




[Bug target/107970] [13 Regression] ICE in extract_insn, at recog.cc:2791 since r13-2730-gd0c73b6c85677e67

2022-12-06 Thread crazylht at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107970

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #3 from Hongtao.liu  ---
Fixed in GCC13.

[Bug target/107970] [13 Regression] ICE in extract_insn, at recog.cc:2791 since r13-2730-gd0c73b6c85677e67

2022-12-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107970

--- Comment #2 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r13-4532-gda7fb32d403759daefefc79dc251d2437c1b638c
Author: liuhongt 
Date:   Tue Dec 6 13:21:04 2022 +0800

Fix ICE due to condition mismatch between expander and define_insn.

ice.i:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 7 6 8 2 (set (reg:V2SF 84 [ vect__3.8 ])
(unspec:V2SF [
(reg:V2SF 86 [ vect__1.7 ])
(const_int 11 [0xb])
] UNSPEC_ROUND)) "ice.i":5:14 -1
 (nil))
during RTL pass: vregs

gcc/ChangeLog:

PR target/107970
* config/i386/mmx.md (btruncv2sf2): Add TARGET_MMX_WITH_SSE to
the condition.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr107970.c: New test.

[Bug c++/105050] error: expression '' is not a constant expression

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105050

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/105050] error: expression '' is not a constant expression

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105050

--- Comment #7 from Andrew Pinski  ---
I think clang still gives a better error message here though:
:43:15: error: static assertion expression is not an integral constant
expression
static_assert(test_swap());
  ^~~
:18:17: note: non-constexpr function '_M_swap_val' cannot be used in a
constant expression
  this->_M_swap_val(__x);
^
:38:6: note: in call to '>swap(e2)'
  e1.swap(e2);
 ^
:43:15: note: in call to 'test_swap()'
static_assert(test_swap());
  ^
:4:10: note: declared here
void _M_swap_val(expected&) { }
 ^

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

2022-12-06 Thread erozen at microsoft dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000

--- Comment #2 from Eugene Rozenfeld  ---
I actually have a fix for this, just wanted to file a simple test case. I
initially ran into this failure while reviving autoprofiledbootstrap build. The
failure happens while using the profile and the bug is an incorrect count
comparison. 

Here is the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606935.html

I will add this test to the patch before submitting it.

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-07
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000

--- Comment #1 from Andrew Pinski  ---
Can you provide the exact command lines being used and does it fail during
while using the profile or before?

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

2022-12-06 Thread joseph at codesourcery dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107980

--- Comment #12 from joseph at codesourcery dot com  ---
The standard rule about not using extra arguments means that any warnings 
would need to avoid even converting those arguments from pp-tokens to 
tokens; it's OK for them to contain pp-tokens that cannot be converted to 
tokens.

I think the accepted change to the standard was entirely clear about 
ignoring the extra arguments; it wasn't some obscure non-obvious 
consequence that such code would become valid.

[Bug ipa/108000] New: Assert during ipa-cp with AutoFDO

2022-12-06 Thread erozen at microsoft dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000

Bug ID: 108000
   Summary: Assert during ipa-cp with AutoFDO
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erozen at microsoft dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The test case below fails with

during IPA pass: cp
/home/erozen/gcc4/gcc/testsuite/gcc.dg/tree-prof/pr1.c:93:1: internal
compiler error: in good_cloning_opportunity_p, at ipa-cp.cc:3545
0x1d7ee83 good_cloning_opportunity_p
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:3545
0x1d7fa66 estimate_local_effects
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:3752
0x1d8098d propagate_constants_topo
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:4080
0x1d80fa5 ipcp_propagate_stage
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:4267
0x1d86fc5 ipcp_driver
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:6574
0x1d87192 execute
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:6651

#include 

volatile int flag;
const int array_size = 10;
int* array;
int iterations = 1000;

#define BAR(num) \
int __attribute__((noinline)) \
bar##num (int i, int j) \
{ \
  if (i == 0) \
return 2*num - 1; \
  else \
return 2*num; \
}

BAR(1)
BAR(2)
BAR(3)
BAR(4)
BAR(5)
BAR(6)
BAR(7)
BAR(8)
BAR(9)
BAR(10)
BAR(11)
BAR(12)
BAR(13)
BAR(14)
BAR(15)
BAR(16)
BAR(17)
BAR(18)
BAR(19)

int __attribute__((noinline))
foo ()
{
  switch (flag)
  {
case 1:
return bar1 (0, 0);
case 2:
return bar2 (0, 0);
case 3:
return bar3 (0, 0);
case 4:
return bar4 (0, 0);
case 5:
return bar5 (0, 0);
case 6:
return bar6 (0, 0);
case 7:
return bar7 (0, 0);
case 8:
return bar8 (0, 0);
case 9:
return bar9 (0, 0);
case 10:
return bar10 (0, 0);
case 11:
return bar11 (0, 0);
case 12:
return bar12 (0, 0);
case 13:
return bar13 (0, 0);
case 14:
return bar14 (0, 0);
case 15:
return bar15 (0, 0);
case 16:
return bar16 (0, 0);
case 17:
return bar17 (0, 0);
case 18:
return bar18 (0, 0);
default:
return bar19(0, 0);
  }
}

int
main ()
{
  flag = 0;
  array = calloc(array_size, sizeof(int));
  for (int i = 0, j = 0; i < iterations; ++i, j = (j + 1) % 10)
array[j] = foo ();
}

[Bug testsuite/107999] [13 Regression] test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|test-error-array-bounds.c   |[13 Regression]
   |now fails because   |test-error-array-bounds.c
   |[-Warray-bounds] was|now fails because
   |updated to  |[-Warray-bounds] was
   |[-Warray-bounds=] in error  |updated to
   |messages|[-Warray-bounds=] in error
   ||messages after
   ||r13-4410-g7c01d029fca669263
   ||b9c2

Re: AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

2022-12-06 Thread Pop, Sebastian via Gcc-patches
Thanks Richard for your review and for pointing out the issue with BTI.


The current patch removes the existing BTI instruction,

and then adds the BTI hint when expanding the patchable_area pseudo.


The attached patch passed bootstrap and regression test on arm64-linux.

Ok to commit to gcc trunk?


Thank you,
Sebastian


From: Richard Sandiford 
Sent: Monday, December 5, 2022 5:34:40 AM
To: Pop, Sebastian
Cc: gcc-patches@gcc.gnu.org; seb...@gmail.com; Kyrylo Tkachov
Subject: RE: [EXTERNAL]AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



"Pop, Sebastian"  writes:
> Hi,
>
> Currently patchable area is at the wrong place on AArch64.  It is placed
> immediately after function label, before .cfi_startproc.  This patch
> adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
> modifies aarch64_print_patchable_function_entry to avoid placing
> patchable area before .cfi_startproc.
>
> The patch passed bootstrap and regression test on aarch64-linux.
> Ok to commit to trunk and backport to active release branches?

Looks good, but doesn't the problem described in the PR then still
apply to the BTI emitted by:

  if (cfun->machine->label_is_assembled
  && aarch64_bti_enabled ()
  && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
{
  /* Remove the BTI that follows the patch area and insert a new BTI
 before the patch area right after the function label.  */
  rtx_insn *insn = next_real_nondebug_insn (get_insns ());
  if (insn
  && INSN_P (insn)
  && GET_CODE (PATTERN (insn)) == UNSPEC_VOLATILE
  && XINT (PATTERN (insn), 1) == UNSPECV_BTI_C)
delete_insn (insn);
  asm_fprintf (file, "\thint\t34 // bti c\n");
}

?  It seems like the BTI will be before the cfi_startproc and the
patchable entry afterwards.

I guess we should keep the BTI instruction as-is (rather than printing
a .hint) and emit the new UNSPECV_PATCHABLE_AREA after the BTI rather
than before it.

Thanks,
Richard

> Thanks,
> Sebastian
>
> gcc/
> PR target/93492
> * config/aarch64/aarch64-protos.h (aarch64_output_patchable_area):
> Declared.
> * config/aarch64/aarch64.cc (aarch64_print_patchable_function_entry):
> Emit an UNSPECV_PATCHABLE_AREA pseudo instruction.
> (aarch64_output_patchable_area): New.
> * config/aarch64/aarch64.md (UNSPECV_PATCHABLE_AREA): New.
> (patchable_area): Define.
>
> gcc/testsuite/
> PR target/93492
> * gcc.target/aarch64/pr98776.c: New.
>
>
> From b9cf87bcdf65f515b38f1851eb95c18aaa180253 Mon Sep 17 00:00:00 2001
> From: Sebastian Pop 
> Date: Wed, 30 Nov 2022 19:45:24 +
> Subject: [PATCH] AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776]
>
> Currently patchable area is at the wrong place on AArch64.  It is placed
> immediately after function label, before .cfi_startproc.  This patch
> adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
> modifies aarch64_print_patchable_function_entry to avoid placing
> patchable area before .cfi_startproc.
>
> gcc/
>   PR target/93492
>   * config/aarch64/aarch64-protos.h (aarch64_output_patchable_area):
>   Declared.
>   * config/aarch64/aarch64.cc (aarch64_print_patchable_function_entry):
>   Emit an UNSPECV_PATCHABLE_AREA pseudo instruction.
>   (aarch64_output_patchable_area): New.
>   * config/aarch64/aarch64.md (UNSPECV_PATCHABLE_AREA): New.
>   (patchable_area): Define.
>
> gcc/testsuite/
>   PR target/93492
>   * gcc.target/aarch64/pr98776.c: New.
> ---
>  gcc/config/aarch64/aarch64-protos.h|  2 ++
>  gcc/config/aarch64/aarch64.cc  | 24 +-
>  gcc/config/aarch64/aarch64.md  | 14 +
>  gcc/testsuite/gcc.target/aarch64/pr98776.c | 11 ++
>  4 files changed, 50 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/aarch64/pr98776.c
>
> diff --git a/gcc/config/aarch64/aarch64-protos.h 
> b/gcc/config/aarch64/aarch64-protos.h
> index 4be93c93c26..2fba24d947d 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -1074,4 +1074,6 @@ const char *aarch64_indirect_call_asm (rtx);
>  extern bool aarch64_harden_sls_retbr_p (void);
>  extern bool aarch64_harden_sls_blr_p (void);
>
> +extern void aarch64_output_patchable_area (unsigned int, bool);
> +
>  #endif /* GCC_AARCH64_PROTOS_H */
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index e97f3b32f7c..e84b33b958c 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -22684,7 +22684,29 @@ aarch64_print_patchable_function_entry (FILE *file,
>asm_fprintf (file, "\thint\t34 // bti c\n");
>  }
>
> -  

[Bug jit/107770] Comparison of vectors of float doesn't work

2022-12-06 Thread bouanto at zoho dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107770

Antoni  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Antoni  ---
Fixed by commit d2e782cb99c3116c389d6a9565678c4ffe26.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

2022-12-06 Thread joseph at codesourcery dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107954

--- Comment #3 from joseph at codesourcery dot com  ---
Editorial review before the CD ballot slipped the schedule.  Second-round 
editorial review after a huge number of changes in the editorial review 
slipped the schedule.  Getting a final draft with all the changes into the 
CD ballot process slipped the schedule.  The January meeting is two weeks 
later than originally planned because of the schedule delays.  I just sent 
206 comments on the CD to BSI for submission to ISO as the UK comments and 
if other NBs have similar numbers of comments, (a) it wouldn't surprise me 
if there's difficulty in getting through all of them in a single week's 
meeting (even if we find a way not to need to discuss all the editorial 
comments individually in the meeting) and (b) there could easily be 
further delays getting all the changes into the working draft and reviewed 
for being correctly applied.  So despite the 56-day "ISO editing" period 
on the schedule before the DIS ballot (which may be meant to deal with all 
the editorial issues ISO comes up with at the last minute), it's entirely 
plausible there could be schedule slip for the DIS ballot - even supposing 
we don't need any extra ballot stages (CD2 or FDIS).

So while it's possible that the new standard will be published in 2023 - 
or with a __STDC_VERSION__ value from 2023 even if published in 2024 - 
there is plenty of scope for the schedule to slip given the amount of work 
that still needs to be done on the draft.

[Bug jit/107999] New: test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages

2022-12-06 Thread bouanto at zoho dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999

Bug ID: 107999
   Summary: test-error-array-bounds.c now fails because
[-Warray-bounds] was updated to [-Warray-bounds=] in
error messages
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

The error message needs to be updated to make this test pass again.

[Bug jit/107770] Comparison of vectors of float doesn't work

2022-12-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107770

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Antoni Boucher :

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

commit r13-4531-gd2e782cb99c3116c389d6a9565678c4ffe26
Author: Antoni Boucher 
Date:   Sun Nov 20 10:22:53 2022 -0500

libgccjit: Fix float vector comparison

Fix float vector comparison and add comparison tests to include float and
vectors.

gcc/testsuite:
PR jit/107770
* jit.dg/harness.h: Add new macro to to perform vector
comparisons
* jit.dg/test-expressions.c: Extend comparison tests to add float
types and vectors

gcc/jit:
PR jit/107770
* jit-playback.cc: Fix vector float comparison
* jit-playback.h: Update comparison function signature
* jit-recording.cc: Update call for "new_comparison" function
* jit-recording.h: Fix vector float comparison

Co-authored-by: Guillaume Gomez 
Signed-off-by: Guillaume Gomez 

Re: Naming flag for specifying the output file name for Binary Module Interface files

2022-12-06 Thread Nathan Sidwell via Gcc

On 12/6/22 16:03, David Blaikie wrote:

Over in https://reviews.llvm.org/D137059 we're discussing the naming
of a clang flag - would be good to have it be consistent with GCC.

The functionality is to name the BMI (.pcm in Clang's parlance) output
file when compiling a C++20 module.

Current proposal is to use `-fsave-std-cxx-module-file=` which is
certainly precise, but maybe a bit verbose. Clang has some other flags
related to modules that skip the std/cxx parts, and are just
`-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.

Do GCC folks have any veto votes (is the currently proposed name
especially objectionable/wouldn't be acceptable in GCC) or preferences
(suggestions to add to the pool)?


I think the suggested option name is problematic for a number of additional 
reasons:

1) 'save' -- does it *cause* the bmi to be saved, or is that actually controlled 
by other options?  (I suspect the latter)


2) 'std' -- why is this there.  There's only one C++ std, with different 
variants thereof being temporally selectable.


3) 'cxx' -- why not 'c++'?  Let's not let this transliteration of + to x get 
into the options -- it hasn't in '-std=c++20' for example.


Might I suggest something more like '-fmodule-output='?  That collates nicely 
with other -fmodule-$FOO options, and the 'output' part is similar to the 
mnemonic '-o' for the regular output file naming.  (Incidentally, as clang 
treats the BMI as a step in the compilation pipeline, what do you do if you just 
want compilation to produce the BMI and no assembly artifact?  Does '-o' name 
the BMI in that case?)


nathan

--
Nathan Sidwell



[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result

2022-12-06 Thread nikolasklauser at berlin dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611

--- Comment #6 from Nikolas Klauser  ---
Is there any update on this?

[Bug tree-optimization/107997] [13 Regression] fd8dd6c03849691 probably uncovered an issue building the Linux kernel

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|regression  |tree-optimization
Summary|fd8dd6c03849691 probably|[13 Regression]
   |uncovered an issue building |fd8dd6c03849691 probably
   |the Linux kernel|uncovered an issue building
   ||the Linux kernel
   Target Milestone|--- |13.0
 Target||powerpc64-linux

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

2022-12-06 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
  Component|bootstrap   |target
 CC||clyon at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64
MULTILIB_OSDIRNAMES = ../lib ../lib32

Hmmm, the fix is obviously just add 32 to MULTILIB_DIRNAMES .

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606887.html

[Bug c++/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

2022-12-06 Thread mckelvey at maskull dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998

--- Comment #2 from James McKelvey  ---
Configured with:

./configure --enable-languages=c,c++ --enable-threads=posix

[Bug analyzer/107882] [13 Regression] ICE in get_last_bit_offset, at analyzer/store.h:255 since 13-2582-g0ea5e3f4542832b8

2022-12-06 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107882

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above patch.

[Bug c++/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

2022-12-06 Thread mckelvey at maskull dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998

--- Comment #1 from James McKelvey  ---
Created attachment 54032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54032=edit
Config log

[committed] analyzer: don't create bindings or binding keys for empty regions [PR107882]

2022-12-06 Thread David Malcolm via Gcc-patches
PR analyzer/107882 reports an ICE, due to trying to get a compound svalue
for this binding:

  cluster for: a:
key:   {bytes 0-3}
value:  {UNKNOWN()}
key:   {empty}
value:  {UNKNOWN()}
key:   {bytes 4-7}
value:  {UNKNOWN()}

where there's an binding to the unknown value of zero bits in size
"somewhere" within "a" (perhaps between bits 3 and 4?)

This makes no sense, so this patch adds an assertion that we never
attempt to create a binding key for an empty region, and adds early
rejection of attempts to get or set the values of such regions, fixing
the ICE.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-4529-gdfe2ef7f2b6cac.

gcc/analyzer/ChangeLog:
PR analyzer/107882
* region-model.cc (region_model::get_store_value): Return an
unknown value for empty regions.
(region_model::set_value): Bail on empty regions.
* region.cc (region::empty_p): New.
* region.h (region::empty_p): New decl.
* state-purge.cc (same_binding_p): Bail if either region is empty.
* store.cc (binding_key::make): Assert that a concrete binding's
bit_size must be > 0.
(binding_cluster::mark_region_as_unknown): Bail on empty regions.
(binding_cluster::get_binding): Likewise.
(binding_cluster::remove_overlapping_bindings): Likewise.
(binding_cluster::on_unknown_fncall): Don't conjure values for
empty regions.
(store::fill_region): Bail on empty regions.
* store.h (class concrete_binding): Update comment to reflect that
the range of bits must be non-empty.
(concrete_binding::concrete_binding): Assert that bit range is
non-empty.

gcc/testsuite/ChangeLog:
PR analyzer/107882
* gcc.dg/analyzer/memcpy-pr107882.c: New test.

Signed-off-by: David Malcolm 
---
 gcc/analyzer/region-model.cc  |  8 +
 gcc/analyzer/region.cc| 12 
 gcc/analyzer/region.h |  2 ++
 gcc/analyzer/state-purge.cc   |  4 +++
 gcc/analyzer/store.cc | 30 +++
 gcc/analyzer/store.h  |  8 +++--
 .../gcc.dg/analyzer/memcpy-pr107882.c |  8 +
 7 files changed, 63 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/analyzer/memcpy-pr107882.c

diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index 430c0e91175..18eaf22a5d1 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -2321,6 +2321,10 @@ const svalue *
 region_model::get_store_value (const region *reg,
   region_model_context *ctxt) const
 {
+  /* Getting the value of an empty region gives an unknown_svalue.  */
+  if (reg->empty_p ())
+return m_mgr->get_or_create_unknown_svalue (reg->get_type ());
+
   check_region_for_read (reg, ctxt);
 
   /* Special-case: handle var_decls in the constant pool.  */
@@ -3159,6 +3163,10 @@ region_model::set_value (const region *lhs_reg, const 
svalue *rhs_sval,
   gcc_assert (lhs_reg);
   gcc_assert (rhs_sval);
 
+  /* Setting the value of an empty region is a no-op.  */
+  if (lhs_reg->empty_p ())
+return;
+
   check_region_size (lhs_reg, rhs_sval, ctxt);
 
   check_region_for_write (lhs_reg, ctxt);
diff --git a/gcc/analyzer/region.cc b/gcc/analyzer/region.cc
index 6d97590a83a..67ba9486980 100644
--- a/gcc/analyzer/region.cc
+++ b/gcc/analyzer/region.cc
@@ -671,6 +671,18 @@ region::symbolic_p () const
   return get_kind () == RK_SYMBOLIC;
 }
 
+/* Return true if this region is known to be zero bits in size.  */
+
+bool
+region::empty_p () const
+{
+  bit_size_t num_bits;
+  if (get_bit_size (_bits))
+if (num_bits == 0)
+  return true;
+  return false;
+}
+
 /* Return true if this is a region for a decl with name DECL_NAME.
Intended for use when debugging (for assertions and conditional
breakpoints).  */
diff --git a/gcc/analyzer/region.h b/gcc/analyzer/region.h
index ecae887edaf..6d8bcfb8868 100644
--- a/gcc/analyzer/region.h
+++ b/gcc/analyzer/region.h
@@ -233,6 +233,8 @@ public:
 
   bool is_named_decl_p (const char *decl_name) const;
 
+  bool empty_p () const;
+
  protected:
   region (complexity c, unsigned id, const region *parent, tree type);
 
diff --git a/gcc/analyzer/state-purge.cc b/gcc/analyzer/state-purge.cc
index 6fac18a2bbc..e9bcb4b0345 100644
--- a/gcc/analyzer/state-purge.cc
+++ b/gcc/analyzer/state-purge.cc
@@ -813,7 +813,11 @@ same_binding_p (const region *reg_a, const region *reg_b,
 {
   if (reg_a->get_base_region () != reg_b->get_base_region ())
 return false;
+  if (reg_a->empty_p ())
+return false;
   const binding_key *bind_key_a = binding_key::make (store_mgr, reg_a);
+  if (reg_b->empty_p ())
+return false;
   const binding_key *bind_key_b = binding_key::make (store_mgr, reg_b);
   return bind_key_a == bind_key_b;
 }
diff --git 

[Bug analyzer/107882] [13 Regression] ICE in get_last_bit_offset, at analyzer/store.h:255 since 13-2582-g0ea5e3f4542832b8

2022-12-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107882

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-4529-gdfe2ef7f2b6cac7017f32a0a04f74e1b6d9f1311
Author: David Malcolm 
Date:   Tue Dec 6 18:24:16 2022 -0500

analyzer: don't create bindings or binding keys for empty regions
[PR107882]

PR analyzer/107882 reports an ICE, due to trying to get a compound svalue
for this binding:

  cluster for: a:
key:   {bytes 0-3}
value:  {UNKNOWN()}
key:   {empty}
value:  {UNKNOWN()}
key:   {bytes 4-7}
value:  {UNKNOWN()}

where there's an binding to the unknown value of zero bits in size
"somewhere" within "a" (perhaps between bits 3 and 4?)

This makes no sense, so this patch adds an assertion that we never
attempt to create a binding key for an empty region, and adds early
rejection of attempts to get or set the values of such regions, fixing
the ICE.

gcc/analyzer/ChangeLog:
PR analyzer/107882
* region-model.cc (region_model::get_store_value): Return an
unknown value for empty regions.
(region_model::set_value): Bail on empty regions.
* region.cc (region::empty_p): New.
* region.h (region::empty_p): New decl.
* state-purge.cc (same_binding_p): Bail if either region is empty.
* store.cc (binding_key::make): Assert that a concrete binding's
bit_size must be > 0.
(binding_cluster::mark_region_as_unknown): Bail on empty regions.
(binding_cluster::get_binding): Likewise.
(binding_cluster::remove_overlapping_bindings): Likewise.
(binding_cluster::on_unknown_fncall): Don't conjure values for
empty regions.
(store::fill_region): Bail on empty regions.
* store.h (class concrete_binding): Update comment to reflect that
the range of bits must be non-empty.
(concrete_binding::concrete_binding): Assert that bit range is
non-empty.

gcc/testsuite/ChangeLog:
PR analyzer/107882
* gcc.dg/analyzer/memcpy-pr107882.c: New test.

Signed-off-by: David Malcolm 

[Bug c++/107998] New: [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

2022-12-06 Thread mckelvey at maskull dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998

Bug ID: 107998
   Summary: [13 Regression] gcc-13-20221204 failure to build on
Cygwin No dirname for option: m32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 54031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54031=edit
Build log

This worked two snapshots ago.

make[3]: Entering directory
'/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc'
if test yes = yes \
   || test -n "../lib ../lib32"; then \
  /bin/sh ../.././gcc/genmultilib \
"m64/m32" \
"64" \
"" \
"" \
"" \
"" \
"../lib ../lib32" \
"" \
"" \
"" \
"yes" \
> tmp-mlib.h; \
else \
  /bin/sh ../.././gcc/genmultilib '' '' '' '' '' '' '' '' \
"" '' no \
> tmp-mlib.h; \
fi
Error calling ../.././gcc/genmultilib: No dirname for option: m32
make[3]: *** [Makefile:2241: s-mlib] Error 1
make[3]: Leaving directory
'/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc'
make[2]: *** [Makefile:4934: all-stage1-gcc] Error 2
make[2]: Leaving directory '/home/McKelvey/gcc-13-20221204'
make[1]: *** [Makefile:23894: stage1-bubble] Error 2
make[1]: Leaving directory '/home/McKelvey/gcc-13-20221204'
make: *** [Makefile:1063: all] Error 2

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/13.0.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221118 (experimental) (GCC)


$ uname
CYGWIN_NT-10.0-19044

[Bug regression/107997] New: fd8dd6c03849691 probably uncovered an issue building the Linux kernel

2022-12-06 Thread jbglaw--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997

Bug ID: 107997
   Summary: fd8dd6c03849691 probably uncovered an issue building
the Linux kernel
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

Hi!

Starting with commit fd8dd6c0384969170e594be34da278a072d5eb76, I see
Linux kernel build errors for the skiroot_defconfig:

[mk all 2022-12-05 19:50:10]   powerpc64-linux-gcc
-Wp,-MMD,drivers/dma-buf/.dma-fence-array.o.d -nostdinc
-I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include
-I./arch/po
werpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/compiler-version.h -include
./include/linux/kconfig.h -include 
./include/linux/compiler_types.h -D__KERNEL__ -I ./arch/powerpc
-DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -Wall -Wundef
-Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-comm
on -fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11
-mlittle-endian -m64 -msoft-float -pipe -mtraceback=no
 -mabi=elfv2 -mcmodel=medium -mno-pointers-to-nested-functions -mcpu=power8
-mtune=power10 -mno-prefixed -mno-pcrel -mno-altivec -mno-vsx -mno-mma
-fno-asynchronous-unwind-tables -mno-string 
-Wa,-maltivec -Wa,-mpower4 -Wa,-many -mno-strict-align -mlittle-endian
-mstack-protector-guard=tls -mstack-protector-guard-reg=r13
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-form
at-truncation -Wno-format-overflow -Wno-address-of-packed-member -Os
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-main -Wno-unused-but-set-variable -Wno-
unused-const-variable -Wno-dangling-pointer -fomit-frame-pointer
-ftrivial-auto-var-init=zero -fno-stack-clash-protection
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function
-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict
-Wno-maybe-uninitialized -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5
-fno-strict-overflow -fno-stack-check -fconse
rve-stack -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -Wno-packed-not-aligned
-mstack-protector-guard-offset=2800   
-DKBUILD_MODFILE='"drivers/dma-buf/dma-fe
nce-array"' -DKBUILD_BASENAME='"dma_fence_array"'
-DKBUILD_MODNAME='"dma_fence_array"' -D__KBUILD_MODNAME=kmod_dma_fence_array -c
-o drivers/dma-buf/dma-fence-array.o drivers/dma-buf/dma-fenc
e-array.c   
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c: In function
'dma_fence_array_create':   
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: error:
control flow in the middle of basic block 12
[mk all 2022-12-05 19:50:10]   154 | struct dma_fence_array
*dma_fence_array_create(int num_fences, 
[mk all 2022-12-05 19:50:10]   |
^~  
[mk all 2022-12-05 19:50:10] during GIMPLE pass: ivopts 
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: internal
compiler error: verify_flow_info failed 
[mk all 2022-12-05 19:50:10] 0x19ea876 internal_error(char const*, ...) 
[mk all 2022-12-05 19:50:10]???:0   
[mk all 2022-12-05 19:50:10] 0x94b00e verify_flow_info()
[mk all 2022-12-05 19:50:10]???:0   
[mk all 2022-12-05 19:50:10] Please submit a full bug report, with preprocessed
source (by using -freport-bug). 
[mk all 2022-12-05 19:50:10] Please include the complete backtrace with any bug
report. 
[mk all 2022-12-05 19:50:10] See  for instructions.  


(Cf. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607874.html)

I'll add the preprocessed sources.

[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd

2022-12-06 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 54030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54030=edit
Incremental patch

The above patch on top of Tobias' initial one fixes some minor issues with
it and improves the behavior for testcase class_75.f90 modified as follows:

! { dg-do compile }
! { dg-additional-options "-fcoarray=single" }
!
! PR fortran/106856
!
!
!
subroutine foo(x,y)
  class(*), optional :: x, y
  optional:: x! { dg-error "Duplicate OPTIONAL attribute" }
  target  :: x
  allocatable :: x
  target  :: x! { dg-error "Duplicate TARGET attribute" }
  allocatable :: x! { dg-error "Duplicate ALLOCATABLE attribute" }
  pointer :: y
  contiguous  :: y
  pointer :: y! { dg-error "Duplicate POINTER attribute" }
  contiguous  :: y! { dg-error "Duplicate CONTIGUOUS attribute" }
  dimension   :: x(:,:)
  dimension   :: y(:,:,:)
  codimension :: x[:]
! < duplicat error for dimension/codimension: TODO add decl.

  ! Currently gives an ICE :-(
end


Note that these patches "regress" as follows:

- gfortran.dg/interface_41.f90 - this had a bogus error on valid code!
  (Removing the dg-error fixes it.)

- gfortran.dg/pr69398.f90 - this ICEs due to the duplicate DIMENSION attribute

I tried to modify restore_old_symbol() to handle CLASS arrays, but then
we ICE along a different path.  Not sure if this is the right approach.

Nevertheless, the patch as is already appears to be a great step forward!

Re: [PATCH] libstdc++: Add error handler for

2022-12-06 Thread Jonathan Wakely via Gcc-patches
On Wed, 30 Nov 2022 at 18:00, François Dumont  wrote:
>
> On 30/11/22 14:07, Jonathan Wakely wrote:
> > On Wed, 30 Nov 2022 at 11:57, Jonathan Wakely  wrote:
> >>
> >>
> >> On Wed, 30 Nov 2022 at 11:54, Jonathan Wakely  wrote:
> >>>
> >>>
> >>> On Wed, 30 Nov 2022 at 06:04, François Dumont via Libstdc++ 
> >>>  wrote:
>  Good catch, then we also need this patch.
> >>>
> >>> Is it worth printing an error? If we can't show the backtrace because of 
> >>> an error, we can just print nothing there.
>
> No strong opinion on that but if we do not print anything the output
> will be:
>
> Backtrace:
>
> Error: ...
>
> I just considered that it did not cost much to report the issue to the
> user that defined _GLIBCXX_DEBUG_BACKTRACE and so is expecting a backtrace.
>
> Maybe printing "Backtrace:\n" could be done in the normal callback
> leaving the user with the feeling that _GLIBCXX_DEBUG_BACKTRACE does not
> work.

OK, how's this?

Tested x86_64-linux.
commit aadf83283f0d3e1d473ac17595ba73d0210bb9ba
Author: Jonathan Wakely 
Date:   Wed Nov 30 12:32:53 2022

libstdc++: Pass error handler to libbacktrace functions

Also pass threaded=1 to __glibcxx_backtrace_create_state and remove some
of the namespace scope declarations in the header.

Co-authored-by: François Dumont 

libstdc++-v3/ChangeLog:

* include/debug/formatter.h [_GLIBCXX_DEBUG_BACKTRACE]
(_Error_formatter::_Error_formatter): Pass error handler to
__glibcxx_backtrace_create_state. Pass 1 for threaded argument.
(_Error_formatter::_S_err): Define empty function.
* src/c++11/debug.cc (_Error_formatter::_M_error): Pass error
handler to __glibcxx_backtrace_full.

diff --git a/libstdc++-v3/include/debug/formatter.h 
b/libstdc++-v3/include/debug/formatter.h
index f120163c6d4..e8a83a21bde 100644
--- a/libstdc++-v3/include/debug/formatter.h
+++ b/libstdc++-v3/include/debug/formatter.h
@@ -32,32 +32,17 @@
 #include 
 
 #if _GLIBCXX_HAVE_STACKTRACE
-struct __glibcxx_backtrace_state;
-
 extern "C"
 {
-  __glibcxx_backtrace_state*
+  struct __glibcxx_backtrace_state*
   __glibcxx_backtrace_create_state(const char*, int,
   void(*)(void*, const char*, int),
   void*);
-
-  typedef int (*__glibcxx_backtrace_full_callback) (
-void*, __UINTPTR_TYPE__, const char *, int, const char*);
-
-  typedef void (*__glibcxx_backtrace_error_callback) (
-void*, const char*, int);
-
-  typedef int (*__glibcxx_backtrace_full_func) (
-__glibcxx_backtrace_state*, int,
-__glibcxx_backtrace_full_callback,
-__glibcxx_backtrace_error_callback,
-void*);
-
   int
   __glibcxx_backtrace_full(
-__glibcxx_backtrace_state*, int,
-__glibcxx_backtrace_full_callback,
-__glibcxx_backtrace_error_callback,
+struct __glibcxx_backtrace_state*, int,
+int (*)(void*, __UINTPTR_TYPE__, const char *, int, const char*),
+void (*)(void*, const char*, int),
 void*);
 }
 #endif
@@ -609,10 +594,10 @@ namespace __gnu_debug
 , _M_function(__function)
 #if _GLIBCXX_HAVE_STACKTRACE
 # ifdef _GLIBCXX_DEBUG_BACKTRACE
-, _M_backtrace_state(__glibcxx_backtrace_create_state(0, 0, 0, 0))
+, _M_backtrace_state(__glibcxx_backtrace_create_state(0, 1, _S_err, 0))
 , _M_backtrace_full(&__glibcxx_backtrace_full)
 # else
-, _M_backtrace_state()
+, _M_backtrace_state(0)
 # endif
 #endif
 { }
@@ -631,8 +616,12 @@ namespace __gnu_debug
 const char*_M_text;
 const char*_M_function;
 #if _GLIBCXX_HAVE_STACKTRACE
-__glibcxx_backtrace_state* _M_backtrace_state;
-__glibcxx_backtrace_full_func  _M_backtrace_full;
+struct __glibcxx_backtrace_state*  _M_backtrace_state;
+// TODO: Remove _M_backtrace_full after __glibcxx_backtrace_full is moved
+// from libstdc++_libbacktrace.a to libstdc++.so:
+__decltype(&__glibcxx_backtrace_full)  _M_backtrace_full;
+
+static void _S_err(void*, const char*, int) { }
 #endif
 
   public:
diff --git a/libstdc++-v3/src/c++11/debug.cc b/libstdc++-v3/src/c++11/debug.cc
index 9eda38023f7..83996ffe622 100644
--- a/libstdc++-v3/src/c++11/debug.cc
+++ b/libstdc++-v3/src/c++11/debug.cc
@@ -1141,6 +1141,23 @@ namespace
 
 return ret;
   }
+
+  void
+  print_backtrace_error(void* data, const char* msg, int errnum)
+  {
+PrintContext& ctx = *static_cast(data);
+
+print_literal(ctx, "Backtrace unavailable: ");
+print_word(ctx, msg ? msg : "");
+if (errnum > 0)
+  {
+   char buf[64];
+   int written = __builtin_sprintf(buf, " (errno=%d)\n", errnum);
+   print_word(ctx, buf, written);
+  }
+else
+  print_literal(ctx, "\n");
+  }
 #endif
 }
 
@@ -1193,7 +1210,7 @@ namespace __gnu_debug
   {
print_literal(ctx, "Backtrace:\n");
_M_backtrace_full(
- _M_backtrace_state, 1, print_backtrace, nullptr, );
+ 

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

2022-12-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jonathan Wakely  ---
Oh yes, I wonder why I bothered handling it there :-)

It should be fixed now, thanks for the report.

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

2022-12-06 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
This should be fixed now, I hope. Please reopen if not.

[committed] libstdc++: Fix test that fails due to name clash with old glibc [PR107979]

2022-12-06 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux. Pushed to trunk.

-- >8 --

This test was recently modified to check that the library doesn't use
__unused anywhere, because that's a macro in newlib. But it's also a
macro in old versions of glibc, so the test now fails for those targets.
Disable that check for those targets as well as for newlib.

libstdc++-v3/ChangeLog:

PR libstdc++/107979
* testsuite/17_intro/names.cc: Do not check __unused on old
Glibc versions.
---
 libstdc++-v3/testsuite/17_intro/names.cc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libstdc++-v3/testsuite/17_intro/names.cc 
b/libstdc++-v3/testsuite/17_intro/names.cc
index ffbb199797b..963f74c11f3 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -241,6 +241,13 @@
 #undef y
 #endif
 
+#ifdef __GLIBC_PREREQ
+#if ! __GLIBC_PREREQ(2, 19)
+// Glibc defines this prior to 2.19
+#undef __unused
+#endif
+#endif
+
 #if __has_include()
 // newlib's  defines these as macros.
 #undef __lockable
-- 
2.38.1



[committed] libstdc++: Add casts for integer-like difference type [PR107871]

2022-12-06 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

PR libstdc++/107871
* include/std/format (_Iter_sink::_M_overflow): Add cast to
size_t.
(_Iter_sink::_M_make_span): Use
typedef instead of decltype.
* testsuite/std/format/functions/107871.cc: New test.
---
 libstdc++-v3/include/std/format|  8 
 .../testsuite/std/format/functions/107871.cc   | 14 ++
 2 files changed, 18 insertions(+), 4 deletions(-)
 create mode 100644 libstdc++-v3/testsuite/std/format/functions/107871.cc

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index 6d6a770eb8c..1072e2c17db 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -2481,12 +2481,12 @@ namespace __format
auto __s = this->_M_used();
if (_M_max < 0) // No maximum.
  _M_out = ranges::copy(__s, std::move(_M_out)).out;
-   else if (_M_count < size_t(_M_max))
+   else if (_M_count < static_cast(_M_max))
  {
auto __max = _M_max - _M_count;
span<_CharT> __first;
if (__max < __s.size())
- __first = __s.first(__max);
+ __first = __s.first(static_cast(__max));
else
  __first = __s;
_M_out = ranges::copy(__first, std::move(_M_out)).out;
@@ -2564,11 +2564,11 @@ namespace __format
 
if (__n > 0)
  {
-   if constexpr (!is_integral_v
+   if constexpr (!is_integral_v>
|| sizeof(__n) > sizeof(size_t))
  {
// __int128 or __detail::__max_diff_type
-   auto __m = (decltype(__n))(size_t)-1;
+   auto __m = iter_difference_t<_OutIter>((size_t)-1);
if (__n > __m)
  __n = __m;
  }
diff --git a/libstdc++-v3/testsuite/std/format/functions/107871.cc 
b/libstdc++-v3/testsuite/std/format/functions/107871.cc
new file mode 100644
index 000..1fb558e7ac6
--- /dev/null
+++ b/libstdc++-v3/testsuite/std/format/functions/107871.cc
@@ -0,0 +1,14 @@
+// { dg-options "-std=gnu++20" }
+// { dg-do compile { target c++20 } }
+
+#include 
+
+struct O {
+  using difference_type = std::ranges::__detail::__max_diff_type;
+  O& operator=(const char&);
+  O& operator*();
+  O& operator++();
+  O& operator++(int);
+};
+
+auto str = std::format_to_n(O{}, 4, "{}", " "); // PR libstdc++/107871
-- 
2.38.1



Re: [PATCH] libstdc++: Make chrono::hh_mm_ss more compact

2022-12-06 Thread Jonathan Wakely via Gcc-patches
I've pushed this to trunk. Tested x86_64-linux.

On Mon, 21 Nov 2022 at 20:44, Jonathan Wakely via Libstdc++
 wrote:
>
> While finishing the time zone support for C++20, I noticed that the
> chrono::hh_mm_ss type is surprisingly large: 40 bytes. That's because
> we use duration for each of the four members, _M_h, _M_m,
> _M_s and _M_ss. This is very wasteful. The patch below reduces it to 16
> bytes (or less for some targets) for most specializations using an
> integral type for the hh_mm_ss::precision::rep type.
>
> Patrick, you added hh_mm_ss, but I assume you just implemented what is
> shown for the exposition-only members in the standard, rather than
> intentionally choosing this 40-byte representation? I don't recall
> discussing it at the time, but I might be forgetting something.
>
> Does the patch below make sense? I could remove the partial
> specialization that use a single byte for the subseconds, or only do
> that on 32-bit targets where alignof(int64_t) is 4. For targets where
> alignof(int64_t) is 8 we're always going to be 16 bytes minimum, so
> maybe there's no point squeezing everything into 12 bytes if we have a
> mandatory 4 bytes of padding.
>
> We could make those members use even less space, something like:
>
> hours _M_h;
> unsigned _M_m : 6;
> unsigned _M_s : 6;
> unsigned _M_is_neg : 1;
> unsigned _M_ss : 51;  // good enough for femtoseconds
>
> This would only require 16 bytes even for hh_mm_ss, but
> requires extra instructions to read the values. That seems like the
> wrong trade off. A compact layout for hh_mm_ss
> and hh_mm_ss seems good enough. Paying
> extra instructions to access the members just to support incredibly high
> precision doesn't make sense to me.
>
> We could also elide the bool _M_is_neg member if _Duration::rep is
> unsigned, but it doesn't seem worth the metaprogramming/maintenance
> cost.
>
> We could consider using duration> for the
> _M_h member instead of chrono::hours (which uses int64_t). It seems
> unlikely (but not impossible) anybody will want to use hh_mm_ss for
> billions of hours past midnight. If we do that, then using a single byte
> for subseconds (when possible) does make sense, because the whole
> hh_mm_ss would fit in just 8 bytes (4 for hours, 1 for minutes, 1 for
> seconds, 1 for is_neg, and 1 for the subseconds). And then bit-fields
> start to look more appealing. Maybe just for the subseconds and is_neg
> flag, which would be 8 bytes for precision::period >= ratio<1,10'000>:
>
> uint_least32_t _M_h;
> uint_least8_t  _M_m;
> uint_least8_t  _M_s;
> uint_least16_t _M_ss : 15;
> uint_least16_t _M_is_neg : 1;
>
> Has anybody got any other suggestions for optimizing this or other
> chrono types? e.g. I think we should also consider using int32_t as the
> rep for chrono::{days,weeks,years} because a 64-bit type for years is
> unnecessary.
>
> It looks like other implementations don't bother trying to save space
> for chrono::hh_mm_ss, which makes me wonder if there's some reason not
> to do this. For MSVC it's only 32 bytes, which I think is because they
> use a 32-bit type for chrono::hours and chrono::minutes, not because
> they're doing anything special to make chrono::hh_mm_ss smaller.
>
>
> -- >8 --
>
> This uses a single byte for the minutes and seconds members, and places
> the bool member next to those single bytes. This means we do not need 40
> bytes to store a time that can fit in a single 8-byte integer.
>
> When there is no subsecond precision we can do away with the _M_ss
> member altogether. If the subsecond precision is coarse enough, we can
> use a smaller representation for _M_ss, e.g. hh_mm_ss only
> needs uint_least32_t for _M_ss, and hh_mm_ss>
> and hh_mm_ss> each only needs a single byte. In
> the latter case the type can only ever represent up to 255ns anyway, so
> we don't need a larger representation type (in such cases, we could even
> remove the _M_h, _M_m and _M_s members, but it's a very unlikely
> scenario that isn't worth optimizing for).
>
> Except for specializations with a floating-point rep or using higher
> precision than nanoseconds, hh_mm_ss should now fit in 16 bytes, or even
> 12 bytes for x86-32 where alignof(long long) == 4.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/chrono (chrono::hh_mm_ss): Do not use 64-bit
> representations for all four duration members. Reorder members.
> (hh_mm_ss::_S_fractional_width()): Optimize using countr_zero.
> (hh_mm_ss::hh_mm_ss()): Define as defaulted.
> (hh_mm_ss::hh_mm_ss(Duration)): Delegate to a new private
> constructor, instead of calling chrono::abs repeatedly.
> * testsuite/std/time/hh_mm_ss/1.cc: Check floating-point
> representations. Check default constructor. Check sizes.
> ---
>  libstdc++-v3/include/std/chrono   | 139 +-
>  libstdc++-v3/testsuite/std/time/hh_mm_ss/1.cc |  54 ++-
>  2 files changed, 158 insertions(+), 35 deletions(-)
>
> diff --git 

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

2022-12-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107979

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:2a23b93f944fa78d4284eb5687051c224e5ab08f

commit r13-4528-g2a23b93f944fa78d4284eb5687051c224e5ab08f
Author: Jonathan Wakely 
Date:   Mon Dec 5 21:44:26 2022 +

libstdc++: Fix test that fails due to name clash with old glibc [PR107979]

This test was recently modified to check that the library doesn't use
__unused anywhere, because that's a macro in newlib. But it's also a
macro in old versions of glibc, so the test now fails for those targets.
Disable that check for those targets as well as for newlib.

libstdc++-v3/ChangeLog:

PR libstdc++/107979
* testsuite/17_intro/names.cc: Do not check __unused on old
Glibc versions.

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

2022-12-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107871

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:9cce91a63dcc40cb39e68f6a771e891e51c51946

commit r13-4527-g9cce91a63dcc40cb39e68f6a771e891e51c51946
Author: Jonathan Wakely 
Date:   Mon Dec 5 21:38:53 2022 +

libstdc++: Add casts for integer-like difference type [PR107871]

libstdc++-v3/ChangeLog:

PR libstdc++/107871
* include/std/format (_Iter_sink::_M_overflow): Add cast to
size_t.
(_Iter_sink::_M_make_span): Use
typedef instead of decltype.
* testsuite/std/format/functions/107871.cc: New test.

[committed] libstdc++: Add hint to compiler about vector invariants [PR106434]

2022-12-06 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux. Pushed to trunk.

-- >8 --

The PR shows a bogus warning where jump threading generates code for the
undefined case that the insertion point is a value-initialized iterator
but _M_finish and _M_end_of_storage are unequal (so at least one must be
non-null). Using __builtin_unreachable() removes the bogus warning. Also
add an assertion to diagnose undefined misuses of a null iterator here,
so we don't just silently optimize that undefined code to something
unsafe.

libstdc++-v3/ChangeLog:

PR c++/106434
* include/bits/vector.tcc (insert(const_iterator, const T&)):
Add assertion and optimization hint that the iterator for the
insertion point must be non-null.
---
 libstdc++-v3/include/bits/vector.tcc | 40 
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/libstdc++-v3/include/bits/vector.tcc 
b/libstdc++-v3/include/bits/vector.tcc
index 27ef1a4ee7f..8ae79ffc7af 100644
--- a/libstdc++-v3/include/bits/vector.tcc
+++ b/libstdc++-v3/include/bits/vector.tcc
@@ -139,26 +139,32 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 {
   const size_type __n = __position - begin();
   if (this->_M_impl._M_finish != this->_M_impl._M_end_of_storage)
-   if (__position == end())
- {
-   _GLIBCXX_ASAN_ANNOTATE_GROW(1);
-   _Alloc_traits::construct(this->_M_impl, this->_M_impl._M_finish,
-__x);
-   ++this->_M_impl._M_finish;
-   _GLIBCXX_ASAN_ANNOTATE_GREW(1);
- }
-   else
- {
+   {
+ __glibcxx_assert(__position != const_iterator());
+ if (!(__position != const_iterator()))
+   __builtin_unreachable(); // PR 106434
+
+ if (__position == end())
+   {
+ _GLIBCXX_ASAN_ANNOTATE_GROW(1);
+ _Alloc_traits::construct(this->_M_impl, this->_M_impl._M_finish,
+  __x);
+ ++this->_M_impl._M_finish;
+ _GLIBCXX_ASAN_ANNOTATE_GREW(1);
+   }
+ else
+   {
 #if __cplusplus >= 201103L
-   const auto __pos = begin() + (__position - cbegin());
-   // __x could be an existing element of this vector, so make a
-   // copy of it before _M_insert_aux moves elements around.
-   _Temporary_value __x_copy(this, __x);
-   _M_insert_aux(__pos, std::move(__x_copy._M_val()));
+ const auto __pos = begin() + (__position - cbegin());
+ // __x could be an existing element of this vector, so make a
+ // copy of it before _M_insert_aux moves elements around.
+ _Temporary_value __x_copy(this, __x);
+ _M_insert_aux(__pos, std::move(__x_copy._M_val()));
 #else
-   _M_insert_aux(__position, __x);
+ _M_insert_aux(__position, __x);
 #endif
- }
+   }
+   }
   else
 #if __cplusplus >= 201103L
_M_realloc_insert(begin() + (__position - cbegin()), __x);
-- 
2.38.1



[committed] libstdc++: Add nodiscard attribute to mutex try_lock functions

2022-12-06 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/bits/std_mutex.h (mutex): Add nodiscard attribute to
try_lock member function.
* include/bits/unique_lock.h (unique_lock): Likewise for
try_lock, try_lock_until, try_lock_for member functions, and
owns_lock and mutex member functions.
* include/std/mutex (recursive_mutex): Likewise for try_lock
member function.
(timed_mutex, recursive_timed_mutex, try_lock): Likewise for
try_lock, try_lock_until, try_lock_for member functions.
(try_lock): Likewise for non-member function.
* include/std/shared_mutex (shared_mutex): Likewise for try_lock
and try_lock_shared member functions.
(shared_timed_mutex): Likewise for try_lock, try_lock_for,
try_lock_shared, try_lock_shared_for, try_lock_until, and
try_lock_shared_until member functions.
(shared_lock): Likewise for try_lock, try_lock, try_lock_for,
try_lock_until, owns_lock, and mutex member functions.
* 
testsuite/30_threads/recursive_timed_mutex/try_lock_until/clock_neg.cc:
Cast discarded value expression to void.
* testsuite/30_threads/shared_lock/locking/3.cc: Likewise.
* testsuite/30_threads/shared_lock/locking/4.cc: Likewise.
* testsuite/30_threads/shared_lock/locking/clock_neg.cc:
Likewise.
* testsuite/30_threads/shared_timed_mutex/try_lock_until/clock_neg.cc:
Likewise.
* testsuite/30_threads/timed_mutex/try_lock_until/clock_neg.cc:
Likewise.
* testsuite/30_threads/try_lock/4.cc: Likewise.
* testsuite/30_threads/unique_lock/cons/60497.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/3.cc: Likewise.
* testsuite/30_threads/unique_lock/locking/clock_neg.cc:
Likewise.
---
 libstdc++-v3/include/bits/std_mutex.h |  1 +
 libstdc++-v3/include/bits/unique_lock.h   |  5 +
 libstdc++-v3/include/std/mutex| 14 
 libstdc++-v3/include/std/shared_mutex | 22 ---
 .../try_lock_until/clock_neg.cc   |  4 ++--
 .../30_threads/shared_lock/locking/3.cc   |  2 +-
 .../30_threads/shared_lock/locking/4.cc   |  2 +-
 .../shared_lock/locking/clock_neg.cc  |  4 ++--
 .../try_lock_until/clock_neg.cc   |  4 ++--
 .../timed_mutex/try_lock_until/clock_neg.cc   |  4 ++--
 .../testsuite/30_threads/try_lock/4.cc|  2 +-
 .../30_threads/unique_lock/cons/60497.cc  |  2 +-
 .../30_threads/unique_lock/locking/3.cc   |  2 +-
 .../unique_lock/locking/clock_neg.cc  |  4 ++--
 14 files changed, 54 insertions(+), 18 deletions(-)

diff --git a/libstdc++-v3/include/bits/std_mutex.h 
b/libstdc++-v3/include/bits/std_mutex.h
index b22e0e12793..68f5fb9ed65 100644
--- a/libstdc++-v3/include/bits/std_mutex.h
+++ b/libstdc++-v3/include/bits/std_mutex.h
@@ -117,6 +117,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__throw_system_error(__e);
 }
 
+_GLIBCXX_NODISCARD
 bool
 try_lock() noexcept
 {
diff --git a/libstdc++-v3/include/bits/unique_lock.h 
b/libstdc++-v3/include/bits/unique_lock.h
index 9ed7ba25766..c6402d94e85 100644
--- a/libstdc++-v3/include/bits/unique_lock.h
+++ b/libstdc++-v3/include/bits/unique_lock.h
@@ -143,6 +143,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  }
   }
 
+  _GLIBCXX_NODISCARD
   bool
   try_lock()
   {
@@ -158,6 +159,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 
   template
+   _GLIBCXX_NODISCARD
bool
try_lock_until(const chrono::time_point<_Clock, _Duration>& __atime)
{
@@ -173,6 +175,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
 
   template
+   _GLIBCXX_NODISCARD
bool
try_lock_for(const chrono::duration<_Rep, _Period>& __rtime)
{
@@ -215,6 +218,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __ret;
   }
 
+  _GLIBCXX_NODISCARD
   bool
   owns_lock() const noexcept
   { return _M_owns; }
@@ -222,6 +226,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   explicit operator bool() const noexcept
   { return owns_lock(); }
 
+  _GLIBCXX_NODISCARD
   mutex_type*
   mutex() const noexcept
   { return _M_device; }
diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
index b310c15687d..aca5f91e03c 100644
--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -124,6 +124,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__throw_system_error(__e);
 }
 
+_GLIBCXX_NODISCARD
 bool
 try_lock() noexcept
 {
@@ -253,6 +254,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__throw_system_error(__e);
 }
 
+_GLIBCXX_NODISCARD
 bool
 try_lock() noexcept
 {
@@ -261,11 +263,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 }
 
 template 
+  _GLIBCXX_NODISCARD
   bool
   try_lock_for(const 

[Bug c++/106434] [12/13 Regression] Spurious -Wnull-dereference when using std::unique_copy() since r12-5187-g1ae8edf5f73ca5c3

2022-12-06 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106434

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:4ba94abf147fe7778a7541849ce27cafee74df9b

commit r13-4525-g4ba94abf147fe7778a7541849ce27cafee74df9b
Author: Jonathan Wakely 
Date:   Mon Dec 5 12:53:42 2022 +

libstdc++: Add hint to compiler about vector invariants [PR106434]

The PR shows a bogus warning where jump threading generates code for the
undefined case that the insertion point is a value-initialized iterator
but _M_finish and _M_end_of_storage are unequal (so at least one must be
non-null). Using __builtin_unreachable() removes the bogus warning. Also
add an assertion to diagnose undefined misuses of a null iterator here,
so we don't just silently optimize that undefined code to something
unsafe.

libstdc++-v3/ChangeLog:

PR c++/106434
* include/bits/vector.tcc (insert(const_iterator, const T&)):
Add assertion and optimization hint that the iterator for the
insertion point must be non-null.

[committed] libstdc++: The Trouble with Tribbles

2022-12-06 Thread Jonathan Wakely via Gcc-patches
Tested x86_64-linux. Pushed to trunk.

-- >8 --

Fix digit grouping for integers formatted with "{:#Lx}" which were
including the "0x" prefix in the grouped digits. This resulted in output
like "0,xff,fff" instead of "0xff,fff".

Also change std:::basic_format_parse_context to not throw for an arg-id
that is larger than the actual number of format arguments. I clarified
with Victor Zverovich that this is the intended behaviour for the
run-time format-string checks. An out-of-range arg-id should be
diagnosed at compile-time (as clarified by LWG 3825) but not run-time.
The formatting function will still throw at run-time when args.arg(id)
returns an empty basic_format_arg.

libstdc++-v3/ChangeLog:

* include/std/format (basic_format_parse_context::next_arg_id):
Only check arg-id is in range during constant evaluation.
* testsuite/std/format/functions/format.cc: Check "{:#Lx}".
* testsuite/std/format/parse_ctx.cc: Adjust expected results for
format-strings using an out-of-range arg-id.
---
 libstdc++-v3/include/std/format   | 29 +++-
 .../testsuite/std/format/functions/format.cc  |  4 ++
 .../testsuite/std/format/parse_ctx.cc | 45 ---
 3 files changed, 40 insertions(+), 38 deletions(-)

diff --git a/libstdc++-v3/include/std/format b/libstdc++-v3/include/std/format
index cb5ce40dece..6d6a770eb8c 100644
--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -221,7 +221,10 @@ namespace __format
if (_M_indexing == _Manual)
  __format::__conflicting_indexing_in_format_string();
_M_indexing = _Auto;
-   // if (std::is_constant_evaluated()) // XXX skip runtime check?
+
+   // _GLIBCXX_RESOLVE_LIB_DEFECTS
+   // 3825. Missing compile-time argument id check in next_arg_id
+   if (std::is_constant_evaluated())
  if (_M_next_arg_id == _M_num_args)
__format::__invalid_arg_id_in_format_string();
return _M_next_arg_id++;
@@ -234,7 +237,7 @@ namespace __format
  __format::__conflicting_indexing_in_format_string();
_M_indexing = _Manual;
 
-   // if (std::is_constant_evaluated()) // XXX skip runtime check?
+   if (std::is_constant_evaluated())
  if (__id >= _M_num_args)
__format::__invalid_arg_id_in_format_string();
   }
@@ -1167,15 +1170,18 @@ namespace __format
  string __grp = __np.grouping();
  if (!__grp.empty())
{
- size_t __n = __str.size();
+ size_t __n = __str.size() - __prefix_len;
  auto __p = (_CharT*)__builtin_alloca(2 * __n
-* sizeof(_CharT));
- auto __end = std::__add_grouping(__p,
+* sizeof(_CharT)
++ __prefix_len);
+ auto __s = __str.data();
+ char_traits<_CharT>::copy(__p, __s, __prefix_len);
+ __s += __prefix_len;
+ auto __end = std::__add_grouping(__p + __prefix_len,
   __np.thousands_sep(),
   __grp.data(),
   __grp.size(),
-  __str.data(),
-  __str.data() + __n);
+  __s, __s + __n);
  __str = {__p, size_t(__end - __p)};
}
}
@@ -3381,10 +3387,11 @@ namespace __format
   __ctx.advance_to(__format::__write(__ctx.out()));
 }
 
-  // TODO define __process_format_string which takes an object with callbacks
-  // can use that for initial constexpr parse of format string (with callbacks
-  // that have no side effects, just non-constant on error).
-
+  // Abstract base class defining an interface for scanning format strings.
+  // Scan the characters in a format string, dividing it up into strings of
+  // ordinary characters, escape sequences, and replacement fields.
+  // Call virtual functions for derived classes to parse format-specifiers
+  // or write formatted output.
   template
 struct _Scanner
 {
diff --git a/libstdc++-v3/testsuite/std/format/functions/format.cc 
b/libstdc++-v3/testsuite/std/format/functions/format.cc
index 8019fbdf712..7a155208a48 100644
--- a/libstdc++-v3/testsuite/std/format/functions/format.cc
+++ b/libstdc++-v3/testsuite/std/format/functions/format.cc
@@ -111,6 +111,10 @@ test_std_examples()
 string s3 = format("{:L}", 1234);
 VERIFY(s3 == "1,234");
 
+// Test locale's "byte-and-a-half" grouping (Imperial word? tribble?).
+string s4 = format("{:#Lx}", 0xf);
+VERIFY(s4 == 

Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678]

2022-12-06 Thread Szabolcs Nagy via Gcc-patches
The 12/06/2022 11:58, Wilco Dijkstra wrote:
> > i don't think how[*RA_STATE] can ever be set to REG_SAVED_OFFSET,
> > this pseudo reg is not spilled to the stack, it is reset to 0 in
> > each frame and then toggled within a frame.
> 
> It's is just a state, we can use any state we want since it is a pseudo reg.
> These registers are global and shared across all functions in an unwind,
> so their state or value isn't reset for each frame. So if we want to reset
> it in each frame then using a virtual register to hold per-function data
> seems like a bad design. I'm surprised nobody has ever tested it...

it was tested (and worked when the frame state was initialized).

in principle the CIE can contain instructions to initialize the
register state for a frame. the RA_STATE pseudo reg behaves as if
the CIE always set its value to 0 at the start of the frame.

the design has issues, but this is what we have now.

the toggle instruction for RA_STATE does not really fit the dwarf
model: the CFI instruction sequence is evaluated with a context
that is valid at the end of the sequence so an unwinder only wants
to evaluate a register's state at the end, not intermediate values
(where the context might not even be valid). so we limited the
instructions allowed for RA_STATE: only remember_/restore_state,
toggle and val_expression are supported and the latter two cannot
be mixed. we still have to use the existing struct for keeping
track of this hence reg[RA_STATE].loc.offset.

and of course the RA_STATE pseudo reg is only used for computing
the return address not propagated to the previous frame so it is
special in many ways. so we will need target hooks to fix this
and i think the cleanest is to initialize RA_STATE per frame and
leave the rest as is.



Re: [PATCH v2 1/2] Allow subtarget customization of CC1_SPEC

2022-12-06 Thread Thomas Schwinge
Hi!

I suppose I just fail to see some detail here, but:

On 2022-11-21T08:25:25+0100, Sebastian Huber 
 wrote:
> gcc/ChangeLog:
>
>   * gcc.cc (SUBTARGET_CC1_SPEC): Define if not defined.
>   (cc1_spec): Append SUBTARGET_CC1_SPEC.
> ---
> v2: Append SUBTARGET_CC1_SPEC directly to cc1_spec and not through CC1_SPEC.
> This avoids having to modify all the CC1_SPEC definitions in the targets.
>
>  gcc/gcc.cc | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/gcc.cc b/gcc/gcc.cc
> index 830ab88701f..4e1574a4df1 100644
> --- a/gcc/gcc.cc
> +++ b/gcc/gcc.cc
> @@ -706,6 +706,13 @@ proper position among the other output files.  */
>  #define CPP_SPEC ""
>  #endif
>
> +/* Subtargets can define SUBTARGET_CC1_SPEC to provide extra args to cc1 and
> +   cc1plus or extra switch-translations.  The SUBTARGET_CC1_SPEC is appended
> +   to CC1_SPEC.  */
> +#ifndef SUBTARGET_CC1_SPEC
> +#define SUBTARGET_CC1_SPEC ""
> +#endif
> +
>  /* config.h can define CC1_SPEC to provide extra args to cc1 and cc1plus
> or extra switch-translations.  */
>  #ifndef CC1_SPEC
> @@ -1174,7 +1181,7 @@ proper position among the other output files.  */
>  static const char *asm_debug = ASM_DEBUG_SPEC;
>  static const char *asm_debug_option = ASM_DEBUG_OPTION_SPEC;
>  static const char *cpp_spec = CPP_SPEC;
> -static const char *cc1_spec = CC1_SPEC;
> +static const char *cc1_spec = CC1_SPEC SUBTARGET_CC1_SPEC;
>  static const char *cc1plus_spec = CC1PLUS_SPEC;
>  static const char *link_gcc_c_sequence_spec = LINK_GCC_C_SEQUENCE_SPEC;
>  static const char *link_ssp_spec = LINK_SSP_SPEC;

... doesn't this (at least potentially?) badly interact with any existing
'SUBTARGET_CC1_SPEC' definitions -- which pe rabove get appended to
'cc1_spec'?

gcc/config/loongarch/gnu-user.h-   and provides this hook instead.  */
gcc/config/loongarch/gnu-user.h:#undef SUBTARGET_CC1_SPEC
gcc/config/loongarch/gnu-user.h:#define SUBTARGET_CC1_SPEC 
GNU_USER_TARGET_CC1_SPEC
gcc/config/loongarch/gnu-user.h-
--
gcc/config/loongarch/loongarch.h-#define EXTRA_SPECS \
gcc/config/loongarch/loongarch.h:  {"subtarget_cc1_spec", 
SUBTARGET_CC1_SPEC}, \
gcc/config/loongarch/loongarch.h-  {"subtarget_cpp_spec", 
SUBTARGET_CPP_SPEC}, \
--
gcc/config/mips/gnu-user.h-   and provides this hook instead.  */
gcc/config/mips/gnu-user.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/gnu-user.h:#define SUBTARGET_CC1_SPEC 
GNU_USER_TARGET_CC1_SPEC
gcc/config/mips/gnu-user.h-
--
gcc/config/mips/linux-common.h-
gcc/config/mips/linux-common.h:#undef  SUBTARGET_CC1_SPEC
gcc/config/mips/linux-common.h:#define SUBTARGET_CC1_SPEC   
\
gcc/config/mips/linux-common.h-  LINUX_OR_ANDROID_CC 
(GNU_USER_TARGET_CC1_SPEC, \
--
gcc/config/mips/mips.h-
gcc/config/mips/mips.h:/* SUBTARGET_CC1_SPEC is passed to the compiler 
proper.  It may be
gcc/config/mips/mips.h-   overridden by subtargets.  */
gcc/config/mips/mips.h:#ifndef SUBTARGET_CC1_SPEC
gcc/config/mips/mips.h:#define SUBTARGET_CC1_SPEC ""
gcc/config/mips/mips.h-#endif
--
gcc/config/mips/mips.h-#define EXTRA_SPECS  
\
gcc/config/mips/mips.h:  { "subtarget_cc1_spec", SUBTARGET_CC1_SPEC },  
\
gcc/config/mips/mips.h-  { "subtarget_cpp_spec", SUBTARGET_CPP_SPEC },  
\
--
gcc/config/mips/r3900.h-/* By default (if not mips-something-else) produce 
code for the r3900 */
gcc/config/mips/r3900.h:#undef SUBTARGET_CC1_SPEC
gcc/config/mips/r3900.h:#define SUBTARGET_CC1_SPEC "\
gcc/config/mips/r3900.h-%{mhard-float:%e-mhard-float not supported} \


Grüße
 Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


Naming flag for specifying the output file name for Binary Module Interface files

2022-12-06 Thread David Blaikie via Gcc
Over in https://reviews.llvm.org/D137059 we're discussing the naming
of a clang flag - would be good to have it be consistent with GCC.

The functionality is to name the BMI (.pcm in Clang's parlance) output
file when compiling a C++20 module.

Current proposal is to use `-fsave-std-cxx-module-file=` which is
certainly precise, but maybe a bit verbose. Clang has some other flags
related to modules that skip the std/cxx parts, and are just
`-fmodule-*` or `-fmodules-*`, so there's some precedent for that too.

Do GCC folks have any veto votes (is the currently proposed name
especially objectionable/wouldn't be acceptable in GCC) or preferences
(suggestions to add to the pool)?


[Bug analyzer/107882] [13 Regression] ICE in get_last_bit_offset, at analyzer/store.h:255 since 13-2582-g0ea5e3f4542832b8

2022-12-06 Thread dmalcolm at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107882

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from David Malcolm  ---
I'm working on an alternate fix for this, which rejects creating bindings and
binding keys for empty bit ranges, as they're meaningless.  Testing it now.

D

2022-12-06 Thread Malika Houston via Gcc



Sent from my iPhone


Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition

2022-12-06 Thread Jonathan Wakely via Gcc
On Tue, 6 Dec 2022 at 20:32, Gavin Ray wrote:
>
> Ah got it, didn't know that (handy, will save me duplicating a bunch of 
> attributes).
> Thanks Jonathan!

The Clang doc acually show all the forms that can be used for each attribute:

https://clang.llvm.org/docs/AttributeReference.html#may-alias

"GNU" means __attribute__((may_alias)) and the C++11 and C2x columns
show that [[gnu::may_alias]] is the right way to use it.

Clang-specific attributes use clang:: instead e.g.
https://clang.llvm.org/docs/AttributeReference.html#preserve-all


Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition

2022-12-06 Thread Gavin Ray via Gcc
Ah got it, didn't know that (handy, will save me duplicating a bunch of
attributes).
Thanks Jonathan!

On Tue, Dec 6, 2022 at 2:23 PM Jonathan Wakely 
wrote:

>
>
> On Tue, 6 Dec 2022, 18:36 Gavin Ray via Gcc,  wrote:
>
>> Oh, D'oh! Thanks Joseph, apologies for the needless email on the list
>> then.
>>
>> One final question if I could -- does that mean that in order to support
>> "may-alias" with the bracket syntax on both Clang and GCC, it would
>> require:
>>
>>  union [[gnu::may_alias]] [[clang::may_alias]] foo {};
>>
>
>
>
> Probably not. Clang accepts the gnu:: namespace for attributes that
> originated with GCC.
>
>
>


[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

2022-12-06 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967

--- Comment #9 from Jakub Jelinek  ---
Created attachment 54029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54029=edit
gcc13-pr107967.patch

Untested fix.  Deferring the mode_composite stuff for later.

[PATCH 2/4] libbacktrace: detect executable path on windows

2022-12-06 Thread Björn Schäpers
From: Björn Schäpers 

This is actually needed so that libstdc++'s  implementation
to be able to work on windows.

Tested on x86_64-linux and i686-w64-mingw32.

-- >8 --

* configure.ac: Add a check for windows.h.
* configure, config.h.in: Regenerate.
* fileline.c: Add windows_get_executable_path.
* fileline.c (fileline_initialiez): Add a pass using
windows_get_executable_path.

Signed-off-by: Björn Schäpers 
---
 libbacktrace/configure.ac |  2 ++
 libbacktrace/fileline.c   | 43 ++-
 4 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/libbacktrace/configure.ac b/libbacktrace/configure.ac
index 1daaa2f62d2..b5feb29bcdc 100644
--- a/libbacktrace/configure.ac
+++ b/libbacktrace/configure.ac
@@ -377,6 +377,8 @@ if test "$have_loadquery" = "yes"; then
   AC_DEFINE(HAVE_LOADQUERY, 1, [Define if AIX loadquery is available.])
 fi
 
+AC_CHECK_HEADERS(windows.h)
+
 # Check for the fcntl function.
 if test -n "${with_target_subdir}"; then
case "${host}" in
diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index a40cd498114..73c2c8e8bc9 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -47,6 +47,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include 
 #endif
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 #include "backtrace.h"
 #include "internal.h"
 
@@ -155,6 +167,28 @@ macho_get_executable_path (struct backtrace_state *state,
 
 #endif /* !defined (HAVE_MACH_O_DYLD_H) */
 
+#ifdef HAVE_WINDOWS_H
+
+static char *
+windows_get_executable_path (char *buf, backtrace_error_callback 
error_callback,
+void *data)
+{
+  if (GetModuleFileNameA (NULL, buf, MAX_PATH - 1) == 0)
+{
+  error_callback (data,
+ "could not get the filename of the current executable",
+ (int) GetLastError ());
+  return NULL;
+}
+  return buf;
+}
+
+#else /* !defined (HAVE_WINDOWS_H) */
+
+#define windows_get_executable_path(buf, error_callback, data) NULL
+
+#endif /* !defined (HAVE_WINDOWS_H) */
+
 /* Initialize the fileline information from the executable.  Returns 1
on success, 0 on failure.  */
 
@@ -168,7 +202,11 @@ fileline_initialize (struct backtrace_state *state,
   int called_error_callback;
   int descriptor;
   const char *filename;
+#ifdef HAVE_WINDOWS_H
+  char buf[MAX_PATH];
+#else
   char buf[64];
+#endif
 
   if (!state->threaded)
 failed = state->fileline_initialization_failed;
@@ -192,7 +230,7 @@ fileline_initialize (struct backtrace_state *state,
 
   descriptor = -1;
   called_error_callback = 0;
-  for (pass = 0; pass < 8; ++pass)
+  for (pass = 0; pass < 9; ++pass)
 {
   int does_not_exist;
 
@@ -224,6 +262,9 @@ fileline_initialize (struct backtrace_state *state,
case 7:
  filename = macho_get_executable_path (state, error_callback, data);
  break;
+   case 8:
+ filename = windows_get_executable_path (buf, error_callback, data);
+ break;
default:
  abort ();
}
-- 
2.38.1



[PATCH 3/4] libbacktrace: work with aslr on windows

2022-12-06 Thread Björn Schäpers
From: Björn Schäpers 

Any underflow which might happen, will be countered by an overflow in
dwarf.c.

Tested on x86_64-linux and i686-w64-mingw32.

-- >8 --

Fixes https://github.com/ianlancetaylor/libbacktrace/issues/89 and
https://github.com/ianlancetaylor/libbacktrace/issues/82.

* pecoff.c (coff_add): Set the base_address of the module, to
find the debug information on moved applications.

Signed-off-by: Björn Schäpers 
---
 libbacktrace/pecoff.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 87b3c0cc647..296f1357b5f 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -39,6 +39,18 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include "backtrace.h"
 #include "internal.h"
 
+#ifdef HAVE_WINDOWS_H
+#ifndef WIN32_MEAN_AND_LEAN
+#define WIN32_MEAN_AND_LEAN
+#endif
+
+#ifndef NOMINMAX
+#define NOMINMAX
+#endif
+
+#include 
+#endif
+
 /* Coff file header.  */
 
 typedef struct {
@@ -610,6 +622,8 @@ coff_add (struct backtrace_state *state, int descriptor,
   int debug_view_valid;
   int is_64;
   uintptr_t image_base;
+  uintptr_t base_address = 0;
+  uintptr_t module_handle;
   struct dwarf_sections dwarf_sections;
 
   *found_sym = 0;
@@ -856,7 +870,12 @@ coff_add (struct backtrace_state *state, int descriptor,
  + (sections[i].offset - min_offset));
 }
 
-  if (!backtrace_dwarf_add (state, /* base_address */ 0, _sections,
+#ifdef HAVE_WINDOWS_H
+module_handle = (uintptr_t) GetModuleHandleW (NULL);
+base_address = module_handle - image_base;
+#endif
+
+  if (!backtrace_dwarf_add (state, base_address, _sections,
0, /* FIXME: is_bigendian */
NULL, /* altlink */
error_callback, data, fileline_fn,
-- 
2.38.1



[PATCH 4/4] libbacktrace: get debug information for loaded dlls

2022-12-06 Thread Björn Schäpers
From: Björn Schäpers 

Fixes https://github.com/ianlancetaylor/libbacktrace/issues/53, except
that libraries loaded after the backtrace_initialize are not handled.
But as far as I can see that's the same for elf.

Tested on x86_64-linux and i686-w64-mingw32.

-- >8 --

* pecoff.c (coff_add): New argument for the module handle of the
file, to get the base address.
* pecoff.c (backtrace_initialize): Iterate over loaded libraries
and call coff_add.

Signed-off-by: Björn Schäpers 
---
 libbacktrace/pecoff.c | 76 ---
 1 file changed, 72 insertions(+), 4 deletions(-)

diff --git a/libbacktrace/pecoff.c b/libbacktrace/pecoff.c
index 296f1357b5f..40395109e51 100644
--- a/libbacktrace/pecoff.c
+++ b/libbacktrace/pecoff.c
@@ -49,6 +49,7 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #endif
 
 #include 
+#include 
 #endif
 
 /* Coff file header.  */
@@ -592,7 +593,8 @@ coff_syminfo (struct backtrace_state *state, uintptr_t addr,
 static int
 coff_add (struct backtrace_state *state, int descriptor,
  backtrace_error_callback error_callback, void *data,
- fileline *fileline_fn, int *found_sym, int *found_dwarf)
+ fileline *fileline_fn, int *found_sym, int *found_dwarf,
+ uintptr_t module_handle ATTRIBUTE_UNUSED)
 {
   struct backtrace_view fhdr_view;
   off_t fhdr_off;
@@ -623,7 +625,6 @@ coff_add (struct backtrace_state *state, int descriptor,
   int is_64;
   uintptr_t image_base;
   uintptr_t base_address = 0;
-  uintptr_t module_handle;
   struct dwarf_sections dwarf_sections;
 
   *found_sym = 0;
@@ -871,7 +872,6 @@ coff_add (struct backtrace_state *state, int descriptor,
 }
 
 #ifdef HAVE_WINDOWS_H
-module_handle = (uintptr_t) GetModuleHandleW (NULL);
 base_address = module_handle - image_base;
 #endif
 
@@ -914,12 +914,80 @@ backtrace_initialize (struct backtrace_state *state,
   int found_sym;
   int found_dwarf;
   fileline coff_fileline_fn;
+  uintptr_t module_handle = 0;
+
+#ifdef HAVE_WINDOWS_H
+  DWORD i;
+  DWORD module_count;
+  DWORD bytes_needed_for_modules;
+  HMODULE *modules;
+  char module_name[MAX_PATH];
+  int module_found_sym;
+  fileline module_fileline_fn;
+
+  module_handle = (uintptr_t) GetModuleHandleW (NULL);
+#endif
 
   ret = coff_add (state, descriptor, error_callback, data,
- _fileline_fn, _sym, _dwarf);
+ _fileline_fn, _sym, _dwarf, module_handle);
   if (!ret)
 return 0;
 
+#ifdef HAVE_WINDOWS_H
+  module_count = 1000;
+ alloc_modules:
+  modules = backtrace_alloc (state, module_count * sizeof(HMODULE),
+error_callback, data);
+  if (modules == NULL)
+goto skip_modules;
+  if (!EnumProcessModules (GetCurrentProcess (), modules, module_count,
+  _needed_for_modules))
+{
+  error_callback(data, "Could not enumerate process modules",
+(int) GetLastError ());
+  goto free_modules;
+}
+  if (bytes_needed_for_modules > module_count * sizeof(HMODULE))
+{
+  backtrace_free (state, modules, module_count * sizeof(HMODULE),
+ error_callback, data);
+  // Add an extra of 2, if some module is loaded in another thread.
+  module_count = bytes_needed_for_modules / sizeof(HMODULE) + 2;
+  modules = NULL;
+  goto alloc_modules;
+}
+
+  for (i = 0; i < bytes_needed_for_modules / sizeof(HMODULE); ++i)
+{
+  if (GetModuleFileNameA (modules[i], module_name, MAX_PATH - 1))
+   {
+ if (strcmp (filename, module_name) == 0)
+   continue;
+
+ module_handle = (uintptr_t) GetModuleHandleA (module_name);
+ if (module_handle == 0)
+   continue;
+
+ descriptor = backtrace_open (module_name, error_callback, data, NULL);
+ if (descriptor < 0)
+   continue;
+
+ coff_add (state, descriptor, error_callback, data,
+   _fileline_fn, _found_sym, _dwarf,
+   module_handle);
+ if (module_found_sym)
+   found_sym = 1;
+   }
+}
+
+ free_modules:
+  if (modules)
+backtrace_free(state, modules, module_count * sizeof(HMODULE),
+  error_callback, data);
+  modules = NULL;
+ skip_modules:
+#endif
+
   if (!state->threaded)
 {
   if (found_sym)
-- 
2.38.1



[PATCH 1/4] libbacktrace: change all pc related variables to uintptr_t

2022-12-06 Thread Björn Schäpers
From: Björn Schäpers 

It's the right thing to do, since the PC shouldn't go out of the
uintptr_t domain, and in backtrace_pcinfo the pc is uintptr_t.
This is a preparation for a following patch.

Tested on x86_64-linux and i686-w64-mingw32.

-- >8 --

* dwarf.c: changed variables holding pc values from uint64_t to
uintptr_t.

Signed-off-by: Björn Schäpers 
---
 libbacktrace/dwarf.c | 44 ++--
 1 file changed, 22 insertions(+), 22 deletions(-)

diff --git a/libbacktrace/dwarf.c b/libbacktrace/dwarf.c
index 45cc9e77e40..0707ccddd3e 100644
--- a/libbacktrace/dwarf.c
+++ b/libbacktrace/dwarf.c
@@ -274,8 +274,8 @@ struct function
 struct function_addrs
 {
   /* Range is LOW <= PC < HIGH.  */
-  uint64_t low;
-  uint64_t high;
+  uintptr_t low;
+  uintptr_t high;
   /* Function for this address range.  */
   struct function *function;
 };
@@ -356,8 +356,8 @@ struct unit
 struct unit_addrs
 {
   /* Range is LOW <= PC < HIGH.  */
-  uint64_t low;
-  uint64_t high;
+  uintptr_t low;
+  uintptr_t high;
   /* Compilation unit for this address range.  */
   struct unit *u;
 };
@@ -1094,7 +1094,7 @@ resolve_addr_index (const struct dwarf_sections 
*dwarf_sections,
uint64_t addr_base, int addrsize, int is_bigendian,
uint64_t addr_index,
backtrace_error_callback error_callback, void *data,
-   uint64_t *address)
+   uintptr_t *address)
 {
   uint64_t offset;
   struct dwarf_buf addr_buf;
@@ -1194,7 +1194,7 @@ function_addrs_search (const void *vkey, const void 
*ventry)
 
 static int
 add_unit_addr (struct backtrace_state *state, void *rdata,
-  uint64_t lowpc, uint64_t highpc,
+  uintptr_t lowpc, uintptr_t highpc,
   backtrace_error_callback error_callback, void *data,
   void *pvec)
 {
@@ -1530,10 +1530,10 @@ lookup_abbrev (struct abbrevs *abbrevs, uint64_t code,
lowpc/highpc is set or ranges is set.  */
 
 struct pcrange {
-  uint64_t lowpc;  /* The low PC value.  */
+  uintptr_t lowpc; /* The low PC value.  */
   int have_lowpc;  /* Whether a low PC value was found.  */
   int lowpc_is_addr_index; /* Whether lowpc is in .debug_addr.  */
-  uint64_t highpc; /* The high PC value.  */
+  uintptr_t highpc;/* The high PC value.  */
   int have_highpc; /* Whether a high PC value was found.  */
   int highpc_is_relative;  /* Whether highpc is relative to lowpc.  */
   int highpc_is_addr_index;/* Whether highpc is in .debug_addr.  */
@@ -1613,16 +1613,16 @@ add_low_high_range (struct backtrace_state *state,
uintptr_t base_address, int is_bigendian,
struct unit *u, const struct pcrange *pcrange,
int (*add_range) (struct backtrace_state *state,
- void *rdata, uint64_t lowpc,
- uint64_t highpc,
+ void *rdata, uintptr_t lowpc,
+ uintptr_t highpc,
  backtrace_error_callback error_callback,
  void *data, void *vec),
void *rdata,
backtrace_error_callback error_callback, void *data,
void *vec)
 {
-  uint64_t lowpc;
-  uint64_t highpc;
+  uintptr_t lowpc;
+  uintptr_t highpc;
 
   lowpc = pcrange->lowpc;
   if (pcrange->lowpc_is_addr_index)
@@ -1663,7 +1663,7 @@ add_ranges_from_ranges (
 struct unit *u, uint64_t base,
 const struct pcrange *pcrange,
 int (*add_range) (struct backtrace_state *state, void *rdata,
- uint64_t lowpc, uint64_t highpc,
+ uintptr_t lowpc, uintptr_t highpc,
  backtrace_error_callback error_callback, void *data,
  void *vec),
 void *rdata,
@@ -1727,10 +1727,10 @@ add_ranges_from_rnglists (
 struct backtrace_state *state,
 const struct dwarf_sections *dwarf_sections,
 uintptr_t base_address, int is_bigendian,
-struct unit *u, uint64_t base,
+struct unit *u, uintptr_t base,
 const struct pcrange *pcrange,
 int (*add_range) (struct backtrace_state *state, void *rdata,
- uint64_t lowpc, uint64_t highpc,
+ uintptr_t lowpc, uintptr_t highpc,
  backtrace_error_callback error_callback, void *data,
  void *vec),
 void *rdata,
@@ -1796,8 +1796,8 @@ add_ranges_from_rnglists (
case DW_RLE_startx_endx:
  {
uint64_t index;
-   uint64_t low;
-   uint64_t high;
+   uintptr_t low;
+   uintptr_t high;
 
index = read_uleb128 (_buf);
if (!resolve_addr_index (dwarf_sections, u->addr_base,
@@ -1819,8 +1819,8 @@ add_ranges_from_rnglists 

[PATCH v4 15/19] modula2 front end: cc1gm2 additional non modula2 source files

2022-12-06 Thread Gaius Mulley via Gcc-patches


Version 4 contains two missed feedback suggestions (namespace in
m2pp.cc) and use build_nonstandard_integer_type in
gm2-lang.cc:gm2_type_for_size.

This patch set contains the .h, .cc and .flex files found in
gcc/m2.  The files are tightly coupled with the gimple interface
(see 04-gimple-interface) and built using the rules found in
(01-03-make).


--8<--8<--8<--8<--8<--8<
diff -ruw /dev/null gcc-git-devel-modula2/gcc/m2/gm2-lang.cc
--- /dev/null   2022-08-24 16:22:16.88870 +0100
+++ gcc-git-devel-modula2/gcc/m2/gm2-lang.cc2022-12-06 18:18:32.612239623 
+
@@ -0,0 +1,889 @@
+/* gm2-lang.cc language-dependent hooks for GNU Modula-2.
+
+Copyright (C) 2002-2022 Free Software Foundation, Inc.
+Contributed by Gaius Mulley .
+
+This file is part of GNU Modula-2.
+
+GNU Modula-2 is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GNU Modula-2 is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Modula-2; see the file COPYING.  If not, write to the
+Free Software Foundation, 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301, USA.  */
+
+#include "gm2-gcc/gcc-consolidation.h"
+
+#include "langhooks-def.h" /* FIXME: for lhd_set_decl_assembler_name.  */
+#include "tree-pass.h" /* FIXME: only for PROP_gimple_any.  */
+#include "toplev.h"
+#include "debug.h"
+
+#include "opts.h"
+
+#define GM2_LANG_C
+#include "gm2-lang.h"
+#include "m2block.h"
+#include "dynamicstrings.h"
+#include "m2options.h"
+#include "m2convert.h"
+#include "m2linemap.h"
+#include "init.h"
+#include "m2-tree.h"
+#include "convert.h"
+#include "rtegraph.h"
+
+static void write_globals (void);
+
+static int insideCppArgs = FALSE;
+
+#define EXPR_STMT_EXPR(NODE) TREE_OPERAND (EXPR_STMT_CHECK (NODE), 0)
+
+/* start of new stuff.  */
+
+/* Language-dependent contents of a type.  */
+
+struct GTY (()) lang_type
+{
+  char dummy;
+};
+
+/* Language-dependent contents of a decl.  */
+
+struct GTY (()) lang_decl
+{
+  char dummy;
+};
+
+/* Language-dependent contents of an identifier.  This must include a
+   tree_identifier.  */
+
+struct GTY (()) lang_identifier
+{
+  struct tree_identifier common;
+};
+
+/* The resulting tree type.  */
+
+union GTY ((desc ("TREE_CODE (&%h.generic) == IDENTIFIER_NODE"),
+chain_next ("CODE_CONTAINS_STRUCT (TREE_CODE (&%h.generic), "
+"TS_COMMON) ? ((union lang_tree_node *) TREE_CHAIN "
+"(&%h.generic)) : NULL"))) lang_tree_node
+{
+  union tree_node GTY ((tag ("0"),
+desc ("tree_node_structure (&%h)"))) generic;
+  struct lang_identifier GTY ((tag ("1"))) identifier;
+};
+
+struct GTY (()) language_function
+{
+
+  /* While we are parsing the function, this contains information about
+  the statement-tree that we are building.  */
+  /* struct stmt_tree_s stmt_tree;  */
+  tree stmt_tree;
+};
+
+/* Language hooks.  */
+
+bool
+gm2_langhook_init (void)
+{
+  build_common_tree_nodes (false);
+  build_common_builtin_nodes ();
+
+  /* The default precision for floating point numbers.  This is used
+ for floating point constants with abstract type.  This may eventually
+ be controllable by a command line option.  */
+  mpfr_set_default_prec (256);
+
+  /* GNU Modula-2 uses exceptions.  */
+  using_eh_for_cleanups ();
+  return true;
+}
+
+/* The option mask.  */
+
+static unsigned int
+gm2_langhook_option_lang_mask (void)
+{
+  return CL_ModulaX2;
+}
+
+/* Initialize the options structure.  */
+
+static void
+gm2_langhook_init_options_struct (struct gcc_options *opts)
+{
+  /* Default to avoiding range issues for complex multiply and divide.  */
+  opts->x_flag_complex_method = 2;
+
+  /* The builtin math functions should not set errno.  */
+  opts->x_flag_errno_math = 0;
+  opts->frontend_set_flag_errno_math = true;
+
+  /* Exceptions are used.  */
+  opts->x_flag_exceptions = 1;
+  init_FrontEndInit ();
+}
+
+/* Infrastructure for a VEC of bool values.  */
+
+/* This array determines whether the filename is associated with the
+   C preprocessor.  */
+
+static vec filename_cpp;
+
+void
+gm2_langhook_init_options (unsigned int decoded_options_count,
+   struct cl_decoded_option *decoded_options)
+{
+  unsigned int i;
+  bool in_cpp_args = false;
+
+  for (i = 1; i < decoded_options_count; i++)
+{
+  switch (decoded_options[i].opt_index)
+{
+case OPT_fcpp_begin:
+  in_cpp_args = true;
+  break;
+case OPT_fcpp_end:
+  in_cpp_args = false;
+  break;
+case 

Re: Using [[may_alias]] in C23/C++23 on a union works in neither post-"union" position, or at the end of the definition

2022-12-06 Thread Jonathan Wakely via Gcc
On Tue, 6 Dec 2022, 18:36 Gavin Ray via Gcc,  wrote:

> Oh, D'oh! Thanks Joseph, apologies for the needless email on the list then.
>
> One final question if I could -- does that mean that in order to support
> "may-alias" with the bracket syntax on both Clang and GCC, it would
> require:
>
>  union [[gnu::may_alias]] [[clang::may_alias]] foo {};
>



Probably not. Clang accepts the gnu:: namespace for attributes that
originated with GCC.


  1   2   3   4   >