[PATCH] arm: Fix parsecpu.awk for aliases [PR113030]
So the problem here is the 2 functions check_cpu and check_arch use
the wrong variable to check if an alias is valid for that cpu/arch.
check_cpu uses cpu_optaliases instead of cpu_opt_alias. cpu_optaliases
is an array of index'ed by the cpuname that contains all of the valid aliases
for that cpu but cpu_opt_alias is an double index array which is index'ed
by cpuname and the alias which provides what is the alias for that option.
Similar thing happens for check_arch and arch_optaliases vs arch_optaliases.
Tested by running:
```
awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+simd"
config/arm/arm-cpus.in
awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon"
config/arm/arm-cpus.in
awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon-vfpv3"
config/arm/arm-cpus.in
```
And they don't return error back.
gcc/ChangeLog:
PR target/113030
* config/arm/parsecpu.awk (check_cpu): Use cpu_opt_alias
instead of cpu_optaliases.
(check_arch): Use arch_opt_alias instead of arch_optaliases.
Signed-off-by: Andrew Pinski
---
gcc/config/arm/parsecpu.awk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/arm/parsecpu.awk b/gcc/config/arm/parsecpu.awk
index ddd4f3b440a..384462bdb5b 100644
--- a/gcc/config/arm/parsecpu.awk
+++ b/gcc/config/arm/parsecpu.awk
@@ -529,7 +529,7 @@ function check_cpu (name) {
for (n = 2; n <= exts; n++) {
if (!((cpu_name, extensions[n]) in cpu_opt_remove) \
- && !((cpu_name, extensions[n]) in cpu_optaliases)) {
+ && !((cpu_name, extensions[n]) in cpu_opt_alias)) {
return "error"
}
}
@@ -552,7 +552,7 @@ function check_arch (name) {
for (n = 2; n <= exts; n++) {
if (!((extensions[1], extensions[n]) in arch_opt_remove)\
- && !((extensions[1], extensions[n]) in arch_optaliases)) {
+ && !((extensions[1], extensions[n]) in arch_opt_alias)) {
return "error"
}
}
--
2.39.3
[COMMITTED] Clean up examples for -Wdangling-pointer [PR109708]
gcc/ChangeLog
PR c/109708
* doc/invoke.texi (Warning Options): Fix broken example and
clean up/reorganize the others. Also describe what the short-form
options mean.
---
gcc/doc/invoke.texi | 56 +++--
1 file changed, 34 insertions(+), 22 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 930c5dc7236..f7a6e11d20e 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9423,51 +9423,63 @@ levels but may yield different results with
optimization than without.
@table @gcctabopt
@item -Wdangling-pointer=1
-At level 1 the warning diagnoses only unconditional uses of dangling pointers.
-For example
+At level 1, the warning diagnoses only unconditional uses of dangling pointers.
+
+@item -Wdangling-pointer=2
+At level 2, in addition to unconditional uses the warning also diagnoses
+conditional uses of dangling pointers.
+@end table
+
+The short form @option{-Wdangling-pointer} is equivalent to
+@option{-Wdangling-pointer=2}, while @option{-Wno-dangling-pointer} and
+@option{-Wdangling-pointer=0} have the same effect of disabling the warnings.
+@option{-Wdangling-pointer=2} is included in @option{-Wall}.
+
+This example triggers the warning at level 1; the address of the unnamed
+temporary is unconditionally referenced outside of its scope.
+
@smallexample
-int f (int c1, int c2, x)
+char f (char c1, char c2, char c3)
@{
- char *p = strchr ((char[])@{ c1, c2 @}, c3);
- // warning: dangling pointer to a compound literal
- return p ? *p : 'x';
+ char *p;
+ @{
+p = (char[]) @{ c1, c2, c3 @};
+ @}
+ // warning: using dangling pointer 'p' to an unnamed temporary
+ return *p;
@}
@end smallexample
+
In the following function the store of the address of the local variable
-@code{x} in the escaped pointer @code{*p} also triggers the warning.
+@code{x} in the escaped pointer @code{*p} triggers the warning at
+level 1.
+
@smallexample
void g (int **p)
@{
int x = 7;
- // warning: storing the address of a local variable in *p
+ // warning: storing the address of local variable 'x' in '*p'
*p =
@}
@end smallexample
-@item -Wdangling-pointer=2
-At level 2, in addition to unconditional uses the warning also diagnoses
-conditional uses of dangling pointers.
-
-For example, because the array @var{a} in the following function is out of
-scope when the pointer @var{s} that was set to point is used, the warning
-triggers at this level.
+In this example, the array @var{a} is out of
+scope when the pointer @var{s} is used. Since the code that sets @code{s}
+is conditional, the warning triggers at level 2.
@smallexample
-void f (char *s)
+extern void frob (const char *);
+void h (char *s)
@{
if (!s)
@{
char a[12] = "tmpname";
s = a;
@}
- // warning: dangling pointer to a may be used
- strcat (s, ".tmp");
- ...
+ // warning: dangling pointer 's' to 'a' may be used
+ frob (s);
@}
@end smallexample
-@end table
-
-@option{-Wdangling-pointer=2} is included in @option{-Wall}.
@opindex Wdate-time
@opindex Wno-date-time
--
2.31.1
Re: [C PATCH] Fix ICE for composite type for structs with unsigned bitfields [PR113492]
On Sat, 20 Jan 2024, Martin Uecker wrote: > C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492] > > This patch fixes a bug when forming a composite type from structs that > contain an unsigned bitfield declared with int while using > -funsigned-bitfields. > In such structs the unsigned integer type was not compatible to the > regular unsigned integer type used elsewhere in the C FE. > > PR c/113492 > > gcc/c: > * c-decl.cc (grokdeclarator): Use c_common_unsigned_type instead of > unsigned_type_for to create the unsigned type for bitfields declared > with int when using -funsigned-bitfields. > > gcc/testsuite: > * gcc.dg/pr113492.c: New test. OK. -- Joseph S. Myers josmy...@redhat.com
[PATCH] c++: Fix importing nested namespace declarations [PR100707]
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
Currently, importing a namespace declarations marks it as imported, and
so marks it as originating from the module that it was imported from.
This is usually harmless, but causes problems with nested namespaces.
In the linked PR, what happens is that the namespace 'A' imported from
the module ends up not being considered when creating the 'A' namespace
within its own TU, and thus it has its 'cp_binding_level' recreated.
However, by this point 'A::B' has already been imported, and so the
'level_chain' member no longer correctly points at 'A's binding level,
so the sanity check for this in 'resume_scope' ICEs.
Since as far as I can tell there's no reason for imported namespaces to
be attached to any specific module (namespace declarations with external
linkage are always attached to the global module by [module.unit] p7.2),
this patch just removes the 'imported' flag, which stops code from
caring about its originating module.
This patch also makes some minor adjustments to existing tests to cater
for the new dumped name.
PR c++/100707
gcc/cp/ChangeLog:
* name-lookup.cc (add_imported_namespace): Don't mark namespaces
as imported.
gcc/testsuite/ChangeLog:
* g++.dg/modules/indirect-1_b.C: Adjust to handle namespaces not
being attached to the module they were imported from.
* g++.dg/modules/indirect-1_c.C: Likewise.
* g++.dg/modules/indirect-2_b.C: Likewise.
* g++.dg/modules/indirect-2_c.C: Likewise.
* g++.dg/modules/indirect-3_b.C: Likewise.
* g++.dg/modules/indirect-3_c.C: Likewise.
* g++.dg/modules/indirect-4_b.C: Likewise.
* g++.dg/modules/indirect-4_c.C: Likewise.
* g++.dg/modules/namespace-5_a.C: New test.
* g++.dg/modules/namespace-5_b.C: New test.
* g++.dg/modules/namespace-5_c.C: New test.
Signed-off-by: Nathaniel Shead
---
gcc/cp/name-lookup.cc| 1 -
gcc/testsuite/g++.dg/modules/indirect-1_b.C | 20 ++---
gcc/testsuite/g++.dg/modules/indirect-1_c.C | 30 ++--
gcc/testsuite/g++.dg/modules/indirect-2_b.C | 20 ++---
gcc/testsuite/g++.dg/modules/indirect-2_c.C | 10 +++
gcc/testsuite/g++.dg/modules/indirect-3_b.C | 16 +--
gcc/testsuite/g++.dg/modules/indirect-3_c.C | 10 +++
gcc/testsuite/g++.dg/modules/indirect-4_b.C | 14 -
gcc/testsuite/g++.dg/modules/indirect-4_c.C | 8 +++---
gcc/testsuite/g++.dg/modules/namespace-5_a.C | 6
gcc/testsuite/g++.dg/modules/namespace-5_b.C | 7 +
gcc/testsuite/g++.dg/modules/namespace-5_c.C | 5
12 files changed, 82 insertions(+), 65 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/namespace-5_a.C
create mode 100644 gcc/testsuite/g++.dg/modules/namespace-5_b.C
create mode 100644 gcc/testsuite/g++.dg/modules/namespace-5_c.C
diff --git a/gcc/cp/name-lookup.cc b/gcc/cp/name-lookup.cc
index 15b5fba6297..e58f3b5cb4d 100644
--- a/gcc/cp/name-lookup.cc
+++ b/gcc/cp/name-lookup.cc
@@ -9089,7 +9089,6 @@ add_imported_namespace (tree ctx, tree name, location_t
loc, unsigned import,
if (!decl)
{
decl = make_namespace (ctx, name, loc, inline_p);
- DECL_MODULE_IMPORT_P (decl) = true;
make_namespace_finish (decl, slot, true);
}
else if (DECL_NAMESPACE_INLINE_P (decl) != inline_p)
diff --git a/gcc/testsuite/g++.dg/modules/indirect-1_b.C
b/gcc/testsuite/g++.dg/modules/indirect-1_b.C
index c450fa9481c..39e9d21ab76 100644
--- a/gcc/testsuite/g++.dg/modules/indirect-1_b.C
+++ b/gcc/testsuite/g++.dg/modules/indirect-1_b.C
@@ -33,20 +33,20 @@ namespace bar
export extern auto const Scoped_Const_Three = foo::Scoped::D;
}
-// { dg-final { scan-lang-dump {Lazily binding '::foo@foo:.::frob'@'foo'
section:} module } }
+// { dg-final { scan-lang-dump {Lazily binding '::foo::frob'@'foo' section:}
module } }
// { dg-final { scan-lang-dump-not {namespace:-[0-9]* namespace_decl:'::foo'}
module } }
-// { dg-final { scan-lang-dump {Wrote import:-[0-9]*
function_decl:'::foo@foo:.::frob@foo:.'@foo} module } }
+// { dg-final { scan-lang-dump {Wrote import:-[0-9]*
function_decl:'::foo::frob@foo:.'@foo} module } }
-// { dg-final { scan-lang-dump {Lazily binding '::foo@foo:.::X'@'foo'
section:} module } }
-// { dg-final { scan-lang-dump {Wrote import:-[0-9]*
type_decl:'::foo@foo:.::X@foo:.'@foo} module } }
+// { dg-final { scan-lang-dump {Lazily binding '::foo::X'@'foo' section:}
module } }
+// { dg-final { scan-lang-dump {Wrote import:-[0-9]*
type_decl:'::foo::X@foo:.'@foo} module } }
-// { dg-final { scan-lang-dump {Lazily binding '::foo@foo:.::Y'@'foo'
section:} module } }
-// { dg-final { scan-lang-dump {Wrote import:-[0-9]*
type_decl:'::foo@foo:.::Y@foo:.'@foo} module } }
+// { dg-final { scan-lang-dump {Lazily binding '::foo::Y'@'foo' section:}
module } }
+// { dg-final { scan-lang-dump {Wrote import:-[0-9]*
Re: PR82943 - Suggested patch to fix
Based on what I am reading here, I can either do the DCO path or the copy right form path? Or is it both, where I send in the copy right forms and then on every commit I put the DCO? On Sat, Jan 20, 2024 at 3:40 PM Harald Anlauf wrote: > Am 20.01.24 um 21:37 schrieb Jerry D: > > On 1/20/24 12:08 PM, Harald Anlauf wrote: > >> Am 20.01.24 um 20:08 schrieb Jerry D: > >>> On 1/20/24 10:46 AM, Alexander Westbrooks wrote: > Hello and Happy New Year! > > I wanted to follow up on this patch I made to address PR82943 for > GFortran. Has anyone had a chance to review it? > > Thanks, > > Alexander Westbrooks > > >>> > >>> Inserting myself in here just a little bit. I will apply and test > today > >>> if I can. Paul is unavailable for a few weeks. Harald can chime in. > >>> > >>> Do you have commit rights for gcc? > >> > >> I am not aware of Alex having a copyright assignment on file, > >> or a DCO certificate, and the patch is not signed off. > >> But I might be wrong. > >> > > --- snip --- > > > > I do not mind committing this but need clarifications regarding the > > copyright (copyleft?) rules in this case. In the past we have allowed > > small contributions like this. This may be a little more than minor. > > It is. This is why I pointed to: > > https://gcc.gnu.org/dco.html > > > Regardless it appears to do the job! > > > > Jerry > > > > > >
[committed] Remove several xfails for 32-bit hppa*-*-*
Tested on hppa-unknown-linux-gnu. Committed to trunk.
Dave
---
Remove several xfails for 32-bit hppa*-*-*
These arise because 32-bit ELF targets were changed from
callee copies to caller copies.
2024-01-20 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/ipa/iinline-4.c: Remove dg-final xfail for
32-bit hppa*-*-*.
* gcc.dg/ipa/inline-5.c: Likewise.
* gcc.dg/ipa/ipcp-cstagg-7.c: Likewise.
* gcc.dg/tree-ssa/vector-4.c: Likewise.
diff --git a/gcc/testsuite/gcc.dg/ipa/iinline-4.c
b/gcc/testsuite/gcc.dg/ipa/iinline-4.c
index f50ffa58221..c78163dbeff 100644
--- a/gcc/testsuite/gcc.dg/ipa/iinline-4.c
+++ b/gcc/testsuite/gcc.dg/ipa/iinline-4.c
@@ -214,7 +214,7 @@ int test7 (void)
/* { dg-final { scan-ipa-dump "hooray1\[^\\n\]*inline copy in test1" "inline"
} } */
/* { dg-final { scan-ipa-dump "hooray2\[^\\n\]*inline copy in test2" "inline"
} } */
/* { dg-final { scan-ipa-dump "hooray3\[^\\n\]*inline copy in test3" "inline"
} } */
-/* { dg-final { scan-ipa-dump "hooray4\[^\\n\]*inline copy in test4" "inline"
{ xfail { { hppa*-*-* } && { ! lp64 } } } } } */
+/* { dg-final { scan-ipa-dump "hooray4\[^\\n\]*inline copy in test4" "inline"
} } */
/* { dg-final { scan-ipa-dump "hooray5\[^\\n\]*inline copy in test5" "inline"
} } */
/* { dg-final { scan-ipa-dump "hooray6\[^\\n\]*inline copy in test6" "inline"
} } */
/* { dg-final { scan-ipa-dump "hooray7\[^\\n\]*inline copy in test7" "inline"
} } */
diff --git a/gcc/testsuite/gcc.dg/ipa/inline-5.c
b/gcc/testsuite/gcc.dg/ipa/inline-5.c
index 559e258955e..390ba499d67 100644
--- a/gcc/testsuite/gcc.dg/ipa/inline-5.c
+++ b/gcc/testsuite/gcc.dg/ipa/inline-5.c
@@ -34,5 +34,5 @@ accessreference (struct a *a)
/* Will be eliminated by inlining */
}
-/* { dg-final { scan-ipa-dump-times "Will be eliminated" 4 "fnsummary" { xfail
{ { hppa*-*-* } && { ! lp64 } } } } } */
+/* { dg-final { scan-ipa-dump-times "Will be eliminated" 4 "fnsummary" } } */
/* { dg-final { scan-ipa-dump-times "50. will be eliminated" 1 "fnsummary" }
} */
diff --git a/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
b/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
index b08c420cd86..6af8bda6d8e 100644
--- a/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
+++ b/gcc/testsuite/gcc.dg/ipa/ipcp-cstagg-7.c
@@ -62,4 +62,4 @@ h (int x)
return bar (s, x);
}
-/* { dg-final { scan-ipa-dump-times "Discovered an indirect call to a known
target" 3 "cp" { xfail { hppa*-*-* && { ! lp64 } } } } } */
+/* { dg-final { scan-ipa-dump-times "Discovered an indirect call to a known
target" 3 "cp" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/vector-4.c
b/gcc/testsuite/gcc.dg/tree-ssa/vector-4.c
index 00ddd2995be..982a2a47d6a 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/vector-4.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/vector-4.c
@@ -10,7 +10,6 @@ v4si vs (v4si a, v4si b)
}
/* The compound literal should be placed directly in the vec_perm. */
-/* Test is xfailed on 32-bit hppa*-*-* because target-callee-copies. */
-/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR ;" 1
"gimple" { target { ! mmix-knuth-mmixware } xfail { hppa*-*-* && { ! lp64 } } }
} } */
+/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR ;" 1
"gimple" { target { ! mmix-knuth-mmixware } } } } */
/* { dg-final { scan-tree-dump-times "VEC_PERM_EXPR ;" 1 "gimple" { target mmix-knuth-mmixware } } } */
signature.asc
Description: PGP signature
[PATCH] Fortran: passing of optional scalar arguments with VALUE attribute [PR113377]
Dear all,
here's the first part of an attempt to fix issues with optional
dummy arguments as actual arguments to optional dummies. This patch
rectifies the case of scalar dummies with the VALUE attribute,
which in gfortran's argument passing convention are passed on the
stack when they are of intrinsic type, and have a hidden variable
for the presence status.
The testcase tries to cover valid combinations of actual and dummy
argument. A few tests that are not standard-conforming but would
still work with gfortran (due to the argument passing convention)
are left there but commented out with a pointer to the standard
(thanks, Mikael!).
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From f6a65138391c902d2782973665059d7d059a50d1 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sat, 20 Jan 2024 22:18:02 +0100
Subject: [PATCH] Fortran: passing of optional scalar arguments with VALUE
attribute [PR113377]
gcc/fortran/ChangeLog:
PR fortran/113377
* trans-expr.cc (gfc_conv_procedure_call): Fix handling of optional
scalar arguments of intrinsic type with the VALUE attribute.
gcc/testsuite/ChangeLog:
PR fortran/113377
* gfortran.dg/optional_absent_9.f90: New test.
---
gcc/fortran/trans-expr.cc | 5 +
.../gfortran.dg/optional_absent_9.f90 | 324 ++
2 files changed, 329 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/optional_absent_9.f90
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 9dd1f4086f4..2f47a75955c 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6526,6 +6526,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
gfc_init_se (, NULL);
argse.want_pointer = 1;
gfc_conv_expr (, e);
+ if (e->symtree->n.sym->attr.dummy
+&& POINTER_TYPE_P (TREE_TYPE (argse.expr)))
+ argse.expr = gfc_build_addr_expr (NULL_TREE,
+argse.expr);
cond = fold_convert (TREE_TYPE (argse.expr),
null_pointer_node);
cond = fold_build2_loc (input_location, NE_EXPR,
@@ -7256,6 +7260,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
&& e->symtree->n.sym->attr.optional
&& (((e->rank != 0 && elemental_proc)
|| e->representation.length || e->ts.type == BT_CHARACTER
+ || (e->rank == 0 && e->symtree->n.sym->attr.value)
|| (e->rank != 0
&& (fsym == NULL
|| (fsym->as
diff --git a/gcc/testsuite/gfortran.dg/optional_absent_9.f90 b/gcc/testsuite/gfortran.dg/optional_absent_9.f90
new file mode 100644
index 000..495a6c00d7f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/optional_absent_9.f90
@@ -0,0 +1,324 @@
+! { dg-do run }
+! PR fortran/113377
+!
+! Test passing of missing optional scalar dummies of intrinsic type
+
+module m_int
+ implicit none
+contains
+ subroutine test_int ()
+integer :: k = 1
+call one (k)
+call one_val (k)
+call one_all (k)
+call one_ptr (k)
+ end
+
+ subroutine one (i, j)
+integer, intent(in) :: i
+integer ,optional :: j
+integer, allocatable :: aa
+integer, pointer :: pp => NULL()
+if (present (j)) error stop "j is present"
+call two (i, j)
+call two_val (i, j)
+call two (i, aa)
+call two (i, pp)
+ end
+
+ subroutine one_val (i, j)
+integer, intent(in) :: i
+integer, value, optional :: j
+if (present (j)) error stop "j is present"
+call two (i, j)
+call two_val (i, j)
+ end
+
+ subroutine one_all (i, j)
+integer, intent(in) :: i
+integer, allocatable,optional :: j
+if (present (j)) error stop "j is present"
+! call two (i, j) ! invalid per F2018:15.5.2.12, par. 3, clause 8
+! call two_val (i, j) ! invalid (*) F2018:15.5.2.12, par. 3, clause 8
+call two_all (i, j)
+ end
+! (*) gfortran argument passing conventions ("scalar dummy arguments of type
+! INTEGER, LOGICAL, REAL, COMPLEX, and CHARACTER(len=1) with VALUE attribute
+! pass the presence status separately") may still allow this case pass
+
+ subroutine one_ptr (i, j)
+integer, intent(in) :: i
+integer, pointer,optional :: j
+if (present (j)) error stop "j is present"
+! call two (i, j) ! invalid per F2018:15.5.2.12, par. 3, clause 7
+! call two_val (i, j) ! invalid (*) F2018:15.5.2.12, par. 3, clause 7
+call two_ptr (i, j)
+ end
+
+ subroutine two (i, j)
+integer, intent(in) :: i
+integer, intent(in), optional :: j
+if (present (j)) error stop 11
+ end
+
+ subroutine two_val (i, j)
+integer, intent(in) :: i
+integer, value, optional :: j
+if (present (j)) error stop 12
+ end
+
+ subroutine two_all (i, j)
+integer, intent(in) :: i
+integer, allocatable,optional :: j
+if (present (j)) error stop 13
+ end
+
+ subroutine two_ptr (i, j)
+integer, intent(in) :: i
+
[committed] Increase timeout by 2 in libgomp.fortran/alloc-comp-3.f90 on hppa*-*-*
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Increase timeout by 2 in libgomp.fortran/alloc-comp-3.f90 on hppa*-*-*
2024-01-20 John David Anglin
libgomp/ChangeLog:
* testsuite/libgomp.fortran/alloc-comp-3.f90: Increase
timeout by 2 on hppa*-*-*.
diff --git a/libgomp/testsuite/libgomp.fortran/alloc-comp-3.f90
b/libgomp/testsuite/libgomp.fortran/alloc-comp-3.f90
index 0185859cb26..eb418e83d9e 100644
--- a/libgomp/testsuite/libgomp.fortran/alloc-comp-3.f90
+++ b/libgomp/testsuite/libgomp.fortran/alloc-comp-3.f90
@@ -2,6 +2,7 @@
! Don't cycle by default through all options, just test -O0 and -O2,
! as this is quite large test.
! { dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } }
+! { dg-timeout-factor 2.0 { target hppa*-*-* } }
module m
type dl
signature.asc
Description: PGP signature
Re: PR82943 - Suggested patch to fix
Am 20.01.24 um 21:37 schrieb Jerry D: On 1/20/24 12:08 PM, Harald Anlauf wrote: Am 20.01.24 um 20:08 schrieb Jerry D: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? I am not aware of Alex having a copyright assignment on file, or a DCO certificate, and the patch is not signed off. But I might be wrong. --- snip --- I do not mind committing this but need clarifications regarding the copyright (copyleft?) rules in this case. In the past we have allowed small contributions like this. This may be a little more than minor. It is. This is why I pointed to: https://gcc.gnu.org/dco.html Regardless it appears to do the job! Jerry
[committed] Don't run libgomp.c/simd-math-1.c on hppa*-*-hpux*
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Don't run libgomp.c/simd-math-1.c on hppa*-*-hpux*
hppa*-*-hpux* lacks necessary math functions.
2024-01-20 John David Anglin
libgomp/ChangeLog:
* testsuite/libgomp.c/simd-math-1.c: Don't run on
hppa*-*-hpux*.
diff --git a/libgomp/testsuite/libgomp.c/simd-math-1.c
b/libgomp/testsuite/libgomp.c/simd-math-1.c
index 42a008c80fc..b30df09caf6 100644
--- a/libgomp/testsuite/libgomp.c/simd-math-1.c
+++ b/libgomp/testsuite/libgomp.c/simd-math-1.c
@@ -1,7 +1,7 @@
/* Check that the SIMD versions of math routines give the same (or
sufficiently close) results as their scalar equivalents. */
-/* { dg-do run } */
+/* { dg-do run { target { ! hppa*-*-hpux* } } } */
/* { dg-options "-O2 -ftree-vectorize -fno-math-errno" } */
/* { dg-additional-options
-foffload-options=amdgcn-amdhsa=-mstack-size=300 { target
offload_target_amdgcn } } */
/* { dg-additional-options "-DNONSTDFUNC=1" { target
nonstandard_math_functions } } */
signature.asc
Description: PGP signature
[committed] xfail scan-tree-dump-times checks on hppa*64*-*-* in gcc.dg/tree-ssa/slsr-13.c
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
xfail scan-tree-dump-times checks on hppa*64*-*-* in gcc.dg/tree-ssa/slsr-13.c
2024-01-20 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/slsr-13.c: xfail scan-tree-dump-times
checks on hppa*64*-*-*.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/slsr-13.c
b/gcc/testsuite/gcc.dg/tree-ssa/slsr-13.c
index 4133694174c..93749d6e856 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/slsr-13.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/slsr-13.c
@@ -20,5 +20,5 @@ f (int s, int c)
return x;
}
-/* { dg-final { scan-tree-dump-times " \\* 4" 2 "optimized" } } */
-/* { dg-final { scan-tree-dump-times " \\* 5" 0 "optimized" } } */
+/* { dg-final { scan-tree-dump-times " \\* 4" 2 "optimized" {xfail
hppa*64*-*-* } } } */
+/* { dg-final { scan-tree-dump-times " \\* 5" 0 "optimized" {xfail
hppa*64*-*-* } } } */
signature.asc
Description: PGP signature
[committed] Require target lra in gcc.dg/torture/pr110422.c
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Require target lra in gcc.dg/torture/pr110422.c
LRA is required for asm goto.
2024-01-20 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr110422.c: Require target lra.
diff --git a/gcc/testsuite/gcc.dg/torture/pr110422.c
b/gcc/testsuite/gcc.dg/torture/pr110422.c
index 2e171a7a19e..2a653bdfce3 100644
--- a/gcc/testsuite/gcc.dg/torture/pr110422.c
+++ b/gcc/testsuite/gcc.dg/torture/pr110422.c
@@ -1,4 +1,4 @@
-/* { dg-do compile } */
+/* { dg-do compile { target lra } } */
struct T { int x; };
int foo(void) {
signature.asc
Description: PGP signature
[PATCH] ipa-cp: Fix check for exceeding param_ipa_cp_value_list_size (PR 113490)
Hi,
When the check for exceeding param_ipa_cp_value_list_size limit was
modified to be ignored for generating values from self-recursive
calls, it should have been changed from equal to, to equals toor is
greater than. This omission manifests itself as PR 113490.
When I examined the condition I also noticed that the parameter should
come from the callee rather than the caller, since the value list is
associated with the former and not the latter. In practice the limit
is of course very likely to be the same, but I fixed this aspect of
the condition too. I briefly audited all other uses of opt_for_fn in
ipa-cp.cc and all the others looked OK.
Bootstrapped and tested on x86_64-linux. OK for master?
Thanks,
Martin
gcc/ChangeLog:
2024-01-19 Martin Jambor
PR ipa/113490
* ipa-cp.cc (ipcp_lattice::add_value): Bail out if value
count is equal or greater than the limit. Use the limit from the
callee.
gcc/testsuite/ChangeLog:
2024-01-19 Martin Jambor
PR ipa/113490
* gcc.dg/ipa/pr113490.c: New test.
---
gcc/ipa-cp.cc | 2 +-
gcc/testsuite/gcc.dg/ipa/pr113490.c | 31 +
2 files changed, 32 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.dg/ipa/pr113490.c
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index b1e2a3a829a..e85477df32d 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -2298,7 +2298,7 @@ ipcp_lattice::add_value (valtype newval,
cgraph_edge *cs,
return false;
}
- if (!same_lat_gen_level && values_count == opt_for_fn (cs->caller->decl,
+ if (!same_lat_gen_level && values_count >= opt_for_fn (cs->callee->decl,
param_ipa_cp_value_list_size))
{
/* We can only free sources, not the values themselves, because sources
diff --git a/gcc/testsuite/gcc.dg/ipa/pr113490.c
b/gcc/testsuite/gcc.dg/ipa/pr113490.c
new file mode 100644
index 000..cffb0c5f639
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr113490.c
@@ -0,0 +1,31 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -Wno-psabi" } */
+
+typedef char A __attribute__((vector_size (64)));
+typedef short B __attribute__((vector_size (64)));
+typedef unsigned C __attribute__((vector_size (64)));
+typedef long D __attribute__((vector_size (64)));
+typedef __int128 E __attribute__((vector_size (64)));
+
+D bar1_D_0;
+E bar4 (A, D);
+
+E
+bar1 (C C_0)
+{
+ C_0 >>= 1;
+ bar4 ((A) C_0, bar1_D_0);
+ bar4 ((A) (E) {~0 }, (D) (A){ ~0 });
+ bar4 ((A) (B) { ~0 }, (D) (C) { ~0 });
+ bar1 ((C) (D){ 0, ~0});
+ bar4 ((A) C_0, bar1_D_0);
+ (A) { bar1 ((C) { 7})[5] - C_0[63], bar4 ((A) (D) {~0}, (D) (C) { 0,
~0})[3]};
+}
+
+E
+bar4 (A A_0, D D_0)
+{
+ bar1 ((C) A_0);
+ bar1 ((C) {5});
+ bar1 ((C) D_0);
+}
--
2.43.0
Re: PR82943 - Suggested patch to fix
On 1/20/24 12:08 PM, Harald Anlauf wrote: Am 20.01.24 um 20:08 schrieb Jerry D: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? I am not aware of Alex having a copyright assignment on file, or a DCO certificate, and the patch is not signed off. But I might be wrong. --- snip --- I do not mind committing this but need clarifications regarding the copyright (copyleft?) rules in this case. In the past we have allowed small contributions like this. This may be a little more than minor. Regardless it appears to do the job! Jerry
[Fortran] half-cycle trig functions and atan[d] fixes
All, I have attached a new patch to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152 which addresses the following issues. PR113152 -- implement half-cycle trigonometric functions PR113412 -- better error message for atan(y,x) PR113413 -- implement atand(y,x) The patch clocks in at 3488 lines, so will not be attached here. There are a few items that may need some explanation. First, some (if not all) of the half-cycle functions are contained in ISO/IEC TS 18661-4, IEEE754-2008, and now Fortran 2023. The patch assumes that an OS's libm may/will contain cospi(), etc. (see for example FreeBSD's libm). If these are not in libm, then fallback routines are provided by libgfortran. The fallback routines have seen limited testing, so your mileage may vary. Second, I have no idea what REAL17 entails; however, I provide untested routines in trigpi_fallback2.F90 where I use REAL(16) in the declarations (yikes). Third, MPFR provides half-cycle functions in version 4.2.0 (and later). For simplicifation, the patch checks for an adequate MPFR version, if an older version is found fallback algorithms are used. These have had limited testing. The patch appears to pass regression testing. Hopefully, someone will find time to test and commit the patch. The remainder is an attempt to write ChangeLog entries. gcc/fortran: * gfortran.h (gfc_isym_id): Add GFC_ISYM_ACOSPI, GFC_ISYM_ASINPI, GFC_ISYM_ATANPI, GFC_ISYM_ATAN2PI, GFC_ISYM_COSPI, GFC_ISYM_SINPI, and GFC_ISYM_TANPI * intrinsic.cc (do_check): Whitespace and typo in comments. (add_functions): Add two-argument form of ATAND. Add half-cycle trigonometric functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI. (sort_actual): Generate sensible error messages for two argument versions of ATAN, ATAND, and ATANPI. * intrinsic.h: New prototypes for gfc_simplify_acospi, gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi, gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi, gfc_resolve_acospi, gfc_resolve_asinpi, gfc_resolve_atanpi, gfc_resolve_atan2pi, gfc_resolve_cospi, gfc_resolve_sinpi, and gfc_resolve_tanpi * intrinsic.texi: Document new functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI. Put the ATAN* family of functions in lexigraphical order. * iresolve.cc (gfc_resolve_acospi, gfc_resolve_asinpi, gfc_resolve_atanpi, gfc_resolve_atan2pi, gfc_resolve_cospi, gfc_resolve_sinpi, gfc_resolve_tanpi): New functions. * simplify.cc (gfc_simplify_acospi, gfc_simplify_asinpi, gfc_simplify_atanpi, gfc_simplify_atan2pi, gfc_simplify_cospi, gfc_simplify_sinpi, gfc_simplify_tanpi): New functions. Introduce MPFR_HALF_CYCLE macros to use MPFR half-cycle functions if available. * trans-intrinsic.cc: Declare asinpi, acospi, atanpi, atan2pi, sinpi, cospi, and tanpi as LIB_FUNCTION's. libgfortran: *Makefile.am: New files trigpi.c, trigpi_fallback1.c, and trigpi_fallback2.F90 * configure.ac: Check libm for float, double, and long double functions for asinpi, acospi, atanpi, atan2pi, sinpi, cospi, and tanpi * Makefile.in: Regenerated. * config.h.in: Ditto. * configure: Ditto. * gfortran.map: Add GFORTRAN_14 section to expose the library symbols. * trigpi.c: Fallback implementations of the half-cycle trigonometric functions. * trigpi_fallback1.c: Fallback functions for float, double, and long double routines if libm does provide them. * trigpi_fallback2.F90: REAL(16)/REAL(17?) fallback implementations of the half-cycle trigonometric functions. -- Steve
Re: PR82943 - Suggested patch to fix
Am 20.01.24 um 20:08 schrieb Jerry D: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? I am not aware of Alex having a copyright assignment on file, or a DCO certificate, and the patch is not signed off. But I might be wrong. Your efforts are appreciated. Regards, Jerry
Re: PR82943 - Suggested patch to fix
On 1/20/24 11:08 AM, Jerry D wrote: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? Your efforts are appreciated. Regards, Jerry I did send you an invite to our Mattermost workspace. I did apply your patch. Some comments. The ChangeLog files are auto generated so do not get manually changed with a patch. The push process to the gcc git repository will generate those from the git commit log. If the git commit log is not formatted correctly the push will be rejected. The patch attempts to create a PDT_33.f03 test case. There is one already there so probably rename that one. In resolve.cc There was a compile error that looked like an extra '&&' in the conditional. I deleted that and all compiled ok and all regression tested OK, including your new test cases and the existing PDT_33.f03 case. I did not try your new test case yet for PDT_33. So next steps are walk you through using the git scripts to make commits with the logs formatted correctly. (assuming no one else chimes in with any other comment about code changes themselves.. Regards, Jerry
[COMMITTED] ipa: Add testcase for already fixed case [PR110705]
This testcase was fixed with r13-1695-gb0f02eeb906b63 which
added an Ada testcase for the issue but adding a C testcase
is a good idea and that is what this does.
Committed after making sure it passes on x86_64-linux-gnu.
PR ipa/110705
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr110705-1.c: New test.
Signed-off-by: Andrew Pinski
---
.../gcc.c-torture/compile/pr110705-1.c| 27 +++
1 file changed, 27 insertions(+)
create mode 100644 gcc/testsuite/gcc.c-torture/compile/pr110705-1.c
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr110705-1.c
b/gcc/testsuite/gcc.c-torture/compile/pr110705-1.c
new file mode 100644
index 000..6c0029c99e3
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr110705-1.c
@@ -0,0 +1,27 @@
+/* PR ipa/110705 */
+
+/* We used to ICE in gimplify_modify_expr due to
+ the gimplifier not handling VCE between an struct
+ and an integer type. */
+
+struct a {
+ long b;
+};
+union d {
+ struct a b;
+ int e;
+}v;
+long c;
+int f;
+static void g(union d h, long i) {
+ while (1)
+switch (c)
+case 4:
+ if (h.e)
+c = 4;
+}
+void j(union d *h) {
+ if (f)
+g(*h, h->b.b);
+}
+void k() { union d *h = j(h); }
--
2.39.3
Re: PR82943 - Suggested patch to fix
On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? Your efforts are appreciated. Regards, Jerry
Re: PR82943 - Suggested patch to fix
Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks On Thu, Jun 29, 2023 at 10:38 PM Alexander Westbrooks wrote: > Hello, > > I have finished my testing, and updated my patch and relevant Changelogs. > I added 4 new tests and all the existing tests in the current testsuite > for gfortran passed or failed as expected. Do I need to attach the test > results here? > > The platform I tested on was a Docker container running in Docker Desktop, > running the "mcr.microsoft.com/devcontainers/universal:2-linux" image. > > I also made sure that my code changes followed the coding standards. > Please let me know if there is anything else that I need to do. I don't > have write-access to the repository. > > Thanks, > > Alexander > > On Wed, Jun 28, 2023 at 4:14 PM Harald Anlauf wrote: > >> Hi Alex, >> >> welcome to the gfortran community. It is great that you are trying >> to get actively involved. >> >> You already did quite a few things right: patches shall be sent to >> the gcc-patches ML, but Fortran reviewers usually notice them only >> where they are copied to the fortran ML. >> >> There are some general recommendations on the formatting of C code, >> like indentation, of the patches, and of the commit log entries. >> >> Regarding coding standards, see https://www.gnu.org/prep/standards/ . >> >> Regarding testcases, a recommendation is to have a look at >> existing testcases, e.g. in gcc/testsuite/gfortran.dg/, and then >> decide if the testcase shall test the compile-time or run-time >> behaviour, and add the necessary dejagnu directives. >> >> You should also verify if your patch passes regression testing. >> For changes to gfortran, it is usually sufficient to run >> >> make check-fortran -j >> >> where is the number of parallel tests. >> You would need to report also the platform where you tested on. >> >> There is also a legal issue to consider before non-trivial patches can >> be accepted for incorporation: https://gcc.gnu.org/contribute.html#legal >> >> If your patch is accepted and if you do not have write-access to the >> repository, one of the maintainers will likely take care of it. >> If you become a regular contributor, you will probably want to consider >> getting write access. >> >> Cheers, >> Harald >> >> >> >> On 6/24/23 19:17, Alexander Westbrooks via Gcc-patches wrote: >> > Hello, >> > >> > I am new to the GFortran community. Over the past two weeks I created a >> > patch that should fix PR82943 for GFortran. I have attached it to this >> > email. The patch allows the code below to compile successfully. I am >> > working on creating test cases next, but I am new to the process so it >> may >> > take me some time. After I make test cases, do I email them to you as >> well? >> > Do I need to make a pull-request on github in order to get the patch >> > reviewed? >> > >> > Thank you, >> > >> > Alexander Westbrooks >> > >> > module testmod >> > >> > public :: foo >> > >> > type, public :: tough_lvl_0(a, b) >> > integer, kind :: a = 1 >> > integer, len :: b >> > contains >> > procedure :: foo >> > end type >> > >> > type, public, EXTENDS(tough_lvl_0) :: tough_lvl_1 (c) >> > integer, len :: c >> > contains >> > procedure :: bar >> > end type >> > >> > type, public, EXTENDS(tough_lvl_1) :: tough_lvl_2 (d) >> > integer, len :: d >> > contains >> > procedure :: foobar >> > end type >> > >> > contains >> > subroutine foo(this) >> > class(tough_lvl_0(1,*)), intent(inout) :: this >> > end subroutine >> > >> > subroutine bar(this) >> > class(tough_lvl_1(1,*,*)), intent(inout) :: this >> > end subroutine >> > >> > subroutine foobar(this) >> > class(tough_lvl_2(1,*,*,*)), intent(inout) :: this >> > end subroutine >> > >> > end module >> > >> > PROGRAM testprogram >> > USE testmod >> > >> > TYPE(tough_lvl_0(1,5)) :: test_pdt_0 >> > TYPE(tough_lvl_1(1,5,6)) :: test_pdt_1 >> > TYPE(tough_lvl_2(1,5,6,7)) :: test_pdt_2 >> > >> > CALL test_pdt_0%foo() >> > >> > CALL test_pdt_1%foo() >> > CALL test_pdt_1%bar() >> > >> > CALL test_pdt_2%foo() >> > CALL test_pdt_2%bar() >> > CALL test_pdt_2%foobar() >> > >> > >> > END PROGRAM testprogram >> >>
[C PATCH] Fix ICE for composite type for structs with unsigned bitfields [PR113492]
C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
This patch fixes a bug when forming a composite type from structs that
contain an unsigned bitfield declared with int while using -funsigned-bitfields.
In such structs the unsigned integer type was not compatible to the
regular unsigned integer type used elsewhere in the C FE.
PR c/113492
gcc/c:
* c-decl.cc (grokdeclarator): Use c_common_unsigned_type instead of
unsigned_type_for to create the unsigned type for bitfields declared
with int when using -funsigned-bitfields.
gcc/testsuite:
* gcc.dg/pr113492.c: New test.
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 4029bbc59fe..8d18a3e11f4 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -6947,7 +6947,7 @@ grokdeclarator (const struct c_declarator *declarator,
"signed". */
if (bitfield && !flag_signed_bitfields && !declspecs->explicit_signed_p
&& TREE_CODE (type) == INTEGER_TYPE)
-type = unsigned_type_for (type);
+type = c_common_unsigned_type (type);
/* Figure out the type qualifiers for the declaration. There are
two ways a declaration can become qualified. One is something
diff --git a/gcc/testsuite/gcc.dg/pr113492.c b/gcc/testsuite/gcc.dg/pr113492.c
new file mode 100644
index 000..56296c51072
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr113492.c
@@ -0,0 +1,43 @@
+/* PR 113492
+ * { dg-do compile }
+ * { dg-options "-std=c23 -funsigned-bitfields" } */
+
+struct foo {
+ int i : 3;
+} i;
+
+void test()
+{
+ struct foo {
+ unsigned i : 3;
+ } u;
+
+ 1 ? i : u;
+ 1 ? u : i;
+}
+
+struct bar {
+ unsigned i : 3;
+} u;
+
+void test2()
+{
+ struct bar {
+ int i : 3;
+ } i;
+
+ 1 ? i : u;
+ 1 ? u : i;
+}
+
+void test3()
+{
+ typedef int myint;
+ struct bar {
+ myint i : 3;
+ } i;
+
+ 1 ? i : u;
+ 1 ? u : i;
+}
+
Re: [PATCH] libgccjit: Add ability to get CPU features
CC-ing Iain in case they can do the review since it is based on how they did it in the D frontend. Could you please do the review? Thanks! On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote: > On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote: > > Hi. > > This patch adds support for getting the CPU features in libgccjit > > (bug > > 112466) > > > > There's a TODO in the test: > > I'm not sure how to test that gcc_jit_target_info_arch returns the > > correct value since it is dependant on the CPU. > > Any idea on how to improve this? > > > > Also, I created a CStringHash to be able to have a > > std::unordered_set. Is there any built-in way of > > doing > > this? > > Thanks for the patch. > > Some high-level questions: > > Is this specifically about detecting capabilities of the host that > libgccjit is currently running on? or how the target was configured > when libgccjit was built? > > One of the benefits of libgccjit is that, in theory, we support all > of > the targets that GCC already supports. Does this patch change that, > or > is this more about giving client code the ability to determine > capabilities of the specific host being compiled for? > > I'm nervous about having per-target jit code. Presumably there's a > reason that we can't reuse existing target logic here - can you > please > describe what the problem is. I see that the ChangeLog has: > > > * config/i386/i386-jit.cc: New file. > > where i386-jit.cc has almost 200 lines of nontrivial code. Where did > this come from? Did you base it on existing code in our source tree, > making modifications to fit the new internal API, or did you write it > from scratch? In either case, how onerous would this be for other > targets? > > I'm not at expert at target hooks (or at the i386 backend), so if we > do > go with this approach I'd want someone else to review those parts of > the patch. > > Have you verified that GCC builds with this patch with jit *not* > enabled in the enabled languages? > > [...snip...] > > A nitpick: > > > +.. function:: const char * \ > > + gcc_jit_target_info_arch (gcc_jit_target_info *info) > > + > > + Get the architecture of the currently running CPU. > > What does this string look like? > How long does the pointer remain valid? > > Thanks again; hope the above makes sense > Dave >
[COMMITTED] Correct documentation for -Warray-parameter [PR102998]
gcc/ChangeLog
PR c/102998
* doc/invoke.texi (Option Summary): Add -Warray-parameter.
(Warning Options): Correct/edit discussion of -Warray-parameter
to make the first example less confusing, and fill in missing info.
---
gcc/doc/invoke.texi | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 313f363f5f2..930c5dc7236 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -332,6 +332,7 @@ Objective-C and Objective-C++ Dialects}.
-Wno-aggressive-loop-optimizations
-Warith-conversion
-Warray-bounds -Warray-bounds=@var{n} -Warray-compare
+-Warray-parameter -Warray-parameter=@var{n}
-Wno-attributes -Wattribute-alias=@var{n} -Wno-attribute-alias
-Wno-attribute-warning
-Wbidi-chars=@r{[}none@r{|}unpaired@r{|}any@r{|}ucn@r{]}
@@ -8467,25 +8468,28 @@ bool same = arr1 == arr2;
@option{-Warray-compare} is enabled by @option{-Wall}.
@opindex Wno-array-parameter
+@opindex Warray-parameter
@item -Warray-parameter
@itemx -Warray-parameter=@var{n}
-Warn about redeclarations of functions involving arguments of array or
+Warn about redeclarations of functions involving parameters of array or
pointer types of inconsistent kinds or forms, and enable the detection
of out-of-bounds accesses to such parameters by warnings such as
@option{-Warray-bounds}.
-If the first function declaration uses the array form the bound specified
+If the first function declaration uses the array form for a parameter
+declaration, the bound specified
in the array is assumed to be the minimum number of elements expected to
be provided in calls to the function and the maximum number of elements
accessed by it. Failing to provide arguments of sufficient size or accessing
more than the maximum number of elements may be diagnosed by warnings such
-as @option{-Warray-bounds}. At level 1 the warning diagnoses inconsistencies
+as @option{-Warray-bounds} or @option{-Wstringop-overflow}.
+At level 1, the warning diagnoses inconsistencies
involving array parameters declared using the @code{T[static N]} form.
-For example, the warning triggers for the following redeclarations because
-the first one allows an array of any size to be passed to @code{f} while
-the second one with the keyword @code{static} specifies that the array
-argument must have at least four elements.
+For example, the warning triggers for the second declaration of @code{f}
+because the first one with the keyword @code{static} specifies that
+the array argument must have at least four elements, while the second
+allows an array of any size to be passed to @code{f}.
@smallexample
void f (int[static 4]);
@@ -8493,7 +8497,7 @@ void f (int[]); // warning (inconsistent array
form)
void g (void)
@{
- int *p = (int *)malloc (4);
+ int *p = (int *)malloc (1 * sizeof (int));
f (p); // warning (array too small)
@dots{}
@}
@@ -8514,6 +8518,10 @@ void g (int[8]);// warning (inconsistent array bound)
@option{-Wvla-parameter} option triggers warnings for similar inconsistencies
involving Variable Length Array arguments.
+The short form of the option @option{-Warray-parameter} is equivalent to
+@option{-Warray-parameter=2}. The negative form @option{-Wno-array-parameter}
+is equivalent to @option{-Warray-parameter=0}.
+
@opindex Wattribute-alias
@opindex Wno-attribute-alias
@item -Wattribute-alias=@var{n}
--
2.31.1
[PATCH 1/2] x86: Add no_callee_saved_registers function attribute
When an interrupt handler is implemented by an assembly stub which does: 1. Save all registers. 2. Call a C function. 3. Restore all registers. 4. Return from interrupt. it is completely unnecessary to save and restore any registers in the C function called by the assembly stub, even if they would normally be callee-saved. Add no_callee_saved_registers function attribute, which is complementary to no_caller_saved_registers function attribute, to mark a function which doesn't have any callee-saved registers. Such a function won't save and restore any registers. Classify function call-saved register handling type with: 1. Default call-saved registers. 2. No caller-saved registers with no_caller_saved_registers attribute. 3. No callee-saved registers with no_callee_saved_registers attribute. Disallow sibcall if callee is a no_callee_saved_registers function and caller isn't a no_callee_saved_registers function. Otherwise, callee-saved registers won't be preserved. After a no_callee_saved_registers function is called, all registers may be clobbered. If the calling function isn't a no_callee_saved_registers function, we need to preserve all registers which aren't used by function calls. gcc/ PR target/103503 PR target/113312 * config/i386/i386-expand.cc (ix86_expand_call): Set call_no_callee_saved_registers to true when calling function with no_callee_saved_registers attribute. Replace no_caller_saved_registers check with call_saved_registers check. * config/i386/i386-options.cc (ix86_set_func_type): Set call_saved_registers to TYPE_NO_CALLEE_SAVED_REGISTERS for noreturn function. Disallow no_callee_saved_registers with interrupt or no_caller_saved_registers attributes together. (ix86_set_current_function): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_handle_no_caller_saved_registers_attribute): Renamed to ... (ix86_handle_call_saved_registers_attribute): This. (ix86_gnu_attributes): Add ix86_handle_call_saved_registers_attribute. * config/i386/i386.cc (ix86_conditional_register_usage): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_function_ok_for_sibcall): Don't allow callee with no_callee_saved_registers attribute when the calling function has callee-saved registers. (ix86_comp_type_attributes): Also check no_callee_saved_registers. (ix86_epilogue_uses): Replace no_caller_saved_registers check with call_saved_registers check. (ix86_hard_regno_scratch_ok): Likewise. (ix86_save_reg): Replace no_caller_saved_registers check with call_saved_registers check. Don't save any registers for TYPE_NO_CALLEE_SAVED_REGISTERS. Save all registers with TYPE_DEFAULT_CALL_SAVED_REGISTERS if function with no_callee_saved_registers attribute is called. (find_drap_reg): Replace no_caller_saved_registers check with call_saved_registers check. * config/i386/i386.h (call_saved_registers_type): New enum. (machine_function): Replace no_caller_saved_registers with call_saved_registers. Add call_no_callee_saved_registers. * doc/extend.texi: Document no_callee_saved_registers attribute. gcc/testsuite/ PR target/103503 PR target/113312 * gcc.dg/torture/no-callee-saved-run-1a.c: New file. * gcc.dg/torture/no-callee-saved-run-1b.c: Likewise. * gcc.target/i386/no-callee-saved-1.c: Likewise. * gcc.target/i386/no-callee-saved-2.c: Likewise. * gcc.target/i386/no-callee-saved-3.c: Likewise. * gcc.target/i386/no-callee-saved-4.c: Likewise. * gcc.target/i386/no-callee-saved-5.c: Likewise. * gcc.target/i386/no-callee-saved-6.c: Likewise. * gcc.target/i386/no-callee-saved-7.c: Likewise. * gcc.target/i386/no-callee-saved-8.c: Likewise. * gcc.target/i386/no-callee-saved-9.c: Likewise. * gcc.target/i386/no-callee-saved-10.c: Likewise. * gcc.target/i386/no-callee-saved-11.c: Likewise. * gcc.target/i386/no-callee-saved-12.c: Likewise. * gcc.target/i386/no-callee-saved-13.c: Likewise. * gcc.target/i386/no-callee-saved-14.c: Likewise. * gcc.target/i386/no-callee-saved-15.c: Likewise. * gcc.target/i386/no-callee-saved-16.c: Likewise. * gcc.target/i386/no-callee-saved-17.c: Likewise. * gcc.target/i386/no-callee-saved-18.c: Likewise. --- gcc/config/i386/i386-expand.cc| 72 --- gcc/config/i386/i386-options.cc | 49 + gcc/config/i386/i386.cc | 70 ++ gcc/config/i386/i386.h| 20 +- gcc/doc/extend.texi | 8 +++ .../gcc.dg/torture/no-callee-saved-run-1a.c | 23
[PATCH 2/2] x86: Don't save callee-saved registers in noreturn functions
There is no need to save callee-saved registers in noreturn functions
if they don't throw nor support exceptions. We can treat them the same
as functions with no_callee_saved_registers attribute.
Adjust stack-check-17.c for noreturn function which no longer saves any
registers.
With this change, __libc_start_main in glibc 2.39, which is a noreturn
function, is changed from
__libc_start_main:
endbr64
push %r15
push %r14
mov%rcx,%r14
push %r13
push %r12
push %rbp
mov%esi,%ebp
push %rbx
mov%rdx,%rbx
sub$0x28,%rsp
mov%rdi,(%rsp)
mov%fs:0x28,%rax
mov%rax,0x18(%rsp)
xor%eax,%eax
test %r9,%r9
to
__libc_start_main:
endbr64
sub$0x28,%rsp
mov%esi,%ebp
mov%rdx,%rbx
mov%rcx,%r14
mov%rdi,(%rsp)
mov%fs:0x28,%rax
mov%rax,0x18(%rsp)
xor%eax,%eax
test %r9,%r9
In Linux kernel 6.7.0 on x86-64, do_exit is changed from
do_exit:
endbr64
call
push %r15
push %r14
push %r13
push %r12
mov%rdi,%r12
push %rbp
push %rbx
mov%gs:0x0,%rbx
sub$0x28,%rsp
mov%gs:0x28,%rax
mov%rax,0x20(%rsp)
xor%eax,%eax
call *0x0(%rip)#
test $0x2,%ah
je
to
do_exit:
endbr64
call
sub$0x28,%rsp
mov%rdi,%r12
mov%gs:0x28,%rax
mov%rax,0x20(%rsp)
xor%eax,%eax
mov%gs:0x0,%rbx
call *0x0(%rip)#
test $0x2,%ah
je
I compared GCC master branch bootstrap and test times on a slow machine
with 6.6 Linux kernels compiled with the original GCC 13 and the GCC 13
with the backported patch. The performance data isn't precise since the
measurements were done on different days with different GCC sources under
different 6.6 kernel versions.
GCC master branch build time in seconds:
beforeafter improvement
30043.75user 30013.16user 0%
1274.85system 1243.72system 2.4%
GCC master branch test time in seconds (new tests added):
beforeafter improvement
216035.90user 216547.51user 0
27365.51system26658.54system 2.6%
gcc/
PR target/38534
* config/i386/i386-options.cc (ix86_set_func_type): Don't
save and restore callee saved registers for a noreturn function
with nothrow or compiled with -fno-exceptions.
gcc/testsuite/
PR target/38534
* gcc.target/i386/pr38534-1.c: New file.
* gcc.target/i386/pr38534-2.c: Likewise.
* gcc.target/i386/pr38534-3.c: Likewise.
* gcc.target/i386/pr38534-4.c: Likewise.
* gcc.target/i386/stack-check-17.c: Updated.
---
gcc/config/i386/i386-options.cc | 16 ++--
gcc/testsuite/gcc.target/i386/pr38534-1.c | 26 +++
gcc/testsuite/gcc.target/i386/pr38534-2.c | 18 +
gcc/testsuite/gcc.target/i386/pr38534-3.c | 19 ++
gcc/testsuite/gcc.target/i386/pr38534-4.c | 18 +
.../gcc.target/i386/stack-check-17.c | 19 +-
6 files changed, 102 insertions(+), 14 deletions(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr38534-1.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr38534-2.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr38534-3.c
create mode 100644 gcc/testsuite/gcc.target/i386/pr38534-4.c
diff --git a/gcc/config/i386/i386-options.cc b/gcc/config/i386/i386-options.cc
index 0cdea30599e..f965568947c 100644
--- a/gcc/config/i386/i386-options.cc
+++ b/gcc/config/i386/i386-options.cc
@@ -3371,9 +3371,21 @@ ix86_simd_clone_adjust (struct cgraph_node *node)
static void
ix86_set_func_type (tree fndecl)
{
+ /* No need to save and restore callee-saved registers for a noreturn
+ function with nothrow or compiled with -fno-exceptions.
+
+ NB: Don't use TREE_THIS_VOLATILE to check if this is a noreturn
+ function. The local-pure-const pass turns an interrupt function
+ into a noreturn function by setting TREE_THIS_VOLATILE. Normally
+ the local-pure-const pass is run after ix86_set_func_type is called.
+ When the local-pure-const pass is enabled for LTO, the interrupt
+ function is marked as noreturn in the IR output, which leads the
+ incompatible attribute error in LTO1. */
bool has_no_callee_saved_registers
-= lookup_attribute ("no_callee_saved_registers",
- TYPE_ATTRIBUTES (TREE_TYPE (fndecl)));
+= (((TREE_NOTHROW (fndecl) || !flag_exceptions)
+ && lookup_attribute ("noreturn", DECL_ATTRIBUTES (fndecl)))
+ || lookup_attribute
[PATCH 0/2] x86: Don't save callee-saved registers if not needed
In some cases, there are no need to save callee-saved registers: 1. If a noreturn function doesn't throw nor support exceptions, it can skip saving callee-saved registers. 2. When an interrupt handler is implemented by an assembly stub which does: 1. Save all registers. 2. Call a C function. 3. Restore all registers. 4. Return from interrupt. it is completely unnecessary to save and restore any registers in the C function called by the assembly stub, even if they would normally be callee-saved. This patch set adds no_callee_saved_registers function attribute, which is complementary to no_caller_saved_registers function attribute, to classify x86 backend call-saved register handling type with 1. Default call-saved registers. 2. No caller-saved registers with no_caller_saved_registers attribute. 3. No callee-saved registers with no_callee_saved_registers attribute. Functions of no callee-saved registers won't save callee-saved registers. If a noreturn function doesn't throw nor support exceptions, it is classified as the no callee-saved registers type. With these changes, __libc_start_main in glibc 2.39, which is a noreturn function, is changed from __libc_start_main: endbr64 push %r15 push %r14 mov%rcx,%r14 push %r13 push %r12 push %rbp mov%esi,%ebp push %rbx mov%rdx,%rbx sub$0x28,%rsp mov%rdi,(%rsp) mov%fs:0x28,%rax mov%rax,0x18(%rsp) xor%eax,%eax test %r9,%r9 to __libc_start_main: endbr64 sub$0x28,%rsp mov%esi,%ebp mov%rdx,%rbx mov%rcx,%r14 mov%rdi,(%rsp) mov%fs:0x28,%rax mov%rax,0x18(%rsp) xor%eax,%eax test %r9,%r9 In Linux kernel 6.7.0 on x86-64, do_exit is changed from do_exit: endbr64 call push %r15 push %r14 push %r13 push %r12 mov%rdi,%r12 push %rbp push %rbx mov%gs:0x0,%rbx sub$0x28,%rsp mov%gs:0x28,%rax mov%rax,0x20(%rsp) xor%eax,%eax call *0x0(%rip)# test $0x2,%ah je to do_exit: endbr64 call sub$0x28,%rsp mov%rdi,%r12 mov%gs:0x28,%rax mov%rax,0x20(%rsp) xor%eax,%eax mov%gs:0x0,%rbx call *0x0(%rip)# test $0x2,%ah je I compared GCC master branch bootstrap and test times on a slow machine with 6.6 Linux kernels compiled with the original GCC 13 and the GCC 13 with the backported patch. The performance data isn't precise since the measurements were done on different days with different GCC sources under different 6.6 kernel versions. GCC master branch build time in seconds: beforeafter improvement 30043.75user 30013.16user 0% 1274.85system 1243.72system 2.4% GCC master branch test time in seconds (new tests added): beforeafter improvement 216035.90user 216547.51user 0 27365.51system26658.54system 2.6% Backported to GCC 13 to rebuild system glibc and kernel on Fedora 39. Systems perform normally. H.J. Lu (2): x86: Add no_callee_saved_registers function attribute x86: Don't save callee-saved registers in noreturn functions gcc/config/i386/i386-expand.cc| 72 --- gcc/config/i386/i386-options.cc | 61 gcc/config/i386/i386.cc | 70 ++ gcc/config/i386/i386.h| 20 +- gcc/doc/extend.texi | 8 +++ .../gcc.dg/torture/no-callee-saved-run-1a.c | 23 ++ .../gcc.dg/torture/no-callee-saved-run-1b.c | 59 +++ .../gcc.target/i386/no-callee-saved-1.c | 30 .../gcc.target/i386/no-callee-saved-10.c | 46 .../gcc.target/i386/no-callee-saved-11.c | 11 +++ .../gcc.target/i386/no-callee-saved-12.c | 10 +++ .../gcc.target/i386/no-callee-saved-13.c | 16 + .../gcc.target/i386/no-callee-saved-14.c | 16 + .../gcc.target/i386/no-callee-saved-15.c | 17 + .../gcc.target/i386/no-callee-saved-16.c | 16 + .../gcc.target/i386/no-callee-saved-17.c | 16 + .../gcc.target/i386/no-callee-saved-18.c | 51 + .../gcc.target/i386/no-callee-saved-2.c | 30 .../gcc.target/i386/no-callee-saved-3.c | 8 +++ .../gcc.target/i386/no-callee-saved-4.c | 8 +++ .../gcc.target/i386/no-callee-saved-5.c | 11 +++ .../gcc.target/i386/no-callee-saved-6.c | 12 .../gcc.target/i386/no-callee-saved-7.c | 49 +
Re: [PATCH] lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
On Sat, Jan 20, 2024 at 12:11:10PM +0100, Richard Biener wrote:
> > The following patch ICEs because fre3 leaves around unfolded
> > _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
>
> Hmm, const_unop should handle this, I suppose either we fail to convert this
> to a NOP_EXPR or native encode/interpret do not handle it?
We just propagate
_BitInt(192) s;
_BitInt(129) _1;
s_6 = 0;
_1 = VIEW_CONVERT_EXPR<_BitInt(129)>(s_6);
to
_1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
without trying to fold it in any way (note, fre1, I mistyped fre3).
And the earlier is result of sra, before that it is
s = {};
_1 = s.b;
Jakub
Re: [PATCH] lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
> Am 20.01.2024 um 10:39 schrieb Jakub Jelinek :
>
> Hi!
>
> The following patch ICEs because fre3 leaves around unfolded
> _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
Hmm, const_unop should handle this, I suppose either we fail to convert this to
a NOP_EXPR or native encode/interpret do not handle it?
Richard
> statement and in handle_cast I was expecting just SSA_NAMEs for the
> large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
> we can handle in that case exactly the same, as the handle_operand recursion
> handles those.
>
> Of course, maybe we should also try to fold_stmt such cases somewhere in
> bitint lowering preparation.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok
Richard
> 2024-01-20 Jakub Jelinek
>
>PR tree-optimization/113462
>* gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
>Handle rhs1 INTEGER_CST like SSA_NAME.
>
>* gcc.dg/bitint-76.c: New test.
>
> --- gcc/gimple-lower-bitint.cc.jj2024-01-19 10:01:37.696673929 +0100
> +++ gcc/gimple-lower-bitint.cc2024-01-19 18:36:34.175254308 +0100
> @@ -1250,7 +1250,7 @@ bitint_large_huge::handle_cast (tree lhs
> {
> tree rhs_type = TREE_TYPE (rhs1);
> gimple *g;
> - if (TREE_CODE (rhs1) == SSA_NAME
> + if ((TREE_CODE (rhs1) == SSA_NAME || TREE_CODE (rhs1) == INTEGER_CST)
> && TREE_CODE (lhs_type) == BITINT_TYPE
> && TREE_CODE (rhs_type) == BITINT_TYPE
> && bitint_precision_kind (lhs_type) >= bitint_prec_large
> --- gcc/testsuite/gcc.dg/bitint-76.c.jj2024-01-19 18:39:23.883980766 +0100
> +++ gcc/testsuite/gcc.dg/bitint-76.c2024-01-19 18:38:48.758451335 +0100
> @@ -0,0 +1,16 @@
> +/* PR tree-optimization/113462 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-std=c23 -O2" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 129
> +typedef _BitInt(129) B;
> +#else
> +typedef _BitInt(63) B;
> +#endif
> +
> +B
> +foo (void)
> +{
> + struct { B b; } s = {};
> + return s.b;
> +}
>
>Jakub
>
Re: [PATCH] tree-switch-conversion: Bugfixes for _BitInt [PR113491]
> Am 20.01.2024 um 10:36 schrieb Jakub Jelinek :
>
> Hi!
>
> The following patch fixes various issues with large/huge _BitInt used as
> switch
> expressions.
> In particular:
> 1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than
> sizetype precision, varasm uses wi::to_offset on those and too large
> indexes ICE; we've already checked earlier that the cluster is at most
> sizetype bits and arrays can't be larger than that anyway
> 2) some spots were using SCALAR_INT_TYPE_MODE or
> lang_hooks.types.type_for_mode on TYPE_MODE to determine types to use,
> that obviously doesn't work for the large/huge BITINT_TYPE
> 3) like the recent change in the C FE, this patch makes sure we don't create
> ARRAY_REFs with indexes with precision above sizetype precision, because
> bitint lowering isn't prepared for that and because the indexes can't be
> larger than sizetype anyway; the subtraction of the cluster minimum from
> the index obviously needs to be done in unsigned __int128 or large/huge
> BITINT_TYPE, but then we cast to sizetype if the precision is larger than
> sizetype
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Ok
Richard
> 2024-01-20 Jakub Jelinek
>
>PR tree-optimization/113491
>* tree-switch-conversion.cc (switch_conversion::build_constructors):
>If elt.index has precision higher than sizetype, fold_convert it to
>sizetype.
>(switch_conversion::array_value_type): Return type if type is
>BITINT_TYPE with precision above MAX_FIXED_MODE_SIZE or with BLKmode.
>(switch_conversion::build_arrays): Use unsigned_type_for rather than
>lang_hooks.types.type_for_mode if utype is BITINT_TYPE with precision
>above MAX_FIXED_MODE_SIZE or with BLKmode. If utype has precision
>higher than sizetype, use sizetype as tidx type and fold_convert the
>subtraction to sizetype.
>
>* gcc.dg/torture/bitint-51.c: New test.
>
> --- gcc/tree-switch-conversion.cc.jj2024-01-03 11:51:24.210832797 +0100
> +++ gcc/tree-switch-conversion.cc2024-01-19 18:13:12.928850888 +0100
> @@ -423,6 +423,9 @@ switch_conversion::build_constructors ()
> constructor_elt elt;
>
> elt.index = int_const_binop (MINUS_EXPR, pos, m_range_min);
> + if (TYPE_PRECISION (TREE_TYPE (elt.index))
> + > TYPE_PRECISION (sizetype))
> +elt.index = fold_convert (sizetype, elt.index);
> elt.value
>= unshare_expr_without_location (m_default_values[k]);
> m_constructors[k]->quick_push (elt);
> @@ -452,6 +455,9 @@ switch_conversion::build_constructors ()
> constructor_elt elt;
>
> elt.index = int_const_binop (MINUS_EXPR, pos, m_range_min);
> + if (TYPE_PRECISION (TREE_TYPE (elt.index))
> + > TYPE_PRECISION (sizetype))
> +elt.index = fold_convert (sizetype, elt.index);
> elt.value = unshare_expr_without_location (val);
> m_constructors[j]->quick_push (elt);
>
> @@ -543,7 +549,10 @@ switch_conversion::array_value_type (tre
>
> type = TYPE_MAIN_VARIANT (type);
>
> - if (!INTEGRAL_TYPE_P (type))
> + if (!INTEGRAL_TYPE_P (type)
> + || (TREE_CODE (type) == BITINT_TYPE
> + && (TYPE_PRECISION (type) > MAX_FIXED_MODE_SIZE
> + || TYPE_MODE (type) == BLKmode)))
> return type;
>
> scalar_int_mode type_mode = SCALAR_INT_TYPE_MODE (type);
> @@ -707,7 +716,7 @@ void
> switch_conversion::build_arrays ()
> {
> tree arr_index_type;
> - tree tidx, sub, utype;
> + tree tidx, sub, utype, tidxtype;
> gimple *stmt;
> gimple_stmt_iterator gsi;
> gphi_iterator gpi;
> @@ -720,14 +729,23 @@ switch_conversion::build_arrays ()
> utype = TREE_TYPE (m_index_expr);
> if (TREE_TYPE (utype))
> utype = lang_hooks.types.type_for_mode (TYPE_MODE (TREE_TYPE (utype)), 1);
> + else if (TREE_CODE (utype) == BITINT_TYPE
> + && (TYPE_PRECISION (utype) > MAX_FIXED_MODE_SIZE
> + || TYPE_MODE (utype) == BLKmode))
> +utype = unsigned_type_for (utype);
> else
> utype = lang_hooks.types.type_for_mode (TYPE_MODE (utype), 1);
> + if (TYPE_PRECISION (utype) > TYPE_PRECISION (sizetype))
> +tidxtype = sizetype;
> + else
> +tidxtype = utype;
>
> arr_index_type = build_index_type (m_range_size);
> - tidx = make_ssa_name (utype);
> + tidx = make_ssa_name (tidxtype);
> sub = fold_build2_loc (loc, MINUS_EXPR, utype,
> fold_convert_loc (loc, utype, m_index_expr),
> fold_convert_loc (loc, utype, m_range_min));
> + sub = fold_convert (tidxtype, sub);
> sub = force_gimple_operand_gsi (, sub,
> false, NULL, true, GSI_SAME_STMT);
> stmt = gimple_build_assign (tidx, sub);
> --- gcc/testsuite/gcc.dg/torture/bitint-51.c.jj2024-01-19
> 18:21:53.013463622 +0100
> +++ gcc/testsuite/gcc.dg/torture/bitint-51.c2024-01-19 18:21:21.793906456
> +0100
> @@ -0,0 +1,88 @@
> +/* PR tree-optimization/113491 */
> +/* { dg-do run {
[PATCH v3] c++/modules: Emit definitions of ODR-used static members imported from modules [PR112899]
On Fri, Jan 19, 2024 at 01:57:18PM -0500, Patrick Palka wrote:
> On Wed, 3 Jan 2024, Nathaniel Shead wrote:
>
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> >
> > -- >8 --
> >
> > Static data members marked 'inline' should be emitted in TUs where they
> > are ODR-used. We need to make sure that statics imported from modules
> > are correctly added to the 'pending_statics' map so that they get
> > emitted if needed, otherwise the attached testcase fails to link.
> >
> > PR c++/112899
> >
> > gcc/cp/ChangeLog:
> >
> > * cp-tree.h (note_variable_template_instantiation): Rename to...
> > (note_static_storage_variable): ...this.
> > * decl2.cc (note_variable_template_instantiation): Rename to...
> > (note_static_storage_variable): ...this.
> > * pt.cc (instantiate_decl): Rename usage of above function.
> > * module.cc (trees_in::read_var_def): Remember pending statics
> > that we stream in.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/modules/init-4_a.C: New test.
> > * g++.dg/modules/init-4_b.C: New test.
> >
> > Signed-off-by: Nathaniel Shead
> > ---
> > gcc/cp/cp-tree.h| 2 +-
> > gcc/cp/decl2.cc | 4 ++--
> > gcc/cp/module.cc| 4
> > gcc/cp/pt.cc| 2 +-
> > gcc/testsuite/g++.dg/modules/init-4_a.C | 9 +
> > gcc/testsuite/g++.dg/modules/init-4_b.C | 11 +++
> > 6 files changed, 28 insertions(+), 4 deletions(-)
> > create mode 100644 gcc/testsuite/g++.dg/modules/init-4_a.C
> > create mode 100644 gcc/testsuite/g++.dg/modules/init-4_b.C
> >
> > diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> > index 1979572c365..ebd2850599a 100644
> > --- a/gcc/cp/cp-tree.h
> > +++ b/gcc/cp/cp-tree.h
> > @@ -7113,7 +7113,7 @@ extern tree maybe_get_tls_wrapper_call
> > (tree);
> > extern void mark_needed(tree);
> > extern bool decl_needed_p (tree);
> > extern void note_vague_linkage_fn (tree);
> > -extern void note_variable_template_instantiation (tree);
> > +extern void note_static_storage_variable (tree);
> > extern tree build_artificial_parm (tree, tree, tree);
> > extern bool possibly_inlined_p (tree);
> > extern int parm_index (tree);
> > diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
> > index 0850d3f5bce..241216b0dfe 100644
> > --- a/gcc/cp/decl2.cc
> > +++ b/gcc/cp/decl2.cc
> > @@ -910,10 +910,10 @@ note_vague_linkage_fn (tree decl)
> >vec_safe_push (deferred_fns, decl);
> > }
> >
> > -/* As above, but for variable template instantiations. */
> > +/* As above, but for variables with static storage duration. */
> >
> > void
> > -note_variable_template_instantiation (tree decl)
> > +note_static_storage_variable (tree decl)
> > {
> >vec_safe_push (pending_statics, decl);
> > }
> > diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> > index 0bd46414da9..14818131a70 100644
> > --- a/gcc/cp/module.cc
> > +++ b/gcc/cp/module.cc
> > @@ -11752,6 +11752,10 @@ trees_in::read_var_def (tree decl, tree
> > maybe_template)
> > DECL_INITIALIZED_P (decl) = true;
> > if (maybe_dup && DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P
> > (maybe_dup))
> > DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P (decl) = true;
> > + if (DECL_CONTEXT (decl)
> > + && RECORD_OR_UNION_TYPE_P (DECL_CONTEXT (decl))
> > + && !DECL_TEMPLATE_INFO (decl))
> > + note_static_storage_variable (decl);
>
> It seems this should also handle templated inlines via
>
>&& (!DECL_TEMPLATE_INFO (decl)
>|| DECL_IMPLICIT_INSTANTIATION (decl))
>
> otherwise the following fails to link:
>
> $ cat init-5_a.H
> template
> struct __from_chars_alnum_to_val_table {
> static inline int value = 42;
> };
>
> inline unsigned char
> __from_chars_alnum_to_val() {
> return __from_chars_alnum_to_val_table::value;
> }
>
> $ cat init-6_b.C
> import "init-5_a.H";
>
> int main() {
> __from_chars_alnum_to_val();
> }
>
> $ g++ -fmodules-ts -std=c++20 init-5_a.H init-5_b.C
> /usr/bin/ld: /tmp/ccNRaads.o: in function `__from_chars_alnum_to_val()':
>
> init-6_b.C:(.text._Z25__from_chars_alnum_to_valv[_Z25__from_chars_alnum_to_valv]+0x6):
> undefined reference to `__from_chars_alnum_to_val_table::value'
Ah yes, of course, since that's the other context where declarations are
added to 'pending_statics'.
>
> By the way I ran into this when testing out std::print with modules:
>
> $ cat std.C
> export module std;
> export import ;
>
> $ cat hello.C
> import std;
>
> int main() {
> std::print("Hello {}!", "World");
> }
>
> $ g++ -fmodules-ts -std=c++26 -x c++-system-header bits/stdc++.h
> $ g++ -fmodules-ts -std=c++26 std.C hello.C && ./a.out # before
> /usr/bin/ld: /tmp/ccqNgOM1.o: in function `unsigned char
>
[patch] nvptx.opt: Add sm_89 and sm_90a to -march-map=
Stumbled over this as we recently got a sm_89 card. -march-map= is mostly a future proof method for user to ensure to use always the best code gen for a specific card - without needing to know which GCC version added support for what --march=sm_... (or -misa=sm_... - those are aliases). sm_89 was added in CUDA 11.8 (ptx isa 7.8) and sm_90a in CUDA 12.0 (ptx isa 8.0) but that's just FYI as -march-map=sm_xx, xx >= 80 is mapping to -march=sm_80 and implies -mptx=7.0 (i.e. ptx isa 7.0, added in CUDA 11.0); hence, any CUDA 11.0+ will do. OK for mainline? Tobias nvptx.opt: Add sm_89 and sm_90a to -march-map= The -march-map= options maps the compute capability to the closest lower compute capability that has been implemented; for sm_89 and sm_90a, that were previously missing, that's currently -march=sm_80 alias -misa=sm_80. gcc/ChangeLog: * config/nvptx/nvptx.opt (march-map=): Add sm_89 and sm_90a. Signed-off-by: Tobias Burnus diff --git a/gcc/config/nvptx/nvptx.opt b/gcc/config/nvptx/nvptx.opt index 09d75fca037..deb006663d7 100644 --- a/gcc/config/nvptx/nvptx.opt +++ b/gcc/config/nvptx/nvptx.opt @@ -108,9 +108,15 @@ Target RejectNegative Alias(misa=,sm_80) march-map=sm_87 Target RejectNegative Alias(misa=,sm_80) +march-map=sm_89 +Target RejectNegative Alias(misa=,sm_80) + march-map=sm_90 Target RejectNegative Alias(misa=,sm_80) +march-map=sm_90a +Target RejectNegative Alias(misa=,sm_80) + Enum Name(ptx_version) Type(int) Known PTX ISA versions (for use with the -mptx= option):
[PATCH] lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
Hi!
The following patch ICEs because fre3 leaves around unfolded
_1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
statement and in handle_cast I was expecting just SSA_NAMEs for the
large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
we can handle in that case exactly the same, as the handle_operand recursion
handles those.
Of course, maybe we should also try to fold_stmt such cases somewhere in
bitint lowering preparation.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-20 Jakub Jelinek
PR tree-optimization/113462
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
Handle rhs1 INTEGER_CST like SSA_NAME.
* gcc.dg/bitint-76.c: New test.
--- gcc/gimple-lower-bitint.cc.jj 2024-01-19 10:01:37.696673929 +0100
+++ gcc/gimple-lower-bitint.cc 2024-01-19 18:36:34.175254308 +0100
@@ -1250,7 +1250,7 @@ bitint_large_huge::handle_cast (tree lhs
{
tree rhs_type = TREE_TYPE (rhs1);
gimple *g;
- if (TREE_CODE (rhs1) == SSA_NAME
+ if ((TREE_CODE (rhs1) == SSA_NAME || TREE_CODE (rhs1) == INTEGER_CST)
&& TREE_CODE (lhs_type) == BITINT_TYPE
&& TREE_CODE (rhs_type) == BITINT_TYPE
&& bitint_precision_kind (lhs_type) >= bitint_prec_large
--- gcc/testsuite/gcc.dg/bitint-76.c.jj 2024-01-19 18:39:23.883980766 +0100
+++ gcc/testsuite/gcc.dg/bitint-76.c2024-01-19 18:38:48.758451335 +0100
@@ -0,0 +1,16 @@
+/* PR tree-optimization/113462 */
+/* { dg-do compile { target bitint } } */
+/* { dg-options "-std=c23 -O2" } */
+
+#if __BITINT_MAXWIDTH__ >= 129
+typedef _BitInt(129) B;
+#else
+typedef _BitInt(63) B;
+#endif
+
+B
+foo (void)
+{
+ struct { B b; } s = {};
+ return s.b;
+}
Jakub
[PATCH] tree-switch-conversion: Bugfixes for _BitInt [PR113491]
Hi!
The following patch fixes various issues with large/huge _BitInt used as switch
expressions.
In particular:
1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than
sizetype precision, varasm uses wi::to_offset on those and too large
indexes ICE; we've already checked earlier that the cluster is at most
sizetype bits and arrays can't be larger than that anyway
2) some spots were using SCALAR_INT_TYPE_MODE or
lang_hooks.types.type_for_mode on TYPE_MODE to determine types to use,
that obviously doesn't work for the large/huge BITINT_TYPE
3) like the recent change in the C FE, this patch makes sure we don't create
ARRAY_REFs with indexes with precision above sizetype precision, because
bitint lowering isn't prepared for that and because the indexes can't be
larger than sizetype anyway; the subtraction of the cluster minimum from
the index obviously needs to be done in unsigned __int128 or large/huge
BITINT_TYPE, but then we cast to sizetype if the precision is larger than
sizetype
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2024-01-20 Jakub Jelinek
PR tree-optimization/113491
* tree-switch-conversion.cc (switch_conversion::build_constructors):
If elt.index has precision higher than sizetype, fold_convert it to
sizetype.
(switch_conversion::array_value_type): Return type if type is
BITINT_TYPE with precision above MAX_FIXED_MODE_SIZE or with BLKmode.
(switch_conversion::build_arrays): Use unsigned_type_for rather than
lang_hooks.types.type_for_mode if utype is BITINT_TYPE with precision
above MAX_FIXED_MODE_SIZE or with BLKmode. If utype has precision
higher than sizetype, use sizetype as tidx type and fold_convert the
subtraction to sizetype.
* gcc.dg/torture/bitint-51.c: New test.
--- gcc/tree-switch-conversion.cc.jj2024-01-03 11:51:24.210832797 +0100
+++ gcc/tree-switch-conversion.cc 2024-01-19 18:13:12.928850888 +0100
@@ -423,6 +423,9 @@ switch_conversion::build_constructors ()
constructor_elt elt;
elt.index = int_const_binop (MINUS_EXPR, pos, m_range_min);
+ if (TYPE_PRECISION (TREE_TYPE (elt.index))
+ > TYPE_PRECISION (sizetype))
+ elt.index = fold_convert (sizetype, elt.index);
elt.value
= unshare_expr_without_location (m_default_values[k]);
m_constructors[k]->quick_push (elt);
@@ -452,6 +455,9 @@ switch_conversion::build_constructors ()
constructor_elt elt;
elt.index = int_const_binop (MINUS_EXPR, pos, m_range_min);
+ if (TYPE_PRECISION (TREE_TYPE (elt.index))
+ > TYPE_PRECISION (sizetype))
+ elt.index = fold_convert (sizetype, elt.index);
elt.value = unshare_expr_without_location (val);
m_constructors[j]->quick_push (elt);
@@ -543,7 +549,10 @@ switch_conversion::array_value_type (tre
type = TYPE_MAIN_VARIANT (type);
- if (!INTEGRAL_TYPE_P (type))
+ if (!INTEGRAL_TYPE_P (type)
+ || (TREE_CODE (type) == BITINT_TYPE
+ && (TYPE_PRECISION (type) > MAX_FIXED_MODE_SIZE
+ || TYPE_MODE (type) == BLKmode)))
return type;
scalar_int_mode type_mode = SCALAR_INT_TYPE_MODE (type);
@@ -707,7 +716,7 @@ void
switch_conversion::build_arrays ()
{
tree arr_index_type;
- tree tidx, sub, utype;
+ tree tidx, sub, utype, tidxtype;
gimple *stmt;
gimple_stmt_iterator gsi;
gphi_iterator gpi;
@@ -720,14 +729,23 @@ switch_conversion::build_arrays ()
utype = TREE_TYPE (m_index_expr);
if (TREE_TYPE (utype))
utype = lang_hooks.types.type_for_mode (TYPE_MODE (TREE_TYPE (utype)), 1);
+ else if (TREE_CODE (utype) == BITINT_TYPE
+ && (TYPE_PRECISION (utype) > MAX_FIXED_MODE_SIZE
+ || TYPE_MODE (utype) == BLKmode))
+utype = unsigned_type_for (utype);
else
utype = lang_hooks.types.type_for_mode (TYPE_MODE (utype), 1);
+ if (TYPE_PRECISION (utype) > TYPE_PRECISION (sizetype))
+tidxtype = sizetype;
+ else
+tidxtype = utype;
arr_index_type = build_index_type (m_range_size);
- tidx = make_ssa_name (utype);
+ tidx = make_ssa_name (tidxtype);
sub = fold_build2_loc (loc, MINUS_EXPR, utype,
fold_convert_loc (loc, utype, m_index_expr),
fold_convert_loc (loc, utype, m_range_min));
+ sub = fold_convert (tidxtype, sub);
sub = force_gimple_operand_gsi (, sub,
false, NULL, true, GSI_SAME_STMT);
stmt = gimple_build_assign (tidx, sub);
--- gcc/testsuite/gcc.dg/torture/bitint-51.c.jj 2024-01-19 18:21:53.013463622
+0100
+++ gcc/testsuite/gcc.dg/torture/bitint-51.c2024-01-19 18:21:21.793906456
+0100
@@ -0,0 +1,88 @@
+/* PR tree-optimization/113491 */
+/* { dg-do run { target bitint } } */
+/* { dg-options "-std=c23
Re: [middle-end PATCH] Prefer PLUS over IOR in RTL expansion of multi-word shifts/rotates.
On Fri, Jan 19, 2024 at 5:50 PM Jeff Law wrote:
>
>
>
> On 1/19/24 09:05, Georg-Johann Lay wrote:
> >
> >
> > Am 18.01.24 um 20:54 schrieb Roger Sayle:
> >>
> >> This patch tweaks RTL expansion of multi-word shifts and rotates to use
> >> PLUS rather than IOR for disjunctive operations. During expansion of
> >> these operations, the middle-end creates RTL like (X<>C2)
> >> where the constants C1 and C2 guarantee that bits don't overlap.
> >> Hence the IOR can be performed by any any_or_plus operation, such as
> >> IOR, XOR or PLUS; for word-size operations where carry chains aren't
> >> an issue these should all be equally fast (single-cycle) instructions.
> >> The benefit of this change is that targets with shift-and-add insns,
> >> like x86's lea, can benefit from the LSHIFT-ADD form.
> >>
> >> An example of a backend that benefits is ARC, which is demonstrated
> >> by these two simple functions:
> >
> > But there are also back-ends where this is bad.
> >
> > The reason is that with ORI, the back-end needs only to operate no
> > these sub-words where the sub-mask is non-zero. But for PLUS this
> > is not the case because the back-end does not know that intermediate
> > carry will be zero. Hence, with PLUS, more instructions are needed.
> > An example is AVR, but maybe much more target with multi-word operations
> > are affected in a bad way.
> >
> > Take for example the case with 2 words and a value of 1.
> >
> > LO |= 1
> > HI |= 0
> >
> > can be optimized to
> >
> > LO |= 1
> >
> > but for addition this is not the case:
> >
> > LO += 1
> > HI +=c 0 ;; Does not know that always carry = 0.
> I think it's clear that the decision is target and possibly uarch
> specific within a target.
>
> Which means that expmed is probably the right place and that we're going
> to need to look for a good way for the target to control. I suspect
> rtx_cost isn't likely a good fit.
Perhaps related is PR108477 [1] and patch at [2], where x86 would
prefer PLUS instead of {X,I}OR, where we have disjoint bits in the
operands of {X,I}OR.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108477
[2] https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642164.html
Uros.
Re: [PING][PATCH] Include safe-ctype.h after C++ standard headers, to avoid over-poisoning
Sam James writes: > Dimitry Andric writes: > >> Ping. It would be nice to get this QoL fix in. >> > > Yes please - we've been using this in Gentoo since around when it was > first posted. No complaints. > > I cannot approve but it looks good to me. Ping. > >> -Dimitry >> >>> On 28 Sep 2023, at 18:37, Dimitry Andric wrote: >>> >>> Ref: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632 >>> >>> When building gcc's C++ sources against recent libc++, the poisoning of >>> the ctype macros due to including safe-ctype.h before including C++ >>> standard headers such as , , etc, causes many compilation >>> errors, similar to: >>> >>> In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: >>> In file included from /home/dim/src/gcc/master/gcc/system.h:233: >>> In file included from /usr/include/c++/v1/vector:321: >>> In file included from >>> /usr/include/c++/v1/__format/formatter_bool.h:20: >>> In file included from >>> /usr/include/c++/v1/__format/formatter_integral.h:32: >>> In file included from /usr/include/c++/v1/locale:202: >>> /usr/include/c++/v1/__locale:546:5: error: '__abi_tag__' attribute >>> only applies to structs, variables, functions, and namespaces >>> 546 | _LIBCPP_INLINE_VISIBILITY >>> | ^ >>> /usr/include/c++/v1/__config:813:37: note: expanded from macro >>> '_LIBCPP_INLINE_VISIBILITY' >>> 813 | # define _LIBCPP_INLINE_VISIBILITY _LIBCPP_HIDE_FROM_ABI >>> | ^ >>> /usr/include/c++/v1/__config:792:26: note: expanded from macro >>> '_LIBCPP_HIDE_FROM_ABI' >>> 792 | >>> __attribute__((__abi_tag__(_LIBCPP_TOSTRING( >>> _LIBCPP_VERSIONED_IDENTIFIER >>> | ^ >>> In file included from /home/dim/src/gcc/master/gcc/gensupport.cc:23: >>> In file included from /home/dim/src/gcc/master/gcc/system.h:233: >>> In file included from /usr/include/c++/v1/vector:321: >>> In file included from >>> /usr/include/c++/v1/__format/formatter_bool.h:20: >>> In file included from >>> /usr/include/c++/v1/__format/formatter_integral.h:32: >>> In file included from /usr/include/c++/v1/locale:202: >>> /usr/include/c++/v1/__locale:547:37: error: expected ';' at end of >>> declaration list >>> 547 | char_type toupper(char_type __c) const >>> | ^ >>> /usr/include/c++/v1/__locale:553:48: error: too many arguments >>> provided to function-like macro invocation >>> 553 | const char_type* toupper(char_type* __low, const >>> char_type* __high) const >>> |^ >>> /home/dim/src/gcc/master/gcc/../include/safe-ctype.h:146:9: note: >>> macro 'toupper' defined here >>> 146 | #define toupper(c) do_not_use_toupper_with_safe_ctype >>> | ^ >>> >>> This is because libc++ uses different transitive includes than >>> libstdc++, and some of those transitive includes pull in various ctype >>> declarations (typically via ). >>> >>> There was already a special case for including before >>> safe-ctype.h, so move the rest of the C++ standard header includes to >>> the same location, to fix the problem. >>> >>> Signed-off-by: Dimitry Andric >>> --- >>> gcc/system.h | 39 ++- >>> 1 file changed, 18 insertions(+), 21 deletions(-) >>> >>> diff --git a/gcc/system.h b/gcc/system.h >>> index e924152ad4c..7a516b11438 100644 >>> --- a/gcc/system.h >>> +++ b/gcc/system.h >>> @@ -194,27 +194,8 @@ extern int fprintf_unlocked (FILE *, const char *, >>> ...); >>> #undef fread_unlocked >>> #undef fwrite_unlocked >>> >>> -/* Include before "safe-ctype.h" to avoid GCC poisoning >>> - the ctype macros through safe-ctype.h */ >>> - >>> -#ifdef __cplusplus >>> -#ifdef INCLUDE_STRING >>> -# include >>> -#endif >>> -#endif >>> - >>> -/* There are an extraordinary number of issues with . >>> - The last straw is that it varies with the locale. Use libiberty's >>> - replacement instead. */ >>> -#include "safe-ctype.h" >>> - >>> -#include >>> - >>> -#include >>> - >>> -#if !defined (errno) && defined (HAVE_DECL_ERRNO) && !HAVE_DECL_ERRNO >>> -extern int errno; >>> -#endif >>> +/* Include C++ standard headers before "safe-ctype.h" to avoid GCC >>> + poisoning the ctype macros through safe-ctype.h */ >>> >>> #ifdef __cplusplus >>> #if defined (INCLUDE_ALGORITHM) || !defined (HAVE_SWAP_IN_UTILITY) >>> @@ -229,6 +210,9 @@ extern int errno; >>> #ifdef INCLUDE_SET >>> # include >>> #endif >>> +#ifdef INCLUDE_STRING >>> +# include >>> +#endif >>> #ifdef INCLUDE_VECTOR >>> # include >>> #endif >>> @@ -245,6 +229,19 @@ extern int errno; >>> # include >>> #endif >>> >>> +/* There are an extraordinary number of issues with . >>> + The last straw is that it varies with the locale. Use libiberty's >>> + replacement instead. */ >>> +#include "safe-ctype.h" >>> + >>> +#include >>> + >>> +#include >>> + >>> +#if !defined (errno) && defined (HAVE_DECL_ERRNO) && !HAVE_DECL_ERRNO >>>
