[committed] texi + c-target.def: Fix typos
Fixed couple of documentation typos; namely, misspelled words and duplicated
words.
Committed as r12-7635.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
commit 1b85638affe6c987a33427c54e0369b819cd7915
Author: Tobias Burnus
Date: Sun Mar 13 10:23:07 2022 +0100
texi + c-target.def: Fix typos
gcc/c-family/ChangeLog:
* c-target.def (check_string_object_format_arg): Fix description typo.
gcc/ChangeLog:
* doc/invoke.texi: Fix typos.
* doc/tm.texi.in: Remove duplicated word.
* doc/tm.texi: Regenerate.
libgomp/ChangeLog:
* libgomp.texi: Fix typo.
---
gcc/c-family/c-target.def | 2 +-
gcc/doc/invoke.texi | 6 +++---
gcc/doc/tm.texi | 4 ++--
gcc/doc/tm.texi.in| 2 +-
libgomp/libgomp.texi | 2 +-
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/c-family/c-target.def b/gcc/c-family/c-target.def
index bd47db0507c..141dcf30716 100644
--- a/gcc/c-family/c-target.def
+++ b/gcc/c-family/c-target.def
@@ -81,7 +81,7 @@ DEFHOOK
DEFHOOK
(check_string_object_format_arg,
- "If a target implements string objects then this hook should should\n\
+ "If a target implements string objects then this hook should\n\
provide a facility to check the function arguments in @var{args_list}\n\
against the format specifiers in @var{format_arg} where the type of\n\
@var{format_arg} is one recognized as a valid string reference type.",
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 036e1f0c32b..2a14e1a9472 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -8238,7 +8238,7 @@ Warn when attempting to deallocate an object that was either not allocated
on the heap, or by using a pointer that was not returned from a prior call
to the corresponding allocation function. For example, because the call
to @code{stpcpy} returns a pointer to the terminating nul character and
-not to the begginning of the object, the call to @code{free} below is
+not to the beginning of the object, the call to @code{free} below is
diagnosed.
@smallexample
@@ -9527,7 +9527,7 @@ accessing more than the maximum number of elements may be diagnosed.
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 specifies that the array argument must have at least @code{n}
-elements. In addition, calling @code{f} with the assotiated VLA bound
+elements. In addition, calling @code{f} with the associated VLA bound
parameter in excess of the actual VLA bound triggers a warning as well.
@smallexample
@@ -19639,7 +19639,7 @@ Generate instructions supported by barrel shifter. This is the default
unless @option{-mcpu=ARC601} or @samp{-mcpu=ARCEM} is in effect.
@item -mjli-always
-@opindex mjli-alawys
+@opindex mjli-always
Force to call a function using jli_s instruction. This option is
valid only for ARCv2 architecture.
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index 49864dd79f8..2f92d37da8c 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -736,7 +736,7 @@ If a target implements string objects then this hook should return
@end deftypefn
@deftypefn {C Target Hook} void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree @var{format_arg}, tree @var{args_list})
-If a target implements string objects then this hook should should
+If a target implements string objects then this hook should
provide a facility to check the function arguments in @var{args_list}
against the format specifiers in @var{format_arg} where the type of
@var{format_arg} is one recognized as a valid string reference type.
@@ -2799,7 +2799,7 @@ intermediate registers or scratch registers.
If copying a register @var{class} in @var{mode} to @var{x} requires an
intermediate or scratch register, @code{SECONDARY_OUTPUT_RELOAD_CLASS}
-was supposed to be defined be defined to return the largest register
+was supposed to be defined to return the largest register
class required. If the
requirements for input and output reloads were the same, the macro
@code{SECONDARY_RELOAD_CLASS} should have been used instead of defining both
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index 95e5e341f07..f869ddd5e5b 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -2279,7 +2279,7 @@ intermediate registers or scratch registers.
If copying a register @var{class} in @var{mode} to @var{x} requires an
intermediate or scratch register, @code{SECONDARY_OUTPUT_RELOAD_CLASS}
-was supposed to be defined be defined to return the largest register
+was supposed to be defined to return the largest register
class required. If the
requirements for input and output reloads were the same,
[PATCH] ifcvt: Punt if not onlyjump_p for find_if_case_{1,2} [PR104814]
Hi!
find_if_case_{1,2} implicitly assumes conditional jumps and rewrites them,
so if they have extra side-effects or are say asm goto, things don't work
well, either the side-effects are lost or we could ICE.
In particular, the testcase below on s390x has there a doloop instruction
that decrements a register in addition to testing it for non-zero and
conditionally jumping based on that.
The following patch fixes that by punting for !onlyjump_p case, i.e.
if there are side-effects in the jump instruction or it isn't a plain PC
setter.
Bootstrapped/regtested on {x86_64,i686,powerpc64le,aarch64,s390x}-linux,
ok for trunk?
2022-03-13 Jakub Jelinek
PR rtl-optimization/104814
* ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb doesn't
end with onlyjump_p.
* gcc.c-torture/execute/pr104814.c: New test.
--- gcc/ifcvt.cc.jj 2022-02-09 12:55:50.750773751 +0100
+++ gcc/ifcvt.cc2022-03-11 17:30:44.248855063 +0100
@@ -5259,6 +5259,10 @@ find_if_case_1 (basic_block test_bb, edg
&& CROSSING_JUMP_P (BB_END (else_bb
return FALSE;
+ /* Verify test_bb ends in a conditional jump with no other side-effects. */
+ if (!BB_END (test_bb) || !onlyjump_p (BB_END (test_bb)))
+return FALSE;
+
/* THEN has one successor. */
if (!single_succ_p (then_bb))
return FALSE;
@@ -5380,6 +5384,10 @@ find_if_case_2 (basic_block test_bb, edg
&& CROSSING_JUMP_P (BB_END (else_bb
return FALSE;
+ /* Verify test_bb ends in a conditional jump with no other side-effects. */
+ if (!BB_END (test_bb) || !onlyjump_p (BB_END (test_bb)))
+return FALSE;
+
/* ELSE has one successor. */
if (!single_succ_p (else_bb))
return FALSE;
--- gcc/testsuite/gcc.c-torture/execute/pr104814.c.jj 2022-03-11
17:36:58.753651766 +0100
+++ gcc/testsuite/gcc.c-torture/execute/pr104814.c 2022-03-11
17:36:45.120841179 +0100
@@ -0,0 +1,30 @@
+/* PR rtl-optimization/104814 */
+
+short a = 0;
+static long b = 0;
+int c = 7;
+char d = 0;
+short *e = &a;
+long f = 0;
+
+unsigned long
+foo (unsigned long h, long j)
+{
+ return j == 0 ? h : h / j;
+}
+
+int
+main ()
+{
+ long k = f;
+ for (; c; --c)
+{
+ for (int i = 0; i < 7; ++i)
+ ;
+ long m = foo (f, --b);
+ d = ((char) m | *e) <= 43165;
+}
+ if (b != -7)
+__builtin_abort ();
+ return 0;
+}
Jakub
Re: [PATCH] ifcvt: Punt if not onlyjump_p for find_if_case_{1, 2} [PR104814]
> Bootstrapped/regtested on {x86_64,i686,powerpc64le,aarch64,s390x}-linux,
> ok for trunk?
>
> 2022-03-13 Jakub Jelinek
>
> PR rtl-optimization/104814
> * ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb
> doesn't end with onlyjump_p.
>
> * gcc.c-torture/execute/pr104814.c: New test.
>
> --- gcc/ifcvt.cc.jj 2022-02-09 12:55:50.750773751 +0100
> +++ gcc/ifcvt.cc 2022-03-11 17:30:44.248855063 +0100
> @@ -5259,6 +5259,10 @@ find_if_case_1 (basic_block test_bb, edg
> && CROSSING_JUMP_P (BB_END (else_bb
> return FALSE;
>
> + /* Verify test_bb ends in a conditional jump with no other side-effects.
> */ + if (!BB_END (test_bb) || !onlyjump_p (BB_END (test_bb)))
> +return FALSE;
> +
>/* THEN has one successor. */
>if (!single_succ_p (then_bb))
> return FALSE;
> @@ -5380,6 +5384,10 @@ find_if_case_2 (basic_block test_bb, edg
> && CROSSING_JUMP_P (BB_END (else_bb
> return FALSE;
>
> + /* Verify test_bb ends in a conditional jump with no other side-effects.
> */ + if (!BB_END (test_bb) || !onlyjump_p (BB_END (test_bb)))
> +return FALSE;
> +
>/* ELSE has one successor. */
>if (!single_succ_p (else_bb))
> return FALSE;
Are the !BB_END tests really necessary? cond_exec_process_if_block has the
same test on onlyjump_p without it. Likewise for noce_find_if_block.
--
Eric Botcazou
Re: [PATCH] i386: Fix up _mm_loadu_si{16,32} [PR99754]
On Sun, Mar 13, 2022 at 3:28 AM Jakub Jelinek wrote:
>
> Hi!
>
> These intrinsics are supposed to do an unaligned may_alias load
> of a 16-bit or 32-bit value and store it as the first element of
> a 128-bit integer vector, with all other elements cleared.
>
> The current _mm_storeu_* implementation implements that correctly, uses
> __*_u types to do the store and extracts the first element of a vector into
> it.
> But _mm_loadu_si{16,32} gets it all wrong. It performs an aligned
> non-may_alias load and because _mm_set_epi{16,32} has the args reversed,
> it also inserts it into the last vector element instead of first.
>
> The following patch fixes that, bootstrapped/regtested on x86_64-linux
> and i686-linux, ok for trunk and affected release branches?
LGTM, thanks for handling this.
>
> Note, while the Intrinsics guide for _mm_loadu_si32 says SSE2,
> for _mm_loadu_si16 it says strangely SSE. But the intrinsics
> returns __m128i, which is only defined in emmintrin.h, and
> _mm_set_epi16 is also only SSE2 and later in emmintrin.h.
> Even clang defines it in emmintrin.h and ends up with inlining
> failure when calling _mm_loadu_si16 from sse,no-sse2 function.
> So, isn't that a bug in the intrinsic guide instead?
I think it's a bug, it's supposed to generate movzx + movd, and movd
is under sse2, and have reported it to the colleague who maintains
Intel intrinsic guide.
Similar bug for
_mm_loadu_si64
_mm_storeu_si16
_mm_storeu_si64
>
> 2022-03-12 Jakub Jelinek
>
> PR target/99754
> * config/i386/emmintrin.h (_mm_loadu_si32): Put loaded value into
> first rather than last element of the vector, use __m32_u to do
> a really unaligned load, use just 0 instead of (int)0.
> (_mm_loadu_si16): Put loaded value into first rather than last
> element of the vector, use __m16_u to do a really unaligned load,
> use just 0 instead of (short)0.
>
> * gcc.target/i386/pr99754-1.c: New test.
> * gcc.target/i386/pr99754-2.c: New test.
>
> --- gcc/config/i386/emmintrin.h.jj 2022-01-11 23:11:21.766298923 +0100
> +++ gcc/config/i386/emmintrin.h 2022-03-11 16:47:24.789884825 +0100
> @@ -718,14 +718,13 @@ _mm_loadu_si64 (void const *__P)
> extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_loadu_si32 (void const *__P)
> {
> - return _mm_set_epi32 (*(int *)__P, (int)0, (int)0, (int)0);
> + return _mm_set_epi32 (0, 0, 0, (*(__m32_u *)__P)[0]);
> }
>
> extern __inline __m128i __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> _mm_loadu_si16 (void const *__P)
> {
> - return _mm_set_epi16 (*(short *)__P, (short)0, (short)0, (short)0,
> - (short)0, (short)0, (short)0, (short)0);
> + return _mm_set_epi16 (0, 0, 0, 0, 0, 0, 0, (*(__m16_u *)__P)[0]);
> }
>
> extern __inline void __attribute__((__gnu_inline__, __always_inline__,
> __artificial__))
> --- gcc/testsuite/gcc.target/i386/pr99754-1.c.jj2022-03-11
> 16:43:30.621120896 +0100
> +++ gcc/testsuite/gcc.target/i386/pr99754-1.c 2022-03-11 16:43:18.250291856
> +0100
> @@ -0,0 +1,20 @@
> +/* PR target/99754 */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -msse2" } */
> +/* { dg-require-effective-target sse2 } */
> +
> +#include "sse2-check.h"
> +#include
> +
> +static void
> +sse2_test (void)
> +{
> + union { unsigned char buf[32]; long long ll; } u;
> + u.buf[1] = 0xfe;
> + u.buf[2] = 0xca;
> + u.buf[17] = 0xaa;
> + u.buf[18] = 0x55;
> + _mm_storeu_si16 (&u.buf[17], _mm_loadu_si16 (&u.buf[1]));
> + if (u.buf[17] != 0xfe || u.buf[18] != 0xca)
> +abort ();
> +}
> --- gcc/testsuite/gcc.target/i386/pr99754-2.c.jj2022-03-11
> 16:43:41.701967763 +0100
> +++ gcc/testsuite/gcc.target/i386/pr99754-2.c 2022-03-11 16:45:16.391659211
> +0100
> @@ -0,0 +1,24 @@
> +/* PR target/99754 */
> +/* { dg-do run } */
> +/* { dg-options "-O2 -msse2" } */
> +/* { dg-require-effective-target sse2 } */
> +
> +#include "sse2-check.h"
> +#include
> +
> +static void
> +sse2_test (void)
> +{
> + union { unsigned char buf[32]; long long ll; } u;
> + u.buf[1] = 0xbe;
> + u.buf[2] = 0xba;
> + u.buf[3] = 0xfe;
> + u.buf[4] = 0xca;
> + u.buf[17] = 0xaa;
> + u.buf[18] = 0x55;
> + u.buf[19] = 0xaa;
> + u.buf[20] = 0x55;
> + _mm_storeu_si32 (&u.buf[17], _mm_loadu_si32 (&u.buf[1]));
> + if (u.buf[17] != 0xbe || u.buf[18] != 0xba || u.buf[19] != 0xfe ||
> u.buf[20] != 0xca)
> +abort ();
> +}
>
> Jakub
>
--
BR,
Hongtao
Re: [PATCH] ifcvt: Punt if not onlyjump_p for find_if_case_{1,2} [PR104814]
On Sun, Mar 13, 2022 at 02:03:33PM +0100, Eric Botcazou wrote:
> > Bootstrapped/regtested on {x86_64,i686,powerpc64le,aarch64,s390x}-linux,
> > ok for trunk?
> >
> > 2022-03-13 Jakub Jelinek
> >
> > PR rtl-optimization/104814
> > * ifcvt.cc (find_if_case_1, find_if_case_2): Punt if test_bb
> > doesn't end with onlyjump_p.
> >
> > * gcc.c-torture/execute/pr104814.c: New test.
> >
> > --- gcc/ifcvt.cc.jj 2022-02-09 12:55:50.750773751 +0100
> > +++ gcc/ifcvt.cc2022-03-11 17:30:44.248855063 +0100
> > @@ -5259,6 +5259,10 @@ find_if_case_1 (basic_block test_bb, edg
> > && CROSSING_JUMP_P (BB_END (else_bb
> > return FALSE;
> >
> > + /* Verify test_bb ends in a conditional jump with no other side-effects.
> > */ + if (!BB_END (test_bb) || !onlyjump_p (BB_END (test_bb)))
> > +return FALSE;
> > +
> >/* THEN has one successor. */
> >if (!single_succ_p (then_bb))
> > return FALSE;
> > @@ -5380,6 +5384,10 @@ find_if_case_2 (basic_block test_bb, edg
> > && CROSSING_JUMP_P (BB_END (else_bb
> > return FALSE;
> >
> > + /* Verify test_bb ends in a conditional jump with no other side-effects.
> > */ + if (!BB_END (test_bb) || !onlyjump_p (BB_END (test_bb)))
> > +return FALSE;
> > +
> >/* ELSE has one successor. */
> >if (!single_succ_p (else_bb))
> > return FALSE;
>
> Are the !BB_END tests really necessary? cond_exec_process_if_block has the
> same test on onlyjump_p without it. Likewise for noce_find_if_block.
Probably not, I've put it there only because the neighboring code is testing
it too:
if ((BB_END (then_bb)
&& JUMP_P (BB_END (then_bb))
&& CROSSING_JUMP_P (BB_END (then_bb)))
|| (BB_END (test_bb)
&& JUMP_P (BB_END (test_bb))
&& CROSSING_JUMP_P (BB_END (test_bb)))
|| (BB_END (else_bb)
&& JUMP_P (BB_END (else_bb))
&& CROSSING_JUMP_P (BB_END (else_bb
return FALSE;
find_if_header which calls find_if_case_* has:
if (EDGE_COUNT (test_bb->succs) != 2)
return NULL;
at the start, and I think an empty bb can't have more than one successor,
because there is nothing to cause different control flow.
Jakub
Re: [x86 PATCH] Fix libitm.c/memset-1.c test fails with new peephole2s.
On Sat, Mar 12, 2022 at 7:50 PM Roger Sayle wrote:
>
>
> My sincere apologies for the breakage, but alas handling SImode in the
> recently added "xorl;movb -> movzbl" peephole2 turns out to be slightly
> more complicated that just using SWI48 as a mode iterator. I'd failed
> to check the machine description carefully, but the *zero_extendsi2
> define_insn is conditionally defined, based on x86 target tuning using
> TARGET_ZERO_EXTEND_WITH_AND, and therefore unavailable on 486 and pentium
> unless optimizing the code for size. It turns out that the libitm testsuite
> specifies -m486 with make check RUNTESTFLAGS="--target_board='unix{-m32}'"
> and therefore encounters/catches my oversight.
>
> Fixed by adding the appropriate conditions to the new peephole2 patterns.
> It don't think it's worth the effort to provide an equivalent optimization
> for
> these (very) old architectures.
>
> Tested on x86_64-pc-linux-gnu with make bootstrap and make -k check
> with no new failures. Confirmed using RUNTESTFLAGS that this
> fixes the above failure, and the recently added testcase with -march=i486.
> Ok for mainline?
>
>
> 2022-03-12 Roger Sayle
>
> gcc/ChangeLog
> * config/i386/i386.md (peephole2 xorl;movb -> movzbl): Disable
> transformation when *zero_extendsi2 is not available.
>
> gcc/testsuite/ChangeLog
> * gcc.target/i386/pr98335.c: Skip this test if tuning for i486
> or pentium, and not optimizing for size.
OK, but please use:
mode != SImode
instead of
!= 4
Thanks,
Uros.
[PATCH] gcc: emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack [PR70536]
Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:
17$: DW_TAG_formal_parameter_pack
DW_AT_name("args")
18$: DW_TAG_formal_parameter
! no DW_AT_name attribute
DW_AT_type(reference to 13$)
(...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
From 2c50fbbfdd42c9ecb6d6b8e4c53bb3029ef1ee25 Mon Sep 17 00:00:00 2001
From: Ed Catmur
Date: Sat, 12 Mar 2022 17:38:33 +
Subject: [PATCH] emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack
Per http://wiki.dwarfstd.org/index.php?title=C%2B%2B0x:_Variadic_templates
DW_TAG_GNU_formal_parameter_pack should have a DW_AT_name:
17$: DW_TAG_formal_parameter_pack
DW_AT_name("args")
18$: DW_TAG_formal_parameter
! no DW_AT_name attribute
DW_AT_type(reference to 13$)
(...)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536
---
gcc/dwarf2out.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 5681b01749add..ef3bc6f88e070 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -23006,7 +23006,7 @@ gen_formal_parameter_pack_die (tree parm_pack,
&& subr_die);
parm_pack_die = new_die (DW_TAG_GNU_formal_parameter_pack, subr_die,
parm_pack);
- add_src_coords_attributes (parm_pack_die, parm_pack);
+ add_name_and_src_coords_attributes (parm_pack_die, parm_pack);
for (arg = pack_arg; arg; arg = DECL_CHAIN (arg))
{
[PATCH 1/2] libcody: Do not use a dummy port number in getaddrinfo().
The getaddrinfo() call requires either a non-null name for the server or
a port service / number. In the code that opens a connection we have
been calling this with a dummy port number of "0". Unfortunately this
triggers a crashing bug in some BSD versions (and OSes importing that code).
In this part of the code we do not really need a port number, since it
is not reasonable to open a connection to an unspecified host.
Setting hints ai_flags field to 0, and the servname parm to nullptr works
around the BSD bug in this case.
Also posted upstream.
(fixes bad-mapper-2/3 on the versions affected).
tested on powerpc,i686-darwin9, x86-64-darwin10,17,20
powerpc64le,powerpc64,x86_64-linux-gnu,
OK for master?
eventual backports?
thanks
Iain
Signed-off-by: Iain Sandoe
libcody/ChangeLog:
* netclient.cc (OpenInet6): Do not provide a dummy port number
in the getaddrinfo() call.
---
libcody/netclient.cc | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libcody/netclient.cc b/libcody/netclient.cc
index 7f81dd91810..558808be485 100644
--- a/libcody/netclient.cc
+++ b/libcody/netclient.cc
@@ -93,7 +93,7 @@ int OpenInet6 (char const **e, char const *name, int port)
}
addrinfo hints;
- hints.ai_flags = AI_NUMERICSERV;
+ hints.ai_flags = 0;
hints.ai_family = AF_INET6;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = 0;
@@ -102,9 +102,7 @@ int OpenInet6 (char const **e, char const *name, int port)
hints.ai_canonname = nullptr;
hints.ai_next = nullptr;
- /* getaddrinfo requires a port number, but is quite happy to accept
- invalid ones. So don't rely on it. */
- if (int err = getaddrinfo (name, "0", &hints, &addrs))
+ if (int err = getaddrinfo (name, nullptr, &hints, &addrs))
{
errstr = gai_strerror (err);
// What's the best errno to set?
--
2.24.3 (Apple Git-128)
[PATCH 2/2] c++tools: Work around a BSD bug in getaddrinfo().
Some versions of the BSD getaddrinfo() call do not work with the specific
input of "0" for the servname entry (a segv results). Since we are making
the call with a dummy port number, the value is actually not important, other
than it should be in range. Work around the BSD bug by using "1" instead.
tested on powerpc,i686-darwin9, x86-64-darwin10,17,20
powerpc64le,powerpc64,x86_64-linux-gnu,
OK for master?
eventual backports?
thanks
Iain
Signed-off-by: Iain Sandoe
c++tools/ChangeLog:
* server.cc (accept_from): Use "1" as the dummy port number.
---
c++tools/server.cc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/c++tools/server.cc b/c++tools/server.cc
index 8c6ad314886..00154a05925 100644
--- a/c++tools/server.cc
+++ b/c++tools/server.cc
@@ -360,7 +360,11 @@ accept_from (char *arg ATTRIBUTE_UNUSED)
hints.ai_next = NULL;
struct addrinfo *addrs = NULL;
- if (int e = getaddrinfo (slash == arg ? NULL : arg, "0", &hints, &addrs))
+ /* getaddrinfo requires either hostname or servname to be non-null, so that
we must
+ set a port number (to cover the case that the string passed contains just
/NN).
+ Use an arbitrary in-range port number, but avoiding "0" which triggers a
bug on
+ some BSD variants. */
+ if (int e = getaddrinfo (slash == arg ? NULL : arg, "1", &hints, &addrs))
{
noisy ("cannot resolve '%s': %s", arg, gai_strerror (e));
ok = false;
--
2.24.3 (Apple Git-128)
Re: [PATCH v7] c++: Add diagnostic when operator= is used as truth cond [PR25689]
On Sat, 12 Mar 2022 at 06:15, Jason Merrill wrote:
> It looks good, but unfortunately regresses some other warning tests,
> such as Wnonnull5.C. Please remember to run the regression tests before
> sending a patch (https://gcc.gnu.org/contribute.html#testing).
>
> This seems to be a complicated problem with suppress_warning, which
> means your call to suppress_warning effectively silences all later
> warnings, not just -Wparentheses.
>
> You should be able to work around this issue by only calling
> suppress_warning in the specific case we're interested in, i.e. when
> warn_parentheses is enabled and "call" is a MODIFY_EXPR.
My apologies. I've fixed the issue as you suggested and run the regression tests
to ensure no test regressions. The new patch (v9) is attached.
v8: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590570.html
Changes since v8:
1. Fix a test regression by calling suppress_warning only when "call"
is a MODIFY_EXPR.
v7: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590464.html
Changes since v7:
1. Suppress -Wparentheses warnings in build_new_method_call.
2. Uncomment the test case for if (b1.operator= (b2)).
v6: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590419.html
Changes since v6:
1. Check for error_mark_node in is_assignment_op_expr_pr.
2. Change "c:" to "c++:".
v5: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590393.html
Changes since v5:
1. Revert changes in v4.
2. Replace gcc_assert with a return NULL_TREE in extract_call_expr.
v4: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590379.html
Changes since v4:
1. Refactor the non-assert-related code out of extract_call_expr and
call that function instead to check for call expressions.
v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.
From 28f884d51a56889e84acba970a5aac9da8b24d99 Mon Sep 17 00:00:00 2001
From: Zhao Wei Liew
Date: Tue, 15 Feb 2022 17:44:29 +0800
Subject: [PATCH] c++: Add diagnostic when operator= is used as truth cond
[PR25689]
When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:
struct A {
A& operator=(int);
operator bool();
};
void f(A a) {
if (a = 0); // no warning
}
This is because a = 0 is a call to operator=, which GCC does not handle.
This patch fixes this issue by handling calls to operator= when deciding
to warn.
Bootstrapped and regression tested on x86_64-pc-linux-gnu.
PR c++/25689
gcc/cp/ChangeLog:
* call.cc (extract_call_expr): Return a NULL_TREE on failure
instead of asserting.
(build_new_method_call): Suppress -Wparentheses diagnostic for
MODIFY_EXPR.
* semantics.cc (is_assignment_op_expr_p): Add function to check
if an expression is a call to an op= operator expression.
(maybe_convert_cond): Handle the case of a op= operator expression
for the -Wparentheses diagnostic.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wparentheses-31.C: New test.
Signed-off-by: Zhao Wei Liew
---
gcc/cp/call.cc | 13 +++--
gcc/cp/semantics.cc | 22 +++-
gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 59 +
3 files changed, 90 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index 8fe8ef306ea..f502251c291 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -7101,9 +7101,10 @@ extract_call_expr (tree call)
default:;
}
- gcc_assert (TREE_CODE (call) == CALL_EXPR
- || TREE_CODE (call) == AGGR_INIT_EXPR
- || call == error_mark_node);
+ if (TREE_CODE (call) != CALL_EXPR
+ && TREE_CODE (call) != AGGR_INIT_EXPR
+ && call != error_mark_node)
+return NULL_TREE;
return call;
}
@@ -11148,6 +11149,12 @@ build_new_method_call (tree instance, tree fns,
vec **args,
*fn_p = fn;
/* Build the actual CALL_EXPR. */
call = build_over_call (cand, flags, complain);
+
+ /* Suppress warnings for if (my_struct.operator= (x)) where
+my_struct is implicitly converted to bool. */
+ if (TREE_CODE (call) == MODIFY_EXPR)
+ suppress_warnin
[PATCH] gcc: rename floatformat_ia64_quad_{big, little} to floatformat_ieee_quad_{big, little}
I submitted a GDB patch [1] to rename floatformats_ia64_quad to
floatformats_ieee_quad to reflect the reality, and then we can
clean up the related code.
As GDB Global Maintainer Tom Tromey said [2]:
These files are maintained in gcc and then imported into the
binutils-gdb repository, so any changes to them will have to
be proposed there first.
this GCC patch is preparation for the GDB patch, no functionality
change.
[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186452.html
[2] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html
Signed-off-by: Tiezhu Yang
---
Hi GCC Maintainers,
I have no write access of gcc.git, if you are OK with this change,
could you please help me to merge this patch to the gcc master?
Thank you.
include/floatformat.h | 6 +++---
libiberty/floatformat.c | 34 +-
2 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/include/floatformat.h b/include/floatformat.h
index 5c18ebf..291acd4 100644
--- a/include/floatformat.h
+++ b/include/floatformat.h
@@ -97,7 +97,7 @@ struct floatformat
const struct floatformat *split_half;
};
-/* floatformats for IEEE single and double, big and little endian. */
+/* floatformats for IEEE half, single, double and quad, big and little endian.
*/
extern const struct floatformat floatformat_ieee_half_big;
extern const struct floatformat floatformat_ieee_half_little;
@@ -105,6 +105,8 @@ extern const struct floatformat floatformat_ieee_single_big;
extern const struct floatformat floatformat_ieee_single_little;
extern const struct floatformat floatformat_ieee_double_big;
extern const struct floatformat floatformat_ieee_double_little;
+extern const struct floatformat floatformat_ieee_quad_big;
+extern const struct floatformat floatformat_ieee_quad_little;
/* floatformat for ARM IEEE double, little endian bytes and big endian words */
@@ -128,8 +130,6 @@ extern const struct floatformat
floatformat_arm_ext_littlebyte_bigword;
/* IA-64 Floating Point register spilt into memory. */
extern const struct floatformat floatformat_ia64_spill_big;
extern const struct floatformat floatformat_ia64_spill_little;
-extern const struct floatformat floatformat_ia64_quad_big;
-extern const struct floatformat floatformat_ia64_quad_little;
/* IBM long double (double+double). */
extern const struct floatformat floatformat_ibm_long_double_big;
extern const struct floatformat floatformat_ibm_long_double_little;
diff --git a/libiberty/floatformat.c b/libiberty/floatformat.c
index ce36bae..f93568b 100644
--- a/libiberty/floatformat.c
+++ b/libiberty/floatformat.c
@@ -78,7 +78,7 @@ floatformat_always_valid (const struct floatformat *fmt
ATTRIBUTE_UNUSED,
a system header, what we do if not, etc. */
#define FLOATFORMAT_CHAR_BIT 8
-/* floatformats for IEEE half, single and double, big and little endian. */
+/* floatformats for IEEE half, single, double and quad, big and little endian.
*/
const struct floatformat floatformat_ieee_half_big =
{
floatformat_big, 16, 0, 1, 5, 15, 31, 6, 10,
@@ -127,6 +127,22 @@ const struct floatformat floatformat_ieee_double_little =
floatformat_always_valid,
NULL
};
+const struct floatformat floatformat_ieee_quad_big =
+{
+ floatformat_big, 128, 0, 1, 15, 16383, 0x7fff, 16, 112,
+ floatformat_intbit_no,
+ "floatformat_ieee_quad_big",
+ floatformat_always_valid,
+ NULL
+};
+const struct floatformat floatformat_ieee_quad_little =
+{
+ floatformat_little, 128, 0, 1, 15, 16383, 0x7fff, 16, 112,
+ floatformat_intbit_no,
+ "floatformat_ieee_quad_little",
+ floatformat_always_valid,
+ NULL
+};
/* floatformat for IEEE double, little endian byte order, with big endian word
ordering, as on the ARM. */
@@ -269,22 +285,6 @@ const struct floatformat floatformat_ia64_spill_little =
floatformat_always_valid,
NULL
};
-const struct floatformat floatformat_ia64_quad_big =
-{
- floatformat_big, 128, 0, 1, 15, 16383, 0x7fff, 16, 112,
- floatformat_intbit_no,
- "floatformat_ia64_quad_big",
- floatformat_always_valid,
- NULL
-};
-const struct floatformat floatformat_ia64_quad_little =
-{
- floatformat_little, 128, 0, 1, 15, 16383, 0x7fff, 16, 112,
- floatformat_intbit_no,
- "floatformat_ia64_quad_little",
- floatformat_always_valid,
- NULL
-};
static int
floatformat_ibm_long_double_is_valid (const struct floatformat *fmt,
--
2.1.0
[PATCH] c++/96765: warn when casting "this" to Derived* in Base ctor/dtor
Hi!
This patch adds a warning when casting "this" to Derived* in the Base
class constructor and destructor. I've added the warning under the
-Wextra flag as I can't find a more appropriate flag for it.
The patch has been bootstrapped and regression tested on x86_64-pc-linux-gnu.
Appreciate reviews and feedback. Thanks!
From c70e087c7ee9db7497da293f8a85891abe895d9a Mon Sep 17 00:00:00 2001
From: Zhao Wei Liew
Date: Tue, 22 Feb 2022 16:03:17 +0800
Subject: [PATCH] c++: warn when casting "this" to Derived* in Base ctor/dtor
[PR96765]
Casting "this" in a base class constructor to a derived class type is
undefined behaviour, but there is no warning when doing so.
Add a warning for this.
Signed-off-by: Zhao Wei Liew
PR c++/96765
gcc/cp/ChangeLog:
* typeck.cc (build_static_cast_1): Add a warning when casting
"this" to Derived * in Base constructor and destructor.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wextra-5.C: New test.
---
gcc/cp/typeck.cc | 9
gcc/testsuite/g++.dg/warn/Wextra-5.C | 33
2 files changed, 42 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/warn/Wextra-5.C
diff --git a/gcc/cp/typeck.cc b/gcc/cp/typeck.cc
index 516fa574ef6..782f70b27e6 100644
--- a/gcc/cp/typeck.cc
+++ b/gcc/cp/typeck.cc
@@ -8079,6 +8079,15 @@ build_static_cast_1 (location_t loc, tree type, tree
expr, bool c_cast_p,
{
tree base;
+ if (current_function_decl
+ && (DECL_CONSTRUCTOR_P (current_function_decl)
+ || DECL_DESTRUCTOR_P (current_function_decl))
+ && TREE_CODE (expr) == NOP_EXPR
+ && is_this_parameter (TREE_OPERAND (expr, 0)))
+warning_at(loc, OPT_Wextra,
+ "invalid % from type %qT to type %qT before
the latter is constructed",
+ intype, type);
+
if (processing_template_decl)
return expr;
diff --git a/gcc/testsuite/g++.dg/warn/Wextra-5.C
b/gcc/testsuite/g++.dg/warn/Wextra-5.C
new file mode 100644
index 000..7e82c4c6121
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wextra-5.C
@@ -0,0 +1,33 @@
+// PR c++/96765
+// { dg-options "-Wextra" }
+
+struct Derived;
+struct Base {
+ Derived *x;
+ Derived *y;
+ Base();
+ ~Base();
+};
+
+struct Derived : Base {};
+
+Base::Base()
+: x(static_cast(this)), // { dg-warning "invalid 'static_cast'"
}
+ y((Derived *)this) // { dg-warning "invalid 'static_cast'" }
+{
+ static_cast(this); // { dg-warning "invalid 'static_cast'" }
+ (Derived *)this; // { dg-warning "invalid 'static_cast'" }
+}
+
+Base::~Base() {
+ static_cast(this); // { dg-warning "invalid 'static_cast'" }
+ (Derived *)this; // { dg-warning "invalid 'static_cast'" }
+}
+
+struct Other {
+ Other() {
+Base b;
+static_cast(&b);
+(Derived *)(&b);
+ }
+};
--
2.25.1
