sa8210...@yahoo.com
Yahoo Mail: Search, Organize, Conquer
changed it to deprecated instead of warning, since
that's available on all compilers we support, but that breaks on clang
and VC because they seem to not do so well with redeclaring standard
library functions. I only have one card left up my sleeve, and that's
to use decltype:
[[deprecat
s
> results in the link step failing if LTO is enabled for some reason
> though. I then changed it to deprecated instead of warning, since
> that's available on all compilers we support, but that breaks on clang
> and VC because they seem to not do so well with redeclaring standard
&
On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
>
> Hi Jonathan,
>
> Yep, unfortunately #pragma GCC poison is far too restrictive, it
> doesn't check if it is a function call to that particular banned
> function, it restricts any and all use of that identifier in the code
> altogether. Not only
On Mon, 14 Apr 2025 at 12:57, Jonathan Wakely wrote:
>
> On Mon, 14 Apr 2025 at 11:53, Julian Waters wrote:
> >
> > Hi Jonathan,
> >
> > Yep, unfortunately #pragma GCC poison is far too restrictive, it
> > doesn't check if it is a function call to that particular banned
> > function, it restricts
ng the whole process.
>
> It would be nice to have compiler support to help with this.
I would recommend writing your GCC plugin which would add some problem specific
pragmas.
Some code from https://github.com/bstarynk/bismon might be improved (by you or
your colleagues/interns) to fit into lat
nctions. The crucial thing is that this mechanism must have a
> > disable switch for when a callsite must actually call a forbidden
> > function, complicating the whole process.
> >
> > It would be nice to have compiler support to help with this. Something like:
> >
>
callsite must actually call a forbidden
> function, complicating the whole process.
>
> It would be nice to have compiler support to help with this. Something like:
>
> #pragma GCC forbidden void *malloc(size_t) // Forbids malloc from
> being called anywhere
Have you looked at
ement that.
The problem is there's really no way at all to forbid standard library
functions. The crucial thing is that this mechanism must have a
disable switch for when a callsite must actually call a forbidden
function, complicating the whole process.
It would be nice to have compiler
Hi,
I know that PDB support has been worked on in binutils. I thinkt
he missing piece is to get GCC to emit CodeView debug information that
binutils will turn into a PDBm (not sure if the work is complete in
binutils, either).
What's the status of this? I ask because our WIndows offeri
Hi Pau!
On 2025-03-19T21:53:22-0400, Pau Sum via Gcc wrote:
> Hey GCC Community,
Welcome to GCC!
> I am interested in contributing to the "Enhance OpenACC Support" project for
> Google Summer of Code 2025.
Thanks for your interest!
I saw you also briefly discussed on GCC
Hi Thomas,
Thanks for your detailed response! I've updated the proposal based on the
feedback. Please kindly check it out. Thanks a lot!
Project Goals and Tasks
GCC currently only partially supports the features specified in OpenACC
2.6. This project aims to enhance GCC's OpenACC supp
> or OpenACC prefetch logic could be integrated into it.
..., or even just synthesizing specific (GIMPLE?) constructs, so that the
existing pass can do its work -- in case that the pass' existing support
maps to (at least specific instances of) the functionality provided by
the respective offloadin
ce transfers. For
acc_memcpy_device, which handles device-to-device transfers, we should
design a similar logic. Further investigation is needed to structure and
implement this functionality effectively.
*2. Support for **init**, **shutdown**, and **set** Directives*
These directives are currently un
On 3/24/25 9:51 PM, Tom Kacvinsky via Gcc wrote:
Hi,
I know that PDB support has been worked on in binutils. I thinkt
he missing piece is to get GCC to emit CodeView debug information that
binutils will turn into a PDBm (not sure if the work is complete in
binutils, either).
What'
ng on a medium-sized (or
> large-sized) project that, broadly speaking, extends the static-analysis
> pass(es). In particular, I’ve been dabbling between extending the analyzer’s
> support for C++ and extending the plugin to add checking for usage of the
> CPython API, such as refere
pass(es). In particular, I’ve been dabbling between extending the
analyzer’s support for C++ and extending the plugin to add checking for
usage of the CPython API, such as reference counting. Both topics can be
found in the [ideas list](https://gcc.gnu.org/wiki/SummerOfCode).
Nevertheless, I haven’t
Hey GCC Community,
I am interested in contributing to the "Enhance OpenACC Support" project for
Google Summer of Code 2025. In particular, I am excited about implementing
acc_memcpy_device and the #pragma acc cache directive.
To prepare, I have started reviewing the OpenACC 2.6 spe
fload-options=nvptx-none=-march=sm_30': [...]
>
> [...] I'll be happy to
> implement (3b) if people think that's still helpful.
>
> In fact, (3b) can then generally support 'configure'-time selection of
> further multilib variants to be built (for example,
> &
Many of the GNU toolchain projects are adding zstd compression. This
is good, but the configure support for this is not ideal.
In particular for GCC, there are a number of issues.
The first problem is that the two subdirectories that use zstd
(libbacktrace and gcc) use very different methods to
about attributes.
Thanks,
Richard
When this feature makes it into GCC, then match_test should behave
similar, I guess? I.e. support function bodies that return bool.
I just wasn't sure which caller of fprint_c_condition runs with
match_test resp. symbol_ref from which context (insn attr
OK, I pushed b19906a029a to remove the enum tags. The type name is
now stored as a const char * in attr_desc::cxx_type.
>> If we do that, then we can just a return a const char * for the type.
>
> Yes, const char* would be easier. I just didn't know how to alloc one,
> and whe
stion / proposal and not a patch.
IMO patches should not come from someone like me who has no experience
in that area; better someone more experienced would take it over.
it causes anything to break, I think we should fix whatever that breaking
thing is. Could you try doing that, as a pre-patch?
Georg-Johann Lay writes:
> So I had that situation where in an insn attribute, providing
> a block of code (rather than just an expression) would be
> useful.
>
> Expressions can provided by means of symbol_ref, like in
>
> (set (attr "length")
> (symbol_ref ("1 + GET_MODE_SIZE (mode)")))
>
So I had that situation where in an insn attribute, providing
a block of code (rather than just an expression) would be
useful.
Expressions can provided by means of symbol_ref, like in
(set (attr "length")
(symbol_ref ("1 + GET_MODE_SIZE (mode)")))
However providing a block of code gives a
On Fri, 2024-06-21 at 18:46 -0400, Eric Gallager wrote:
> On Fri, Jun 21, 2024 at 12:12 PM David Malcolm via Gcc
> wrote:
> >
> > I've create a wiki page to track our support for GCC:
> > https://gcc.gnu.org/wiki/SARIF
> >
> > and a keyword "SAR
On Fri, Jun 21, 2024 at 12:12 PM David Malcolm via Gcc wrote:
>
> I've create a wiki page to track our support for GCC:
> https://gcc.gnu.org/wiki/SARIF
>
> and a keyword "SARIF" in our bugzilla instance for bugs relating to it
> (see links on the above page).
I've create a wiki page to track our support for GCC:
https://gcc.gnu.org/wiki/SARIF
and a keyword "SARIF" in our bugzilla instance for bugs relating to it
(see links on the above page).
Dave
On 6/4/24 8:51 PM, Erick Kuo-Chen Huang(黃國鎭) via Gcc-help wrote:
Hi,
We would like to know which GCC version start to support RISC-V RVV1.0 ?
We appreciate for your help.
gcc-14.
Jeff
Hi,
We would like to know which GCC version start to support RISC-V RVV1.0 ?
We appreciate for your help.
Best Regards,
Erick
CONFIDENTIALITY NOTICE:
This e-mail (and its attachments) may contain confidential and legally
privileged information or information protected from disclosure. If you
On Wed, 24 Apr 2024, Krishna Narayanan via Gcc wrote:
> Hi all,
> Is the RISC-V community planning to add support for trapping math in RISC-V
> in the near future!?
> This LLVM thread
> https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7 suggests a
> software emulatio
Hi all,
Is the RISC-V community planning to add support for trapping math in RISC-V
in the near future!?
This LLVM thread
https://discourse.llvm.org/t/trapping-math-for-risc-v/72168/7 suggests a
software emulation of traps, is the GNU team also on similar lines to this
implementation or has some
On 4/18/24 13:41, Arnd Bergmann wrote:
On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote:
On Wed, 17 Apr 2024, Sandra Loosemore wrote:
Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
support from all toolchain components after the release is made. I'
On 4/18/24 8:41 PM, Arnd Bergmann wrote:
On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote:
On Wed, 17 Apr 2024, Sandra Loosemore wrote:
Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
support from all toolchain components after the release is made. I'
On Thu, Apr 18, 2024, at 17:44, Joseph Myers wrote:
> On Wed, 17 Apr 2024, Sandra Loosemore wrote:
>
>> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
>> support from all toolchain components after the release is made. I'm not
>> sure
On 4/18/24 10:06, Jeff Law wrote:
ACK. Just one more note to the wider audience. I looked at QEMU's user
mode support for nios2 on/off over the last couple years. It never
seemed to work well enough be able to run the GCC testsuite reliably.
I looked at the problems with the nios2
On 4/18/24 9:57 AM, Joel Sherrill wrote:
On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers <mailto:josmy...@redhat.com>> wrote:
On Wed, 17 Apr 2024, Sandra Loosemore wrote:
> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and
remove
&
On Thu, Apr 18, 2024 at 10:46 AM Joseph Myers wrote:
> On Wed, 17 Apr 2024, Sandra Loosemore wrote:
>
> > Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
> > support from all toolchain components after the release is made. I'm
> not s
On Wed, 17 Apr 2024, Sandra Loosemore wrote:
> Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and remove
> support from all toolchain components after the release is made. I'm not sure
> there is an established process for obsoleting/removing support in other
&g
;s time to pull the plug.
Therefore I'd like to mark Nios II as obsolete in GCC 14 now, and
remove support from all toolchain components after the release is
made. I'm not sure there is an established process for
obsoleting/removing support in other components; besides binutils,
GDB
'd like to mark Nios II as obsolete in GCC 14 now, and remove
support from all toolchain components after the release is made. I'm not
sure there is an established process for obsoleting/removing support in
other components; besides binutils, GDB, and GLIBC, there's QEMU,
newlib/
C 14 now, and remove
support from all toolchain components after the release is made. I'm
not sure there is an established process for obsoleting/removing support
in other components; besides binutils, GDB, and GLIBC, there's QEMU,
newlib/libgloss, and the Linux kernel. But, we
ware Engineer at Qualcomm
> Wireless R&D. I recently discovered your organization and the exciting GSOC
> projects you are proposing, namely "Offloading to a separate process on the
> same host" and "Enhance OpenACC support." I am writing to express my
> enthusi
d the exciting GSOC
projects you are proposing, namely "Offloading to a separate process on the
same host" and "Enhance OpenACC support." I am writing to express my
enthusiastic interest in potentially contributing to either of these
projects and to inquire about the next steps to
Control: merge 1064476 1058665 1058664
I would even love to have finally a debian again which can be used to
debug and profile production ready binaries (at least on amd64). See
also
*
https://www.brendangregg.com/blog/2024-03-17/the-return-of-the-frame-pointers.html
*
https://ubuntu.com/blog/u
Gcc
> wrote:
> > > >
> > > > -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> > > > not even supported with LTO. Does it make sense to deprecate the
> > > > support for GCC 14 and remove it in GCC 15?
> > > >
> &
On Mon, Dec 18, 2023 at 2:35 AM Andrew Pinski via Gcc wrote:
>
> On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager wrote:
> >
> > On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc
> > wrote:
> > >
> > > -fgnu-tm support has not been improved si
On Sun, Dec 17, 2023 at 1:20 PM Eric Gallager wrote:
>
> On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc wrote:
> >
> > -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> > not even supported with LTO. Does it make sense to deprecate the
&g
On Sat, Dec 16, 2023 at 3:16 PM Andrew Pinski via Gcc wrote:
>
> -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> not even supported with LTO. Does it make sense to deprecate the
> support for GCC 14 and remove it in GCC 15?
>
> Thanks,
> Andrew Pinski
On Sun, Dec 17, 2023 at 8:26 AM Florian Weimer wrote:
>
> * Andrew Pinski via Gcc:
>
> > -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> > not even supported with LTO. Does it make sense to deprecate the
> > support for GCC 14 and remove it in GC
* Andrew Pinski via Gcc:
> -fgnu-tm support has not been improved since GCC 5 or earlier. It is
> not even supported with LTO. Does it make sense to deprecate the
> support for GCC 14 and remove it in GCC 15?
Is this the stuff around libitm and that adds _ITM_registerTMClone
-fgnu-tm support has not been improved since GCC 5 or earlier. It is
not even supported with LTO. Does it make sense to deprecate the
support for GCC 14 and remove it in GCC 15?
Thanks,
Andrew Pinski
On Wed, 2023-11-15 at 08:23 +, Taisei Katô via Gcc wrote:
> Dear GCC developers,
>
> There is a typo in Section "C++14 Support in GCC" in "C++ Standards
> Support in GCC."<https://gcc.gnu.org/projects/cxx-status.html#cxx14>
> "GCC has full suppo
Dear GCC developers,
There is a typo in Section "C++14 Support in GCC" in "C++ Standards Support in
GCC."<https://gcc.gnu.org/projects/cxx-status.html#cxx14>
"GCC has full support for the of the 2014 C++ standard."
Yours sincerely,
Katô Taisei
gcc's assembler has had support for Windows style Structured Exception
Handling for a while now, it would be useful if gcc itself had support for
catching hardware faults on Windows through this mechanism as well (For
example, the Java HotSpot VM will simply not work on Windows without
suppor
On Wed, 1 Nov 2023 at 09:45, Vishal B Patil wrote:
>
> Hi team,
>
> I'm using Mingw win32. My total code size is around 82MB. I'm getting error
> while compilation "out of memory allocating 48 bytes" , I have attached the
> snap for your reference.
>
> I have cleaned temp folder but not solved,
Hello Toon,
the implementation is not finished, we have just made some tests for now.
If no one sees huge problems with this new approach, we will continue to
implement and stabilize it.
Thank you for your interest !
Sylvain
On 10/17/23 22:37, Toon Moene wrote:
Sylvain,
Is this on a branc
Sylvain,
Is this on a branch in your github repository
https://github.com/kalray/gcc
somewhere ?
That would make it easier to test it for me (and probably others).
See for instance my mail here (d.d. Thu Oct 5 14:45:05 GMT 2023):
https://gcc.gnu.org/pipermail/gcc/2023-October/242643.
Hi,
We are trying to update our patches on complex numbers to take into
account what has been discussed.
The main change from our previous patches consists of replacing vectors
of complex types with classical vectors of real types (ex V4SF instead
of V2SC) associated with existing complex op
On Tue, Oct 10, 2023 at 2:43 PM Joern Rennecke
wrote:
>
> I'm working on implementing hardware loops for the CORE-V CV32E40P
> https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/corev_hw_loop.html
>
> This core supports nested hardware lops, but does not allow any other flow
> co
I'm working on implementing hardware loops for the CORE-V CV32E40P
https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/corev_hw_loop.html
This core supports nested hardware lops, but does not allow any other flow
control inside hardware loops. I found that our existing interfaces
On 9/26/23 20:40, Toon Moene wrote:
/On 9/26/23 09:30, Richard Biener via Gcc wrote: />>//>>>/On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc />>>/ wrote: />>///As I said at the end of the presentation, we have written a paper which //explains //our implementation in details. Yo
On 9/26/23 20:40, Toon Moene wrote:
On 9/26/23 09:30, Richard Biener via Gcc wrote:
On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc
wrote:
As I said at the end of the presentation, we have written a paper which
explains
our implementation in details. You can find it on the wiki page
Hello list,
i work for a companie that is heavy user of gcc C-compiler (Intel &arm). We
were ask for projects and i would
like to support the C-compiler. (not personaly but providing support for a
project).
Does someone feel competent so we can discuss what is doable ? (e.g. I would
hav
On 9/26/23 09:30, Richard Biener via Gcc wrote:
On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc wrote:
As I said at the end of the presentation, we have written a paper which
explains
our implementation in details. You can find it on the wiki page of the
Cauldron
(https://gcc.gnu.org/w
On Mon, 25 Sep 2023, Sylvain Noiry via Gcc wrote:
> --> Idea: Add an attribute to the Tree complex type which specify pure real /
> pure
> imaginary / full complex ?
If you start from the implementation approach of lowering imaginary type
operations in the front end, a flag on a REAL_TYPE wou
; > > We had very interesting discussions during our presentation with Paul
> > > on the support of complex numbers in gcc at the Cauldron.
> > >
> > > Thank you all for your participation !
> > >
> > > Here is a small summary from our viewpoint:
&g
nu.org;
> > sylvain.no...@hotmail.fr
> > Subject: Re: Complex numbers support: discussions summary
> >
> > On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote:
> > > On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc
> > wrote:
> &g
> -Original Message-
> From: Gcc On Behalf
> Of Paul Iannetta via Gcc
> Sent: Tuesday, September 26, 2023 9:54 AM
> To: Richard Biener
> Cc: Sylvain Noiry ; gcc@gcc.gnu.org;
> sylvain.no...@hotmail.fr
> Subject: Re: Complex numbers support: discussions summary
&
On Tue, Sep 26, 2023 at 09:30:21AM +0200, Richard Biener via Gcc wrote:
> On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc wrote:
> >
> > Hi,
> >
> > We had very interesting discussions during our presentation with Paul on
> > the
> > support of
Hi,
I tried to find you two on Sunday but couldn't locate you. Thanks for the
presentation!
> >
> > We had very interesting discussions during our presentation with Paul
> > on the support of complex numbers in gcc at the Cauldron.
> >
> > Thank you all for y
On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc wrote:
>
> Hi,
>
> We had very interesting discussions during our presentation with Paul on
> the
> support of complex numbers in gcc at the Cauldron.
>
> Thank you all for your participation !
>
> Here is a sm
Hi,
We had very interesting discussions during our presentation with Paul on
the
support of complex numbers in gcc at the Cauldron.
Thank you all for your participation !
Here is a small summary from our viewpoint:
- Replace CONCAT with a backend defined internal representation in RTL
On Tue, Sep 19, 2023 at 17:33:34 -0400, Jason Merrill wrote:
> Pushed, thanks!
Thanks!
Is there a process I can use to backport this to GCC 13?
--Ben
On 9/1/23 09:04, Ben Boeckel wrote:
Hi,
This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not embarrassingly parallel and need
On Sun, 2023-09-10 at 22:12 -0400, Eric Feng wrote:
> On Thu, Sep 7, 2023 at 1:28 PM David Malcolm
> wrote:
>
> > On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote:
> >
[...snip...]
> >
> >
> > I know you're emulating the old behavior I implemented way back in
> > cpychecker, but I don't li
On Thu, Sep 7, 2023 at 1:28 PM David Malcolm wrote:
> On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote:
>
> > Hi Dave,
>
> Hi Eric, thanks for the patch.
>
> >
> > Recently I've been working on symbolic value support for the reference
> > count chec
On Mon, 2023-09-04 at 22:13 -0400, Eric Feng wrote:
> Hi Dave,
Hi Eric, thanks for the patch.
>
> Recently I've been working on symbolic value support for the reference
> count checker. I've attached a patch for it below; let me know it looks
> OK for trunk.
Hi Dave,
Recently I've been working on symbolic value support for the reference
count checker. I've attached a patch for it below; let me know it looks
OK for trunk. Thanks!
Best,
Eric
---
This patch enhances the reference count checker in the CPython plugin by
adding support fo
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Support is communicated through the following three new flags:
- `-fdeps-format=` specifies the format for the
Hi,
This patch series adds initial support for ISO C++'s [P1689R5][], a
format for describing C++ module requirements and provisions based on
the source code. This is required because compiling C++ with modules is
not embarrassingly parallel and need to be ordered to ensure that
`i
Hi David,
On Wed, Aug 30, 2023 at 1:01 AM David Malcolm wrote:
>
> > ?
>
> Yes; please submit it, so that we can work towards getting what you
> have into trunk.
>
> Given that we don't properly support C++ yet, improvements to C++
> support don't have t
On Mon, 2023-08-28 at 17:13 +0200, Benjamin Priour wrote:
> Hi,
>
> Test gcc.dg/analyzer/pr94362-1.c actually has an additional
> null_deref
> > warning in C++, which is not affected by exceptions
> > or optimizations. I will keep updated on that one. Note that no
> > warnings
> > are emitted for
value" that accompanies "null deref" of nothrow new
> variants
> ?
Yes; please submit it, so that we can work towards getting what you
have into trunk.
Given that we don't properly support C++ yet, improvements to C++
support don't have to be perfect.
>
>
Hi,
Test gcc.dg/analyzer/pr94362-1.c actually has an additional null_deref
> warning in C++, which is not affected by exceptions
> or optimizations. I will keep updated on that one. Note that no warnings
> are emitted for this test in C.
>
> analyzer/pr94362-1.c: In function ‘const EVP_PKEY_ASN1_M
Hi David,
Sorry I missed out on your answer about the operator new patch on the IRC.
Should I submit the first bit of the operator new patch ? Putting aside for
now fixing the
"uninitialized value" that accompanies "null deref" of nothrow new variants
?
About generalizing tests to C++, I'll soon
On 7/2/23 12:32, Ben Boeckel wrote:
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Support is communicated through the following three new flags:
- `-fdeps
Jonathan Wakely wrote:
>>
>> On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote:
>>>
>>> Luckily most of these aren’t problems for libc++. We only support the
>>> latest GCC. We can only use `if constexpr` in C++11, but that is already a
>>> win I
On Tue, 8 Aug 2023 at 17:07, Jonathan Wakely wrote:
>
> On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote:
> >
> > Luckily most of these aren’t problems for libc++. We only support the
> > latest GCC. We can only use `if constexpr` in C++11, but that is already a
>
On Tue, 8 Aug 2023 at 17:04, Nikolas Klauser wrote:
>
> Luckily most of these aren’t problems for libc++. We only support the latest
> GCC. We can only use `if constexpr` in C++11, but that is already a win I
> think.
Can you use it in C++11 though? The body of a constexpr functi
Luckily most of these aren’t problems for libc++. We only support the latest
GCC. We can only use `if constexpr` in C++11, but that is already a win I think.
Nikolas
> On Aug 8, 2023, at 12:33 AM, Jakub Jelinek wrote:
>
> On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klau
nsions-from-future-standards-in-libc/71898/4).
> > > > By that I mean things like using `if constexpr` with `-std=c++11`. GCC
> > > > has
> > > > quite a lot of these kinds of conforming extensions, but doesn't
> > > > document
> > > &
On Mon, Aug 07, 2023 at 08:03:05PM -0700, Nikolas Klauser wrote:
> Thanks for the answers!
>
> There are a few really interesting extensions that I would like to use:
>
> - inline variables
> - variable templates
> - `if constexpr`
> - fold expressions
> - conditional explicit
> - static operator
-from-future-standards-in-libc/71898/4).
By that I mean things like using `if constexpr` with `-std=c++11`.
GCC has quite a lot of these kinds of conforming extensions, but
doesn't document them AFAICT. While discussing using these
extensions, the question came up what GCCs supp
On Mon, 2023-08-07 at 15:04 +0200, Benjamin Priour wrote:
> Hi Dave,
[...snip...]
> Last test I'd like to discuss is analyzer/pr99193-1.c
>
[...snip...]
>
> If I comment out the call to perror("realloc"), then G++ behaves as
> GCC.
> If I replace perror ("realloc") by any other call, to a ful
On Mon, 2023-08-07 at 15:04 +0200, Benjamin Priour wrote:
> Hi Dave,
Hi Benjamin.
>
> I made some more progress on moving tests from gcc.dg/analyzer/ to
> c-c++-common/analyzer.
Thanks.
It sounds like you have a large amount of "pending" work that is
accumulating on your hard drive. This make
Hi Dave,
I made some more progress on moving tests from gcc.dg/analyzer/ to
c-c++-common/analyzer.
I'll only detail the most noteworthy tests I encountered.
gcc.dg/analyzer/pr103892.c troubled me with an Excess error when compiled
with g++
analysis bailed out early (91 'after-snode' enodes; 314 e
`-std=c++11`. GCC has
> > > quite a lot of these kinds of conforming extensions, but doesn't document
> > > them AFAICT. While discussing using these extensions, the question came up
> > > what GCCs support policy for these is. Aaron was kind enough to answer
> > &g
AFAICT. While discussing using these extensions, the question came up
> > what GCCs support policy for these is. Aaron was kind enough to answer
> > these questions for us on the Clang side. Since I couldn't find anything in
> > the documentation, I thought I'd ask
4).
> By that I mean things like using `if constexpr` with `-std=c++11`. GCC has
> quite a lot of these kinds of conforming extensions, but doesn't document
> them AFAICT. While discussing using these extensions, the question came up
> what GCCs support policy for these is. Aa
1 - 100 of 1883 matches
Mail list logo
