The LoongArch support for libubsan and libasan has been added in:
- https://reviews.llvm.org/D129371
- https://reviews.llvm.org/D129418
and we've merged them in r13-2269. It's time to enable them.
No unexpected failures in GCC asan.exp and ubsan.exp tests.
libsanitizer/ChangeLog:
*
After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.
libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
Add _GLIBCXX_DEBUG_BACKTRACE macro to activate backtrace
generation on
_GLIBCXX_DEBUG assertions.
If I got your point correctly here is this patch again with just the
change on '0' becoming 'nullptr' in assertions.
libstdc++: [_GLIBCXX_DEBUG] Review nullptr assertion diagnostics
Review null string checks to show:
_String != nullptr
rather than:
_String != 0
On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:
> Once Alex is OK with this patch, then it'll be good to go.
>
> jeff
Gentle ping as a distro maintainer :).
--
Xi Ruoyao
School of Aerospace Science and Technology, Xidian University
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #17 from gagan sidhu (broly) ---
(In reply to Xi Ruoyao from comment #16)
> (In reply to gagan sidhu (broly) from comment #15)
>
> > and also: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9f943b2446f2d0
>
> Please don't use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
--- Comment #16 from Xi Ruoyao ---
(In reply to gagan sidhu (broly) from comment #15)
> and also: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=9f943b2446f2d0
Please don't use this. I've already said why this is not correct in previous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
gagan sidhu (broly) changed:
What|Removed |Added
CC||broly at mac dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106736
Kewen Lin changed:
What|Removed |Added
Attachment #53513|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106643
--- Comment #1 from Henry Le Berre ---
Here is a more minimal version:
m_mod.f90:
```fortran
module m_mod
real(kind(0d0)),allocatable, dimension(:) :: arrs
!$acc declare create(arrs)
contains
subroutine s_mod_init()
On 2022-08-30 8:13 p.m., Jeff Law wrote:
On 8/28/2022 10:34 AM, John David Anglin wrote:
On 2022-08-26 3:15 a.m., Martin Liška wrote:
Removes the deprecated ports. If I'm correct all hpux9,hpux10 should be removed
as they only provide 32-bit targets. On the contrary, hpux11 supports hppa64
On 8/28/2022 10:34 AM, John David Anglin wrote:
On 2022-08-26 3:15 a.m., Martin Liška wrote:
Removes the deprecated ports. If I'm correct all hpux9,hpux10 should
be removed
as they only provide 32-bit targets. On the contrary, hpux11 supports
hppa64 that
we still do support.
It is my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106774
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106672
--- Comment #2 from Eric Gallager ---
Well, at the very least GCC could print a nicer error message (and possibly
suggest a fix-it hint for it, too)
On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:
> Hi, Joseph and Nathan,
>
> Could you please review the C and C++ FE parts of the patch?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html
I think some work is still needed on the diagnostic wording.
> + "%qE
On Mon, 29 Aug 2022, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
> > For convenience, singleton_p() returns false for a NAN. IMO, it makes
> > the implementation cleaner, but I'm not wed to the idea if someone
> > objects.
>
> If
On Sat, 27 Aug 2022, Jose E. Marchesi via Gcc-patches wrote:
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* { dg-warning "comparison of distinct pointer
> types" } */
> + if (metadata + 1 > data) /* There shouldn't
On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> I was hoping Joseph would chime in here - I recollect debugging this kind
> of thing and a thread about this a while back but unfortunately I do not
> remember the details here (IIRC some things get included where they
> better should
On 8/30/22 11:20, Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 11:31:54PM -0400, Jason Merrill wrote:
The pedwarn on -std=c++23 -finput-charset=UTF-8 or just documenting that
"conforming" UTF-8 is only -finput-charset=UTF-8 -Werror=invalid-utf8 ?
The former.
Ok.
So, here is an updated
On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
> > I'm seeing build failures of glibc for powerpc64, as illustrated by the
> > following C code:
> >
> > #if 0
> > \NARG
> > #endif
> >
> > (the actual
On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
> I'm seeing build failures of glibc for powerpc64, as illustrated by the
> following C code:
>
> #if 0
> \NARG
> #endif
>
> (the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
> __ASSEMBLER__).
>
> This shows some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
George Pee changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
I'm seeing build failures of glibc for powerpc64, as illustrated by the
following C code:
#if 0
\NARG
#endif
(the actual sysdeps/powerpc/powerpc64/sysdep.h code is inside #ifdef
__ASSEMBLER__).
This shows some problems with this feature - and with delimited escape
sequences - as it affects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104265
Thomas Koenig changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment
This looks good to me, one thing though:
On Thu, Aug 11, 2022 at 09:38:12PM -0400, David Malcolm via Gcc-patches wrote:
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1439,6 +1439,10 @@ Wwrite-strings
> C ObjC C++ ObjC++ Var(warn_write_strings) Warning
> In C++, nonzero means warn
Hi, Joseph and Nathan,
Could you please review the C and C++ FE parts of the patch?
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599901.html
The middle-end changes have been approved by Richard already.
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600379.html
Thanks.
On 8/11/22 21:38, David Malcolm via Gcc-patches wrote:
PR c/90885 notes various places in real-world code where people have
written C/C++ code that uses ^ (exclusive or) where presumbably they
meant exponentiation.
For example
On Tue, Aug 30, 2022 at 09:57:45PM +0200, Tim Lange wrote:
> Hello,
>
> I was preparing a patch for GCC and used the unordered_map from the C++
> stdlib in my patch. Later on, I noticed that it is used nowhere else inside
> GCC except for some files in the go frontend.
>
> I wondered, now that
Hello,
I was preparing a patch for GCC and used the unordered_map from the C++
stdlib in my patch. Later on, I noticed that it is used nowhere else
inside GCC except for some files in the go frontend.
I wondered, now that building GCC requires a C++11 host compiler,
whether there is a
On 2022-08-29 10:06 a.m., Martin Liška wrote:
Thanks for the feedback, can you please check the updated version of the patch?
@@ -353,9 +347,6 @@ proc check_weak_available { } {
# return 1 if weak undefined symbols are supported.
proc check_effective_target_weak_undefined { } {
- if {
On Tue, 30 Aug 2022, 19:46 Anton Wöllert, wrote:
> Thanks for your comments,
>
> sorry for posting on the wrong mailing list. I'll just restate my
> initial question here on gcc-help again:
>
>I was trying to build a cross-compilation toolchain for a specific
>target using a newer GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
--- Comment #7 from Todd Richmond ---
i was playing w/ cmdline and had deleted an extra arg. the 12.2 path is before
the 12.1 path. However, our build scripts include the correct gcc header dir
to all configure lines to ensure we don't pull in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106750
--- Comment #2 from anlauf at gcc dot gnu.org ---
If you need a workaround, replace:
j(i) = do_with_array(ts(choose)) ! [#1] MEMORY LEAK
by
j(i) = do_with_array([ts(choose)]) ! [#1] no more MEMORY LEAK
On 2022-08-29 10:06 a.m., Martin Liška wrote:
Thanks for the feedback, can you please check the updated version of the patch?
The changes to the libffi directory are not necessary and incorrect. libffi is
a separate project.
Dave
--
John David Anglin dave.ang...@bell.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106750
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2022-08-30
Ever
Hi!
If you have an interest in the long term future of the sourceware
hosting server which this project is using, please consider checking
out this thread on our local overseers@ mailing list. Everything is
fine, we're just thinking ahead.
Hi!
If you have an interest in the long term future of the sourceware
hosting server which this project is using, please consider checking
out this thread on our local overseers@ mailing list. Everything is
fine, we're just thinking ahead.
Thanks for your comments,
sorry for posting on the wrong mailing list. I'll just restate my
initial question here on gcc-help again:
I was trying to build a cross-compilation toolchain for a specific
target using a newer GCC version, than the one that the binaries
were build on the
On 2022-08-29 10:06 a.m., Martin Liška wrote:
Thanks for the feedback, can you please check the updated version of the patch?
hppa64-hp-hpux11.11 built successfully with the updated patch:
https://gcc.gnu.org/pipermail/gcc-testresults/2022-August/767508.html
Dave
--
John David Anglin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
--- Comment #6 from Jakub Jelinek ---
Where does the:
-I/tools/arch/Linux_3.10.0-x86_64/gcc-12.1.0-bootstrap//include
come there? If it e.g. contains glibc fixincluded ansidecl.h, then that could
explain why it breaks.
But you don't want to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
--- Comment #5 from Jakub Jelinek ---
include/ansidecl.h has:
#if defined (__STDC__) || defined(__cplusplus) || defined (_AIX) || (defined
(__mips) && defined (_SYSTYPE_SVR4)) || defined(_WIN32)
...
#define PTR void *
...
#else /*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
--- Comment #4 from Todd Richmond ---
one other comment. all the gcc prereqs are the latest available releases -
every 3rd party package is built by us from the most up-to-date versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
--- Comment #3 from Todd Richmond ---
We have been using the same build setup for the last 20 years and this is the
1st gcc failure :) We build EVERYTHING in a self contained fashion and don't
rely on any OS libraries except libc.so.
I don't
CM_PIC is no longer doing anything directly. Removing it might
potentially affect USE_LOAD_ADDRESS_MACRO() but seems unlikely.
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 4
gcc/config/riscv/riscv-opts.h | 3 +--
gcc/config/riscv/riscv.cc | 2 +-
3 files changed,
Hi,
A couple of cleanup patches when trying to understand -mexplicit-relocs
and code model.
- 1/2 should be strightfwd
- 2/2 might be slightly controversial.
Tested with a bunch of rv32/rv64 configs: same results before after,
granted pic might not really be getting tested here.
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/riscv/riscv-c.cc b/gcc/config/riscv/riscv-c.cc
index
On Tue, Aug 30, 2022 at 9:46 AM Jose E. Marchesi
wrote:
>
>
> > On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
> > wrote:
> >>
> >>
> >> LLVM defines both __bpf__ and __BPF_ as target macros.
> >> GCC was defining only __BPF__.
> >>
> >> This patch defines __bpf__ as a target
I'd like to ping the following patch.
Peter
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/600451.html
Message-ID:
>When we expand an MMA disassemble built-in with C++ using a pointer that
>is casted to a valid MMA type, the type isn't passed down to the expand
>machinery and we
This doesn't belong on this mailing list though, please use the gcc-help
list instead.
This list is for discussion of GCC development, not help using it.
On Tue, 30 Aug 2022, 18:20 Jonathan Wakely, wrote:
>
>
> On Tue, 30 Aug 2022, 17:53 Anton Wöllert, wrote:
>
>> Hi Jonathan,
>>
>> thank
On Tue, 30 Aug 2022, 17:53 Anton Wöllert, wrote:
> Hi Jonathan,
>
> thank you for your reply!
>
> On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote:
> >
> >
> > On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc,
> > wrote:
> > > If this libstdc++ is
> > > newer than the one one the
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__unarize): Define.
(adjacent_view::_Iterator): Befriend adjacent_transform_view.
(adjacent_transform_view): Define.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* testsuite/20_util/logical_traits/requirements/short_circuit.cc: New
test.
---
.../requirements/short_circuit.cc | 32 +++
1 file changed, 32 insertions(+)
create mode
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (adjacent_view): Define.
(enable_borrowed_range): Define.
(__detail::__repeated_tuple): Define.
(adjacent_view::_Iterator): Define.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106780
Bug ID: 106780
Summary: gcc maybe-uninitialized warning on std_function.h
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi
this patch extends the previous one by using the same data structure
to represent aggregate values in classes ipa_auto_call_arg_values and
ipa_call_arg_values.
This usually simplifies handling and makes allocations of memory much
cheaper because only a single vectore is needed, as opposed to
Hi,
this patch replaces linked lists of ipa_agg_replacement_value with
vectors of similar structures called ipa_argagg_value and simplifies
how we compute them in the first place. Having a vector should also
result in less overhead when allocating and because we keep it sorted,
it leads to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106775
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
Hi Andrew,
> On 26/08/2022 12:04, Jakub Jelinek wrote:
>>> gcc/ChangeLog:
>>>
>>> * doc/tm.texi: Regenerate.
>>> * omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
>>> vecsize.
>>> (simd_clone_adjust_argument_types): Likewise.
>>> * target.def
Hi Jonathan,
thank you for your reply!
On Tue, 2022-08-30 at 17:09 +0100, Jonathan Wakely wrote:
>
>
> On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc,
> wrote:
> > If this libstdc++ is
> > newer than the one one the target, I get undefined references
> > (because
> > there are some newer
> On Mon, Aug 29, 2022 at 1:16 PM Jose E. Marchesi via Gcc-patches
> wrote:
>>
>>
>> LLVM defines both __bpf__ and __BPF_ as target macros.
>> GCC was defining only __BPF__.
>>
>> This patch defines __bpf__ as a target macro for BPF.
>> Tested in bpf-unknown-none.
>>
>> gcc/ChangeLog:
>>
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
--- Comment #1 from Todd Richmond ---
filename is likely wrong - I did this 2 days ago and lost the log output. 100%
consistent on 2 different build systems/OS though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106779
Bug ID: 106779
Summary: GCC 12.2 fails to compile in libiberty - uknown symbol
PTR - requires later patch
Product: gcc
Version: unknown
Status: UNCONFIRMED
On Tue, 30 Aug 2022, 15:48 Anton Wöllert via Gcc, wrote:
> Hello list!
>
> I was trying to build a cross-compilation toolchain for a specific
> target using a newer GCC version, than the one that the binaries were
> build on the target.
>
> The C part seems to work well, but the C++ part
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #3 from H.J. Lu ---
This debug INSN:
(debug_insn 29 28 30 2 (var_location:BLK D#2 (concatn:BLK [
(mem/j:SI (plus:DI (plus:DI (ashift:DI (zero_extend:DI (and:SI
(mem:SI (plus:DI (reg/f:DI 7 sp)
Previously [5,6] U NAN would just drop to VARYING. With this patch,
the resulting range becomes [5,6] with the NAN bit set to unknown.
[I still have yet to decide what to do with intersections. ISTM, the
intersection of a known NAN with anything else should be a NAN, but it
could also be
Martin Liška writes:
> On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
>>
>> Another very brief update to say that I'm now tidying up the code and
>> primary platform testing
>>
>> regards,
>> Gaius
>
> Hello.
>
> As you may know I'm working on the documentation migration from texinfo to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106778
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
On Mon, Aug 29, 2022 at 11:31:54PM -0400, Jason Merrill wrote:
> > The pedwarn on -std=c++23 -finput-charset=UTF-8 or just documenting that
> > "conforming" UTF-8 is only -finput-charset=UTF-8 -Werror=invalid-utf8 ?
>
> The former.
Ok.
So, here is an updated patch that implements that, and also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31290
--- Comment #5 from Andrew Pinski ---
(In reply to Philipp from comment #4)
> I disagree about this bug for gcc.c-torture/execute/920711-1.c. I think
> there was no bug here, and the "fix" actually introduced a problem, and
> should be reverted:
On Mon, Aug 15, 2022 at 07:42:39PM +0300, Frolov Daniil wrote:
> вт, 12 апр. 2022 г. в 00:56, Marek Polacek :
>
> >
> > On Thu, Apr 07, 2022 at 02:10:48AM +0500, Frolov Daniil wrote:
> > > Hello! Thanks for your feedback. I've tried to take into account your
> > > comments. New patch applied to
On 09/08/2022 14:23, Andrew Stubbs wrote:
Enable and configure SIMD clones for amdgcn. This affects both the __simd__
function attribute, and the OpenMP "declare simd" directive.
Note that the masked SIMD variants are generated, but the middle end doesn't
actually support calling them yet.
On 26/08/2022 12:04, Jakub Jelinek wrote:
gcc/ChangeLog:
* doc/tm.texi: Regenerate.
* omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
vecsize.
(simd_clone_adjust_argument_types): Likewise.
* target.def (compute_vecsize_and_simdlen): Document
Jeff Law via Gcc-patches writes:
> On 8/25/2022 7:07 AM, Richard Sandiford via Gcc-patches wrote:
>> Currently SLP tries to force permute operations "down" the graph
>> from loads in the hope of reducing the total number of permutations
>> needed or (in the best case) removing the need for the
Hello list!
I was trying to build a cross-compilation toolchain for a specific
target using a newer GCC version, than the one that the binaries were
build on the target.
The C part seems to work well, but the C++ part doesn't. It seems that
the G++ ships it's own libstdc++ include headers. If
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #6 from George Pee ---
That explanation makes a lot of sense. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #5 from Richard Earnshaw ---
My guess (and it's only a guess because I'm not a kernel expert) is that the OS
has disabled the FP/SIMD unit because of something like a context switch and
then is failing, somehow, to recognize that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #4 from George Pee ---
Yes, it's possible that this isn't a compiler bug. I thought that it might be
because the problem started showing up after upgrading the toolchain.
I wasn't sure if the compiler was failing to emit some kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106759
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106759
--- Comment #6 from CVS Commits ---
The releases/gcc-12 branch has been updated by Marek Polacek
:
https://gcc.gnu.org/g:29dfe1cacadd2a47b4e5b1cab11bd7263fe211c9
commit r12-8729-g29dfe1cacadd2a47b4e5b1cab11bd7263fe211c9
Author: Marek Polacek
> I see, thank you for explaining the issue, and sorry if I was a bit stubborn.
>
> Does the attached patch (incremental change below) look better? It no longer
> has the 'shortcut' where iterating over referrers is avoided for the common
> case of plain 'gcc -O2' and no 'optimize' attributes,
On Tue, Aug 30, 2022 at 09:22:14AM -0400, Jason Merrill via Gcc-patches wrote:
> On 7/13/22 15:29, Nathan Sidwell wrote:
> > Inspired by a user question. Jason, thoughts?
> >
> > Since C++ is such a moving target, Microsoft have /std:c++latest
> > (AFAICT clang does not), to select the currently
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-16T17:13:42+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-08-06T21:20:38+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-27T17:48:58+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
Hi Tom!
Ping.
Grüße
Thomas
On 2022-08-16T17:12:47+0200, I wrote:
> Hi Tom!
>
> Ping.
>
>
> Grüße
> Thomas
>
>
> On 2022-08-06T21:20:23+0200, I wrote:
>> Hi Tom!
>>
>> Ping.
>>
>>
>> Grüße
>> Thomas
>>
>>
>> On 2022-07-27T17:48:46+0200, I wrote:
>>> Hi Tom!
>>>
>>> Ping.
>>>
>>>
>>> Grüße
On Thu, Aug 25, 2022 at 10:37 AM Martin Liška wrote:
>
> Remove the port that has been marked obsolete in GCC 12 change notes.
>
> Ready to be installed?
OK.
> Thanks,
> Martin
>
> contrib/ChangeLog:
>
> * config-list.mk: Remove the port.
>
> gcc/ChangeLog:
>
> * config.gcc:
Xi Ruoyao via Gcc-patches writes:
> Another attempt to make kernel module happy.
>
> One remaining issue: the patch cannot diagnostic some insane thing like
>
> int x __attribute__((model("normal")));
> int x __attribute__((model("extreme")));
>
> It seems incredibly difficult to diagnose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106763
--- Comment #3 from Richard Earnshaw ---
Programs don't generally take SIGILL intermittently - if that really is the
case, then it's unlikely to be a bug in the compiler.
You haven't told us what OS you are running on, or anything else about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73550
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:ce776225249d99b089d02424b9472811a6bbd7f5
commit r13-2279-gce776225249d99b089d02424b9472811a6bbd7f5
Author: Richard Biener
Date:
This produces less redundancy and more complete info dumping
the control dependence chains.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple-predicate-analysis.cc (format_edge_vec): Dump
both source and destination.
(dump_dep_chains): Remove.
The MAX_NUM_CHAINS is applied once with <= and once with < which
results in the chains not limited but analyis dropped completely.
That's one issue in the PR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/73550
* gimple-predicate-analysis.cc
> On Aug 30, 2022, at 9:22 AM, Jason Merrill via Gcc-patches
> wrote:
>
> On 7/13/22 15:29, Nathan Sidwell wrote:
>> Inspired by a user question. Jason, thoughts?
>> Since C++ is such a moving target, Microsoft have /std:c++latest
>> (AFAICT clang does not), to select the currently
On 8/22/22 15:09, Ulrich Drepper via Gcc-patches wrote:
This is the second version of the proposed patch to add more identifiers to
the known list to give hints about #include and version numbers.
Marek looked through the first version and found it acceptable but remarked
that the list is
On 7/13/22 15:29, Nathan Sidwell wrote:
Inspired by a user question. Jason, thoughts?
Since C++ is such a moving target, Microsoft have /std:c++latest
(AFAICT clang does not), to select the currently implemented version
of the working paper. But the use of 'std:latest' is somewhat
ambiguous
On Tue, 30 Aug 2022, Martin Jambor wrote:
> There is still the optimize attribute so in fact no, even in non-LTO
> mode if there is no current function, you cannot trust the "global"
> "optimize" thing.
>
> Ideally we would assert that no "analysis" phase of an IPA pass reads
> the global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90994
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73550
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106778
David Binderman changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106775
--- Comment #2 from Marek Polacek ---
The difference between -fstrong-eval-order=all and -fstrong-eval-order=some:
<).b = 1) >;
+ (void) ((TARGET_EXPR ).b[0] = 1) >;
return = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106778
Bug ID: 106778
Summary: libcpp/makeuname2c.cc:454: sanity check in wrong place
?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
1 - 100 of 165 matches
Mail list logo
