Snapshot gcc-12-20230901 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/12-20230901/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Thank you for the patch!
On Fri, Sep 1, 2023 at 10:51 AM David Malcolm wrote:
>
> On Fri, 2023-09-01 at 04:49 +0200, Hans-Peter Nilsson wrote:
> > (Looks like this was committed as r14-3580-g597b9ec69bca8a)
> >
> > > Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, Eric Feng
> > >
> > > From: Eric
> On Sep 1, 2023, at 12:35 PM, Tomas Bortoli via Gcc wrote:
>
> Hi,
>
> I recently discovered that the following C statement:
>
> pointer++;
>
> is semantically equivalent to the following:
>
> *pointer++;
>
> Is this due to operators' priority? To me, that looks weird.
Yes, https://en.c
On Fri, Sep 1, 2023 at 12:37 PM Tomas Bortoli via Gcc
wrote:
> Hi,
>
> I recently discovered that the following C statement:
>
> pointer++;
>
> is semantically equivalent to the following:
>
> *pointer++;
>
> Is this due to operators' priority? To me, that looks weird.
>
Equivalent in the effect
Hi,
I recently discovered that the following C statement:
pointer++;
is semantically equivalent to the following:
*pointer++;
Is this due to operators' priority? To me, that looks weird.
Thanks in advance,
Tomas
On Fri, 2023-09-01 at 04:49 +0200, Hans-Peter Nilsson wrote:
> (Looks like this was committed as r14-3580-g597b9ec69bca8a)
>
> > Cc: gcc@gcc.gnu.org, gcc-patc...@gcc.gnu.org, Eric Feng
> >
> > From: Eric Feng via Gcc
>
> > gcc/testsuite/ChangeLog:
> > PR analyzer/107646
> > * gcc.dg/p
Hi Jonathan,
On 2023-09-01 08:49, Jonathan Wakely wrote:
> On Thu, 31 Aug 2023, 17:05 Alejandro Colomar via Gcc,
> wrote:
>
>> Hi!
>>
>> I've been confused for some time with a compilation error that
>> pointed to a slightly-off location. I wasn't seeing that I used
>> a temporary variable in a
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 out
It affects the build, and if used as a static file, can reliably be
tracked using the `-MF` mechanism.
gcc/cp/:
* mapper-client.cc, mapper-client.h (open_module_client): Accept
dependency tracking and track module mapper files as
dependencies.
* module.cc (make_map
They affect the build, so report them via `-MF` mechanisms.
gcc/cp/
* module.cc (do_import): Report imported CMI files as
dependencies.
gcc/testsuite/
* g++.dg/modules/depreport-1_a.C: New test.
* g++.dg/modules/depreport-1_b.C: New test.
* g++.dg/modules
When passing `-o` flags to other options, the typical `-o foo` spelling
leaves a leading whitespace when replacing elsewhere. This ends up
creating flags spelled as `-some-option-with-arg= foo.ext` which doesn't
parse properly. When attempting to make a spec function to just remove
the leading whit
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
`import some_modul
On Thu, 2023-08-31 at 21:25 -0400, Eric Feng wrote:
> On Thu, Aug 31, 2023 at 4:19 PM David Malcolm
> wrote:
> >
> > On Thu, 2023-08-31 at 15:09 -0400, Eric Feng wrote:
> > > On Thu, Aug 31, 2023 at 1:01 PM David Malcolm
> > >
> > > wrote:
> > > >
> > > > On Wed, 2023-08-30 at 18:15 -0400, Eric
Hi,
The below (slightly) reduced test-case from gcc.c-torture/execute/simd-2.c
produces an execution failure for avr.
typedef short __attribute__((vector_size (16))) vecint;
vecint i = { 150, 100, 150, 200, 0, 0, 0, 0 };
vecint j = { 10, 13, 20, 30, 1, 1, 1, 1 };
vecint k;
union {
vecint
On Fri, Sep 01, 2023 at 10:13:40AM +0200, Richard Biener via Gcc wrote:
> The value of .CLZ (0) is undefined then. I belive your analysis is correct in
> that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
> the range for _35. I wonder why we don't elide _36 ? _31 : 1 with
On Thu, Aug 31, 2023 at 3:58 PM Krister Walfridsson via Gcc
wrote:
>
> My translation validation tool reports some miscompilations related to the
> internal call CLZ(0) when CLZ_DEFINED_VALUE_AT_ZERO is false, but I am not
> sure I use the correct semantics...
>
> I started by modeling CLZ(0) as u
16 matches
Mail list logo
