On Fri, Jun 24, 2022 at 2:34 AM Andrew Pinski via Gcc-patches
wrote:
>
> On Thu, Jun 23, 2022 at 2:24 PM Dimitar Dimitrov wrote:
> >
> > 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_
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.
fixincludes/ChangeLog:
* fixinc.in: Use grep -E instead of egrep.
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.
libstdc++-v3/ChangeLog:
* scripts/extract_symvers.in: Use grep -E instead of egrep.
* libstdc+
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.
libbacktrace/ChangeLog:
* configure.ac: Use grep -F instead of fgrep.
* configure: Regenerate.
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.
And, the fgrep command in exgettext is no longer useful after we
migrated from SVN to Git. Remove the fgrep command so we won't see the
warning.
gcc/ChangeL
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.
gcc/ChangeLog:
* fortran/Make-lang.in: Use grep -F instead of fgrep.
---
gcc/fortran/Make-lang.in | 2
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.
gcc/testsuite/ChangeLog:
* ada/acats/run_all.sh: Use grep -E instead of egrep.
* go.test/go-te
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.
contrib/ChangeLog:
* check_GNU_style.sh: Use grep -E instead of egrep.
* test_summary: Likewis
Hi Xi,
> 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
On Thu, 23 Jun 2022, Richard Sandiford wrote:
> In a reduction pair like:
>
> typedef float T;
>
> void
> f1 (T *x)
> {
> T res1 = 0;
> T res2 = 0;
> for (int i = 0; i < 100; ++i)
> {
> res1 += x[i * 2];
> res2 += x[i * 2 + 1];
> }
> x[0] = res1;
>
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
> please remember that there's a world outside of GNU grep: e.g. Solaris
> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
> unconditionally replacing egrep with grep -E in several places is
> likely
> to break at least th
Hi Xi,
> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
>
>> please remember that there's a world outside of GNU grep: e.g. Solaris
>> /bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
>> unconditionally replacing egrep with grep -E in several places is
>> likely
>> to b
Hi.
As noticed in the PR, I wrongly introduced /= and *= operators.
Problem was that these operators need to modify *this object.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR middle-end/106059
gcc/ChangeLog:
*
On 2022-06-24, Rainer Orth wrote:
Hi Xi,
On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
please remember that there's a world outside of GNU grep: e.g. Solaris
/bin/grep doesn't support grep -E (while /usr/xpg4/bin/grep does), so
unconditionally replacing egrep with grep -E in several p
> Am 23.06.2022 um 16:00 schrieb Jan Hubicka via Gcc-patches
> :
>
> Hi,
> this patch adds fnspecs for cxa_* functions in except.cc. Main goal is to
> make
> modref to see proper side-effects of functions which may throw. So in general
> we get
> - cxa_allocate_exception
>which gets the
On Fri, Jun 24, 2022 at 1:27 AM Fangrui Song via Gcc-patches
wrote:
>
> On 2022-06-24, Rainer Orth wrote:
> >Hi Xi,
> >
> >> On Fri, 2022-06-24 at 09:24 +0200, Rainer Orth wrote:
> >>
> >>> please remember that there's a world outside of GNU grep: e.g. Solaris
> >>> /bin/grep doesn't support grep
> Am 21.06.2022 um 10:43 schrieb Martin Liška :
>
> On 6/21/22 09:56, Richard Biener wrote:
>>> On Mon, Jun 20, 2022 at 12:20 PM Martin Liška wrote:
>>>
>>> On 6/20/22 11:32, Richard Biener wrote:
On Thu, Jun 16, 2022 at 9:01 AM Martin Liška wrote:
>
> lto-plugin/ChangeLog:
>>
> Am 24.06.2022 um 10:14 schrieb Martin Liška :
>
> Hi.
>
> As noticed in the PR, I wrongly introduced /= and *= operators.
> Problem was that these operators need to modify *this object.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Hi Fangrui,
> FWIW: glibc recently got the grep -E change and the solution is to use
> plain grep -E, without $EGREP things.
> Isn't setting PATH a good workaround if Solaris has the problem?
>
> https://sourceware.org/pipermail/libc-alpha/2022-June/139420.html
while it's possible, the $PATH solu
Richard Biener writes:
> On Thu, 23 Jun 2022, Richard Sandiford wrote:
>> In a reduction pair like:
>>
>> typedef float T;
>>
>> void
>> f1 (T *x)
>> {
>> T res1 = 0;
>> T res2 = 0;
>> for (int i = 0; i < 100; ++i)
>> {
>> res1 += x[i * 2];
>> res2 += x[i * 2
On 21.06.22 07:31, Alexandre Oliva via Gcc-patches wrote:
rtems6 declares a global struct bitset in a header file included
indirectly by sys/types.h, that ambiguates the unqualified references
to bitset after "using namespace std" in the testsuite.
Work around the namespace pollution with using
On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
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.
>
> libstdc++-v3/ChangeLog:
>
> *
On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:
> We currently use
> %rename lib liborig
> *lib: %{static-libgfortran:--as-needed} -lquadmath
> %{static-libgfortran:--no-as-needed} -lm %(libgcc) %(liborig)
> in libgfortran.spec (on targets where we do configure in li
> 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.
Ada part is OK, thanks.
> gcc/testsuite/ChangeLog:
>
> * ada/acats/run_all.sh: Use grep -E instea
On Thu, 23 Jun 2022 at 15:05, Alexandre Oliva wrote:
>
> On Jun 23, 2022, Jonathan Wakely wrote:
>
> > On Thu, 23 Jun 2022 at 12:08, Alexandre Oliva wrote:
> >>
> >> On Jun 22, 2022, Jonathan Wakely wrote:
> >>
> >> > There are other interactions between AT_CDCWD and ::openat not covered
> >> >
On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> 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 usin
On Fri, 24 Jun 2022 15:06:32 +0800
Xi Ruoyao via Gcc-patches 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.
> Stop using fgrep so we won't see the warning.
>
> gcc/ChangeLog:
>
> * for
On Fri, 24 Jun 2022 at 12:08, Xi Ruoyao via Libstdc++
wrote:
>
> On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> > On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> > wrote:
> > >
> > > egrep has been deprecated in favor of grep -E for a long time, and
> > > the
> > > next grep
On Fri, 24 Jun 2022 at 12:18, Jonathan Wakely wrote:
>
> On Fri, 24 Jun 2022 at 12:08, Xi Ruoyao via Libstdc++
> wrote:
> >
> > On Fri, 2022-06-24 at 11:00 +0100, Jonathan Wakely wrote:
> > > On Fri, 24 Jun 2022 at 08:03, Xi Ruoyao via Libstdc++
> > > wrote:
> > > >
> > > > egrep has been deprec
On 23.06.22 13:39, Sebastian Huber wrote:
Remove RTEMS support from crossconfig.m4 since this code is not used due to
"with_newlib" being "yes".
libstdc++-v3/ChangeLog:
* configure: Regnerate.
* configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
targets ex
Hi Jonathan,
>> > I'll need some rework as Rainer told me "grep -E" may not work on some
>> > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
>> > is exactly for Solaris...
>>
>> I checked that, and it's not :-)
>>
>> The egrep uses in extract_symvers.in are for everything
On Fri, 24 Jun 2022, Richard Sandiford wrote:
> Richard Biener writes:
> > On Thu, 23 Jun 2022, Richard Sandiford wrote:
> >> In a reduction pair like:
> >>
> >> typedef float T;
> >>
> >> void
> >> f1 (T *x)
> >> {
> >> T res1 = 0;
> >> T res2 = 0;
> >> for (int i = 0; i <
On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i
> > debian' >/dev/null 2>&1; then \
> > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i
> > debian' >/dev/null 2>&1; then \
>
Hi Xi,
> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>
>> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>> > -i debian' >/dev/null 2>&1; then \
>> > + if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v
>> > -i debian' >/dev/null 2
On Fri, 2022-06-24 at 13:41 +0200, Rainer Orth wrote:
> Hi Jonathan,
>
> > > > I'll need some rework as Rainer told me "grep -E" may not work on some
> > > > Solaris systems w/o GNU grep, and the code snippet in extract_symvers.in
> > > > is exactly for Solaris...
> > >
> > > I checked that, and
On Fri, 24 Jun 2022 at 13:37, Xi Ruoyao wrote:
>
> On Fri, 2022-06-24 at 13:41 +0200, Rainer Orth wrote:
> > Hi Jonathan,
> >
> > > > > I'll need some rework as Rainer told me "grep -E" may not work on some
> > > > > Solaris systems w/o GNU grep, and the code snippet in
> > > > > extract_symvers.
The following fixes up r13-469-g9a53101caadae1b5 by properly
implementing what operand_equal_for_comparison_p did.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2022-06-24 Richard Biener
PR middle-end/106070
* match.pd (a != b ? a : b): Fix translation of
On 6/24/2022 5:38 AM, Sebastian Huber wrote:
On 23.06.22 13:39, Sebastian Huber wrote:
Remove RTEMS support from crossconfig.m4 since this code is not used
due to
"with_newlib" being "yes".
libstdc++-v3/ChangeLog:
* configure: Regnerate.
* configure.ac (newlib, *-rtems*): Enable TL
Hi,
On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
- if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v -i debian'
>/dev/null 2>&1; then \
+ if $(SHELL) -c 'install-info --version | sed 1q | grep -F -s -v -i debian'
>/dev/null 2>&1; then \
On 6/23/22 09:59, Jan Hubicka via Gcc-patches wrote:
Note that your email subject line is missing "[PATCH]" and a component
tag like "c++:".
this patch adds fnspecs for cxa_* functions in except.cc. Main goal is to make
modref to see proper side-effects of functions which may throw. So in ge
On 6/22/22 00:04, 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 return
checking
with just -fsanitize=unreachable than
This patch implements the missed optimization described in PR 94026,
where a the shift can be eliminated from the sequence of a shift,
followed by a bit-wise AND followed by an equality/inequality test.
Specifically, ((X << C1) & C2) cmp C3 into (X & (C2 >> C1)) cmp (C3 >> C1)
and likewise ((X >>
Hi!
Testing this on powerpc64le-linux revealed some problems
with the patch when gcc is configured against glibc 2.26 through 2.31.
Here is incremental patch (against the v2 patch) that fixes it.
Built and tested on powerpc64le-linux with glibc 2.28, ok for trunk?
2022-06-24 Jakub Jelinek
On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches 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.
> And, the fgrep command in exgettext is no longer useful after we
> migrated from SVN to Git. Rem
On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:
> Though I do find that -E/-F have been part of the POSIX standard since
> at least 2004 which is interesting.
grep -E and -F are already defined, and egrep and fgrep marked as
obsolescent, in the 1992/1993 edition of POSIX.2.
--
Joseph
> On 24 Jun 2022, at 17:09, Joseph Myers wrote:
>
> On Fri, 24 Jun 2022, Andrew Pinski via Gcc-patches wrote:
>
>> Though I do find that -E/-F have been part of the POSIX standard since
>> at least 2004 which is interesting.
>
> grep -E and -F are already defined, and egrep and fgrep marked
Hi!
Please Cc: me on all combine patches, so that I will not miss any.
On Thu, Jun 23, 2022 at 11:39:16AM +0800, liuhongt via Gcc-patches wrote:
> This is follow-up to [1], return INVALID_REGNUM instead of gcc_assert,
> also adjust some conditions guarded for reg_or_subregno.
>
> >OK, but I
Hi!
On Fri, Jun 24, 2022 at 09:03:59AM +0800, Kewen.Lin wrote:
> on 2022/6/24 03:06, Segher Boessenkool wrote:
> > On Wed, May 18, 2022 at 10:07:48PM +0800, Kewen.Lin wrote:
> >> As PR103353 shows, we may want to continue to expand a MMA built-in
> >> function like a normal function, even if we ha
Clean up whitespace in preparation for a follow-up patch.
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-1249-g3752e21d8c180b.
gcc/analyzer/ChangeLog:
* call-string.cc (call_string::calc_recursion_depth): Whitespace
ana::call_string is a wrapper around an auto_vec of callsites, leading
to non-trivial copying when copying around call_string instances, e.g.
in ana::program_point.
This patch consolidates call_string instances within the
region_model_manager: it now owns the root/empty call_string, and
each call_
On 6/21/22 9:12 AM, Jose E. Marchesi wrote:
On 6/17/22 10:18 AM, Jose E. Marchesi wrote:
Hi Yonghong.
On 6/15/22 1:57 PM, David Faust wrote:
On 6/14/22 22:53, Yonghong Song wrote:
On 6/7/22 2:43 PM, David Faust wrote:
Hello,
This patch series adds support for:
- Two new C-language
I'd like to ping this patch again:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595436.html
OK for trunk?
Thanks
Dave
On Mon, 2022-06-13 at 14:23 -0400, David Malcolm wrote:
> Ping for this patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595436.html
>
> OK for tunk?
>
>
On Mon, 2022-06-13 at 14:25 -0400, David Malcolm wrote:
> Ping on this patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595434.html
>
> OK for trunk?
>
> Thanks
> Dave
>
> On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > gcc/ChangeLog:
> > * expr.cc: Add "final" a
I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595435.html
OK for trunk?
Thanks
Dave
On Mon, 2022-06-13 at 14:26 -0400, David Malcolm wrote:
> Ping for this patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595435.html
>
> OK for trunk?
>
> Than
Excerpts from Jeff Law via Gcc-patches's message of Juni 22, 2022 8:16 pm:
>
>
> On 6/22/2022 11:30 AM, Iain Buclaw via Gcc-patches wrote:
>> Hi,
>>
>> Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get
>> optimized into `j != 922337203685477580', which will result in an
>> infin
I'd like to ping this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
OK for trunk?
Thanks
Dave
On Mon, 2022-06-13 at 14:30 -0400, David Malcolm wrote:
> Ping for this patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595440.html
>
> OK for trunk?
>
> Th
On Mon, 2022-06-13 at 14:30 -0400, David Malcolm wrote:
> Ping re this patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595443.html
>
> OK for trunk?
>
> Thanks
> Dave
>
> On Mon, 2022-05-23 at 15:28 -0400, David Malcolm wrote:
> > gcc/cp/ChangeLog:
> > * cxx-pretty-print.h:
On Linux/x86_64,
b36a1c964f99758de1f3b169628965d3c3af812b is the first bad commit
commit b36a1c964f99758de1f3b169628965d3c3af812b
Author: Richard Biener
Date: Fri Jun 24 13:37:22 2022 +0200
middle-end/106070 - bogus cond-expr folding
caused
FAIL: gcc.dg/torture/pr106070.c -O0 executio
On Mon, 2022-06-06 at 17:49 -0400, Lewis Hyatt via Gcc-patches wrote:
> Hello-
>
> The attached patch upgrades the cpp_wcwidth() function (needed for
> computing display columns in diagnostics output) from Unicode 13 to
> Unicode 14. I just mechanically followed the procedure in
> contrib/unicode/
This patch to the Go frontend uses bool for a comma-ok statement if
the variable already has a type that is not a boolean type. This is a
statement like
v, ok := m[k]
Otherwise we may try to convert an unnamed bool type to an interface
type, which will fail. But we don't want to always use
On 24 June 2022 14:35:20 CEST, Rainer Orth
wrote:
>Hi Xi,
>
>> On Fri, 2022-06-24 at 13:13 +0200, Bernhard Reutner-Fischer wrote:
>>
>>> > - if $(SHELL) -c 'install-info --version | sed 1q | fgrep -s -v
>>> > -i debian' >/dev/null 2>&1; then \
>>> > + if $(SHELL) -c 'install-info --ve
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
OK for trunk?
Sorry, I though the series had been approved at some point. In
general,
Hi,
This patch merges the D front-end with upstream dmd 529110f66.
The git revision hash of libdruntime has also been bumped, though the
only changes made have been outside what is merged downstream.
D front-end changes:
- Import latest bug fixes to mainline.
Bootstrapped and regression te
Hi,
This patch changes the D front-end code generation of index expressions
to use an ARRAY_REF when the array expression is a ARRAY_TYPE.
This is a small simplification over `((T *)&array)[index]', which also
allows eliding an unneccesary marking of TREE_ADDRESSABLE when the array
expression is
Hi,
This patch adds a new `@register' attribute to the D compiler and
library. Addressing a feature request in PR105413.
The `@register` attribute specifies that a local or `__gshared` variable
is to be given a register storage-class in the C sense of the term, and
will be placed into a register
Hi,
This patch adjusts all the "not a string" errors in the D attribute
handlers to use the same format string for consistency.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* d-attribs.cc (d_handle_sec
On 6/23/2022 3:21 PM, Dimitar Dimitrov wrote:
This test spuriously fails on AVR with:
error: width of 'bitfield_c' exceeds its type
8-bit and 16-bit microcontrollers do not seem to be the target audience
for BTF file format. So the least intrusive fix is to simply skip the
test for them.
On Fri, 24 Jun 2022, David Malcolm via Gcc-patches wrote:
> > BTW, is this something simple enough I should just commit it without
> > bugging
> > the list for approval?
>
> The patch seems reasonable to me, but Joseph seems to be the expert on
> i18n-related matters.
>
> Joseph, do we have a po
Dear all,
we failed to fully check arguments to UNPACK when the MASK
argument was not simplified and considered a variable instead
of an array. The fix is a one-liner.
Regtested on x86_64-pc-linux-gnu and committed to mainline
as obvious after an OK by Steve in the PR.
Thanks,
Harald
From f21f
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, but if all other targets do the same,
x86 shouldn't be left behind.
So, rubber-stamping OK.
Hi Jakub,
Am 24.06.22 um 12:29 schrieb Jakub Jelinek via Gcc-patches:
On Thu, Jun 23, 2022 at 11:17:50PM +0200, Jakub Jelinek via Gcc-patches wrote:
We currently use
%rename lib liborig
*lib: %{static-libgfortran:--as-needed} -lquadmath
%{static-libgfortran:--no-as-needed} -lm %(libgcc) %(libo
Hi,
Here is a patch to add -Woverloaded-virtual to -Wall:
https://gcc.gnu.org/bugzilla/attachment.cgi?id=49021
It should address this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729
Regards,
On 6/15/2022 5:36 AM, Richard Sandiford wrote:
Jeff Law via Gcc-patches writes:
On 6/13/2022 5:54 AM, Richard Biener wrote:
On Sun, Jun 12, 2022 at 7:27 PM Jeff Law via Gcc-patches
wrote:
[...]
On a related topic, any thoughts on keeping complex objects as complex
types/modes through gimp
This seems like a good warning to have in -Wall, as requested. But as
pointed out in PR20423, some users want a warning only when a derived
function doesn't override any base function. So let's put that lesser
version in -Wall (and -Woverloaded-virtual=1) while leaving the semantics
for the exist
On 6/24/2022 12:19 PM, Iain Buclaw wrote:
Excerpts from Jeff Law via Gcc-patches's message of Juni 22, 2022 8:16 pm:
On 6/22/2022 11:30 AM, Iain Buclaw via Gcc-patches wrote:
Hi,
Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get
optimized into `j != 922337203685477580', w
On Thu, Jun 02, 2022 at 05:08:54PM -0400, Jason Merrill wrote:
> On 5/26/22 11:01, Marek Polacek wrote:
> > In this problem, we are failing to properly perform copy elision with
> > a conditional operator, so this:
> >
> >constexpr A a = true ? A{} : A{};
> >
> > fails with:
> >
> >error
On Fri, 2022-06-24 at 16:06 +, Joseph Myers wrote:
> On Fri, 24 Jun 2022, Xi Ruoyao via Gcc-patches 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.
> > And, the fgrep command i
77 matches
Mail list logo
