Snapshot gcc-9-20201127 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20201127/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 11/26/20 6:50 PM, Jonathan Wakely via Gcc wrote:
I've touched on the subject a few times, e.g.
https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
Libstdc++ code is indented by 2 columns for the enclosing namespace,
usual
Hello,
Gcc will diagnose C or C++ code that converts a pointer to a restrict qualified
type to a pointer to a type without restrict:
int * __restrict p;
int **pp = &p; // [C] warning: initialization discards 'restrict' qualifier
// [C++] error: invalid conversion from 'int* _
On Fri, 27 Nov 2020, Florian Weimer via Gcc wrote:
> The nature of these non-normal numbers is that the CPU does not produce
> them. I think we should make sure that glibc doesn't, either, with
> obvious exceptions such as memcpy. But beyond that, I don't know.
Exceptions probably also include
* Siddhesh Poyarekar:
> On 11/27/20 5:01 PM, Florian Weimer wrote:
>> I think the last part (the “bug”) is new. I welcome a consensus along
>> those lines. I just want to highlight this aspect.
>
> Should we consider fixing behaviour if the bug manifests in a user
> application and not in glibc
Hi there,
I was just looking through the history of how some code came about, and
get the impression that DECL_NONSHAREABLE was meant to be removed.
It seems like it was added to solve PR49103, with the idea that it could
be removed once a more robust solution was added.
Original comment an
On 11/27/20 5:01 PM, Florian Weimer wrote:
I think the last part (the “bug”) is new. I welcome a consensus along
those lines. I just want to highlight this aspect.
Should we consider fixing behaviour if the bug manifests in a user
application and not in glibc itself? i.e. a crash because gl
* Joseph Myers:
> glibc effectively treats them as unspecified behavior - we don't expect
> them to produce any particular meaningful function return value (this
> includes the possibility that such an invalid encoding might be returned
> by a function given such an encoding as input), but if t
On Freitag, 27. November 2020 00:50:57 CET Jonathan Wakely via Gcc wrote:
> I've touched on the subject a few times, e.g.
> https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
>
> Libstdc++ code is indented by 2 columns for
On Fri, 27 Nov 2020 at 11:54, Liu Hao via Libstdc++
wrote:
> As you can see, qualified names in C++ can grow up to ~100 characters quite
> frequently. This may
> deteriorate when `typename` and `template` are sometimes required. I don't
> think there is
> practically a set of rules which governs
在 2020/11/27 下午4:14, Richard Biener 写道:
>
> I prefer the ( on the next line. The argument list can be two spaces
> indented from
> the function name or "right justified" (I think the latter looks
> visually better).
>
The right justification thing looks reasonable. For example, I think this
``
On Fri, 27 Nov 2020 at 10:16, Richard Biener via Libstdc++
wrote:
> > Why not change this to:
> >
> > > if (present)
> > > ptr = gfc_build_conditional_assign_expr (
> > > block, present, ptr, nullarg);
> > >
> >
> > I think
On Fri, Nov 27, 2020 at 3:48 AM Liu Hao via Gcc wrote:
>
> 在 2020/11/27 上午7:50, Jonathan Wakely via Gcc 写道:
> > I've touched on the subject a few times, e.g.
> > https://gcc.gnu.org/pipermail/gcc/2019-December/230993.html
> > and https://gcc.gnu.org/pipermail/gcc/2019-December/231013.html
> >
> >
13 matches
Mail list logo
