On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > On 05.10.21 23:54, Segher Boessenkool wrote:
> > >>There is also the issue of binary data. If some user has written
> > >>out data in double double and wants to
On Mon, Oct 04, 2021 at 12:07:54PM +0200, Jakub Jelinek wrote:
> etc. Could we just pretend in the compiler to libgfortran ABI that
> powerpc64le-linux real(kind=16) is kind 17 and make sure that if anything
> would actually think it is 17 bytes it uses 16 instead (though, kind=10
> on x86-64 or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102600
--- Comment #2 from Johel Ernesto Guerrero Peña ---
A workaround:
```C++
export using byte = // Workaround GCC bug 102600.
#if not defined(NDEBUG) or (defined(__clang__) or not defined(__GNUC__))
std::byte;
#else
unsigned char;
#endif
```
On 10/1/21 16:10, Patrick Palka wrote:
Here we're crashing when level-lowering the variadic constraints on the
template template parameter TT because tsubst_pack_expansion expects
processing_template_decl to be set during a partial substitution.
bootstrapped and regtested on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
--- Comment #5 from Martin Sebor ---
Section 25.8. Using FS and GS segments in user space applications in
https://www.kernel.org/doc/html/latest/x86/x86_64/fsgs.html makes it sound like
null might be a valid address in a named address space. I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102230
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
On 10/5/2021 10:15 AM, Hans-Peter Nilsson wrote:
On Sat, 25 Sep 2021, Hu Jialun wrote:
Hello,
Sorry for bumping it again but I guess it was getting overlooked.
I am very junior with mailing list open source contributions so please feel
free to point out if I have inadvertantly done
On 10/1/21 16:58, Jonathan Wakely wrote:
An initializer-list constructor taking a non-const lvalue cannot be
called with a temporary, so the array's lifetime probably doesn't end
with the full expression. -Winit-list-lifetime should not warn for that
case.
PR c++/102482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90773
H.J. Lu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98442
H.J. Lu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101761
H.J. Lu changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101804
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
--- Comment #4 from Martin Sebor ---
A test case is below. Warnings for accesses at address zero are intentionally
suppressed (to avoid false positives for unreachable code) but they are issued
for accesses at nonzero offsets from null because
On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64
On 10/6/2021 10:22 AM, Aldy Hernandez via Gcc-patches wrote:
On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor wrote:
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
-Wmaybe-uninitialized certainly suffers from a high rate of false
positives (I count 40 open PRs). Even after all this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
Martin Sebor changed:
What|Removed |Added
Target Milestone|--- |12.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98513
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102634
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On Oct 5, 2021, Pierre-Marie de Rodat wrote:
> * gcc-interface/utils.c (handle_strub_attribute): New.
> (gnat_internal_attribute_table): Add strub.
FTR, this is just a dummy. The actual implementation was submitted
along with the language- and machine-independent infrastructure at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102634
Bug ID: 102634
Summary: Optimization in dom2 pass makes wrong signed integer
overflow inference
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity:
On 10/6/21 15:52, Patrick Palka wrote:
On Wed, 6 Oct 2021, Patrick Palka wrote:
On Tue, 5 Oct 2021, Jason Merrill wrote:
On 10/5/21 15:17, Patrick Palka wrote:
On Mon, 4 Oct 2021, Patrick Palka wrote:
When passing a function template as the argument to a function NTTP
inside a template,
On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> With "not in any" I mean: not for other architectures either! All archs
> that do not say anything about floating point in their machine
> description get a working sofware floating point (for binary32 and
> binary64 currently).
Any architecture
On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > There's still some code in the compiler for a very old soft-float ABI for
> > binary128 long double (passing by reference, using _q_* libcall names). I
> > don't really think it makes much sense to use that for future _Float128
> > support for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633
Martin Sebor changed:
What|Removed |Added
CC||muecker at gwdg dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633
Martin Sebor changed:
What|Removed |Added
Summary|warning for |[11/12 Regression] warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102633
Bug ID: 102633
Summary: warning for self-initialization despite -Wno-init-self
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an actual argument that corresponds to a dummy argument that
is an INTENT (OUT) assumed-rank array, it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659
--- Comment #6 from Tobias Burnus ---
(In reply to Paul from comment #5)
> Just tried all versions of gfortran available up to 10.2.0: the very same
> 'internal compiler error' is still reported using the initial reproducer.
Can you share the
On 10/6/21 05:06, Jakub Jelinek wrote:
On Tue, Oct 05, 2021 at 10:40:45PM -0400, Jason Merrill wrote:
I've switched to handling bases via binfo as discussed on IRC and added
spaceship-synth14.C to test proper base handling with virtual <=>. Here's
what I'm committing:
Thanks a lot.
I see
On Wed, Oct 06, 2021 at 07:42:31PM +, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> > Soft float is not described in any formal ABI btw (well, except the
> > Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
>
> It's fully documented in the unified
Merged revision: fdf4c035225de52f596899931b1f6100e5e3e928
---
libsanitizer/MERGE| 2 +-
libsanitizer/asan/asan_allocator.cpp | 15 -
libsanitizer/asan/asan_allocator.h| 2 -
libsanitizer/asan/asan_debugging.cpp | 5 +-
---
libsanitizer/asan/asan_globals.cpp| 19 --
libsanitizer/asan/asan_interceptors.h | 7 ++-
libsanitizer/asan/asan_mapping.h | 2 +-
.../sanitizer_linux_libcdep.cpp | 4
.../sanitizer_common/sanitizer_mac.cpp| 12
I am checking in these patches to merge with upstream commit:
commit fdf4c035225de52f596899931b1f6100e5e3e928
Author: H.J. Lu
Date: Fri Sep 10 06:24:36 2021 -0700
[sanitizer] Support Intel CET
1. Include in sanitizer_common/sanitizer_asm.h to mark Intel CET
support when Intel
On Wed, 6 Oct 2021, Patrick Palka wrote:
> On Tue, 5 Oct 2021, Jason Merrill wrote:
>
> > On 10/5/21 15:17, Patrick Palka wrote:
> > > On Mon, 4 Oct 2021, Patrick Palka wrote:
> > >
> > > > When passing a function template as the argument to a function NTTP
> > > > inside a template, we resolve
On Wed, 6 Oct 2021, Segher Boessenkool wrote:
> Soft float is not described in any formal ABI btw (well, except the
> Power 32-bit embedded ABI :-) ) -- it is an compiler-internal affair.
It's fully documented in the unified 32-bit ABI document (under
ATR-SOFT-FLOAT conditionals).
There's
On 10/6/21 12:50 PM, Segher Boessenkool wrote:
> So we have three options (well, four):
>
> 0) Do nothing. We will stay in this hell forever. Not my choice :-)
> 1) Use a soft-float-like parameter passing everywhere. This works but
>will be horridly slow on newer systems. We can do better
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new headers.
* include/Makefile.in: Regenerate.
* include/std/functional: Include .
* include/std/version (__cpp_lib_move_only_function): Define.
* include/bits/mofunc_impl.h: New file.
*
On 10/6/21 11:03 AM, Aldy Hernandez wrote:
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
Okay, thanks. I see what you mean that reducing it to a test case
is challenging. I'll see if I can find some time to distill it to
something useful.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61355
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #14 from Segher Boessenkool ---
(In reply to Patrick McGehearty from comment #13)
> I may be mistaken about the source of the issue being glibc.
> Perhaps it is a system include file issue? Here are some
> more details.
>
> Here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60009
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment
On Wed, Oct 06, 2021 at 05:13:59PM +, Joseph Myers wrote:
> On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote:
> > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > We can emulate it everywhere (using libquadmath for example). This can
> > > magically make -msoft-float
commit 9069eb28d45baaa8baf5e3790b03b0e2cc5b49b3
Author: Igor Tsimbalist
Date: Fri Nov 17 22:34:50 2017 +0100
Enable building libsanitizer with Intel CET
libsanitizer/
* acinclude.m4: Add enable.m4 and cet.m4.
* Makefile.in: Regenerate.
*
Please review my small doc patch. Thank you.
Diane
On 9/15/21, 5:02 PM, "Diane Meirowitz"
wrote:
doc: improve -fsanitize=undefined description
gcc/ChangeLog:
* doc/invoke.texi: add link to
UndefinedBehaviorSanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102632
Bug ID: 102632
Summary: Missing AM_CCASFLAGS in libsanitizer Makefile.am
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
--- Comment #3 from Martin Sebor ---
If the warning is keeping Glibc from building with GCC 12 then applying the
patch until this is resolved (hopefully still in stage 1, or in stage 3) seems
like a reasonable workaround. It wouldn't be the
On Wed, Oct 06, 2021 at 07:07:43PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> > > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > > We can emulate
On Wed, Oct 6, 2021 at 12:21 PM Segher Boessenkool
wrote:
>
> On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> > On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> > wrote:
> > >
> > > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > > On 05.10.21 23:54,
I forgot to ask if with this patch this overload:
template
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>)
return std::__to_address(__ptr.base().operator->());
else
return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #13 from Patrick McGehearty
---
I may be mistaken about the source of the issue being glibc.
Perhaps it is a system include file issue? Here are some
more details.
Here are some of the error messages I got when building with
Here is another proposal with the __to_address overload.
I preferred to let it open to any kind of __normal_iterator
instantiation cause afaics std::vector supports fancy pointer types. It
is better if __to_address works fine also in this case, no ?
libstdc++: Overload std::__to_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
--- Comment #2 from joseph at codesourcery dot com ---
Since we concluded this was a GCC bug, rather than an unavoidable
limitation of the warning, suppressing it in glibc seems inappropriate.
On Wed, 6 Oct 2021, Jakub Jelinek via Gcc wrote:
> On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > We can emulate it everywhere (using libquadmath for example). This can
> > magically make -msoft-float work as well everywhere, btw.
>
> Emulation is one thing, but another
On Wed, Oct 06, 2021 at 11:59:37AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> > On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > > We can emulate it everywhere (using libquadmath for example). This can
> > > magically
FWIW, I've opened a PR with both testcases:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Blocks|
On Wed, Oct 06, 2021 at 06:34:33PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> > We can emulate it everywhere (using libquadmath for example). This can
> > magically make -msoft-float work as well everywhere, btw.
>
> Emulation is one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
--- Comment #3 from Aldy Hernandez ---
(In reply to Aldy Hernandez from comment #2)
> Created attachment 51562 [details]
> similar problem on aarch64 bootstrap
$ ./cc1plus calls-aarch64.ii -O2 -quiet -Wall
In function ‘void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
--- Comment #2 from Aldy Hernandez ---
Created attachment 51562
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51562=edit
similar problem on aarch64 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102192
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
--- Comment #1 from Aldy Hernandez ---
$ ./cc1 team.i -O2 -quiet -Wall
/home/aldyh/src/gcc/libgomp/team.c: In function ‘gomp_team_start’:
/home/aldyh/src/gcc/libgomp/team.c:315:34: warning: ‘start_data’ may be used
uninitialized in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102631
Bug ID: 102631
Summary: -Wmaybe-uninitialized cannot see through a series of
PHIs
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
On Wed, Oct 06, 2021 at 11:07:30AM -0500, Segher Boessenkool wrote:
> We can emulate it everywhere (using libquadmath for example). This can
> magically make -msoft-float work as well everywhere, btw.
Emulation is one thing, but another one is where are those __float128 or
quad long double
-‐‐ Original Message ‐‐‐
On Wednesday, October 6th, 2021 at 4:10 PM, Jonathan Wakely
wrote:
> On Wed, 6 Oct 2021 at 16:57, dimechc dime...@protonmail.com wrote:
>
> > ‐‐‐ Original Message ‐‐‐
> >
> > On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #12 from Segher Boessenkool ---
(In reply to Patrick McGehearty from comment #8)
> My challenge is that the very old glibc on gcc135.fsffrance.org
> does not know about _TF_ vs _KF_ and _IF_. It refused to
> build the new
On Tue, 5 Oct 2021, Jason Merrill wrote:
> On 10/5/21 15:17, Patrick Palka wrote:
> > On Mon, 4 Oct 2021, Patrick Palka wrote:
> >
> > > When passing a function template as the argument to a function NTTP
> > > inside a template, we resolve it to the right specialization ahead of
> > > time via
On Wed, 6 Oct 2021, Richard Biener via Gcc-patches wrote:
> Currently the frontend rejects those addresses as not lvalues
> because the C frontend doens't expect MEM_REF or TARGET_MEM_REF
> to appear (but they would be valid lvalues there). The following
> fixes that by amending lvalue_p.
>
>
On Wed, Oct 6, 2021 at 5:03 PM Martin Sebor wrote:
>
> On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
> -Wmaybe-uninitialized certainly suffers from a high rate of false
> positives (I count 40 open PRs). Even after all this time debugging
> it I still struggle with the code for it
On Wed, Oct 06, 2021 at 11:42:17AM -0400, David Edelsohn wrote:
> On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
> wrote:
> >
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > On 05.10.21 23:54, Segher Boessenkool wrote:
> > > >>There is also the issue of binary data.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
Bug ID: 102630
Summary: [12 Regression] Spurious -Warray-bounds with named
address space
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords:
On Wed, 6 Oct 2021 at 16:57, dimechc wrote:
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely
> wrote:
>
>
>
> On Wed, 6 Oct 2021, 14:19 dimechc, wrote:
>>
>> I got the GCC 11.2 download, but cannot locate the doc directory used to
>>
On Wed, Oct 06, 2021 at 05:41:07PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> > On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > > >That means flipping the default on all PowerPC to no longer be double-
> > > >double. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #23 from H.J. Lu ---
(In reply to Thiago Macieira from comment #22)
> (In reply to H.J. Lu from comment #21)
> > Created attachment 51559 [details]
> > The new v3 patch
> >
> > The new v3 patch to check invalid mask.
>
> v3? We
Hi all,
FYI The next RISC-V GNU Toolchain Biweekly Sync is cancelled because
the developers from mainland China are still on their National Holiday.
There were not too much new topics in the past weeks, except a few
psABI issues, which could be postponed to the next meeting.
--
Best wishes,
Wei
On Wed, Oct 06, 2021 at 03:57:35PM +, dimechc via Gcc wrote:
> ‐‐‐ Original Message ‐‐‐
> On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely
> wrote:
>
> > On Wed, 6 Oct 2021, 14:19 dimechc, wrote:
> >
> >> I got the GCC 11.2 download, but cannot locate the doc directory
‐‐‐ Original Message ‐‐‐
On Wednesday, October 6th, 2021 at 2:50 PM, Jonathan Wakely
wrote:
> On Wed, 6 Oct 2021, 14:19 dimechc, wrote:
>
>> I got the GCC 11.2 download, but cannot locate the doc directory used to
>> produce the
>> gcc documentation manuals.
>
> You still haven't said
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #22 from Thiago Macieira ---
(In reply to H.J. Lu from comment #21)
> Created attachment 51559 [details]
> The new v3 patch
>
> The new v3 patch to check invalid mask.
v3? We were already up to v6.
> Recursive call graph edges, even when they are hot and important for
> the compiled program, can never have frequency bigger than one, even
> when the actual time savings in the next recursion call are not
> realized just once but depend on the depth of recursion. The current
> IPA-CP effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
H.J. Lu changed:
What|Removed |Added
Attachment #51558|0 |1
is obsolete|
On Wed, Oct 6, 2021 at 11:19 AM Segher Boessenkool
wrote:
>
> On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > On 05.10.21 23:54, Segher Boessenkool wrote:
> > >>There is also the issue of binary data. If some user has written
> > >>out data in double double and wants to read
On Wed, Oct 06, 2021 at 10:17:44AM -0500, Segher Boessenkool wrote:
> On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> > On 05.10.21 23:54, Segher Boessenkool wrote:
> > >>There is also the issue of binary data. If some user has written
> > >>out data in double double and wants to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102566
--- Comment #20 from Thiago Macieira ---
And:
$ cat /tmp/test.cpp
#include
bool tbit(std::atomic )
{
return i.fetch_xor(CONSTANT, std::memory_order_relaxed) & (CONSTANT);
}
$ ~/dev/gcc/bin/gcc "-DCONSTANT=(1LL<<63)" -S -o - -O2
On Wed, Oct 06, 2021 at 12:39:01PM +0100, Kwok Cheung Yeung wrote:
> --- a/gcc/gimplify.c
> +++ b/gcc/gimplify.c
> @@ -11599,8 +11599,11 @@ omp_construct_selector_matches (enum tree_code
> *constructs, int nconstructs,
> }
> }
>if (!target_seen
> - && lookup_attribute ("omp
> 2021-08-23 Martin Jambor
>
> * params.opt (param_ipa_cp_profile_count_base): New parameter.
> * ipa-cp.c (max_count): Replace with base_count, replace all
> occurrences too, unless otherwise stated.
> (ipcp_cloning_candidate_p): identify mostly-directly called
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629
Bug ID: 102629
Summary: internal compiler error: tree check: expected
record_type or union_type or qual_union_type, have
decltype_type in lookup_base, at cp/search.c:233
On Wed, Oct 06, 2021 at 10:09:31AM -0300, Raphael M Zinsly wrote:
> On 05/10/2021 19:03, Segher Boessenkool wrote:
> >So what is new or different in v3 compared to v2?
>
> gcc/testsuite/gcc.target/powerpc/unwind-backchain.c:
> - Added a comment explaining why test only on *-linux targets.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90556
Bug 90556 depends on bug 90735, which changed state.
Bug 90735 Summary: missing location in -Wreturn-local-addr on a function with
two return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90735
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90735
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Last
On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote:
> On 05.10.21 23:54, Segher Boessenkool wrote:
> >>There is also the issue of binary data. If some user has written
> >>out data in double double and wants to read it in as IEEE quad,
> >>the results are going to be garbage. Another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
Avi Kivity changed:
What|Removed |Added
CC||a...@cloudius-systems.com
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644
--- Comment #19 from Martin Sebor ---
GCC 12 has changed to point the warning at the closing curly as suggested in
pr90735 so its output now looks like this:
pr93644.c: In function ‘careadlinkat’:
pr93644.c:30:1: warning: function may return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581
--- Comment #8 from Jan Hubicka ---
Actually, this is shorter patch - we already should notice that one
range is contained in other, but we give up too early.
Honza
diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h
index
On 10/6/21 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the light on
some warning bug.
If you take the calls.ii file from the aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543
--- Comment #2 from Richard Biener ---
Caused by
commit 001e73373e6d2e7c756141e0d7ac8e24ae1574ad
Author: Sergey Shalnov
Date: Thu Feb 8 23:31:15 2018 +0100
re PR target/83008 ([performance] Is it better to avoid extra instructions
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102628
Bug ID: 102628
Summary: [12 regression] New test case
libgomp.c-c++-common/alloc-9.c fails after its
introduction in r12-4033
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474
--- Comment #3 from Jan Hubicka ---
may be dup of PR102581 (where I attached fix I am testing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102581
--- Comment #7 from Jan Hubicka ---
Hi,
the problem is that we assume that merge is symmetric (merging a to b
succeeds if and only if merging b to a succeeds). There was one
symetrical path missing in the (fancy and bit ugly) logic on what we
This patch provides an intersect to irange which accepts a wide_int
lower and upper bound instead of an irange.
This both prevents us from having to creates trees when we needs a
temporary irange of single bounds.
This is also a bit more efficient as we can do the intersect directly in
the
One of the cases which causes ranger to bog down is processing large
switch statements.
We create ranges for each individual case, and at meet points need to
intersect those ranges and combine them. As Switches get larger, the
number of subranges at meets points increase and this becomes a
We set the upper and lower bounds in an irange whenever we call
set_varying (). Unfortunately, we create a new tree for the bounds each
time, and this is quite expensive.. creating a lot of unnecessary work.
This patch will use the values of TYPE_MIN_VALUE and TYPE_MAX_VALUE if
possible,
1 - 100 of 190 matches
Mail list logo
