On Mon, 10 Feb 2020 at 06:45, Sam Varshavchik wrote:
>
> Iñaki Ucar writes:
>
> > On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote:
> > >
> > > Iñaki Ucar writes:
> > >
> > > > Thoughts?
> > > >
> > > > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
> > >
> > > I manage
Iñaki Ucar writes:
On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote:
>
> Iñaki Ucar writes:
>
> > Thoughts?
> >
> > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
>
> I managed to find the part of the C++ standard that specified the semantics
> of extern "C" linkage,
On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik wrote:
>
> Iñaki Ucar writes:
>
> > Thoughts?
> >
> > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
>
> I managed to find the part of the C++ standard that specified the semantics
> of extern "C" linkage, it is [dcl.link]. The
Iñaki Ucar writes:
Thoughts?
[1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
I managed to find the part of the C++ standard that specified the semantics
of extern "C" linkage, it is [dcl.link]. The term used is "language linkage".
There is no such thing as an inlin
Hi,
I've stumbled upon a regression, and I'm not sure this is a gcc 10 bug
or not. Consider the sample program in [1], a simplification of a real
case out there [2]. It fails to compile in Fedora Rawhide with the
following message:
/tmp/cccbVeNV.s: Assembler messages:
/tmp/cccbVeNV.s:59: Error: s
