[PATCH v5, rs6000] Implemented f[min/max]_optab by xs[min/max]dp [PR103605]
Hi,
This patch implements optab f[min/max]_optab by xs[min/max]dp on rs6000.
Tests show that outputs of xs[min/max]dp are consistent with the standard
of C99 fmin/max.
This patch also binds __builtin_vsx_xs[min/max]dp to fmin/max instead
of smin/max. So the builtins always generate xs[min/max]dp on all
platforms.
Compared with previous version, I added a condition check for finite_math_only
in fmin/max insn.
Bootstrapped and tested on ppc64 Linux BE and LE with no regressions.
Is this okay for trunk? Any recommendations? Thanks a lot.
ChangeLog
2022-06-20 Haochen Gui
gcc/
PR target/105414
* match.pd (minmax): Skip constant folding for fmin/fmax when both
arguments are sNaN or one is sNaN and another is NaN.
gcc/testsuite/
PR target/105414
* gcc.dg/pr105414.c: New.
patch.diff
diff --git a/gcc/config/rs6000/rs6000-builtins.def
b/gcc/config/rs6000/rs6000-builtins.def
index f4a9f24bcc5..8b735493b40 100644
--- a/gcc/config/rs6000/rs6000-builtins.def
+++ b/gcc/config/rs6000/rs6000-builtins.def
@@ -1613,10 +1613,10 @@
XSCVSPDP vsx_xscvspdp {}
const double __builtin_vsx_xsmaxdp (double, double);
-XSMAXDP smaxdf3 {}
+XSMAXDP fmaxdf3 {}
const double __builtin_vsx_xsmindp (double, double);
-XSMINDP smindf3 {}
+XSMINDP fmindf3 {}
const double __builtin_vsx_xsrdpi (double);
XSRDPI vsx_xsrdpi {}
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index bf85baa5370..ae0dd98f0f9 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -158,6 +158,8 @@ (define_c_enum "unspec"
UNSPEC_HASHCHK
UNSPEC_XXSPLTIDP_CONST
UNSPEC_XXSPLTIW_CONST
+ UNSPEC_FMAX
+ UNSPEC_FMIN
])
;;
@@ -5341,6 +5343,22 @@ (define_insn_and_split "*s3_fpr"
DONE;
})
+
+(define_int_iterator FMINMAX [UNSPEC_FMAX UNSPEC_FMIN])
+
+(define_int_attr minmax_op [(UNSPEC_FMAX "max")
+(UNSPEC_FMIN "min")])
+
+(define_insn "f3"
+ [(set (match_operand:SFDF 0 "vsx_register_operand" "=wa")
+ (unspec:SFDF [(match_operand:SFDF 1 "vsx_register_operand" "wa")
+ (match_operand:SFDF 2 "vsx_register_operand" "wa")]
+FMINMAX))]
+ "TARGET_VSX && !flag_finite_math_only"
+ "xsdp %x0,%x1,%x2"
+ [(set_attr "type" "fp")]
+)
+
(define_expand "movcc"
[(set (match_operand:GPR 0 "gpc_reg_operand")
(if_then_else:GPR (match_operand 1 "comparison_operator")
diff --git a/gcc/testsuite/gcc.target/powerpc/pr103605.c
b/gcc/testsuite/gcc.target/powerpc/pr103605.c
new file mode 100644
index 000..e43ac40c2d1
--- /dev/null
+++ b/gcc/testsuite/gcc.target/powerpc/pr103605.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_vsx_ok } */
+/* { dg-options "-O1 -mvsx" } */
+/* { dg-final { scan-assembler-times {\mxsmaxdp\M} 3 } } */
+/* { dg-final { scan-assembler-times {\mxsmindp\M} 3 } } */
+
+#include
+
+double test1 (double d0, double d1)
+{
+ return fmin (d0, d1);
+}
+
+float test2 (float d0, float d1)
+{
+ return fmin (d0, d1);
+}
+
+double test3 (double d0, double d1)
+{
+ return fmax (d0, d1);
+}
+
+float test4 (float d0, float d1)
+{
+ return fmax (d0, d1);
+}
+
+double test5 (double d0, double d1)
+{
+ return __builtin_vsx_xsmindp (d0, d1);
+}
+
+double test6 (double d0, double d1)
+{
+ return __builtin_vsx_xsmaxdp (d0, d1);
+}
[ping][PATCH v1.1] tree-optimization/105736: Don't let error_mark_node escape for ADDR_EXPR
Hello,
ping!
On 14/06/2022 21:01, Siddhesh Poyarekar wrote:
The addr_expr computation does not check for error_mark_node before
returning the size expression. This used to work in the constant case
because the conversion to uhwi would end up causing it to return
size_unknown, but that won't work for the dynamic case.
Modify the control flow to explicitly return size_unknown if the offset
computation returns an error_mark_node.
gcc/ChangeLog:
PR tree-optimization/105736
* tree-object-size.cc (addr_object_size): Return size_unknown
when object offset computation returns an error.
gcc/testsuite/ChangeLog:
PR tree-optimization/105736
* gcc.dg/builtin-dynamic-object-size-0.c (TV4, val3,
test_pr105736): New struct declaration, variable and function to
test PR.
(main): Use them.
Signed-off-by: Siddhesh Poyarekar
---
Changes from v1:
- Used FAIL() instead of __builtin_abort() in the test.
Tested:
- x86_64 bootstrap and test
- --with-build-config=bootstrap-ubsan build
May I also backport this to gcc12?
.../gcc.dg/builtin-dynamic-object-size-0.c| 18 +
gcc/tree-object-size.cc | 20 ++-
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
index b5b0b3a677c..01a280b2d7b 100644
--- a/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
+++ b/gcc/testsuite/gcc.dg/builtin-dynamic-object-size-0.c
@@ -479,6 +479,20 @@ test_loop (int *obj, size_t sz, size_t start, size_t end,
int incr)
return __builtin_dynamic_object_size (ptr, 0);
}
+/* Other tests. */
+
+struct TV4
+{
+ __attribute__((vector_size (sizeof (int) * 4))) int v;
+};
+
+struct TV4 val3;
+int *
+test_pr105736 (struct TV4 *a)
+{
+ return >v[0];
+}
+
unsigned nfails = 0;
#define FAIL() ({ \
@@ -633,6 +647,10 @@ main (int argc, char **argv)
FAIL ();
if (test_loop (arr, 42, 20, 52, 1) != 0)
FAIL ();
+ /* pr105736. */
+ int *t = test_pr105736 ();
+ if (__builtin_dynamic_object_size (t, 0) != -1)
+FAIL ();
if (nfails > 0)
__builtin_abort ();
diff --git a/gcc/tree-object-size.cc b/gcc/tree-object-size.cc
index 5ca87ae3504..12bc0868b77 100644
--- a/gcc/tree-object-size.cc
+++ b/gcc/tree-object-size.cc
@@ -695,19 +695,21 @@ addr_object_size (struct object_size_info *osi,
const_tree ptr,
var_size = pt_var_size;
bytes = compute_object_offset (TREE_OPERAND (ptr, 0), var);
if (bytes != error_mark_node)
- bytes = size_for_offset (var_size, bytes);
- if (var != pt_var
- && pt_var_size
- && TREE_CODE (pt_var) == MEM_REF
- && bytes != error_mark_node)
{
- tree bytes2 = compute_object_offset (TREE_OPERAND (ptr, 0), pt_var);
- if (bytes2 != error_mark_node)
+ bytes = size_for_offset (var_size, bytes);
+ if (var != pt_var && pt_var_size && TREE_CODE (pt_var) == MEM_REF)
{
- bytes2 = size_for_offset (pt_var_size, bytes2);
- bytes = size_binop (MIN_EXPR, bytes, bytes2);
+ tree bytes2 = compute_object_offset (TREE_OPERAND (ptr, 0),
+ pt_var);
+ if (bytes2 != error_mark_node)
+ {
+ bytes2 = size_for_offset (pt_var_size, bytes2);
+ bytes = size_binop (MIN_EXPR, bytes, bytes2);
+ }
}
}
+ else
+ bytes = size_unknown (object_size_type);
wholebytes
= object_size_type & OST_SUBOBJECT ? var_size : pt_var_wholesize;
[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106022 --- Comment #2 from Hongtao.liu --- (In reply to H.J. Lu from comment #1) > SLP thinks that it needs 4 stores to store 4 bytes of integer constant. > But it takes only 1 4-byte store. I think we can simplify that at combine. Failed to match this instruction: (set (mem:V4QI (reg:DI 84) [0 MEM [(char *)c_2(D)]+0 S4 A8]) (const_vector:V4QI [ (const_int 0 [0]) (const_int 1 [0x1]) (const_int 2 [0x2]) (const_int 3 [0x3]) ])) x86 at most supports mov imm64, m64, so v2qi/v4qi/v8qi/v2hi/v4hi/v2hf/v4hf const_vector stores can be simplified to just mov imm64/imm32/imm16, m64/m32/m16.
Re: [PATCH 2/2] xtensa: Fix RTL insn cost estimation about relaxed MOVI instructions
On Sun, Jun 19, 2022 at 12:15 PM Takayuki 'January June' Suwa wrote: > > These instructions will all be converted to L32R ones with litpool entries > by the assembler. > > gcc/ChangeLog: > > * config/xtensa/xtensa.cc (xtensa_is_insn_L32R_p): > Consider relaxed MOVI instructions as L32R. > --- > gcc/config/xtensa/xtensa.cc | 22 ++ > 1 file changed, 14 insertions(+), 8 deletions(-) Regtested for target=xtensa-linux-uclibc, no new regressions. Committed to master. -- Thanks. -- Max
Re: [PATCH 1/2] xtensa: Apply a few minor fixes
On Sun, Jun 19, 2022 at 12:15 PM Takayuki 'January June' Suwa wrote: > > No functional changes. > > gcc/ChangeLog: > > * config/xtensa/xtensa.cc (xtensa_emit_move_sequence): > Use can_create_pseudo_p(), instead of using individual > reload_in_progress and reload_completed. > (xtensa_expand_block_set_small_loop): Use xtensa_simm8x256(), > the existing predicate function. > (xtensa_is_insn_L32R_p, gen_int_relational, xtensa_emit_sibcall): > Use the standard RTX code predicate macros such as MEM_P, > SYMBOL_REF_P and/or CONST_INT_P. > * config/xtensa/xtensa.md: Avoid using numeric literals to determine > if callee-saved register, at the split patterns for indirect sibcall > fixups. > --- > gcc/config/xtensa/xtensa.cc | 16 > gcc/config/xtensa/xtensa.md | 8 > 2 files changed, 12 insertions(+), 12 deletions(-) Regtested for target=xtensa-linux-uclibc, no new regressions. Committed to master. -- Thanks. -- Max
gcc-13-20220619 is now available
Snapshot gcc-13-20220619 is now available on https://gcc.gnu.org/pub/gcc/snapshots/13-20220619/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 13 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 4390e7bfbc641a52c6192b448768dafdf4565527 You'll find: gcc-13-20220619.tar.xz Complete GCC SHA256=90d2f107b82ca3a634081ee8f31d2e80bb27ce254f868aef2ac13e2a4d01b7b4 SHA1=000a3ed3d4fc3adedb66db50acd18bd88410999f Diffs from 13-20220612 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-13 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032
Andrew Pinski changed:
What|Removed |Added
Summary|[12/13 Regression] wrong|[10/11/12/13 Regression]
|code at -Os and above on|wrong code at -Os and above
|x86_64-linux-gnu|on x86_64-linux-gnu
Known to work|11.3.0 |6.1.0, 6.4.0
Target Milestone|13.0|10.4
Known to fail||7.1.0, 8.1.0, 9.1.0
--- Comment #4 from Andrew Pinski ---
Here is a testcase which shows this was latent but fails in GCC 7+ (so it is
still a regression):
int a, b, c, *d;
int main() {
int e = 0, f = 0;
int *dd = d;
for (; f < 1; f++)
if (c < 0)
e = *dd;
if (a) {
a = b ? 0 : a;
e && (b = a);
}
return 0;
}
[Bug rtl-optimization/106032] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |rtl-optimization
--- Comment #3 from Andrew Pinski ---
The tree level looks ok. THe only difference is 12/13 has:
if (c.0_1 < 0)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 679839639]:
e_15 = *d.1_2;
[local count: 59055800]:
While 11 does:
if (c.0_1 < 0)
goto ; [67.00%]
else
goto ; [33.00%]
[local count: 679839639]:
d.1_2 = d;
e_15 = *d.1_2;
[local count: 59055800]:
That is the load from the global d is now unconditional but the load from *d is
still conditional.
I see ce2 is doing ifcvt on that and changing it to be an unconditional load.
IF-THEN-JOIN block found, pass 1, test 3, then 4, join 5
(insn 57 56 58 2 (parallel [
(set (reg:SI 89)
(ashiftrt:SI (reg:SI 90 [ c ])
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":7:9 758 {ashrsi3_cvt}
(expr_list:REG_DEAD (reg:SI 90 [ c ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashiftrt:SI (mem/c:SI (symbol_ref:DI ("c")
[flags 0x2] ) [1 c+0 S4 A32])
(const_int 31 [0x1f]))
(nil)
(insn 58 57 16 2 (parallel [
(set (reg:SI 91)
(and:SI (reg:SI 89)
(mem:SI (reg/f:DI 83 [ d.1_2 ]) [1 *d.1_2+0 S4 A32])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":7:9 533 {*andsi_1}
(expr_list:REG_DEAD (reg:SI 89)
(expr_list:REG_DEAD (reg/f:DI 83 [ d.1_2 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
[Bug tree-optimization/106032] [12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032 Andrew Pinski changed: What|Removed |Added Version|unknown |13.0 Known to work||11.3.0 Last reconfirmed||2022-06-19 Keywords||wrong-code Ever confirmed|0 |1 Known to fail||12.1.0, 13.0 Target Milestone|--- |13.0 Summary|wrong code at -Os and above |[12/13 Regression] wrong |on x86_64-linux-gnu |code at -Os and above on ||x86_64-linux-gnu Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/106032] wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032 --- Comment #1 from Zhendong Su --- Compiler Explorer: https://godbolt.org/z/PnTzaKsf4
[Bug tree-optimization/106032] New: wrong code at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106032
Bug ID: 106032
Summary: wrong code at -Os and above on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a regression from 11.*.
[640] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers
--enable-languages=c,c++ --disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220619 (experimental) [master r13-1166-g4390e7bfbc6] (GCC)
[641] %
[641] % gcctk -O1 small.c; ./a.out
[642] %
[642] % gcctk -Os small.c
[643] % ./a.out
Segmentation fault
[644] %
[644] % cat small.c
int a, b, c, *d;
int main() {
int e = 0, f = 0;
for (; f < 1; f++)
if (c < 0)
e = *d;
if (a) {
a = b ? 0 : a;
e && (b = a);
}
return 0;
}
[Bug fortran/105954] ICE in gfc_element_size, at fortran/target-memory.cc:132
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105954 --- Comment #5 from anlauf at gcc dot gnu.org --- The following patch fixes the ICE and regtests OK: diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc index bd586e75008..3e04f45e9ac 100644 --- a/gcc/fortran/decl.cc +++ b/gcc/fortran/decl.cc @@ -2775,6 +2775,17 @@ variable_decl (int elem) else gfc_free_expr (n); } + /* For bounds of an array spec that are both constant, ensure +that the upper bound is not lower than lower bound minus +one. Otherwise fix it. */ + if (as->lower[i]->expr_type == EXPR_CONSTANT + && as->upper[i]->expr_type == EXPR_CONSTANT + && as->lower[i]->ts.type == BT_INTEGER + && as->upper[i]->ts.type == BT_INTEGER + && mpz_cmp (as->upper[i]->value.integer, + as->lower[i]->value.integer) < 0) + mpz_sub_ui (as->upper[i]->value.integer, + as->lower[i]->value.integer, 1); } } }
Re: remove intl/ directory?
Hi Bruno,
> On 19 Jun 2022, at 09:40, Iain Sandoe via Gcc wrote:
>
>> On 19 Jun 2022, at 01:32, Bruno Haible wrote:
>>> - so, please could we follow the pattern for GMP et. al. where the library
>>> can be provided with —with-intl= pointing to an installation
>>> , or be built in-tree by symlinking an approved version into the GCC tree.
>> I believe that this can be achieved easily by adding a few lines to the
>> Makefile.def, such as:
>>
>> host_modules= { module= gettext-runtime; no_install=true;
>> extra_configure_flags='--disable-shared';
>> lib_path=intl/.libs; };
>>
>> The symlink 'gettext-runtime' will need to point to the 'gettext-runtime'
>> *subdirectory* of an unpacked GNU gettext tarball.
>
> Thanks, that’s very helpful information - it could be something to trial
> relatively
> easily.
So, indeed, part of this is quite straight forward - we can amend the
Makefile.def
to specify that GCC should use gettext-runtime (it will be used if the
directory is
present, otherwise there will be no intl support).
The tricky part is that we need to use the runtime ‘uninstalled’, and here is
where
intl is helpful - it provides a ‘config.intl’ that can be sourced via
gettext-sister.m4
to provide the neccessary configure input to directories that want to use intl.
I have hacked a change to gettext-sister.m4 that fishes the same information out
of gettext-runtime/Makefile (as configured in $build) - obviously this is going
to be
fragile w.r.t different versions of gettext-runtime (so I am not suggesting
this is a
viable patch) - simply something to illustrate what needs to be figured out.
So - the changes are in Makefile.def and config/gettext-sister.m4 (the patch
includes
the regenerated files for convenience of use).
I tried this with gettext-0.21 on macOS 10.15 and, AFAICT, it DTRT - but needs
work
to resolve the main point above.
This has been tried with / without deleting intl; from the GCC perspective it
works the
same both ways, except that there’s a redundant build of intl when
gettext-runtime is
present (but it does mean that the other packages - GDB et. al, are not
changed).
I’d be interested in your ideas for how to solve the ‘uninstalled’ use.
Iain
P.S. I am slighty surprised that configuring with —disable-java does not appear
to stop
the on-screen popup appearing that tells me I need to install Java to use this
… that
would be an irritation when using this on a headless box.
0001-config-Quick-hack-to-try-using-gettext-runtime-in-pl.patch
Description: Binary data
[PATCH 1/2] xtensa: Apply a few minor fixes
No functional changes.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_emit_move_sequence):
Use can_create_pseudo_p(), instead of using individual
reload_in_progress and reload_completed.
(xtensa_expand_block_set_small_loop): Use xtensa_simm8x256(),
the existing predicate function.
(xtensa_is_insn_L32R_p, gen_int_relational, xtensa_emit_sibcall):
Use the standard RTX code predicate macros such as MEM_P,
SYMBOL_REF_P and/or CONST_INT_P.
* config/xtensa/xtensa.md: Avoid using numeric literals to determine
if callee-saved register, at the split patterns for indirect sibcall
fixups.
---
gcc/config/xtensa/xtensa.cc | 16
gcc/config/xtensa/xtensa.md | 8
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index c5d00acdf2c..2c534ff9c60 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -752,7 +752,7 @@ gen_int_relational (enum rtx_code test_code, /* relational
test (EQ, etc) */
}
/* See if we need to invert the result. */
- invert = ((GET_CODE (cmp1) == CONST_INT)
+ invert = (CONST_INT_P (cmp1)
? p_info->invert_const
: p_info->invert_reg);
@@ -1209,7 +1209,7 @@ xtensa_emit_move_sequence (rtx *operands, machine_mode
mode)
}
}
- if (!(reload_in_progress | reload_completed)
+ if (can_create_pseudo_p ()
&& !xtensa_valid_move (mode, operands))
operands[1] = force_reg (mode, operands[1]);
@@ -1612,7 +1612,7 @@ xtensa_expand_block_set_small_loop (rtx *operands)
thus limited to only offset to the end address for ADDI/ADDMI
instruction. */
if (align == 4
- && ! (bytes <= 127 || (bytes <= 32512 && bytes % 256 == 0)))
+ && ! (bytes <= 127 || xtensa_simm8x256 (bytes)))
return 0;
/* If no 4-byte aligned, loop count should be treated as the
@@ -2169,7 +2169,7 @@ xtensa_emit_sibcall (int callop, rtx *operands)
static char result[64];
rtx tgt = operands[callop];
- if (GET_CODE (tgt) == CONST_INT)
+ if (CONST_INT_P (tgt))
sprintf (result, "j.l\t" HOST_WIDE_INT_PRINT_HEX ", a9",
INTVAL (tgt));
else if (register_operand (tgt, VOIDmode))
@@ -4282,17 +4282,17 @@ xtensa_rtx_costs (rtx x, machine_mode mode, int
outer_code,
}
static bool
-xtensa_is_insn_L32R_p(const rtx_insn *insn)
+xtensa_is_insn_L32R_p (const rtx_insn *insn)
{
rtx x = PATTERN (insn);
if (GET_CODE (x) == SET)
{
- x = XEXP (x, 1);
- if (GET_CODE (x) == MEM)
+ x = SET_SRC (x);
+ if (MEM_P (x))
{
x = XEXP (x, 0);
- return (GET_CODE (x) == SYMBOL_REF || CONST_INT_P (x))
+ return (SYMBOL_REF_P (x) || CONST_INT_P (x))
&& CONSTANT_POOL_ADDRESS_P (x);
}
}
diff --git a/gcc/config/xtensa/xtensa.md b/gcc/config/xtensa/xtensa.md
index ef6bbc451b0..84b975cf00e 100644
--- a/gcc/config/xtensa/xtensa.md
+++ b/gcc/config/xtensa/xtensa.md
@@ -1246,14 +1246,14 @@
int i = 0;
rtx x = XEXP (operands[1], 0);
long l[2];
- if (GET_CODE (x) == SYMBOL_REF
+ if (SYMBOL_REF_P (x)
&& CONSTANT_POOL_ADDRESS_P (x))
x = get_pool_constant (x);
else if (GET_CODE (x) == CONST)
{
x = XEXP (x, 0);
gcc_assert (GET_CODE (x) == PLUS
- && GET_CODE (XEXP (x, 0)) == SYMBOL_REF
+ && SYMBOL_REF_P (XEXP (x, 0))
&& CONSTANT_POOL_ADDRESS_P (XEXP (x, 0))
&& CONST_INT_P (XEXP (x, 1)));
i = INTVAL (XEXP (x, 1));
@@ -2212,7 +2212,7 @@
(match_operand 1 ""))]
"reload_completed
&& !TARGET_WINDOWED_ABI && SIBLING_CALL_P (insn)
- && IN_RANGE (REGNO (operands[0]), 12, 15)"
+ && ! call_used_or_fixed_reg_p (REGNO (operands[0]))"
[(set (reg:SI A10_REG)
(match_dup 0))
(call (mem:SI (reg:SI A10_REG))
@@ -2245,7 +2245,7 @@
(match_operand 2 "")))]
"reload_completed
&& !TARGET_WINDOWED_ABI && SIBLING_CALL_P (insn)
- && IN_RANGE (REGNO (operands[1]), 12, 15)"
+ && ! call_used_or_fixed_reg_p (REGNO (operands[1]))"
[(set (reg:SI A10_REG)
(match_dup 1))
(set (match_dup 0)
--
2.20.1
[PATCH 2/2] xtensa: Fix RTL insn cost estimation about relaxed MOVI instructions
These instructions will all be converted to L32R ones with litpool entries
by the assembler.
gcc/ChangeLog:
* config/xtensa/xtensa.cc (xtensa_is_insn_L32R_p):
Consider relaxed MOVI instructions as L32R.
---
gcc/config/xtensa/xtensa.cc | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/gcc/config/xtensa/xtensa.cc b/gcc/config/xtensa/xtensa.cc
index 2c534ff9c60..13f2b2b832c 100644
--- a/gcc/config/xtensa/xtensa.cc
+++ b/gcc/config/xtensa/xtensa.cc
@@ -4286,17 +4286,23 @@ xtensa_is_insn_L32R_p (const rtx_insn *insn)
{
rtx x = PATTERN (insn);
- if (GET_CODE (x) == SET)
+ if (GET_CODE (x) != SET)
+return false;
+
+ x = XEXP (x, 1);
+ if (MEM_P (x))
{
- x = SET_SRC (x);
- if (MEM_P (x))
- {
- x = XEXP (x, 0);
- return (SYMBOL_REF_P (x) || CONST_INT_P (x))
-&& CONSTANT_POOL_ADDRESS_P (x);
- }
+ x = XEXP (x, 0);
+ return (SYMBOL_REF_P (x) || CONST_INT_P (x))
+&& CONSTANT_POOL_ADDRESS_P (x);
}
+ /* relaxed MOVI instructions, that will be converted to L32R by the
+ assembler. */
+ if (CONST_INT_P (x)
+ && ! xtensa_simm12b (INTVAL (x)))
+return true;
+
return false;
}
--
2.20.1
[Bug c++/105931] [12/13 regression] ICE in cxx_eval_constant_expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105931 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/105982] [13 Regression] internal compiler error: in lookup_template_class, at cp/pt.cc:10361
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105982 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/105956] [13 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1819
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105956 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug ada/106031] New: ICE on container map empty aggregate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106031 Bug ID: 106031 Summary: ICE on container map empty aggregate. Product: gcc Version: 12.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: p.p11 at orange dot fr Target Milestone: --- Created attachment 53166 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53166=edit Full source code Following the example section of RM Ada 2022 § 4.3.5 Container Aggregate, I want to try map aggregates: 4.package Section_4_3_5_Paragraph_54 is 5. type Map_Type is private 6. with Aggregate => (Empty => Empty_Map, 7. Add_Named => Add_To_Map); 8. 9. procedure Add_To_Map (M : in out Map_Type; Key : in Integer; Value : in String); 10. 11. Empty_Map : constant Map_Type; 12. 13. function Get (M : Map_Type; Key : in Integer) return String; 14.private 15. type Map_Type is array (1..10) of String (1..10); 16. Empty_Map : constant Map_Type := []; 17.end Section_4_3_5_Paragraph_54; It is ok when checking but issues a bug box when compiling: gprbuild -d -P/Users/me/Tests/tests.gpr -XBUILD_MODE=Debugging test_20220619_map_agg.adb Compile [Ada] test_20220619_map_agg.adb +===GNAT BUG DETECTED==+ | 12.1.0 (x86_64-apple-darwin19.6.0) GCC error:| | in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:472 | | Error detected at test_20220619_map_agg.adb:16:40| | Compiling /Users/me/Tests/2022/test_20220619_map_agg.adb| | Please submit a bug report; see https://gcc.gnu.org/bugs/ . | | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact command that you entered. | | Also include sources listed below. | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /Users/me/Tests/2022/test_20220619_map_agg.adb test_20220619_map_agg.adb:23:28: warning: index for "Value" may assume lower bound of 1 [-gnatww] test_20220619_map_agg.adb:23:28: warning: suggested replacement: "Value'First" [-gnatww] test_20220619_map_agg.adb:23:31: warning: index for "Value" may assume lower bound of 1 [-gnatww] test_20220619_map_agg.adb:23:31: warning: suggested replacement: "Value'First + 9" [-gnatww] compilation abandoned gprbuild: *** compilation phase failed [2022-06-19 19:08:24] process exited with status 4, elapsed time: 00.69s
[Bug c/106030] ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030 --- Comment #1 from David Binderman --- I should mention that this code is fine on x86_64, but breaks on arm-32 native and cross.
[Bug c++/77306] Unable to specify visibility for explicit template instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77306 Thiago Macieira changed: What|Removed |Added CC||thiago at kde dot org --- Comment #3 from Thiago Macieira --- *** Bug 106023 has been marked as a duplicate of this bug. ***
[Bug c++/106023] Would like to control the ELF visibility of template explicit instantiations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106023 Thiago Macieira changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Thiago Macieira --- Ah, so it is. Thanks for putting up with my being lazy. *** This bug has been marked as a duplicate of bug 77306 ***
[Bug c/106030] New: ice in emit_move_insn, at expr.cc:4026
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106030
Bug ID: 106030
Summary: ice in emit_move_insn, at expr.cc:4026
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
int safe_mul_func_int8_t_s_s_si2, g_7014, g_11941_l_12290;
char(safe_mul_func_uint8_t_u_u)(ui1, ui2) { return ui1 * ui2; }
void g_11941() {
char __trans_tmp_1 =
(safe_mul_func_uint8_t_u_u <= g_7014) * safe_mul_func_int8_t_s_s_si2;
g_11941_l_12290 = safe_mul_func_uint8_t_u_u(2 != g_11941, __trans_tmp_1);
}
can be compiled like this:
$ /home/dcb/gcc/results/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/home/dcb/gcc/results/bin/gcc
COLLECT_LTO_WRAPPER=/home/dcb/gcc/results.20220617/libexec/gcc/arm-linux-gnueabihf/13.0.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../trunk/configure --prefix=/home/dcb/gcc/results.20220617
--disable-bootstrap --disable-multilib --disable-werror
--with-pkgversion=1d6044c250e3badf --enable-checking=yes
--enable-languages=c,c++ --with-cpu=cortex-a72 --with-fpu=neon-fp-armv8
--with-float=hard --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220617 (experimental) (1d6044c250e3badf)
$ /home/dcb/gcc/results/bin/gcc -c -w q.i
$
but switch on -O1 and this happens:
$ /home/dcb/gcc/results/bin/gcc -c -w -O1 q.i
during RTL pass: expand
q.i: In function 'g_11941':
q.i:6:19: internal compiler error: in emit_move_insn, at expr.cc:4026
6 | g_11941_l_12290 = safe_mul_func_uint8_t_u_u(2 != g_11941,
__trans_tmp_
1);
|
^~
~~
0x551897 emit_move_insn(rtx_def*, rtx_def*)
/home/dcb/gcc/working/gcc/../../trunk/gcc/expr.cc:4025
0x54608f expand_and(machine_mode, rtx_def*, rtx_def*, rtx_def*)
/home/dcb/gcc/working/gcc/../../trunk/gcc/expmed.cc:5482
[Bug tree-optimization/106025] Incorrect optimization at -O2 leads to infinite test execution time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106025 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #1 from Mikael Pettersson --- I can reproduce with gcc version 13.0.0 20220619 at -O2 on x86_64-pc-linux-gnu, but not with gcc version 12.1.1 20220618 or gcc-11. I tried -fsanitize=undefined to see if the code had any UB, but that was silent _and_ masked the problem.
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 Immad Mir changed: What|Removed |Added Last reconfirmed||2022-06-19 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
save/relocate/restore call stack or coroutine?
Hi! Purely theoretical question here. :) Many people, including myself, keep falling into this trap: https://www.reddit.com/r/cpp/comments/eewqwc/serializable_coroutines_in_c_gameplay_code/ Which is that they take the fibers/coroutines to implement some logic with wait/blocking capability, and, because there is a state object (eg ucontext_t) and an explicitly allocated stack frame, they expect to be able to save/restore it along with any other save data. I believe this even worked in some limited scenarios in pre-ASLR era, but today they face the fact that the call stack needs to be somehow "relocated" to be loaded on a different process. I looked around to see what gcc technologines are available to help with that, and what I've found, is: - backtrace() can be used to identify all return addresses on stack, and to patch them up. - Named address spaces __seg_fs, __seg_gs can be used to make some pointers relocation- friendly. Unfortunately there seem to be no way to build the entire compilation unit with __seg_fs being a default address space, and also there seem to be no conversion between __seg_fs and normal pointers (by adding/subtracting rdfsbase on a conversion). - Stack maps: https://www.mail-archive.com/gcc@gcc.gnu.org/msg77319.html were considered too difficult to implement: https://www.mail-archive.com/gcc@gcc.gnu.org/msg77317.html and AFAICS are still not implemented. They could help to identify all pointers to heap objects and relocate them, but I wonder if they are only considered for strongly-typed languages, and not for C/C++. So the question is: how realistic is to expect that the call stacks would be saveable/relocatable one day? How far are we from that point? It looks like all the needed technologies already either exist or at least are considered for an implementation. Or am I missing much more unsolvable problems? Or maybe there is already some other way of doing that? :)
[Bug middle-end/105998] [10/11/12 Regression] ICE: in as_a, at machmode.h:365 with vector arithmetics since r9-1971-g315aa691f486bf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105998
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e8df0d960b36146c8e193b269f9f7ae7dc76e08b
commit r12-8496-ge8df0d960b36146c8e193b269f9f7ae7dc76e08b
Author: Jakub Jelinek
Date: Sat Jun 18 11:07:13 2022 +0200
varasm: Fix up ICE in narrowing_initializer_constant_valid_p [PR105998]
The following testcase ICEs because there is NON_LVALUE_EXPR (location
wrapper) around a VAR_DECL and has TYPE_MODE V2SImode and
SCALAR_INT_TYPE_MODE on that ICEs. Or for -m32 -march=i386 TYPE_MODE
is DImode, but SCALAR_INT_TYPE_MODE still uses the raw V2SImode and ICEs
too.
2022-06-18 Jakub Jelinek
PR middle-end/105998
* varasm.cc (narrowing_initializer_constant_valid_p): Check
SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P, also break on
! INTEGRAL_TYPE_P and do the same check also on op{0,1}'s type.
* c-c++-common/pr105998.c: New test.
(cherry picked from commit ef662120177d39af5f88ffc622d90bb6ae0ca1d3)
[Bug c++/106001] [12/13 Regression] ICE: expected expression 'static_cast(1)' of kind static_cast_expr since r12-1128-gef8176e0fac935
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106001 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:566e599c8194f789b077eb94a5e45ced2de5b31e commit r12-8495-g566e599c8194f789b077eb94a5e45ced2de5b31e Author: Jakub Jelinek Date: Fri Jun 17 17:40:49 2022 +0200 c++: Use fold_non_dependent_expr rather than maybe_constant_value in __builtin_shufflevector handling [PR106001] In this case the STATIC_CAST_EXPR expressions in the call aren't type nor value dependent, but maybe_constant_value still ICEs on those when processing_template_decl. Calling fold_non_dependent_expr on it instead fixes the ICE and folds them to INTEGER_CSTs. 2022-06-17 Jakub Jelinek PR c++/106001 * typeck.cc (build_x_shufflevector): Use fold_non_dependent_expr instead of maybe_constant_value. * g++.dg/ext/builtin-shufflevector-4.C: New test. (cherry picked from commit a284fadcce8ef443cc3cc047a8017745efb51758)
[Bug middle-end/105951] [12 Regression] ICE in emit_store_flag, at expmed.cc:6027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105951
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:86e10e471fddfcacb0c02d02f30ab5bb2038e504
commit r12-8494-g86e10e471fddfcacb0c02d02f30ab5bb2038e504
Author: Jakub Jelinek
Date: Thu Jun 16 10:58:58 2022 +0200
expand: Fix up IFN_ATOMIC_{BIT*,*CMP_0} expansion [PR105951]
Both IFN_ATOMIC_BIT_TEST_AND_* and IFN_ATOMIC_*_FETCH_CMP_0 ifns
are matched if their corresponding optab is implemented for the particular
mode. The fact that those optabs are implemented doesn't guarantee
they will succeed though, they can just FAIL in their expansion.
The expansion in that case uses expand_atomic_fetch_op as fallback, but
as has been reported and and can be reproduced on the testcases,
even those can fail and we didn't have any fallback after that.
For IFN_ATOMIC_BIT_TEST_AND_* we actually have such calls. One is
done whenever we lost lhs of the ifn at some point in between matching
it in tree-ssa-ccp.cc and expansion. The following patch for that case
just falls through and expands as if there was a lhs, creates a temporary
for it. For the other expand_atomic_fetch_op call in the same expander
and for the only expand_atomic_fetch_op call in the other, this falls
back the hard way, by constructing a CALL_EXPR to the call from which
the ifn has been matched and expanding that. Either it is lucky and
manages
to expand inline, or it emits a libatomic API call.
So that we don't have to rediscover which builtin function to call in the
fallback, we record at tree-ssa-ccp.cc time gimple_call_fn (call) in
an extra argument to the ifn.
2022-06-16 Jakub Jelinek
PR middle-end/105951
* tree-ssa-ccp.cc (optimize_atomic_bit_test_and,
optimize_atomic_op_fetch_cmp_0): Remember gimple_call_fn (call)
as last argument to the internal functions.
* builtins.cc (expand_ifn_atomic_bit_test_and): Adjust for the
extra call argument to ifns. If expand_atomic_fetch_op fails for
the
lhs == NULL_TREE case, fall through into the optab code with
gen_reg_rtx (mode) as target. If second expand_atomic_fetch_op
fails, construct a CALL_EXPR and expand that.
(expand_ifn_atomic_op_fetch_cmp_0): Adjust for the extra call
argument
to ifns. If expand_atomic_fetch_op fails, construct a CALL_EXPR
and
expand that.
* gcc.target/i386/pr105951-1.c: New test.
* gcc.target/i386/pr105951-2.c: New test.
(cherry picked from commit 6a27c430468cb85454b19cef881a1422580657ff)
[Bug tree-optimization/105739] [10 Regression] Miscompilation of Linux kernel update.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105739 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:bf4ba940673b80961c5979078f9d37a7bef2f5ff commit r12-8493-gbf4ba940673b80961c5979078f9d37a7bef2f5ff Author: Jan Hubicka Date: Tue Jun 14 14:05:53 2022 +0200 Fix ipa-cp wrt volatile loads Check for volatile flag to ipa_load_from_parm_agg. gcc/ChangeLog: 2022-06-10 Jan Hubicka PR ipa/105739 * ipa-prop.cc (ipa_load_from_parm_agg): Punt on volatile loads. gcc/testsuite/ChangeLog: 2022-06-10 Jan Hubicka * gcc.dg/ipa/pr105739.c: New test. (cherry picked from commit 8f6c317b3a16350698f3c9e0accb43a9b4acb4ae)
[Bug c++/105871] ICE: in wide_int_to_tree_1, at tree.cc:1777 with __builtin_shufflevector() in C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105871 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0ddeeb11e45b9b7e9ebc18292a42769304bf3e44 commit r12-8492-g0ddeeb11e45b9b7e9ebc18292a42769304bf3e44 Author: Jakub Jelinek Date: Thu Jun 9 17:42:31 2022 +0200 c++: Fix up ICE on __builtin_shufflevector constexpr evaluation [PR105871] As the following testcase shows, BIT_FIELD_REF result doesn't have to have just integral type, it can also have vector type. And in that case cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that case, creates the initial value with build_int_cst (sure, that one could be easily replaced with build_zero_cst) and then expects it can through shifts, ands and ors come up with the final value, but that doesn't work for vectors. We already call fold_ternary if whole is a VECTOR_CST, this patch does the same if the result doesn't have integral type. And, there is no guarantee fold_ternary will succeed and the callers certainly don't expect NULL being returned, so it also diagnoses those as non-constant and returns original t in that case. 2022-06-09 Jakub Jelinek PR c++/105871 * constexpr.cc (cxx_eval_bit_field_ref): For BIT_FIELD_REF with non-integral result type use fold_ternary too like for BIT_FIELD_REFs from VECTOR_CST. If fold_ternary returns NULL, diagnose non-constant expression, set *non_constant_p and return t, instead of returning NULL. * g++.dg/pr105871.C: New test. (cherry picked from commit 4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d)
[Bug tree-optimization/106012] rsqrtps and rcpps instructiona generated even if -fno-reciprocal-math specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106012 vincenzo Innocente changed: What|Removed |Added Summary|rsqrtss instruction |rsqrtps and rcpps |generated even if |instructiona generated even |-mno-recip specified|if -fno-reciprocal-math ||specified Status|RESOLVED|NEW Resolution|WONTFIX |--- --- Comment #3 from vincenzo Innocente --- Thanks for the suggestion. -fno-reciprocal-math does indeed inhibit scalar reciprocal instructions. NOT in vectorized loop though. see https://godbolt.org/z/9eMb4Tjee
[Bug c++/106029] New: gcc doesn't report full stack trace for static_assert()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106029
Bug ID: 106029
Summary: gcc doesn't report full stack trace for
static_assert()
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: realazthat at gmail dot com
Target Milestone: ---
Created attachment 53165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53165=edit
symbol.cxx
When triggering a static_assert within the standard library, clang prints a
stack-trace of the instantiation that triggered the assert, but every file/line
it lists in the trace is not in user code (rather, it is within stdlib), which
makes it extraordinarily difficult to debug ( kinds of traces are very famously
difficult to read in the first place, there is no reason to make it nearly
impossible!).
In the code below, const std::optional>> =
c; is invalid instantiation because Thing is not copy constructible, and this
forces the optional not to be copy constructible, yet the only possible thing
to do here is to make a copy, so it asserts.
However, the error does not point to this line, and in a large amount of code I
required creduce to pinpoint this.
### Code
symbol.cxx:
```
#include
#include
struct Thing {
Thing() = delete;
Thing(const Thing&) = delete;
Thing& operator=(const Thing&) = delete;
Thing& operator=( Thing&&);
Thing(Thing&&);
};
void b() {
std::vector> c;
// The following line instantiates the static_assert failure,
// but it is not listed in the error.
const std::optional>> = c;
}
```
### Compile command
```
$g++-11 symbol.cxx -std=c++20
```
### Output
In file included from /usr/include/c++/11/vector:66,
from symbol.cxx:2:
/usr/include/c++/11/bits/stl_uninitialized.h: In instantiation of
‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator*, std::vector > >; _ForwardIterator =
std::optional*]’:
/usr/include/c++/11/bits/stl_uninitialized.h:333:37: required from
‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator,
_ForwardIterator, std::allocator<_Tp>&) [with _InputIterator =
__gnu_cxx::__normal_iterator*,
std::vector > >; _ForwardIterator = std::optional*;
_Tp = std::optional]’
/usr/include/c++/11/bits/stl_vector.h:558:31: required from ‘std::vector<_Tp,
_Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp =
std::optional; _Alloc = std::allocator >]’
/usr/include/c++/11/optional:225:8: required from ‘constexpr
std::_Optional_payload_base<_Tp>::_Storage<_Up,
false>::_Storage(std::in_place_t, _Args&& ...) [with _Args =
{std::vector, std::allocator > >&};
_Up = std::vector >; _Tp =
std::vector >]’
/usr/include/c++/11/optional:116:4: required from ‘constexpr
std::_Optional_payload_base<_Tp>::_Optional_payload_base(std::in_place_t,
_Args&& ...) [with _Args = {std::vector,
std::allocator > >&}; _Tp =
std::vector >]’
/usr/include/c++/11/optional:358:42: required from here
/usr/include/c++/11/bits/stl_uninitialized.h:138:72: error: static assertion
failed: result type must be constructible from value type of input range
138 | static_assert(is_constructible<_ValueType2,
decltype(*__first)>::value,
|
^
/usr/include/c++/11/bits/stl_uninitialized.h:138:72: note:
‘std::integral_constant::value’ evaluates to false
```
### Expected output
An additional line like this:
```
/path/to/symbol.cxx:16:2: required from here
```
### GCC Version
```
$g++-11 --v
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.1.0-1ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --disable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
Re: remove intl/ directory?
Hi Bruno,
> On 19 Jun 2022, at 01:32, Bruno Haible wrote:
>
> Iain Sandoe wrote:
>> As a maintainer for GCC on a non-glibc system, I would:
>> (b) not want to [force] add a shared lib dependency for my downstream.
>
> In order to avoid shared libs, the user merely has to pass the option
> '--disable-shared' to GNU gettext's configure.
Well, we try to make things easy for end-users, so actually the objective would
be that (for those who are prepared to download a pre-built binary) that they do
not have to find and build _any_ other libs.
“Distributions” might choose to go the shared library route - on the basis that
they have already presumably automated the installation of dependencies
- so it’s just that the user has to wait a little longer for the install...
For people intending to build from source, we can try to automate with scripts
and pre-fetching of prerequisites etc. .. OTOH GCC is complex enough in its
own right, it’s better to keep things as simple as possible.
>
>> - so, please could we follow the pattern for GMP et. al. where the library
>> can be provided with —with-intl= pointing to an installation
>
> That convention is already built-in in the gettext.m4 macro; the option is
> called --with-libintl-prefix there.
>
>> , or be built in-tree by symlinking an approved version into the GCC tree.
>
> If you are referring to the sentence found in the GCC documentation for
> ISL, MPFR, etc.
> "If an isl source distribution is found in a subdirectory of your GCC
> sources named isl, it will be built together with GCC."
yes, exactly - that is usually how I build GCC - in addition to the
simplification of distributing a built compiler, it also has the advantage that
the same deps that one tested with are fixed into the binary.
> I believe that this can be achieved easily by adding a few lines to the
> Makefile.def, such as:
>
> host_modules= { module= gettext-runtime; no_install=true;
>extra_configure_flags='--disable-shared';
>lib_path=intl/.libs; };
>
> The symlink 'gettext-runtime' will need to point to the 'gettext-runtime'
> *subdirectory* of an unpacked GNU gettext tarball.
Thanks, that’s very helpful information - it could be something to trial
relatively
easily.
** NOTE: this is not a GCC-only decision, intl is used by a number of other
pieces
(GDB, GDB-server, binutils etc. etc) These projects share the top-level build
infrastructure — [see Makefile.def and grep intl].
I suppose one could try s/intl/gettext-runtime/ and then rebuild the top-level
makefiles..
thanks,
Iain
[Bug lto/105933] LTO ltrans object files does not have proper st_bind and st_visibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105933 --- Comment #2 from Tatsuyuki Ishi --- Created attachment 53164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53164=edit A source that fails to link when ltrans is grabbed separatedly and passed to link Here's a minimized test case from the linked mold issue for the purpose of reproducing the issue. For normal LTO usage, it compiles fine with `g++ main.cpp /usr/lib/libboost_fiber.a /usr/lib/libboost_context.a -flto`. We now add `-save-temps` to grab a copy of the ltrans output. Then, we grab the command line used to link through `-v`, then pass the ltrans object to ld directly. It will give you a duplicate symbol error. Exact command line attached below. $ ld --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/Scrt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtbeginS.o -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0 -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../.. a.ltrans0.ltrans.o /usr/lib/libboost_fiber.a /usr/lib/libboost_context.a -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/../../../../lib/crtn.o ld: /usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZGVZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0): multiple definition of `guard variable for boost::fibers::detail::spinlock_ttas::lock()::generator'; a.ltrans0.ltrans.o:(.tbss+0x8): first defined here ld: /usr/lib/libboost_fiber.a(condition_variable.o):(.tbss._ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator[_ZZN5boost6fibers6detail13spinlock_ttas4lockEvE9generator]+0x0): multiple definition of `boost::fibers::detail::spinlock_ttas::lock()::generator'; a.ltrans0.ltrans.o:(.tbss+0x0): first defined here To ensure successful resolution with GNU_UNIQUE TLS symbols, you need either WEAK symbols or COMDAT groups. GCC ltrans contains neither. When used with the LTO plugin, it inherits the weak st_bind from IR objects, and passes through the fallback WEAK symbols based resolution for duplicate C++ definitions (we usually use COMDAT). When you don't have the LTO plugin, boom, it's a GLOBAL symbol vs UNIQUE symbol which is a conflict without question.
[Bug libstdc++/106028] New: std::filesystem::path lacks conversion to native mbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106028
Bug ID: 106028
Summary: std::filesystem::path lacks conversion to native mbs
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: goughostt at gmail dot com
Target Milestone: ---
The following assumes c++17 std.
With Windows (mingw): a path can be build with UTF-8 (`u8path`) or native mbs
(`path(const char*)`) and converted to UTF-8 string (`path.string()` and
`path.u8string()`).
It seems impossible to get a native mbs string back (easily).
I suggest `path.string()` to return the native mbs string instead.
That allows one to `printf` the path in Windows.
Otherwise, I cannot find an easy way (without explicit encoding conversion) for
a mingw cross-compiled binary to print paths to the Cmd console.
As I understand, the suggested change conforms to the standard.
And developers also noted this in the code (XXX):
if (__str_codecvt_out_all(__wfirst, __wlast, __u8str, __cvt)) {
if constexpr (is_same_v<_CharT, char>)
return __u8str; // XXX assumes native ordinary encoding is UTF-8.
else {
