Re: [pushed] aarch64: Define out-of-class static constants

[Vaseeharan Vinayagamoorthy]

Hi Richard,

I think this patch is breaking the build of aarch64-none-elf and 
aarch64-none-linux-gnu targets, when building with GCC 4.8.
This is not an issue when building with GCC 7.5.

Kind regards,
Vasee


From: Richard Sandiford 
Sent: 06 March 2024 10:06
To: gcc-patches@gcc.gnu.org
Subject: [pushed] aarch64: Define out-of-class static constants

While reworking the aarch64 feature descriptions, I forgot
to add out-of-class definitions of some static constants.
This could lead to a build failure with some compilers.

This was seen with some WIP to increase the number of extensions
beyond 64.  It's latent on trunk though, and a regression from
before the rework.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
* config/aarch64/aarch64-feature-deps.h (feature_deps::info): Add
out-of-class definitions of static constants.
---
 gcc/config/aarch64/aarch64-feature-deps.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/config/aarch64/aarch64-feature-deps.h 
b/gcc/config/aarch64/aarch64-feature-deps.h
index a1b81f9070b..3641badb82f 100644
--- a/gcc/config/aarch64/aarch64-feature-deps.h
+++ b/gcc/config/aarch64/aarch64-feature-deps.h
@@ -71,6 +71,9 @@ template struct info;
 static constexpr auto enable = flag | get_enable REQUIRES; \
 static constexpr auto explicit_on = enable | get_enable EXPLICIT_ON; \
   };   \
+  const aarch64_feature_flags info::flag;  \
+  const aarch64_feature_flags info::enable;\
+  const aarch64_feature_flags info::explicit_on; \
   constexpr info IDENT ()  \
   {\
 return info ();\
--
2.25.1

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

[Vaseeharan Vinayagamoorthy]

Hi Lipeng,

It looks like your draft patch to fix the builds for arm-none-eabi target is 
not merged yet, because our arm-none-eabi builds are still broken. Are you 
waiting for additional information, or would you be able to fix this issue?

Kind regards,
Vasee

From: Richard Earnshaw 
Sent: 15 December 2023 19:23
To: Lipeng Zhu ; Richard Earnshaw 
; ja...@redhat.com 
Cc: fort...@gcc.gnu.org ; gcc-patches@gcc.gnu.org 
; hongjiu...@intel.com ; 
pan.d...@intel.com ; rep.dot@gmail.com 
; tianyou...@intel.com ; 
tkoe...@netcologne.de ; wangyang@intel.com 

Subject: Re: [PATCH v7] libgfortran: Replace mutex with rwlock



On 15/12/2023 11:31, Lipeng Zhu wrote:
>
>
> On 2023/12/14 23:50, Richard Earnshaw (lists) wrote:
>> On 09/12/2023 15:39, Lipeng Zhu wrote:
>>> This patch try to introduce the rwlock and split the read/write to
>>> unit_root tree and unit_cache with rwlock instead of the mutex to
>>> increase CPU efficiency. In the get_gfc_unit function, the percentage
>>> to step into the insert_unit function is around 30%, in most instances,
>>> we can get the unit in the phase of reading the unit_cache or unit_root
>>> tree. So split the read/write phase by rwlock would be an approach to
>>> make it more parallel.
>>>
>>> BTW, the IPC metrics can gain around 9x in our test
>>> server with 220 cores. The benchmark we used is
>>> https://github.com/rwesson/NEAT
>>>
>>> libgcc/ChangeLog:
>>>
>>> * gthr-posix.h (__GTHREAD_RWLOCK_INIT): New macro.
>>> (__gthrw): New function.
>>> (__gthread_rwlock_rdlock): New function.
>>> (__gthread_rwlock_tryrdlock): New function.
>>> (__gthread_rwlock_wrlock): New function.
>>> (__gthread_rwlock_trywrlock): New function.
>>> (__gthread_rwlock_unlock): New function.
>>>
>>> libgfortran/ChangeLog:
>>>
>>> * io/async.c (DEBUG_LINE): New macro.
>>> * io/async.h (RWLOCK_DEBUG_ADD): New macro.
>>> (CHECK_RDLOCK): New macro.
>>> (CHECK_WRLOCK): New macro.
>>> (TAIL_RWLOCK_DEBUG_QUEUE): New macro.
>>> (IN_RWLOCK_DEBUG_QUEUE): New macro.
>>> (RDLOCK): New macro.
>>> (WRLOCK): New macro.
>>> (RWUNLOCK): New macro.
>>> (RD_TO_WRLOCK): New macro.
>>> (INTERN_RDLOCK): New macro.
>>> (INTERN_WRLOCK): New macro.
>>> (INTERN_RWUNLOCK): New macro.
>>> * io/io.h (struct gfc_unit): Change UNIT_LOCK to UNIT_RWLOCK in
>>> a comment.
>>> (unit_lock): Remove including associated internal_proto.
>>> (unit_rwlock): New declarations including associated internal_proto.
>>> (dec_waiting_unlocked): Use WRLOCK and RWUNLOCK on unit_rwlock
>>> instead of __gthread_mutex_lock and __gthread_mutex_unlock on
>>> unit_lock.
>>> * io/transfer.c (st_read_done_worker): Use WRLOCK and RWUNLOCK on
>>> unit_rwlock instead of LOCK and UNLOCK on unit_lock.
>>> (st_write_done_worker): Likewise.
>>> * io/unit.c: Change UNIT_LOCK to UNIT_RWLOCK in 'IO locking rules'
>>> comment. Use unit_rwlock variable instead of unit_lock variable.
>>> (get_gfc_unit_from_unit_root): New function.
>>> (get_gfc_unit): Use RDLOCK, WRLOCK and RWUNLOCK on unit_rwlock
>>> instead of LOCK and UNLOCK on unit_lock.
>>> (close_unit_1): Use WRLOCK and RWUNLOCK on unit_rwlock instead of
>>> LOCK and UNLOCK on unit_lock.
>>> (close_units): Likewise.
>>> (newunit_alloc): Use RWUNLOCK on unit_rwlock instead of UNLOCK on
>>> unit_lock.
>>> * io/unix.c (find_file): Use RDLOCK and RWUNLOCK on unit_rwlock
>>> instead of LOCK and UNLOCK on unit_lock.
>>> (flush_all_units): Use WRLOCK and RWUNLOCK on unit_rwlock instead
>>> of LOCK and UNLOCK on unit_lock.
>>>
>>
>> It looks like this has broken builds on arm-none-eabi when using newlib:
>>
>> In file included from
>> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran
>> /runtime/error.c:27:
>> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h: In
>> function
>> ‘dec_waiting_unlocked’:
>> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1023:3: 
>> error
>> : implicit declaration of function ‘WRLOCK’
>> [-Wimplicit-function-declaration]
>>   1023 |   WRLOCK (_rwlock);
>>|   ^~
>> /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1025:3: 
>> error
>> : implicit declaration of function ‘RWUNLOCK’
>> [-Wimplicit-function-declaration]
>>   1025 |   RWUNLOCK (_rwlock);
>>|   ^~~~
>>
>>
>> R.
>
> Hi Richard,
>
> The root cause is that the macro WRLOCK and RWUNLOCK are not defined in
> io.h. The reason of x86 platform not failed is that
> HAVE_ATOMIC_FETCH_ADD is defined then caused above macros were never
> been used. Code logic show as below:
> #ifdef HAVE_ATOMIC_FETCH_ADD
>(void) __atomic_fetch_add (>waiting, -1, __ATOMIC_RELAXED);
> #else
>WRLOCK (_rwlock);
>u->waiting--;
>RWUNLOCK (_rwlock);
> #endif
>
> I just draft a patch try to fix this bug, because I didn't have arm
> platform, would you 

Re: [PATCH] tree-optimization/107672 - avoid vector mode type_for_mode call

[Vaseeharan Vinayagamoorthy via Gcc-patches]

Hi,


I am seeing an internal compiler error, related to this patch:



during GIMPLE pass: slp

options-save.cc: In function 'void cl_optimization_restore(gcc_options*, 
gcc_options*, cl_optimization*)':

options-save.cc:1292:1: internal compiler error: in 
supportable_widening_operation, at tree-vect-stmts.cc:12199


 1292 | cl_optimization_restore (struct gcc_options *opts, struct gcc_options 
*opts_set,

 | ^~~

/…/src/gcc/gcc/profile-count.cc: In member function 'int 
profile_count::to_cgraph_frequency(profile_count) const':

/…/src/gcc/gcc/profile-count.cc:308:1: note: parameter passing for argument of 
type 'profile_count' changed in GCC 9.1

 308 | profile_count::to_cgraph_frequency (profile_count entry_bb_count) const

 | ^

/…/src/gcc/gcc/profile-count.cc: In member function 'sreal 
profile_count::to_sreal_scale(profile_count, bool*) const':

/…/src/gcc/gcc/profile-count.cc:326:1: note: parameter passing for argument of 
type 'profile_count' changed in GCC 9.1

 326 | profile_count::to_sreal_scale (profile_count in, bool *known) const

 | ^

0x2195bdd supportable_widening_operation(vec_info*, tree_code, _stmt_vec_info*, 
tree_node*, tree_node*, tree_code*, tree_code*, int*, vec*)

 /…/src/gcc/gcc/tree-vect-stmts.cc:12199

0x2180493 vectorizable_conversion

 /…/src/gcc/gcc/tree-vect-stmts.cc:5064

0x2192fdd vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, 
_slp_instance*, vec*)

 /…/src/gcc/gcc/tree-vect-stmts.cc:11256


/…/src/gcc/gcc/profile-count.cc: In member function 'profile_count 
profile_count::combine_with_ipa_count(profile_count)':

/…/src/gcc/gcc/profile-count.cc:398:1: note: parameter passing for argument of 
type 'profile_count' changed in GCC 9.1

 398 | profile_count::combine_with_ipa_count (profile_count ipa)

 | ^

0x14f95d1 vect_slp_analyze_node_operations_1

 /…/src/gcc/gcc/tree-vect-slp.cc:5958

0x14f9c19 vect_slp_analyze_node_operations

 /…/src/gcc/gcc/tree-vect-slp.cc:6147

0x14f9b4d vect_slp_analyze_node_operations

 /…/src/gcc/gcc/tree-vect-slp.cc:6126

0x14fa439 vect_slp_analyze_operations(vec_info*)

 /…/src/gcc/gcc/tree-vect-slp.cc:6387

0x14fd423 vect_slp_analyze_bb_1

 /…/src/gcc/gcc/tree-vect-slp.cc:7372

0x14fd599 vect_slp_region

 /…/src/gcc/gcc/tree-vect-slp.cc:7419

0x14fe0d1 vect_slp_bbs

 /…/src/gcc/gcc/tree-vect-slp.cc:7610

0x14fe46f vect_slp_function(function*)

 /…/src/gcc/gcc/tree-vect-slp.cc:7698

0x151a109 execute

 /…/src/gcc/gcc/tree-vectorizer.cc:1532

Please submit a full bug report, with preprocessed source (by using 
-freport-bug).

Please include the complete backtrace with any bug report.

See  for instructions.

Makefile:1146: recipe for target 'options-save.o' failed

make[3]: *** [options-save.o] Error 1


That happens when building the arm-none-linux-gnueabihf toolchain natively with 
glibc bootstrap:
Build:arm-none-linux-gnueabihf
Host:arm-none-linux-gnueabihf
Target: arm-none-linux-gnueabihf

The compiler being used to build the toolchain is gcc 7.5.0.


Kind regards
Vasee

From: Gcc-patches  on behalf 
of Richard Biener via Gcc-patches 
Sent: 22 November 2022 08:48
To: gcc-patches@gcc.gnu.org 
Subject: [PATCH] tree-optimization/107672 - avoid vector mode type_for_mode call

The following avoids using type_for_mode on vector modes which might
not work for all frontends.  Instead we look for the inner mode
type and use build_vector_type_for_mode instead.

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

PR tree-optimization/107672
* tree-vect-stmts.cc (supportable_widening_operation): Avoid
type_for_mode on vector modes.
---
 gcc/tree-vect-stmts.cc | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index bc0ef136f19..b35b986889d 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -12195,9 +12195,15 @@ supportable_widening_operation (vec_info *vinfo,
 intermediate_type
   = vect_halve_mask_nunits (prev_type, intermediate_mode);
   else
-   intermediate_type
- = lang_hooks.types.type_for_mode (intermediate_mode,
-   TYPE_UNSIGNED (prev_type));
+   {
+ gcc_assert (VECTOR_MODE_P (intermediate_mode));
+ tree intermediate_element_type
+   = lang_hooks.types.type_for_mode (GET_MODE_INNER 
(intermediate_mode),
+ TYPE_UNSIGNED (prev_type));
+ intermediate_type
+   = build_vector_type_for_mode (intermediate_element_type,
+ intermediate_mode);
+   }

   if (VECTOR_BOOLEAN_TYPE_P (intermediate_type)
   && VECTOR_BOOLEAN_TYPE_P (prev_type)
--
2.35.3

Re: V3 [PATCH 1/2] Switch to a new section if the SECTION_RETAIN bit doesn't match

[Vaseeharan Vinayagamoorthy via Gcc-patches]

This patch fixes the section type conflict that I have been seeing. I have 
tested this patch using :
Build: x86_64
Host: x86_64
Target: aarch64-none-linux-gnu



On 08/12/2020, 12:52, "Gcc-patches on behalf of H.J. Lu via Gcc-patches" 
 wrote:

When definitions marked with used attribute and unmarked definitions are
placed in the section with the same name, switch to a new section if the
SECTION_RETAIN bit doesn't match.

gcc/

PR target/98146
* output.h (switch_to_section): Add a tree argument, default to
nullptr.
* varasm.c (get_section): If the SECTION_RETAIN bit doesn't match,
return and switch to a new section later.
(assemble_start_function): Pass decl to switch_to_section.
(assemble_variable): Likewise.
(switch_to_section): If the SECTION_RETAIN bit doesn't match,
switch to a new section.

gcc/testsuite/

PR target/98146
* c-c++-common/attr-used-5.c: New test.
* c-c++-common/attr-used-6.c: Likewise.
* c-c++-common/attr-used-7.c: Likewise.
* c-c++-common/attr-used-8.c: Likewise.
* c-c++-common/attr-used-9.c: Likewise.
---
 gcc/output.h |  2 +-
 gcc/testsuite/c-c++-common/attr-used-5.c | 26 
 gcc/testsuite/c-c++-common/attr-used-6.c | 26 
 gcc/testsuite/c-c++-common/attr-used-7.c |  8 +++
 gcc/testsuite/c-c++-common/attr-used-8.c |  8 +++
 gcc/testsuite/c-c++-common/attr-used-9.c | 28 ++
 gcc/varasm.c | 30 
 7 files changed, 123 insertions(+), 5 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-5.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-6.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-7.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-8.c
 create mode 100644 gcc/testsuite/c-c++-common/attr-used-9.c

diff --git a/gcc/output.h b/gcc/output.h
index fa8ace1f394..1f9af46da1d 100644
--- a/gcc/output.h
+++ b/gcc/output.h
@@ -548,7 +548,7 @@ extern void switch_to_other_text_partition (void);
 extern section *get_cdtor_priority_section (int, bool);

 extern bool unlikely_text_section_p (section *);
-extern void switch_to_section (section *);
+extern void switch_to_section (section *, tree = nullptr);
 extern void output_section_asm_op (const void *);

 extern void record_tm_clone_pair (tree, tree);
diff --git a/gcc/testsuite/c-c++-common/attr-used-5.c 
b/gcc/testsuite/c-c++-common/attr-used-5.c
new file mode 100644
index 000..9fc0d3834e9
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-used-5.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+struct dtv_slotinfo_list
+{
+  struct dtv_slotinfo_list *next;
+};
+
+extern struct dtv_slotinfo_list *list;
+
+static int __attribute__ ((section ("__libc_freeres_fn")))
+free_slotinfo (struct dtv_slotinfo_list **elemp)
+{
+  if (!free_slotinfo (&(*elemp)->next))
+return 0;
+  return 1;
+}
+
+__attribute__ ((used, section ("__libc_freeres_fn")))
+static void free_mem (void)
+{
+  free_slotinfo ();
+}
+
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"ax\"" { target 
R_flag_in_section } } } */
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"axR\"" { target 
R_flag_in_section } } } */
diff --git a/gcc/testsuite/c-c++-common/attr-used-6.c 
b/gcc/testsuite/c-c++-common/attr-used-6.c
new file mode 100644
index 000..0cb82ade5a9
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-used-6.c
@@ -0,0 +1,26 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+struct dtv_slotinfo_list
+{
+  struct dtv_slotinfo_list *next;
+};
+
+extern struct dtv_slotinfo_list *list;
+
+static int __attribute__ ((used, section ("__libc_freeres_fn")))
+free_slotinfo (struct dtv_slotinfo_list **elemp)
+{
+  if (!free_slotinfo (&(*elemp)->next))
+return 0;
+  return 1;
+}
+
+__attribute__ ((section ("__libc_freeres_fn")))
+void free_mem (void)
+{
+  free_slotinfo ();
+}
+
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"ax\"" { target 
R_flag_in_section } } } */
+/* { dg-final { scan-assembler "__libc_freeres_fn,\"axR\"" { target 
R_flag_in_section } } } */
diff --git a/gcc/testsuite/c-c++-common/attr-used-7.c 
b/gcc/testsuite/c-c++-common/attr-used-7.c
new file mode 100644
index 000..fba2706ffc1
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/attr-used-7.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-options "-Wall -O2" } */
+
+int __attribute__((used,section(".data.foo"))) 

Re: Fix handling of stores in modref_summary::useful_p

[Vaseeharan Vinayagamoorthy via Gcc-patches]

Hi,

After this patch, I am noticing that some glibc crypto tests get stuck in scanf 
which goes into busy loop.

My build/host/target setup is:
Build: aarch64-none-linux-gnu
Host: aarch64-none-linux-gnu
Target: aarch64-none-linux-gnu



Kind regards
Vasee


On 27/09/2020, 22:46, "Gcc-patches on behalf of Jan Hubicka" 
 wrote:

Hi,
this patch fixes a pasto in modref_summary::useful_p that made
ipa-modref to give up on tracking stores when all load info got lost.

Bootstrapped/regtested x86_64-linux, comitted.

gcc/ChangeLog:

2020-09-27  Jan Hubicka  

* ipa-modref.c (modref_summary::useful_p): Fix testing of stores.

diff --git a/gcc/ipa-modref.c b/gcc/ipa-modref.c
index 728c6c1523d..6225552e41a 100644
--- a/gcc/ipa-modref.c
+++ b/gcc/ipa-modref.c
@@ -135,7 +135,7 @@ modref_summary::useful_p (int ecf_flags)
 return true;
   if (ecf_flags & ECF_PURE)
 return false;
-  return stores && !loads->every_base;
+  return stores && !stores->every_base;
 }

 /* Dump A to OUT.  */

Re: [PING 2][PATCH 2/5] C front end support to detect out-of-bounds accesses to array parameters

[Vaseeharan Vinayagamoorthy]

After this patch, I am seeing this -Warray-parameter error:

In file included from ../include/pthread.h:1,
 from ../sysdeps/nptl/thread_db.h:25,
 from ../nptl/descr.h:32,
 from ../sysdeps/aarch64/nptl/tls.h:44,
 from ../include/errno.h:25,
 from ../sysdeps/unix/sysv/linux/sysdep.h:23,
 from ../sysdeps/unix/sysv/linux/generic/sysdep.h:22,
 from ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:24,
 from :1:
../sysdeps/nptl/pthread.h:734:47: error: argument 1 of type ‘struct 
__jmp_buf_tag *’ declared as a pointer [-Werror=array-parameter=]
  734 | extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) 
__THROWNL;
  | ~~^
In file included from ../include/setjmp.h:2,
 from ../nptl/descr.h:24,
 from ../sysdeps/aarch64/nptl/tls.h:44,
 from ../include/errno.h:25,
 from ../sysdeps/unix/sysv/linux/sysdep.h:23,
 from ../sysdeps/unix/sysv/linux/generic/sysdep.h:22,
 from ../sysdeps/unix/sysv/linux/aarch64/sysdep.h:24,
 from :1:
../setjmp/setjmp.h:54:46: note: previously declared as an array ‘struct 
__jmp_buf_tag[1]’
   54 | extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask) 
__THROWNL;
  | ~^~~~
cc1: all warnings being treated as errors


The build/host/target setup is:
Build: x86_64-linux-gnu (Ubuntu 18.04)
Host: x86_64-linux-gnu
Target: aarch64-none-linux-gnu, aarch64_be-none-linux-gnu, 
arm-none-linux-gnueabi, arm-none-linux-gnueabihf



Kind regards
Vasee



On 20/09/2020, 01:02, "Gcc-patches on behalf of Martin Sebor via Gcc-patches" 
 wrote:

On 9/17/20 4:38 PM, Joseph Myers wrote:
> On Wed, 16 Sep 2020, Martin Sebor via Gcc-patches wrote:
> 
>> Attached is an updated revision of the patch.  Besides the tweaks
>> above it also contains a cosmetic change to the warning issued
>> for mismatches in unspecified VLA bounds: it points at the decl
>> with more of them to guide the user to specify them rather than
>> make them all unspecified.
> 
> The previous version of the patch had a while loop as previously discussed
> to handle skipping multiple consecutive cdk_attrs.
> 
> +  next = pd->declarator;
> +  while (next && next->kind == cdk_attrs)
> +   next = next->declarator;
> 
> This version is back to an "if", but I don't see anything else in the new
> version of that function that actually means the "if" would skip multiple
> consecutive cdk_attrs as desired.
> 
> The patch is OK with the "while" restored there.  If for some reason the
> "while" breaks something, we'll need to look in more detail at exactly
> what case isn't being handled correctly by "while".

I guess it was the result of an experiment, trying to see if I could
break it with the 'if'.  I (hope I) put it back and pushed the whole
series.  I had to squash patches 1 and 2 because of a dependency that
I had missed.

Thanks for the review, by the way.  I think the signature validation
we've ended up with is quite a bit more comprehensive than the first
attempt.

Martin

Re: [PATCH] arm: Fix up gcc.target/arm/lto/pr96939_* FAIL

[Vaseeharan Vinayagamoorthy]

I am seeing this unused parameter 'opts' error when building for this 
configuration:
Build: arm-none-linux-gnueabihf
Host: arm-none-linux-gnueabihf
Target: arm-none-linux-gnueabihf

In function 'void arm_option_restore(gcc_options*, gcc_options*, 
cl_target_option*)':
/src/gcc/gcc/config/arm/arm.c:3042:41: error: unused parameter 'opts' 
[-Werror=unused-parameter]
 3042 | arm_option_restore (struct gcc_options *opts, struct gcc_options 
*opts_set,
  | ^~~~


Regards
Vasee


On 13/09/2020, 09:39, "Gcc-patches on behalf of Jakub Jelinek via Gcc-patches" 
 wrote:

Hi!

The following patch on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553801.html
patch fixes the gcc.target/arm/lto/pr96939_* test in certain ARM
configurations.
As said in the above mentioned patch, the generic code takes care of
saving/restoring TargetVariables or Target Save options, so this just
arranges for the generic code to save those instead of needing the
arm backend to do it manually.

Bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?

2020-09-13  Jakub Jelinek  

* config/arm/arm.opt (x_arm_arch_string, x_arm_cpu_string,
x_arm_tune_string): Remove TargetSave entries.
(march=, mcpu=, mtune=): Add Save keyword.
* config/arm/arm.c (arm_option_save): Remove.
(TARGET_OPTION_SAVE): Don't redefine.
(arm_option_restore): Don't restore x_arm_*_string here.

--- gcc/config/arm/arm.opt.jj   2020-01-12 11:54:36.273415521 +0100
+++ gcc/config/arm/arm.opt  2020-09-12 10:45:51.239935884 +0200
@@ -21,15 +21,6 @@
 HeaderInclude
 config/arm/arm-opts.h

-TargetSave
-const char *x_arm_arch_string
-
-TargetSave
-const char *x_arm_cpu_string
-
-TargetSave
-const char *x_arm_tune_string
-
 Enum
 Name(tls_type) Type(enum arm_tls_type)
 TLS dialect to use:
@@ -82,7 +73,7 @@ mapcs-stack-check
 Target Report Mask(APCS_STACK) Undocumented

 march=
-Target RejectNegative Negative(march=) ToLower Joined Var(arm_arch_string)
+Target Save RejectNegative Negative(march=) ToLower Joined 
Var(arm_arch_string)
 Specify the name of the target architecture.

 ; Other arm_arch values are loaded from arm-tables.opt
@@ -107,7 +98,7 @@ Target Report Mask(CALLER_INTERWORKING)
 Thumb: Assume function pointers may go to non-Thumb aware code.

 mcpu=
-Target RejectNegative Negative(mcpu=) ToLower Joined Var(arm_cpu_string)
+Target Save RejectNegative Negative(mcpu=) ToLower Joined 
Var(arm_cpu_string)
 Specify the name of the target CPU.

 mfloat-abi=
@@ -232,7 +223,7 @@ Target Report Mask(TPCS_LEAF_FRAME)
 Thumb: Generate (leaf) stack frames even if not needed.

 mtune=
-Target RejectNegative Negative(mtune=) ToLower Joined Var(arm_tune_string)
+Target Save RejectNegative Negative(mtune=) ToLower Joined 
Var(arm_tune_string)
 Tune code for the given processor.

 mprint-tune-info
--- gcc/config/arm/arm.c.jj 2020-09-11 17:44:28.643014087 +0200
+++ gcc/config/arm/arm.c2020-09-12 10:48:09.951888347 +0200
@@ -247,8 +247,6 @@ static tree arm_build_builtin_va_list (v
 static void arm_expand_builtin_va_start (tree, rtx);
 static tree arm_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq 
*);
 static void arm_option_override (void);
-static void arm_option_save (struct cl_target_option *, struct gcc_options 
*,
-struct gcc_options *);
 static void arm_option_restore (struct gcc_options *, struct gcc_options *,
struct cl_target_option *);
 static void arm_override_options_after_change (void);
@@ -443,9 +441,6 @@ static const struct attribute_spec arm_a
 #undef TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
 #define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE 
arm_override_options_after_change

-#undef TARGET_OPTION_SAVE
-#define TARGET_OPTION_SAVE arm_option_save
-
 #undef TARGET_OPTION_RESTORE
 #define TARGET_OPTION_RESTORE arm_option_restore

@@ -3042,24 +3037,11 @@ arm_override_options_after_change (void)
   arm_override_options_after_change_1 (_options, 
_options_set);
 }

-/* Implement TARGET_OPTION_SAVE.  */
-static void
-arm_option_save (struct cl_target_option *ptr, struct gcc_options *opts,
-struct gcc_options */* opts_set */)
-{
-  ptr->x_arm_arch_string = opts->x_arm_arch_string;
-  ptr->x_arm_cpu_string = opts->x_arm_cpu_string;
-  ptr->x_arm_tune_string = opts->x_arm_tune_string;
-}
-
 /* Implement TARGET_OPTION_RESTORE.  */
 static void
 arm_option_restore (struct gcc_options *opts, struct gcc_options *opts_set,
struct cl_target_option *ptr)
 {
-  opts->x_arm_arch_string = ptr->x_arm_arch_string;
-  opts->x_arm_cpu_string 

Re: [PATCH] configure: Require C++11 for building code generation tools

[Vaseeharan Vinayagamoorthy]

Hi Tobias,

This patch fixes the issue that I was seeing, thanks.
I will also now try your updated patch from 
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552330.html

Kind Regards
Vasee

On 20/08/2020, 17:29, "Tobias Burnus"  wrote:

Hi,

how about my (unreviewed) patch for PR 96612 at
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551900.html ?

That one also tries to solve the CXX_FOR_BUILD issue with an older GCC.
Would that solve your issue as well?

Tobias

On 8/20/20 4:19 PM, Ilya Leoshkevich via Gcc-patches wrote:

> On Thu, 2020-08-20 at 13:59 +0100, Vasee Vinayagamoorthy wrote:
>> Hello,
>>
>> After commit [1] ("Redefine NULL to nullptr"), building gcc
>> fails when $CXX_FOR_BUILD is not using C++11 mode by default.
>> This happens with gcc-4.8 which is still supported.
>>
>> This patch fixes this by adding -std=c++11 or its equivalent
>> to $CXX_FOR_BUILD using AX_CXX_COMPILE_STDCXX(11).
>>
>> Tested by successful cross native build for aarch64-none-linux-gnu
>> target.
>>
>> OK for trunk?
>>
>>
>> ChangeLog:
>>
>> 2020-08-20  Ilya Leoshkevich  
>>  Vasee Vinayagamoorthy  <
>> vaseeharan.vinayagamoor...@arm.com>
>>
>>  PR target/95700
>>  * configure: Regenerate.
>>  * configure.ac: Require C++11 for building code generation
>> tools.
>>
>> Regards
>> Vasee Vinayagamoorthy
>>
>>
>> PS: I do not have commit rights, therefore could I request
>> someone to commit it on my behalf if this patch is approved.
>> Thanks in advance.
>>
>> [1]
>> 
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d59a576b8b5e12c3a56f0262912090e2921f5daa
> Hi!
>
> First of all, sorry about losing track of this issue.
>
> Regarding your addition to the patch, I fear that
>
> CXX="$CXX -std=c++11"
>
> might break some rarely used compilers. But doing this portably is
> exactly what AX_CXX_COMPILE_STDCXX(11) is for. Do you know why isn't it
> working for you?
>
> Best regards,
> Ilya
>
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / 
Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, 
Alexander Walter

Re: [PATCH] configure: Require C++11 for building code generation tools

[Vaseeharan Vinayagamoorthy]

Hi Szabolcs,

In the top level gcc config.log, I see:

configure:5541: checking whether aarch64-none-linux-gnu-g++ supports C++11 
features by default
configure:5837: aarch64-none-linux-gnu-g++ -c -g -O2  conftest.cpp >&5
configure:5837: $? = 0
configure:5844: result: yes
configure:6542: checking whether g++ supports C++11 features by default
configure:6845: result: yes

Not sure whether that helps?

Regards
Vasee


On 20/08/2020, 16:26, "Szabolcs Nagy"  wrote:

The 08/20/2020 13:59, Vasee Vinayagamoorthy wrote:
> +# Also require C++11 for building code generation tools.
> +# Do nothing if "${build}" = "${host}", because in this case
> +# CXX_FOR_BUILD="\$(CXX)", and $CXX is already set to the correct value 
above.
> +if test "${build}" != "${host}"; then
> +  saved_CXX=$CXX
> +  saved_CXXCPP=$CXXCPP
> +  CXX=$CXX_FOR_BUILD
> +  CXXCPP=
> +  AX_CXX_COMPILE_STDCXX(11)
> +  CXX="$CXX -std=c++11"
> +  CXX_FOR_BUILD=$CXX
> +  CXX=$saved_CXX
> +  CXXCPP=$saved_CXXCPP
> +fi

i think AX_CXX_COMPILE_STDCXX(11) should
set CXX correctly (it seems it would set
it to "g++ -std=gnu++11" instead of
"g++ -std=c++11" but either should work)

please look at the top level config.log
i think you should look for

"checking whether g++ supports C++11 features with -std=gnu++11"

and that check should be successful.