Eli Schwartz writes:
> There are ***not*** thousands of Makefiles that have this issue. But if
> there were, then Makefiles are very easy to update, and only have to be
> updated once per project, not thousands of times. So this is fine. You
> may have to update your Makefile, but that is no big
On Thu, May 11, 2023 at 10:45 PM liuhongt via Gcc-patches
wrote:
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/89701
> * common.opt: Refactor -fcf-protection= to support combination
> of param.
> *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48092
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/89701
* common.opt: Refactor -fcf-protection= to support combination
of param.
* lto-wrapper.c (merge_and_complain): Adjusted.
* opts.c
On Wed, May 10, 2023 at 5:10 PM liuhongt wrote:
>
> > The quoted patch shows -shared in context and you didn't post a
> > backport version
> > to look at. But yes, we shouldn't change -shared behavior on a
> > branch, even less so make it
> > inconsistent between targets.
> Here's the patch.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98532
Andrew Pinski changed:
What|Removed |Added
Assignee|pinskia at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Sam James writes:
> They're using > c89/gnu89 often because defaults have changed (a point
> others have raised, including Arsen and Eli Schwartz) even though they
> weren't intended to be compiled with newer C.
>
> A fair amount of other projects do explicitly ask for either c99/gnu99
> or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #8 from Janez Zemva ---
I took a look and I believe the c_global is already being selected and I
believe the hack I presented should perhaps be applied to
libstdc++-v3/include/c_global/cmath - the hack template is in there. As for
From: Pan Li
We are running out of the machine_mode(8 bits) in RISC-V backend. Thus
we would like to extend the machine mode bit size from 8 to 16 bits.
However, it is sensitive to extend the memory size in common structure
like tree or rtx. This patch would like to extend the machine mode bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79191
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed|2017-08-28 00:00:00 |2023-5-11
--- Comment #8 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64731
--- Comment #6 from Andrew Pinski ---
On the trunk we get at -O2:
.L2:
leaq(%rdi,%rax), %rcx
leaq(%rsi,%rax), %rdx
movapd (%rdx), %xmm0
addpd (%rcx), %xmm0
movaps %xmm0, -64(%rsp)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
--- Comment #4 from Andrew Pinski ---
Using:
typedef uint64_t ua64_t __attribute__((aligned(1), may_alias));
#define UNALIGNED_LOAD64(_p) (*reinterpret_cast(_p))
#define UNALIGNED_STORE64(_p, _val) (*reinterpret_cast(_p) = (_val))
Does fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
--- Comment #3 from Andrew Pinski ---
The second issue an buffer overflow:
-O0 -fsanitize=undefined -fsanitize=address, we get:
/app/example.cpp:19:9: runtime error: store to misaligned address
0x7f4fad20002c for type 'uint64_t', which
On 5/11/23 10:39 PM, Po Lu wrote:
>> If so, then as far as I can tell, that was the original plan? The flag
>> already exists, even. And the original proposal was to provide another
>> flag that doesn't even restrict you to c89.
>
> And what will guarantee this ``always'' always remains true?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109789
--- Comment #4 from alex at zrythm dot org ---
I have simplified the test source file using cvise. This can now be reproduced
with:
```
LANG=C gcc -fanalyzer -Werror=analyzer-use-of-uninitialized-value -c
audio_exporter6.c.i
```
Committed to trunk.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Kito Cheng via Gcc-patches
Sent: Friday, May 12, 2023 11:00 AM
To: 钟居哲
Cc: GCC Patches ; Palmer Dabbelt ;
Jeff Law ; Robin Dapp
Subject: Re: [PATCH V3] RISC-V: Add basic vec_init for VLS RVV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109789
alex at zrythm dot org changed:
What|Removed |Added
Attachment #55028|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
--- Comment #2 from Xionghu Luo (luoxhu at gcc dot gnu.org) ---
(In reply to Andrew Pinski from comment #1)
> Two issues which make this undefined. First the unaligned macros still use
> aligned types which gcc uses for alignment of the pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109789
alex at zrythm dot org changed:
What|Removed |Added
Attachment #55029|0 |1
is obsolete|
From: Juzhe-Zhong
After update local codebase to the trunk. I realize there is one more fail in
RV32.
After this patch, all fails of RVV are cleaned up.
Thanks.
FAIL: gcc.target/riscv/rvv/autovec/vmv-imm-rv64.c -O3 -ftree-vectorize (test
for excess errors)
Excess errors:
cc1: error: ABI
On 5/11/23 10:08 PM, Po Lu wrote:
>> I do not consider that you are being told what to do with your code.
>> Your code is not being broken. You may have to update your Makefile to
>
>
> My code is being broken. There are
Po Lu via Gcc writes:
> Eli Schwartz writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is
I have remove comments related to LLVM and reorg testcases:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618256.html
V3 can you take a look again.
Sorry for sending wrong comments in changelog. Well, I goal is not to disparage
LLVM.
I am just used to reading the LLVM implementation while
Ok
於 2023年5月12日 週五 10:57 寫道：
> From: Juzhe-Zhong
>
> #include
>
> typedef int8_t vnx16qi __attribute__((vector_size (16)));
>
> #include
>
> typedef int8_t vnx16qi __attribute__ ((vector_size (16)));
> typedef int8_t vnx32qi __attribute__ ((vector_size (32)));
> typedef int8_t vnx64qi
Po Lu via Gcc writes:
> Eli Schwartz writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
From: Juzhe-Zhong
#include
typedef int8_t vnx16qi __attribute__((vector_size (16)));
#include
typedef int8_t vnx16qi __attribute__ ((vector_size (16)));
typedef int8_t vnx32qi __attribute__ ((vector_size (32)));
typedef int8_t vnx64qi __attribute__ ((vector_size (64)));
typedef int8_t
On Thu, May 11, 2023 at 10:39 PM Po Lu via Gcc wrote:
>
> Eli Schwartz writes:
>
> > This discussion thread is about having very good technical reasons -- as
> > explained multiple times, including instances where you agreed that the
> > technical reasons were good.
> >
> > Furthermore, even
Po Lu writes:
> Sam James writes:
>
>> And I would not want to see that happen either, nor do I think Florian
>> would, or many of the other participants in this thread.
>>
>> Indeed, for some projects, where it's hopeless^Wlots of work,
>> we're using -std=c89 or -std=gnu89 as appropriate -
Sam James writes:
> And I would not want to see that happen either, nor do I think Florian
> would, or many of the other participants in this thread.
>
> Indeed, for some projects, where it's hopeless^Wlots of work,
> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>
> But
Eli Schwartz writes:
> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>
> The argument is that on newer values for -std (such as the one GCC
> defaults to if no -std is specified), GCC should adapt its diagnostics
> better for the std in question. These
Eli Schwartz writes:
> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.
>
> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not
Arsen Arsenović writes:
> Indeed they should be - but warning vs. error holds significance. A
> beginner is much less likely to be writing clever code that allegedly
> uses these features properly than to be building new code, and simply
> having made an error that they do not want and will
From: Pan Li
1. This patch is moving binary autovec testcases into binop directory to
make it
easier to maintain.
2. Current binary autovec only tested in LMUL = 1, enable testing in
LMUL = 2/4/8.
Tested on both rv32/rv64, with no fails in RVV.
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109821
Bug ID: 109821
Summary: vect: Different output with -O2 -ftree-loop-vectorize
compared to -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
From: Pan Li
In rv32:
FAIL: gcc.target/riscv/rvv/autovec/vmax-rv64gcv.c -O3 -ftree-vectorize
(test for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vmin-run.c -O3 -ftree-vectorize (test
for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vadd-rv64gcv.c -O3 -ftree-vectorize
(test for
> This patch makes vec_init support common init vector handling (using
> vslide1down to insert element)
> which can handle any cases of initialization vec but it's not optimal for
> cases.
>
> And support Case 1 optimizaiton:
> https://godbolt.org/z/Yb9PK9jsz
Don't use godbolt link in comment,
ok, thanks :)
On Fri, May 12, 2023 at 9:04 AM juzhe.zh...@rivai.ai
wrote:
>
> This patch has tested on both RV32/RV64, and all fails in RVV are cleaned up.
> Ok for trunk?
>
>
>
> juzhe.zh...@rivai.ai
>
> From: juzhe.zhong
> Date: 2023-05-12 07:29
> To: gcc-patches
> CC: kito.cheng; palmer;
OK
On Fri, May 12, 2023 at 9:03 AM wrote:
>
> From: Juzhe-Zhong
>
> 1. This patch is moving binary autovec testcases into binop directory to make
> it
> easier to maintain.
>
> 2. Current binary autovec only tested in LMUL = 1, enable testing in LMUL =
> 2/4/8.
>
> Tested on both rv32/rv64,
Eli Schwartz writes:
> I expect no such thing, but I do expect that people making decisions in
> the real world acknowledge that ***they*** (and no one else) made those
> decisions of their own volition.
>
> I am unsure what "decisions made in the real world" has to do with my
> observation that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108757
--- Comment #22 from Jiu Fu Guo ---
(In reply to Andrew Pinski from comment #21)
> (In reply to Jiu Fu Guo from comment #20)
> > Interesting thing:
> > the VR is always VR_VARYING, even for the below simple case:
> >
> > typedef unsigned long
From: Pan Li
The decl_or_value is defined as void * before this PATCH. It will take
care of both the tree_node and rtx_def. Unfortunately, given a void
pointer cannot tell the input is tree_node or rtx_def.
Then we have some implicit structure layout requirement similar as
below. Or we will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #11
Arsen Arsenović writes:
> Seems that the algorithm and I agree. I don't see any use in the int()
> guess that the compiler does, besides accepting old code (which makes it
> candidate for -fpermissive).
I believe:
extern int foo ();
covers at least 50% of all C functions, since they are
LGTM, thanks :)
Palmer Dabbelt 於 2023年5月12日 週五 06:32 寫道：
> The vector shift immediates happen to have the same constraints as some
> of the CSR-related operands, but it's a different usage. This adds a
> name for them, so I don't get confused again next time.
>
> gcc/ChangeLog:
>
> *
From: Juzhe-Zhong
Rebase to trunk.
This is patching is adding basic vec_init support for RVV auto-vectorization.
This patch has been full coverage tested.
This patch makes vec_init support common init vector handling (using
vslide1down to insert element)
which can handle any cases of
This patch has tested on both RV32/RV64, and all fails in RVV are cleaned up.
Ok for trunk?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-05-12 07:29
To: gcc-patches
CC: kito.cheng; palmer; jeffreyalaw; Juzhe-Zhong
Subject: [PATCH] RISC-V: Fix RVV binary auto-vectorizaiton test fails
From: Juzhe-Zhong
1. This patch is moving binary autovec testcases into binop directory to make it
easier to maintain.
2. Current binary autovec only tested in LMUL = 1, enable testing in LMUL =
2/4/8.
Tested on both rv32/rv64, with no fails in RVV.
Ok for trunk ?
gcc/testsuite/ChangeLog:
Hi Joseph, Kees,
On 5/12/23 00:52, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
>
>> Okay, understood. If this is a C-only thing, we can ignore the C++
>> impact.
>
> We're a lot more careful lately in WG14 about checking for C++
> compatibility issues and expecting
On 5/12/23 01:58, Yair Lenga via Gcc wrote:
Hi,
I wonder if it will be possible to add support for "scoped" enum to GCC.
The current C standard has one name space for all enums, and different name
space for the members of each "struct". As a result, possible to say
struct foo { int a } ;
Hi,
Yair Lenga via Gcc writes:
> I wonder if it will be possible to add support for "scoped" enum to GCC.
> The current C standard has one name space for all enums, and different name
> space for the members of each "struct". As a result, possible to say
>
> struct foo { int a } ;
> struct bar
Hi,
I wonder if it will be possible to add support for "scoped" enum to GCC.
The current C standard has one name space for all enums, and different name
space for the members of each "struct". As a result, possible to say
struct foo { int a } ;
struct bar { double a }; // This is different
On Thu, 11 May 2023 at 21:20, Jonathan Wakely via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Tested powerpc64le-linux. Pushed to trunk.
>
> I don't plan to backport the assertions, because they're an API change
> that isn't suitable for the branches. But removing _Alloc_traits_impl
> and
From: Juzhe-Zhong
In rv32:
FAIL: gcc.target/riscv/rvv/autovec/vmax-rv64gcv.c -O3 -ftree-vectorize (test
for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vmin-run.c -O3 -ftree-vectorize (test for
excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vadd-rv64gcv.c -O3 -ftree-vectorize (test
From: Juzhe-Zhong
In rv32:
FAIL: gcc.target/riscv/rvv/autovec/vmax-rv64gcv.c -O3 -ftree-vectorize (test
for excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vmin-run.c -O3 -ftree-vectorize (test for
excess errors)
FAIL: gcc.target/riscv/rvv/autovec/vadd-rv64gcv.c -O3 -ftree-vectorize (test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
--- Comment #5 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:c787f593e62869ae0b230949b4791f4f3a26e50e
commit r14-743-gc787f593e62869ae0b230949b4791f4f3a26e50e
Author: Gaius Mulley
Date: Fri
Hi, Richards.
Could you take a look at this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618241.html
Thanks
juzhe.zh...@rivai.ai
From: Richard Sandiford
Date: 2023-05-11 20:42
To: juzhe.zhong\@rivai.ai
CC: gcc-patches; rguenther
Subject: Re: [PATCH V4] VECT: Add decrement IV
From: Ju-Zhe Zhong
1. Fix document description according Jeff && Richard.
2. Add LOOP_VINFO_USING_SELECT_VL_P for single rgroup.
3. Add LOOP_VINFO_USING_SLP_ADJUSTED_LEN_P for SLP multiple rgroup.
Fix bugs for V5 after testing:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618209.html
On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> Okay, understood. If this is a C-only thing, we can ignore the C++
> impact.
We're a lot more careful lately in WG14 about checking for C++
compatibility issues and expecting approval from the liaison group for
anything with possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Christoph Reiter changed:
What|Removed |Added
CC||reiter.christoph at gmail dot
com
On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> Please be serious, and please don't mock your opponents. This is a
> serious discussion of a serious subject, not a Twitter post.
I responded with precisely the degree of seriousness as the statement I
responded to.
For the record, I believe both
On 5/11/23 2:18 AM, Po Lu wrote:
> Eli Schwartz writes:
>> Absolutely! It's a very good point. It's a point that people writing
>> traditional not-C in this day and age are doing so with highly complex
>> toolchains they have personally written to do things that no non-bespoke
>> toolchain does.
Snapshot gcc-11-20230511 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/11-20230511/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Eli Schwartz via Gcc writes:
> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>>> Date: Wed, 10 May 2023 23:14:20 -0400
>>> From: Eli Schwartz via Gcc
>>>
>>> Second of all, why is this GCC's problem? You are not a user of GCC,
>>> apparently.
>>
>> He is telling you that removing support for these
LGTM
juzhe.zh...@rivai.ai
From: Palmer Dabbelt
Date: 2023-05-12 06:31
To: juzhe.zhong
CC: gcc-patches; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Add v_uimm_operand
On Thu, 11 May 2023 15:00:48 PDT (-0700), juzhe.zh...@rivai.ai wrote:
>>> ;; V has 32-bit unsigned immediates. This happens to
On Thu, 11 May 2023 15:00:48 PDT (-0700), juzhe.zh...@rivai.ai wrote:
;; V has 32-bit unsigned immediates. This happens to be the same constraint asIt
should be 5-bit unsigned immediates>> ; the csr_operand, but it's not CSR
related.
(define_predicate "v_uimm_operand"
(match_operand 0
The vector shift immediates happen to have the same constraints as some
of the CSR-related operands, but it's a different usage. This adds a
name for them, so I don't get confused again next time.
gcc/ChangeLog:
* config/riscv/autovec.md (shifts): Use
On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>> Date: Wed, 10 May 2023 23:14:20 -0400
>> From: Eli Schwartz via Gcc
>>
>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
>
> He is telling you that removing support for these old features, you
> draw users away from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #7 from Jonathan Wakely ---
Some of the libstdc++ changes in
https://aur.archlinux.org/cgit/aur.git/tree/gcc-djgpp.diff?h=dosbox-gcc would
be great to upstream.
On Thu, May 11, 2023 at 09:43:49PM +, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
>
> > Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> > question is: what's needed to support the idea of a zero-sized object?
>
> Zero-sized objects break
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #37 from joseph at codesourcery dot com ---
If _BitInt constants aren't INTEGER_CST, then all places that expect that
any integer constant expression is folded to an INTEGER_CST will need
updating to handle whatever tree code is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
--- Comment #4 from Gaius Mulley ---
The patch improves the error virtual token accuracy, for example:
$ gm2 -g highice.mod
highice.mod:6:6: error: string constant ‘12’ is too large to be assigned to the
array ‘a’
6 |a := '12'
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109810
--- Comment #3 from Gaius Mulley ---
Created attachment 55059
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55059=edit
Proposed fix
Here is a proposed patch with test code which has successfully bootstrapped on
x86_64 linux.
>> ;; V has 32-bit unsigned immediates. This happens to be the same
>> constraint asIt should be 5-bit unsigned immediates>> ; the csr_operand,
>> but it's not CSR related.
>> (define_predicate "v_uimm_operand"
>> (match_operand 0 "csr_operand"))
To make name consistent, it should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109819
--- Comment #2 from Tobias Burnus ---
The not-doing LTO sounds as if we want to handle this by passing some arg that
gets processed in
lto-plugin/lto-plugin.c's process_option
possibly besides other places that need to be updated.
On Mon, 27 Mar 2023 at 22:25, Weslley da Silva Pereira via Libstdc++ <
libstd...@gcc.gnu.org> wrote:
> Dear all,
>
> Here follows a patch that removes implicit type casts in std::complex.
>
> *Description:* The current implementation of `complex<_Tp>` assumes that
> `int, double, long double` are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109819
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109820
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> Why are zero-sized objects missing in Standard C? Or, perhaps, the better
> question is: what's needed to support the idea of a zero-sized object?
Zero-sized objects break the principle that different objects have
different addresses, and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109820
Bug ID: 109820
Summary: False-positive in tautological-compare
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #8 from Tobias Burnus ---
First, I want to remark that inside lto_output_toplevel_asms,
lto_stream_offload_p is true even with -flto.
However, the following is for output_symtab:
(In reply to Jakub Jelinek from comment #7)
> Not
Hi Florian,
On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote:
> * alleged code generation bugs because the upper 32 bits of a pointer
> are set to zero or 0x, resulting in crashes. This can happen
> if GCC synthesizes an implicit int declaration for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #6 from Janez Zemva ---
There are a lot of patches and I never went over all of them. I'll take another
look and update my bug report, if necessary (I think you're probably right).
But, should anyone else want to, the build script
On Thu, 11 May 2023 at 21:25, Jason Merrill wrote:
> On 5/9/23 08:07, Alex Coplan wrote:
> > This patch implements clang's __has_feature and __has_extension in GCC.
>
> Thanks!
>
> > Currently the patch aims to implement all documented features (and some
> > undocumented ones) following the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109819
Bug ID: 109819
Summary: [OpenMP][OpenACC] -fno-lto effectively disables
offloading
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openacc, openmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #5 from Jonathan Wakely ---
And the $build-dir/$target/libstdc++-v3/config.log file should show the output
from this:
AC_MSG_NOTICE("C" header strategy set to $enable_cheaders)
That would confirm if it's being set to c_std
On Thu, May 11, 2023 at 08:53:52PM +, Joseph Myers wrote:
> On Thu, 11 May 2023, Kees Cook via Gcc wrote:
>
> > On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > > On 5/11/23 18:07, Alejandro Colomar wrote:
> > > [...]
> > > > Would you allow flexible array members in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #4 from Jonathan Wakely ---
Hmm, I don't see anything in the configure scripts that would cause c_std to be
used implicitly for djgpp (or any other target). Maybe there's a local patch
applied to the djgpp copy of GCC sources?
It
Eli Zaretskii writes:
>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Thu, 11 May 2023 10:44:47 +0200
>> From: Arsen Arsenović via Gcc
>>
>> the current default of accepting this code in C is harmful to those
>> who are writing new code, or are learning C.
>
> People who learn C should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #7 from Jakub Jelinek ---
Not
--- gcc/lto-cgraph.cc 2023-01-09 13:30:47.105343886 +0100
+++ gcc/lto-cgraph.cc 2023-05-11 23:05:54.266991677 +0200
@@ -1023,7 +1023,8 @@ output_symtab (void)
if (!asm_nodes_output)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #3 from Janez Zemva ---
I am the "maintainer" of this dosbox-gcc aur (mostly I just borrow from other
builds). I have told the DJGPP community about this issue 2 times and they
shrugged it off, since they mostly compile .c source
On Thu, 11 May 2023, Kees Cook via Gcc wrote:
> On Thu, May 11, 2023 at 06:29:10PM +0200, Alejandro Colomar wrote:
> > On 5/11/23 18:07, Alejandro Colomar wrote:
> > [...]
> > > Would you allow flexible array members in unions? Is there any
> > > strong reason to disallow them?
>
> Yes please!!
On Thu, 11 May 2023 at 13:42, Jonathan Wakely wrote:
>
>
> On Thu, 11 May 2023 at 13:19, Mike Crowe wrote:
>
>> However, ...
>>
>> > > diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
>> > > index 89e7f5f5f45..e2700b05ec3 100644
>> > > --- a/libstdc++-v3/acinclude.m4
>> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109816
--- Comment #6 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #5)
> The above can work only if toplevel asms are in separate section and so
> inputting it or not doesn't affect input of other data.
> I think it would be better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #9 from Amyspark ---
(In reply to Andrew Pinski from comment #7)
> Simple testcase:
> ```
> struct basic_string {
> ~basic_string() { }
> };
> const basic_string data[] = { {} };
> ```
>
> This fails with `ulimit -s 1024` which
On Wed, 22 Mar 2023, Jonathan Wakely via Gcc-patches wrote:
> We don't currently have a single page where you can find out when
> support for a given standard became non-experimental (you have to look
> through all the gcc-X/changes.html pages to find it). I think we should
> have that info on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
Patrick Palka changed:
What|Removed |Added
Summary|[13/14 Regression] |[13 Regression] Incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:02777f20be4f40160f1b4ed34fa59ba75245b5b7
commit r14-742-g02777f20be4f40160f1b4ed34fa59ba75245b5b7
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943
--- Comment #8 from Alexander Monakov ---
Ah, forgot to mention that compiler the offending User.cpp without -flto also
avoids the problem.
1 - 100 of 414 matches
Mail list logo
