potential bug in libstc++ ?

2017-11-14 Thread Sergey Nenakhov 
Hello.

Excuse me if I'm posting to the wrong mailing list. I've grabbed gcc-7.2.0
sources and noticed strange statement in the file
gcc-7.2.0\libstdc++-v3\include\bits\locale_conv.h  which seems like a bug
to me:
Line 434 and 434 of that file are:
if (__nbytes < 1)
  __nbytes == 1;

Should not it be ?
if (__nbytes < 1)
  __nbytes = 1;

(=  vs == if it didn't hit your eye).

I couldn't find libstdc++-v3 folder in online svn repository to verify if
it was changed since 7.2.0 release

Thanks!

Sergey Nenakhov.

Re: potential bug in libstc++ ?

2017-11-14 Thread Richard Biener 
On Tue, Nov 14, 2017 at 3:35 PM, Sergey Nenakhov
 wrote:
> Hello.
>
> Excuse me if I'm posting to the wrong mailing list. I've grabbed gcc-7.2.0
> sources and noticed strange statement in the file
> gcc-7.2.0\libstdc++-v3\include\bits\locale_conv.h  which seems like a bug
> to me:
> Line 434 and 434 of that file are:
> if (__nbytes < 1)
>   __nbytes == 1;
>
> Should not it be ?
> if (__nbytes < 1)
>   __nbytes = 1;
>
> (=  vs == if it didn't hit your eye).
>
> I couldn't find libstdc++-v3 folder in online svn repository to verify if
> it was changed since 7.2.0 release

Still there.

Richard.

> Thanks!
>
> Sergey Nenakhov.

Re: potential bug in libstc++ ?

2017-11-14 Thread Jonathan Wakely 
On 14 November 2017 at 14:35, Sergey Nenakhov wrote:
> Hello.
>
> Excuse me if I'm posting to the wrong mailing list.

libstdc++ has its own mailing list (which Richard CC'd).

> I've grabbed gcc-7.2.0
> sources and noticed strange statement in the file
> gcc-7.2.0\libstdc++-v3\include\bits\locale_conv.h  which seems like a bug
> to me:
> Line 434 and 434 of that file are:
> if (__nbytes < 1)
>   __nbytes == 1;
>
> Should not it be ?
> if (__nbytes < 1)
>   __nbytes = 1;
>
> (=  vs == if it didn't hit your eye).

Yes, thanks, I'll take care of it.

> I couldn't find libstdc++-v3 folder in online svn repository to verify if
> it was changed since 7.2.0 release

You need to select page 2 from the dropdown list,
https://gcc.gnu.org/viewcvs/gcc/trunk/ only shows the first 25
entries.

bitfield types

2017-11-14 Thread Mike Stump 
The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me.  The type of 
the expression x.b << 8 has size 8,  a size 8 integral type is a 64-bit type.  
If the result is a 64-bit type, then it's argument (x.b) was a 64-bit type.  In 
C++, we observed what they meant in the C language standard and ever so 
slightly clarified the language.  I don't think we viewed the semantics of C 
any different than what we wrote at the time.  The problem is that in C, sizeof 
bit-field doesn't work, but sizeof (bitfield << 0) does work.  For this to 
work, the size can't refer to the size in bits, so must refer to some other 
integral type.  The obvious one to use would be the smallest one that fits the 
size, or the underlying type.  In C++, we felt the underlying type was the 
right one.  The C standard does say that the type of the bitfield is what we 
call the underlying type in C++.  Because of this, the test case is wrong, and 
the C semantics are wrong.

Now, this is might be contentious to some, so, I wonder if a later C language 
DR or C language standard clarified this any?  Any language lawyer want to 
argue other semantics?

https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00723.html is fallout of the 
wrong semantics by the C front-end and the entire issue evaporates once the 
code-gen is fixed.

I did expect bit-fields to be well understood and implemented at this point and 
was kinda amused to see that isn't the case yet.  I'd be interested in survey 
results of all (long||long long) > int C compilers.  clang for example, does 
the right thing.

Re: bitfield types

2017-11-14 Thread Joseph Myers 
On Tue, 14 Nov 2017, Mike Stump wrote:

> The testsuite/gcc.c-torture/execute/pr34971.c seems wrong to me.  The 
> type of the expression x.b << 8 has size 8, a size 8 integral type is a 
> 64-bit type.  If the result is a 64-bit type, then it's argument (x.b) 
> was a 64-bit type.  In C++, we observed what they meant in the C 

A 64-bit type *with padding bits, not necessarily 64 value bits*.

See what I said in .

-- 
Joseph S. Myers
jos...@codesourcery.com