On Tue, Nov 17, 2020 at 2:02 PM Richard Sandiford
wrote:
>
> Richard Biener via Gcc-patches writes:
> > On Tue, Nov 17, 2020 at 12:24 PM Richard Sandiford via Gcc-patches
> > wrote:
> >>
> >> We're now able to vectorise the set-up loop:
> >>
> >> int p = power2 (fns[i].po2);
> >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85315
--- Comment #11 from Richard Biener ---
(In reply to Andrew Macleod from comment #10)
> OK, so whats the deal here. I can't really follow what the final request, or
> action is.
>
> Is there a conclusion on what needs to be done? if anything?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #12 from Jan Hubicka ---
With ODR name hashing fix and fix to streaming the access types we now get:
957 false returned: 'different references' in compare_symbol_references
at ../../gcc/ipa-icf.c:465
961 false returned:
On Wed, 18 Nov 2020, Jan Hubicka wrote:
> Hi,
> main purpose of obj_type_ref is to hold the type that was used in
> virutal call. We do not hash this info in hash_operand that causes a
> lot of miscompares at ICF time. With LTO this is quite important for
> icf performance and in that case we
On Tue, 17 Nov 2020, Jeff Law wrote:
>
>
> On 11/4/20 8:10 AM, Raoni Fassina Firmino via Gcc-patches wrote:
> > On Wed, Nov 04, 2020 at 10:35:03AM +0100, Richard Biener wrote:
> >>> +/* Expand call EXP to the fegetround builtin (from C99 fenv.h),
> >>> returning the
> >>> + result and
Hi,
main purpose of obj_type_ref is to hold the type that was used in
virutal call. We do not hash this info in hash_operand that causes a
lot of miscompares at ICF time. With LTO this is quite important for
icf performance and in that case we do have manged type names (for
non-anonymous types)
On Tue, 17 Nov 2020, Jeff Law wrote:
>
> Minor questions for Jan and Richi embedded below...
>
> On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
> > When investigating the issue from
> > https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549786.html
> > I find the BB COUNTs of loop seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
--- Comment #1 from s.baur...@tu-berlin.de ---
Created attachment 49584
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49584=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97884
Bug ID: 97884
Summary: INT_MIN falsely expanded to 64 bit
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Patch set committed :)
On Wed, Nov 18, 2020 at 1:43 PM Kito Cheng wrote:
> >> Current GCC implementation is RISC-V ISA 2.2, this patch set implement
> v20190608 and v20191213, and also add option
> -misa-spec=[2.2|20190608|20191213] to change the default ISA spec version.
> >>
> >> There is one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97417
--- Comment #39 from Levy ---
Checked all pass from 250r.shorten_memrefs to 270r.ce2
In 269r.combine I saw the following combination merged the replaced address:
---
modifying insn i327:
On Tue, Nov 17, 2020 at 11:33:29PM -0600, will schmidt wrote:
> On Sun, 2020-11-15 at 12:23 -0500, Michael Meissner via Gcc-patches wrote:
> > PowerPC: Restrict long double test to use IBM long double.
> >
> > I posted this patch previously as a set of 3 testsuite patches. I have
> > separated
On Tue, Nov 17, 2020 at 11:33:23PM -0600, will schmidt wrote:
> On Sun, 2020-11-15 at 12:12 -0500, Michael Meissner via Gcc-patches wrote:
> > Include math.h in nextafter-2.c test.
> >
> > I previously posted this with two other patches. I've separated this into
> > its
> > own patch. What
>> - CSR related instructions and fence instructions has to be splitted from
>>baseline ISA, zicsr and zifencei are corresponding sub-extension.
>
>
> It is actually only fence.i that is split off. fence is still part of the
> base ISA. This is why it is called zifencei.
Oh...I didn't
On Wed, Nov 18, 2020 at 5:29 AM Jim Wilson wrote:
>
> On Thu, Nov 12, 2020 at 11:28 PM Kito Cheng wrote:
>>
>> +#ifndef HAVE_AS_MARCH_ZIFENCE
>> + /* Skip since older binutils don't recognize zifencei,
>> + we mad a mistake that is binutils 2.35 support zicsr but not support
>> +
>> Current GCC implementation is RISC-V ISA 2.2, this patch set implement
>> v20190608 and v20191213, and also add option
>> -misa-spec=[2.2|20190608|20191213] to change the default ISA spec version.
>>
>> There is one major incompatible
>>
>> That option will effect the default version of each
On Sun, 2020-11-15 at 12:17 -0500, Michael Meissner via Gcc-patches wrote:
> From 698d9fd8a5701fa4ed9690ddf71d57765921778c Mon Sep 17 00:00:00 2001
> From: Michael Meissner
> Date: Sun, 15 Nov 2020 00:48:23 -0500
> Subject: [PATCH] PowerPC Fix ibm128 defaults for pr70117.c test.
>
> This patch
On Sun, 2020-11-15 at 12:12 -0500, Michael Meissner via Gcc-patches wrote:
> Include math.h in nextafter-2.c test.
>
> I previously posted this with two other patches. I've separated this into its
> own patch. What happens is because the nextafter-2.c test uses -fno-builtin,
> and it does not
On Sun, 2020-11-15 at 12:23 -0500, Michael Meissner via Gcc-patches wrote:
> PowerPC: Restrict long double test to use IBM long double.
>
> I posted this patch previously as a set of 3 testsuite patches. I have
> separated them into separate patches. This patch marks the convert-bfp-11.c
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97873
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85304
Nikhil changed:
What|Removed |Added
CC||nmahalle at in dot ibm.com
--- Comment #5 from
On Fri, 2020-11-13 at 16:04 -0600, Pat Haugen via Gcc-patches wrote:
> Add Power10 scheduling description.
>
> This patch adds the Power10 scheduling description. Since power10.md
> was pretty much a complete rewrite (existing version of power10.md is
> mostly just a copy of power9.md), I diffed
On Fri, 2020-11-13 at 16:04 -0600, Pat Haugen via Gcc-patches wrote:
> diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
> index 4d528a39a37..85bb42d6dce 100644
> --- a/gcc/config/rs6000/rs6000.c
> +++ b/gcc/config/rs6000/rs6000.c
> @@ -1080,6 +1080,26 @@ struct processor_costs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97883
Bug ID: 97883
Summary: [C++20] Segmentation fault on template with
braced initializer list A<{}>
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity:
This libgo patch updates the gofrontend mangling checks, in
preparation for changing the mangling scheme again.
This is a port of two patches in the master repository.
https://golang.org/cl/259298
cmd/cgo: split gofrontend mangling checks into cmd/internal/pkgpath
This is a step toward
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97744
Kewen Lin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On 11/16/20 4:54 PM, Jeff Law wrote:
On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
wrote:
GCC considers PTRDIFF_MAX - 1 to be the size of the largest object
so that the difference between a pointer to the byte just
Hi, Thomas
The patch resolves the "no such variable" error message, but I see
"during GIMPLE pass: omplower"
excess error message.
I installed Tcl 8.6 with Expect 5.45. This removes the "no such
variable" error messages for C and C++ test cases, but they still
occur for Fortran.
I guess that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #5 from Bruno Haible ---
Nice! Thank you.
On 14/11/20 14:23 +, Jonathan Wakely via Libstdc++ wrote:
On Sat, 14 Nov 2020, 13:30 Mike Crowe via Libstdc++,
wrote:
On Saturday 14 November 2020 at 00:17:59 +, Jonathan Wakely via
Libstdc++ wrote:
> On 32-bit targets where userspace has switched to 64-bit time_t, we
> cannot pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421
--- Comment #10 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:1e3e6c700f04fe6992b9077541e434172c1cbdae
commit r11-5114-g1e3e6c700f04fe6992b9077541e434172c1cbdae
Author: Jonathan Wakely
On 17/11/20 21:51 +0100, François Dumont via Libstdc++ wrote:
This is a change that has been done to _Hashtable and that I forgot to
propose for _Rb_tree.
The _GLIBCXX_XREF macro can be easily removed of course.
   libstdc++: _Rb_tree code cleanup, remove lambdas.
   Use an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91191
Andrew Macleod changed:
What|Removed |Added
CC||aldyh at redhat dot com,
On 11/17/20 5:01 PM, Segher Boessenkool wrote:
> On Tue, Nov 17, 2020 at 12:41:58PM -0600, Peter Bergner wrote:
>>> +;; Return 1 if this operand is valid for an MMA disassemble insn.
>>> +(define_predicate "mma_disassemble_output_operand"
>>> + (match_code "reg,subreg,mem")
>>> +{
>>> + if
On Tue, 17 Nov 2020, Alejandro Colomar via Libc-alpha wrote:
> Nice!
> Please update me on any feedback you receive.
Apparently the author is planning new versions of those papers so WG14
discussion is waiting for those.
> So glibc will basically hold this patch
> at least until the WG answers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85316
Bug 85316 depends on bug 91029, which changed state.
Bug 91029 Summary: missed optimization regarding value of modulo operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
On Tue, Nov 17, 2020 at 12:03:05PM -0600, acsaw...@linux.ibm.com wrote:
> From: Aaron Sawdey
>
> After the MMA opaque mode patch goes in, we can re-enable
> use of vector pair in the inline expansion of memcpy/memmove.
>
> After bootstrap/regtest, OK for trunk?
Yes, okay for trunk after the
On Tue, Nov 17, 2020 at 12:41:58PM -0600, Peter Bergner wrote:
> > +;; Return 1 if this operand is valid for an MMA disassemble insn.
> > +(define_predicate "mma_disassemble_output_operand"
> > + (match_code "reg,subreg,mem")
> > +{
> > + if (REG_P (op) && !vsx_register_operand (op, mode))
> > +
Hi Joseph,
On 11/17/20 11:44 PM, Joseph Myers wrote:
> I've asked the WG14 reflector why N2529 (and N2530, though that one's not
> relevant to this feature) doesn't seem to have made it onto a meeting
> agenda yet, when there have been two WG14 meetings since that proposal
was
> made and a third
I've asked the WG14 reflector why N2529 (and N2530, though that one's not
relevant to this feature) doesn't seem to have made it onto a meeting
agenda yet, when there have been two WG14 meetings since that proposal was
made and a third one coming up.
--
Joseph S. Myers
jos...@codesourcery.com
Hi!
On Tue, Nov 17, 2020 at 11:48:04AM -0600, acsaw...@linux.ibm.com wrote:
> This patch changes powerpc MMA builtins to use the new opaque
> mode class and use modes OO (32 bytes) and XO (64 bytes)
> instead of POI/PXI. Using the opaque modes prevents
> optimization from trying to do anything
Hi,
Do you think the patch is ready,
or is there anything else I should do before merging it?
Thanks,
Alex
On 9/28/20 9:12 PM, Alejandro Colomar wrote:
> 'nitems()' calculates the length of an array in number of items.
> It is safe: if a pointer is passed to the macro (or function, in C++),
>
On 11/4/20 8:10 AM, Raoni Fassina Firmino via Gcc-patches wrote:
> On Wed, Nov 04, 2020 at 10:35:03AM +0100, Richard Biener wrote:
>>> +/* Expand call EXP to the fegetround builtin (from C99 fenv.h), returning
>>> the
>>> + result and setting it in TARGET. Otherwise return NULL_RTX on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Joseph S. Myers changed:
What|Removed |Added
Last reconfirmed||2020-11-17
Target Milestone|---
On 11/4/20 8:10 AM, Raoni Fassina Firmino via Gcc-patches wrote:
> On Wed, Nov 04, 2020 at 10:35:03AM +0100, Richard Biener wrote:
>>> +/* Expand call EXP to the fegetround builtin (from C99 fenv.h), returning
>>> the
>>> + result and setting it in TARGET. Otherwise return NULL_RTX on
On Tue, Nov 17, 2020 at 09:10:53PM +, Will Deacon wrote:
> On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> > On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> > >
> > > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > > constrained on what kind of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94936
--- Comment #4 from CVS Commits ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:cbc9dab25fb807278d2e09ec3e89e466385c9fce
commit r9-9054-gcbc9dab25fb807278d2e09ec3e89e466385c9fce
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #13 from Iain Sandoe ---
(In reply to jos...@codesourcery.com from comment #12)
> config.sub and config.guess are imported, unmodified, from upstream
> config.git.
thanks I will try to do that and test it over the next days (I've
Minor questions for Jan and Richi embedded below...
On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
> When investigating the issue from
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/549786.html
> I find the BB COUNTs of loop seems are not accurate in some case.
> For example:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #12 from joseph at codesourcery dot com ---
config.sub and config.guess are imported, unmodified, from upstream
config.git.
libtool has lots of local changes, hopefully all of them submitted
upstream but maybe not and maybe some
PR 91029 observes when
a % b > 0 && b >= 0,
then a has an implied range of a >=0. likewise
a % b < 0 implies a range of a <= 0.
This patch is a good example of how range-ops can be leveraged to solve
problems. It simply implements operator_trunc_mod::op1_range() to solve
for 'A' when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91029
--- Comment #3 from CVS Commits ---
The master branch has been updated by Andrew Macleod :
https://gcc.gnu.org/g:1e27e7a582a9b86bcf86f5c103cd947672746e97
commit r11-5111-g1e27e7a582a9b86bcf86f5c103cd947672746e97
Author: Andrew MacLeod
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22326
--- Comment #7 from joseph at codesourcery dot com ---
I agree that match.pd is a sensible place for this (and the front end is
not, we should be getting optimizations out of the front ends).
I'd encourage anyone looking at this also to look
On 10/30/20 5:34 AM, Thomas Schwinge wrote:
> Hi!
>
> On 2017-05-22T18:55:29+0200, Tom de Vries wrote:
>> On 05/16/2017 03:12 PM, Rainer Orth wrote:
>>> [...], but the new proc ['dg-line'] needs documenting in sourcebuild.texi.
>> Attached patch adds the missing documentation.
> OK to expand
On 11/17/20 2:27 PM, Pop, Sebastian via Gcc-patches wrote:
> Hi,
>
> here is a follow-up patch to add missing Arm64 configure flags as aliases to
> the existing flags.
>
> gcc/
> * config.gcc: add configure flags --with-{cpu,arch,tune}-{32,64}
> as alias flags for
On 11/17/20 10:53 AM, Pop, Sebastian via Gcc-patches wrote:
> Hi,
>
> the attached patch fixes a configure error on Arm64 when passing
> --with-tune=... to configure:
> ```
> This target does not support --with-tune.
> Valid --with options are: abi cpu arch
> ```
> The missing flag sets target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #11 from Jan Hubicka ---
Created attachment 49582
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49582=edit
Memory use of GCC 10 release branch with ICF
On Thu, Nov 12, 2020 at 11:27 PM Kito Cheng wrote:
> Current GCC implementation is RISC-V ISA 2.2, this patch set implement
> v20190608 and v20191213, and also add option
> -misa-spec=[2.2|20190608|20191213] to change the default ISA spec version.
>
> There is one major incompatible
>
> That
On 11/17/20 2:13 PM, Jan Hubicka wrote:
> Hi,
> I am testing the following fix. I manually applied a rejected hunk and
> for some reaosn managed to reverse the conditonal :(
>
> Honza
>
> * ipa-icf.c (sem_function::hash_stmt): Fix conditional on
> variably_modified_type_p.
> diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Thu, Nov 12, 2020 at 11:28 PM Kito Cheng wrote:
> +#ifndef HAVE_AS_MARCH_ZIFENCE
> + /* Skip since older binutils don't recognize zifencei,
> + we mad a mistake that is binutils 2.35 support zicsr but not support
> + zifencei. */
> + skip_zifencei = true;
> +#endif
>
I'd suggest
Committed to master as obvious.
Thanks,
Harald
Fortran texi: Fix description of GFC_RTCHECK_* macros.
gcc/fortran/ChangeLog:
* gfortran.texi: Fix description of GFC_RTCHECK_* to match actual
code.
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97877
--- Comment #3 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:e0da4aed176a8de042a8482beb65499e29448556
commit r11-5108-ge0da4aed176a8de042a8482beb65499e29448556
Author: Nathan Sidwell
Date:
This modules-related patch extends cache_integer_cst. Currently, when
given a small cst, that cst is added to the type's small and /must
not/ already be there. Large values are fine if they are already in
the large cache. This adds a parameter to indicate small duplicates
are ok, and it
Hi,
here is a follow-up patch to add missing Arm64 configure flags as aliases to
the existing flags.
gcc/
* config.gcc: add configure flags --with-{cpu,arch,tune}-{32,64}
as alias flags for --with-{cpu,arch,tune} on AArch64.
* doc/install.texi: Document new flags for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
--- Comment #11 from Iain Sandoe ---
Created attachment 49581
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49581=edit
regenerated files
the second patch is all the regenerated files .. much larger :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97865
Iain Sandoe changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
On Thu, Nov 12, 2020 at 11:29 PM Kito Cheng wrote:
> - CSR related instructions and fence instructions has to be splitted from
>baseline ISA, zicsr and zifencei are corresponding sub-extension.
>
It is actually only fence.i that is split off. fence is still part of the
base ISA. This is
Am Dienstag, den 17.11.2020, 11:31 -0800 schrieb Linus Torvalds:
> On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> >
> > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > constrained on what kind of expressions it accepts as arguments.
>
> Yup.
>
> > Anyway, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97882
Bug ID: 97882
Summary: Segmentation Fault on improper redeclaration of
function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
We ICED with a duplicated block-scope extern, as duplicate_decls was
dropping the decl_lang_specific of olddecl. Simplys adding
appropriate retrofitting and copying turned out to be insufficient
because you can get a block-scope using decl also matching the extern.
The latter seems a little
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
--- Comment #3 from Eric Niebler ---
It seems like GitHub actions uses the latest libstdc++ by default when testing
even with old (e.g., clang-4) toolsets. That seems busted, but regardless, this
is now breaking _all_ my Linux clang tests for
Hi,
I am testing the following fix. I manually applied a rejected hunk and
for some reaosn managed to reverse the conditonal :(
Honza
* ipa-icf.c (sem_function::hash_stmt): Fix conditional on
variably_modified_type_p.
diff --git a/gcc/ipa-icf.c b/gcc/ipa-icf.c
index
On Tue, Nov 17, 2020 at 11:31:57AM -0800, Linus Torvalds wrote:
> On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
> >
> > It would need to be typeof( (typeof(type)) (type) ) to not be that
> > constrained on what kind of expressions it accepts as arguments.
>
> Yup.
>
> > Anyway, it won't
This is a change that has been done to _Hashtable and that I forgot to
propose for _Rb_tree.
The _GLIBCXX_XREF macro can be easily removed of course.
libstdc++: _Rb_tree code cleanup, remove lambdas.
Use an additional template parameter on the clone method to
propagate if the values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97870
--- Comment #2 from Vladimir Makarov ---
(In reply to Richard Biener from comment #1)
> Possibly related to the asm goto enhancements.
This test should work only for x86-64. Running it on other targets can give
an error.
So error about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #10 from Jan Hubicka ---
Here are main reason for miscompares:
1125 libxul.so.wpa.076i.icf: false returned: 'variables types are
different' in equals at ../../gcc/ipa-icf.c:1697
1171 libxul.so.wpa.076i.icf: false returned:
On Linux/x86_64,
afa6adbd6c83eeef6d75655140f7c0c9a02a479e is the first bad commit
commit afa6adbd6c83eeef6d75655140f7c0c9a02a479e
Author: Jan Hubicka
Date: Tue Nov 17 15:41:06 2020 +0100
Improve handling of memory operands in ipa-icf 3/4
caused
FAIL: gcc.c-torture/execute/20020412-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866
--- Comment #3 from Ilya Leoshkevich ---
I believe it's already fixed by:
commit 253c415a1acba50711c82693426391743ac18040
Author: Vladimir N. Makarov
Date: Sun Nov 15 11:22:19 2020 -0500
Do not put reload insns in the last empty BB.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866
--- Comment #2 from Ilya Leoshkevich ---
Never mind, I managed to reproduce it now:
ubuntu-focal-amd64$ git rev-parse --short HEAD
77f67db2a47
ubuntu-focal-amd64$ ../configure --target=s390x-linux-gnu --exec-prefix=/usr
--disable-bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #9 from Jan Hubicka ---
Created attachment 49578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49578=edit
Memory use of GCC trunk (11) without ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
--- Comment #8 from Jan Hubicka ---
Created attachment 49577
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49577=edit
Memory use of GCC trunk (11) with ICF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92535
Jan Hubicka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
---
On Tue, Nov 17, 2020 at 11:13 AM Linus Torvalds
wrote:
>
> > +#define __unqual_typeof(type) typeof( (typeof(type))type )
>
> that's certainly a much nicer version than the existing pre-processor
> expansion from hell.
Oh, and sparse doesn't handle this, and doesn't remove any qualifiers
for the
On Tue, Nov 17, 2020 at 11:25 AM Jakub Jelinek wrote:
>
> It would need to be typeof( (typeof(type)) (type) ) to not be that
> constrained on what kind of expressions it accepts as arguments.
Yup.
> Anyway, it won't work with array types at least,
> int a[10];
> typeof ((typeof (a)) (a)) b;
This invalid (?) code broke my assumption that if decl_specifiers->type
is null, there must be any type-specifiers. Turn the assert into an if
to fix this crash.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
gcc/cp/ChangeLog:
PR c++/97881
* parser.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
--- Comment #5 from Marek Polacek ---
Short test from Bug 97751:
template
struct use_as_nttp {};
template
struct has_nttp {};
template
using has_nttp_2 = has_nttp;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93083
Marek Polacek changed:
What|Removed |Added
CC||janpmoeller at gmx dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97751
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97801
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
On Tue, Nov 17, 2020 at 11:13:52AM -0800, Linus Torvalds wrote:
> > +#define __unqual_typeof(type) typeof( (typeof(type))type )
> that's certainly a much nicer version than the existing pre-processor
> expansion from hell.
It would need to be typeof( (typeof(type)) (type) ) to not be that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97837
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
--- Comment #2 from Jonathan Wakely ---
Changing the _Stop_state_ref default constructor to:
_Stop_state_ref() noexcept {}
allows it to compile. It shouldn't be needed, but I suppose since the
constructor is already non-trivial (due to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97876
--- Comment #1 from Jonathan Wakely ---
It works fine in Clang 9.0.0 though. We've never really set a hard limit on how
many old versions of Clang we support, but given that 9 and 10 (and trunk)
work, I'm inclined to think that three versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97878
Marek Polacek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #2
On Mon, Nov 16, 2020 at 3:11 AM Peter Zijlstra wrote:
>
> XXX: I've only verified the below actually compiles, I've not verified
> the generated code is actually 'correct'.
Well, it was mainly the arm64 code generation for load-acquire and
store-release that wanted this - so it's really the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97866
Ilya Leoshkevich changed:
What|Removed |Added
CC||iii at linux dot ibm.com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86707
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
1 - 100 of 301 matches
Mail list logo
