Hi Segher!
on 2022/6/28 00:02, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Jun 27, 2022 at 05:35:03PM +0800, Kewen.Lin wrote:
>> -(define_insn "*rotl3_insert_4"
>> - [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
>> -(ior:GPR (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
>> -
Thanks a lot! I fixed it.
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 54d8ad41a6f..151770f59f4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -478,6 +478,7 @@ Jeff Knaggs
From: Antoni Boucher
gcc/ChangeLog:
PR target/106095
* config/i386/sse.md: Fix asm generation.
gcc/testsuite/ChangeLog:
PR target/106095
* gcc.target/i386/pr106095.c: Add test using those AVX builtins.
---
gcc/config/i386/sse.md | 10 ++---
Hi.
This fixes the following bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095
It's the first time I work outside of the jit component, so please tell
me if I forgot anything.
Here are the results of running the test:
=== gcc Summary ===
# of expected passes
From: Sergei Trofimovich
On musl uses calloc() (via ). jit/ includes
it directly and exposes use of poisoned calloc():
/build/build/./prev-gcc/xg++ ...
../../gcc-13-20220626/gcc/jit/jit-playback.cc
make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
make[3]: *** Waiting for
Re-sending this without the large attachment, since it was rejected by the
list. The second attachment was just the Unicode data files to be added:
ftp://ftp.unicode.org/Public/UNIDATA/DerivedNormalizationProps.txt
ftp://ftp.unicode.org/Public/UNIDATA/DerivedCoreProperties.txt
Thanks!
-Lewis
On Jun 27, 2022, Jonathan Wakely wrote:
> -#if _GLIBCXX_HAVE_DIRFD
> +#if _GLIBCXX_HAVE_DIRFD && _GLIBCXX_HAVE_OPENAT && _GLIBCXX_HAVE_UNLINKAT
Thanks, I had this bit in the WIP _At_path patch, as well as my updated
remove_all patch, in the latest round of tests.
I confirm that I don't get any
Hello, Jan-Benedict,
On Jun 27, 2022, Jan-Benedict Glaw wrote:
> For me, this patch broke building a basic cross compiler using Debian
> sid's "gcc-snapshot" package as the build/host compiler
Thanks for reporting the problem you've encountered, and for your
interest.
AFAIK the general
On Fri, 2022-06-24 at 22:58 +0200, Uros Bizjak wrote:
> On Fri, Jun 24, 2022 at 8:19 PM David Malcolm
> wrote:
> >
> > I'd like to ping this patch:
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
> >
> > OK for trunk?
>
> I have no idea what patch does,
Sorry for any
On Fri, 2022-06-24 at 12:45 -0600, Jeff Law via Gcc-patches wrote:
>
>
> On 6/24/2022 12:08 PM, David Malcolm via Gcc-patches wrote:
> > On Mon, 2022-06-13 at 14:22 -0400, David Malcolm wrote:
> > > Ping for this patch:
> > > https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595444.html
> >
On Mon, 27 Jun 2022, Jakub Jelinek via Gcc-patches wrote:
> On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> > I don’t like the _Float128 vs __float128 business, it’s confusing.
> > And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> > they seem to be
On Sun, Jun 26, 2022 at 11:10 PM Xi Ruoyao via Gcc-patches
wrote:
>
> libbacktrace/ChangeLog:
>
> * configure.ac (AC_PROG_FGREP): Use grep instead of fgrep.
> * configure: Regenerate.
Thanks. Committed to mainline.
Ian
Another ping for
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596065.html .
I got a review from Andi
(https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596549.html) but I also
need a review from someone who can approve the changes.
Thanks,
Eugene
-Original Message-
From:
With DOM converted to ranger, there are no longer any uses of the EVRP
engine. For that matter, we haven't used the legacy mode in quite a
while, so I think it's safe to remove any associated code.
There are some methods in vr_values which should now be private, but I
didn't bother changing
The conversion for loop-ch is trivial, since the range of a
GIMPLE_COND is always an integer.
OK for trunk?
p.s. The loop unswitch code requires a bit more thought, since there
are numerous range temporaries in the code that are not necessarily
integers.
On Mon, Jun 13, 2022 at 11:44 AM Richard
Hi!
On Thu, 2022-05-12 12:40:09 +, Pierre-Marie de Rodat via Gcc-patches
wrote:
> GNAT does not issue a warning anymore on a postcondition of True (used
> here to prevent inining inside GNATprove for proof).
>
> Tested on x86_64-pc-linux-gnu, committed on trunk
>
> gcc/ada/
>
> *
Fixed since bug 97899 was fixed.
PR c++/89197
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/initlist130.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/initlist130.C | 5 +
1 file changed, 5 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/initlist130.C
diff --git
A few testcases were marked for avr target, which has no alignment
requirements. But those tests in fact should filter for any
target having __BIGGEST_ALIGNMENT__=1.
A new effective target check is introduced: no_alignment_constraints.
It checks whether __BIGGEST_ALIGNMENT__ is declared as 1.
On Mon, Jun 27, 2022 at 9:47 AM wrote:
>
> From: Sören Tempel
>
> This patch addresses two minor compatibility issues with musl libc:
>
> * On some architecture (e.g. PowerPC), musl has more than one field
> prefixed with st_{a,m,c}tim in struct stat. This causes the sed(1)
> invocation to
This Go frontend patch avoids using a sink name (_) as a parameter
name when creating a method expression thunk. The patch also fixes a
couple of cases where the error led to a later compiler crash. The
test case is https://go.dev/cl/414336. This fixes
https://go.dev/issue/52871. Bootstrapped
This patch to the Go frontend corrects the integer import code to
always initialize an mpfr value. The test case for this is
https://go.dev/cl/413980. This fixes https://go.dev/issue/52862.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
From: Sören Tempel
This patch addresses two minor compatibility issues with musl libc:
* On some architecture (e.g. PowerPC), musl has more than one field
prefixed with st_{a,m,c}tim in struct stat. This causes the sed(1)
invocation to not work correctly (since it will only replace the
I've pushed these three patches to the devel/omp/gcc-11 branch ("OG11").
I'll be submitting mainline versions soonish.
The patches add a means to track "requires unified_shared_memory" from
the frontend, through the backend compiler, and on to the runtime, plus
all the bits needed to
On Mon, Jun 20, 2022 at 04:03:50PM -0400, Jason Merrill wrote:
> > + if (code == COMPLEX_TYPE)
> > + {
> > + if (TREE_CODE (*valp) == COMPLEX_CST)
> > + *valp = build2 (COMPLEX_EXPR, type, TREE_REALPART (*valp),
> > + TREE_IMAGPART (*valp));
> > + else if
On Sun, 26 Jun 2022 at 21:06, François Dumont wrote:
>
> I knew you were going to ask for it but was to impatient to propose
> those patches to wait anymore.
Heh, OK :-)
I've started reviewing them, but I thought I'd ask that question first.
>
> Attached you'll find what I start to work on.
Hi!
On Mon, Jun 27, 2022 at 05:35:03PM +0800, Kewen.Lin wrote:
> -(define_insn "*rotl3_insert_4"
> - [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
> - (ior:GPR (and:GPR (match_operand:GPR 3 "gpc_reg_operand" "0")
> - (match_operand:GPR 4 "const_int_operand" "n"))
>
> Am 27.06.2022 um 16:50 schrieb Sergei Trofimovich :
>
> From: Sergei Trofimovich
>
> On musl uses calloc() (via ). includes
> it indirectly and exposes use of poisoned calloc() when module code
> is built:
>
>/build/build/./prev-gcc/xg++ ...
>
On Mon, 27 Jun 2022 at 15:00, Jonathan Wakely wrote:
>
> On Mon, 27 Jun 2022 at 14:32, Jonathan Wakely wrote:
> >
> > On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva wrote:
> > >
> > > On Jun 27, 2022, Alexandre Oliva wrote:
> > >
> > > > It looks like the atp.pathname is missing the
On Wed, Jun 22, 2022 at 12:04:59AM -0400, Jason Merrill wrote:
> On 6/20/22 16:16, Jason Merrill wrote:
> > On 6/20/22 07:05, Jakub Jelinek wrote:
> > > On Fri, Jun 17, 2022 at 05:20:02PM -0400, Jason Merrill wrote:
> > > > Related to PR104642, the current situation where we get less
> > > >
Hi!
On Sun, Jun 26, 2022 at 07:07:35PM +0200, Uros Bizjak via Gcc-patches wrote:
> On Sun, Jun 26, 2022 at 2:04 PM Roger Sayle
> wrote:
> > I'll investigate whether this optimization can also be implemented
> > more generically in simplify_rtx when the backend provides
> > accurate rtx_costs
From: Sergei Trofimovich
On musl uses calloc() (via ). includes
it indirectly and exposes use of poisoned calloc() when module code
is built:
/build/build/./prev-gcc/xg++ ...
../../gcc-13-20220626/gcc/cp/mapper-resolver.cc
In file included from
Hi!
[Something is wrong with your mail program. It puts white lines
everywhere, and prefixes a space to the existing white lines.]
On Sun, Jun 26, 2022 at 09:56:07PM +0100, Roger Sayle wrote:
> It turns out this optimization already exists in the form of a combine
> splitter in rs6000.md, but
This setting is way out of date; global constructors have worked on GCN
for a while now.
Andrewamdgcn: test global constructors
The tests are disabled for historical reasons only.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_effective_target_global_constructor):
Hi,
Per our discussion in the bug report, I came up with the following patch:
===
PR101836: Add a new option -fstrict-flex-array[=n]
Add the new option and use it in __builtin_object_size.
Treat the trailing array of a structure as a flexible array member in a
stricter way. The value of
On Mon, 27 Jun 2022 at 14:32, Jonathan Wakely wrote:
>
> On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva wrote:
> >
> > On Jun 27, 2022, Alexandre Oliva wrote:
> >
> > > It looks like the atp.pathname is missing the nonexistent_path
> > > assigned to variable dir in test_pr99290, so we attempt to
On 6/26/22 11:38, Aldy Hernandez wrote:
Thanks for pushing this.
The patch triggered a (known) regression on
g++.dg/warn/Wstringop-overflow-4.C. In the original submission I
mentioned I would XFAIL it, but forgot to do so. I have pushed the
attached patch.
Note that since this was the last
On 6/27/22 15:03, Tom de Vries wrote:
Hi,
When building gdb with --enabled-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
`.rodata' can not be used when making a shared object; recompile with -fPIC
ld: build/zlib/libz.a(libz_a-inflate.o):
On Mon, 27 Jun 2022 at 14:29, Alexandre Oliva wrote:
>
> On Jun 23, 2022, Alexandre Oliva wrote:
>
> > libstdc++: testsuite: conditionalize symlink tests
>
>
> libstdc++: testsuite: conditionalize another symlink test
>
> In the recent patch that introduced NO_SYMLINKS, I missed one of the
>
On Mon, 27 Jun 2022 at 14:05, Alexandre Oliva wrote:
>
> On Jun 27, 2022, Alexandre Oliva wrote:
>
> > It looks like the atp.pathname is missing the nonexistent_path
> > assigned to variable dir in test_pr99290, so we attempt to open
> > subdirs thereof as if with openat.
>
> This appears to be
On Mon, Jun 27, 2022 at 01:56:10PM +0200, Mikael Morin wrote:
> Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :
> > Still, using __float128 when the APIs are declared for __float128 and
> > _Float128 when the APIs are declared for _Float128 can be better for
> > consistency.
> >
> I agree with
On Jun 23, 2022, Alexandre Oliva wrote:
> Sorry, I goofed when testing this, and another internal xfail machinery
> hid the bug: I had to use dg-xfail-run-if instead.
And then, having enabled pipe(), disabled the internal xfail machinery,
and added -Wl,--gc-sections after -lbsd as recommended,
On Jun 23, 2022, Alexandre Oliva wrote:
> libstdc++: testsuite: conditionalize symlink tests
libstdc++: testsuite: conditionalize another symlink test
In the recent patch that introduced NO_SYMLINKS, I missed one of the
testcases that created symlinks.
Regstrapped on x86_64-linux-gnu, also
On Jun 22, 2022, Jonathan Wakely wrote:
> I haven't properly reviewed it yet
Nevermind that one, it's broken because I hadn't realized the recursive
iteration. It fails and throws/errors out when we attempt to __erase a
subdir that wasn't successfully emptied because some of its entries were
On Jun 27, 2022, Alexandre Oliva wrote:
> It looks like the atp.pathname is missing the nonexistent_path
> assigned to variable dir in test_pr99290, so we attempt to open
> subdirs thereof as if with openat.
This appears to be caused by the early return in fs::_Dir's ctor:
_Dir(const
On Sun, Jun 26, 2022 at 10:50 PM Hongtao Liu wrote:
>
> On Tue, Jun 21, 2022 at 3:50 AM Uros Bizjak via Gcc-patches
> wrote:
> >
> > On Mon, Jun 20, 2022 at 8:14 PM H.J. Lu wrote:
> > >
> > > On Tue, May 10, 2022 at 9:25 AM H.J. Lu wrote:
> > > >
> > > > Mark a function with
Hi,
When building gdb with --enabled-shared, I run into:
...
ld: build/zlib/libz.a(libz_a-inffast.o): relocation R_X86_64_32S against \
`.rodata' can not be used when making a shared object; recompile with -fPIC
ld: build/zlib/libz.a(libz_a-inflate.o): warning: relocation against \
This patch removed some workarounds that were required for old versions
of the LLVM assembler. The minimum supported version is now 13.0.1 so
the workarounds are no longer needed.
Andrewamdgcn: remove obsolete assembler workarounds
This nonsense is no longer required, now that the minimum
On Jun 23, 2022, Jonathan Wakely wrote:
> It defines a new _At_path type which contains a {fd, path} pair (to be
> used together by openat and unlinkat) and a separate path to be used
> on its own. This allows identifying a file within a directory
> unambiguously, without being concerned with
Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :
Still, using __float128 when the APIs are declared for __float128 and
_Float128 when the APIs are declared for _Float128 can be better for
consistency.
I agree with that.
I was implicitly suggesting to change the libquadmath API to use the
Committed to fix OG11-only fails. For details, see commit log + patch
(attached) – with two commits.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank
On Tue, 21 Jun 2022 at 06:38, Alexandre Oliva via Libstdc++
wrote:
>
>
> simd_math.h assumes declarations for many C99 functions to be present,
> that libstdc++ doesn't add to target systems that don't have them in
> the C library.
>
> Add the C99 math requirement to tests for simd features, so
On Tue, 21 Jun 2022 at 06:39, Alexandre Oliva via Libstdc++
wrote:
>
>
> In case we need to supplement the C standard library with additional
> definitions for float and long double, the declarations expected to be
> in the C headers may not be there. Rely on the cmath overloads
> instead.
>
>
On Mon, 27 Jun 2022, Jakub Jelinek wrote:
> Hi!
>
> The test FAILs on 32-bit targets, because when unsigned long
> is 32-bit, (unsigned long) -1 isn't 0x.
> The options to fix this would be either using -1UL, or switch
> to unsigned long long and using -1ULL, I chose the latter
On Jun 21, 2022, Alexandre Oliva wrote:
> * testsuite/experimental/simd/standard_abi_usable.cc: Require
> cmath support.
> * testsuite/experimental/simd/standard_abi_usable_2.cc:
> Likewise.
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596920.html
--
On Mon, 27 Jun 2022 at 11:09, Alexandre Oliva via Libstdc++
wrote:
>
> On Jun 21, 2022, Alexandre Oliva wrote:
>
> > * testsuite/26_numerics/complex/proj.cc: Skip test in the
> > circumstances in which the implementation of proj is known to
> > be broken.
>
> Ping?
>
>
On Jun 21, 2022, Alexandre Oliva wrote:
> * testsuite/20_util/to_chars/long_double.cc: Use cmath
> long double overloads for nexttoward and ldexp.
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596921.html
--
Alexandre Oliva, happy hacker
On Mon, 27 Jun 2022 at 10:32, Alexandre Oliva wrote:
>
> On Jun 23, 2022, Jonathan Wakely wrote:
>
> > The attached makes this a bit more efficient, and makes more of the
> > code common to the mkstemp and non-mkstmp branches. I'll wait to hear
> > back from you before pushing it (since it has
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/ext/mt_allocator/22309_thread.cc: Include .
---
libstdc++-v3/testsuite/ext/mt_allocator/22309_thread.cc | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Joel Brobecker
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
We have noticed that, on RTEMS, a small number of testscases are
failing because two calls to this method return the same filename.
This happens for instance in 27_io/filesystem/operations/copy_file.cc
where it does:
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This is not suitable to backport, as it affects the ABI of std::variant
and so isn't appropriate for a release branch.
libstdc++-v3/ChangeLog:
* include/bits/move_only_function.h (_Never_valueless_alt):
Define partial
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/std/variant (_Build_FUN::_S_fun): Define fallback case
as deleted.
(__accepted_index, _Extra_visit_slot_needed): Replace class
templates with variable templates.
---
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h (__is_path_iter_src): Replace class
template with variable template.
---
libstdc++-v3/include/bits/fs_path.h | 15 ++-
1 file changed, 6 insertions(+), 9
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
This redefines std::is_clock in terms of std::is_clock_v, instead of the
other way around. This avoids instantiatng the class template for code
that only uses the variable template.
libstdc++-v3/ChangeLog:
* include/bits/chrono.h
On Jun 21, 2022, Alexandre Oliva wrote:
> * testsuite/26_numerics/complex/proj.cc: Skip test in the
> circumstances in which the implementation of proj is known to
> be broken.
Ping?
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/596922.html
(I've dropped the '-v3' from
Hi Roger,
on 2022/6/27 04:56, Roger Sayle wrote:
>
>
> This patch tweaks the code generated on POWER for integer multiplications
>
> by a constant, by making use of rldimi instructions. Much like x86's
>
> lea instruction, rldimi can be used to implement a shift and add pair
>
> in some
On Mon, Jun 27, 2022 at 2:10 AM Xi Ruoyao via Gcc-patches
wrote:
>
> egrep/fgrep has been deprecated in favor of grep -E/-F for a long time,
> and the next grep release (3.8 or 4.0) will print a warning if egrep or
> fgrep is used. Stop using egrep and fgrep so we won't see the warning.
>
> But,
On Mon, 27 Jun 2022 at 10:49, Alexandre Oliva wrote:
>
> On Jun 24, 2022, Jonathan Wakely wrote:
>
> > Ah, but this patch only added the HAVE_OPENAT check to
> > src/filesystem/dir.cc not the similar code in src/c++17/fs_dir.cc
>
> Doh! It was such a long and goof-ful day :-(
>
> Thanks for
On Jun 24, 2022, Jonathan Wakely wrote:
> Ah, but this patch only added the HAVE_OPENAT check to
> src/filesystem/dir.cc not the similar code in src/c++17/fs_dir.cc
Doh! It was such a long and goof-ful day :-(
Thanks for catching it.
Unless you ask me not to, I'd like to install this to
Hi!
The test FAILs on 32-bit targets, because when unsigned long
is 32-bit, (unsigned long) -1 isn't 0x.
The options to fix this would be either using -1UL, or switch
to unsigned long long and using -1ULL, I chose the latter because
the test then FAILs in r13-1242 even on 32-bit
Hi,
define_insn *rotl3_insert_4 use mode iterator GPR which
consists of SImode and conditional DImode, but the condition
of this define_insn requires the mode should be SImode. By
further checking, it's found that the rldimi instruction can
not be used for this pattern since the required mask
On Jun 23, 2022, Jonathan Wakely wrote:
> The attached makes this a bit more efficient, and makes more of the
> code common to the mkstemp and non-mkstmp branches. I'll wait to hear
> back from you before pushing it (since it has Joel's name on the
> patch).
Thanks, I've given it a spin, both
On Mon, 27 Jun 2022 at 07:09, Xi Ruoyao wrote:
>
> fgrep has been deprecated in favor of grep -F for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of fgrep is used.
> But, we can't simply replace fgrep to grep -F, or the build will break
> with some non-GNU grep
On Mon, 27 Jun 2022 at 07:12, Xi Ruoyao wrote:
>
> egrep has been deprecated in favor of grep -E for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of egrep is used.
> Stop using egrep so we won't see the warning.
>
> Some non-POSIX grep implementations does not
Sorry, should be between
Boris Kolpackov
Dave Korn
Hongyu Wang 于2022年6月27日周一 16:29写道：
>
> According to the official guide, please sort your last name in
> alphabetical order, which means you shold put your name between
>
> Dave Korn
> Julia Koval
>
> Kong, Lingling via Gcc-patches
According to the official guide, please sort your last name in
alphabetical order, which means you shold put your name between
Dave Korn
Julia Koval
Kong, Lingling via Gcc-patches 于2022年6月27日周一 16:05写道：
>
> Hi,
>
> I want to add myself in MAINTANINER for write after approval.
>
> OK for
Hi,
I want to add myself in MAINTANINER for write after approval.
OK for master?
ChangeLog:
* MAINTAINERS (Write After Approval): Add myself.
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 54d8ad41a6f..49627e5d113 100644
---
Hello,
after further discussion I changed the ! default_packed to attribute
aligned, so that the test passes also on targets where 4 bytes types are
aligned on 2 byte boundaries.
Best regards,
Vit Kabele
-- >8 --
Subject: [PATCH v3] c: Extend the -Wpadded message with actual padding size
When
On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> I don’t like the _Float128 vs __float128 business, it’s confusing.
> And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> they seem to be basically the same thing, so it’s also redundant.
I thought __float128
On Tue, 21 Jun 2022, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, June 21, 2022 2:15 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; ja...@redhat.com
> > Subject: RE: [PATCH 2/2]middle-end: Support recognition of three-way
>
Hi,
all 11k regression tests pass with the new linking implementation (on
devel/m2link). I plan to migrate the patches back to devel/modula-2 and
then remove devel/m2link. Thereafter {polish,test} and generate new
patch sets. Thanks for the clear explanation on how the dynamic
scaffold
> egrep has been deprecated in favor of grep -E for a long time, and the
> next grep release (3.8 or 4.0) will print a warning of egrep is used.
> Stop using egrep so we won't see the warning.
>
> However, simply replacing egrep with grep -E will break build on some
> systems (notably Solaris)
Cherry-pick libffi commit 280fe78d37f58927b280e2e316a2ae19201f2b83,
and regenerate configure.
libffi/ChangeLog:
* configure.ac: Call AC_PROG_EGREP, and use $EGREP instead of
egrep.
* configure: Regenerate.
---
libffi/configure| 270
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
Stop using fgrep so we won't see the warning.
We can't hard code grep -F here or it may break build on hosts w/o GNU
grep. autoconf documentation contains
On Mon, Jun 27, 2022 at 7:25 AM Tamar Christina via Gcc-patches
wrote:
>
> > -Original Message-
> > From: Richard Sandiford
> > Sent: Thursday, June 16, 2022 7:54 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
> > ; Marcus Shawcroft
> > ; Kyrylo
Python 2 has been EOL'ed for two years. egrep has been deprecated
for many years and the next grep release will start to print warning if
it is used.
-E option may be unsupported by some non-POSIX grep implementations, but
gcc-auto-profile won't work on non-Linux systems anyway.
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
Some non-POSIX grep implementations does not support -E option, so for
test_summary and warn_summary we prefer
egrep has been deprecated in favor of grep -E for a long time, and the
next grep release (3.8 or 4.0) will print a warning of egrep is used.
Stop using egrep so we won't see the warning.
However, simply replacing egrep with grep -E will break build on some
systems (notably Solaris) w/o a
fgrep has been deprecated in favor of grep -F for a long time, and the
next grep release (3.8 or 4.0) will print a warning of fgrep is used.
But, we can't simply replace fgrep to grep -F, or the build will break
with some non-GNU grep implementations (lacking -F support).
As "add-gnu-debuglink"
egrep/fgrep has been deprecated in favor of grep -E/-F for a long time,
and the next grep release (3.8 or 4.0) will print a warning if egrep or
fgrep is used. Stop using egrep and fgrep so we won't see the warning.
But, we can't simply replace egrep to grep -E or fgrep to grep -F or the
build
egrep has been deprecated in favor of grep -E for a long time, and the
next GNU grep release (3.8 or 4.0) will print a warning if egrep is used.
Unfortunately, old hosts with non-GNU grep may lack the support for -E
option. Use AC_PROG_EGREP and $EGREP variable so we'll work fine on
both old and
egrep and fgrep have been deprecated for a long time, and the next grep
release will emit a warning if egrep or fgrep is invoked:
https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a951562
To prevent us from a lot of these warnings in the future, we should stop
using egrep and fgrep. These
91 matches
Mail list logo
