Re: [Bug driver/81358] libatomic not automatically linked with C11 code

[Joseph Myers]

I should also note the testsuite point I mentioned in the BoF, and related 
points about building target libraries, which mean this is more 
complicated than just the driver specs change:

There is testsuite logic (see gcc/testsuite/lib/atomic-dg.exp) to locate 
libatomic for build-tree testing and set appropriate -L options and 
LD_LIBRARY_PATH.

This is only used in gcc/testsuite/gcc.dg/atomic/atomic.exp at present.  
If the driver specs change to use "--as-needed -latomic --no-as-needed" 
whenever libatomic is built (obviously they shouldn't do so for 
configurations not building libatomic, whether because unsupported for the 
target or because disabled at configure time), linking *any* target 
program will then require libatomic to be somewhere that ld can find it 
(because ld requires a library named with -l to be somewhere it can find, 
even inside --as-needed; it can only know whether a library is needed 
after seeing what symbols it defines).

Thus, that logic would need to be used globally for all testsuites.  In 
addition, all configure tests in target libraries that run link tests, and 
linking of shared target libraries, would need to pass appropriate -L 
options to find libatomic, and we'd need to make sure the target library 
dependencies in toplevel Makefile.def ensure libatomic is built before 
other target libraries are configured for this to work.  I think libgcc 
should still be built before libatomic and so we'd need some driver option 
to disable linking with libatomic that would be passed when linking shared 
libgcc.

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

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Tue, 15 Aug 2017, Martin Sebor wrote:

> It looks like the data loss extends beyond 8/14.  Bug 81840
> was created Sunday afternoon but is not in the database:
> 
>   https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html
> 
> (Strangely, 81841 is there, as is 81839.)

That's another 81839 replacing the original 81839.  As I noted on 
overseers, the cut-off for GCC Bugzilla appears to be between 
 and 
, early Sunday 
morning UTC (and for sourceware Bugzilla it may well be similar).

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

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Tue, 15 Aug 2017, Martin Sebor wrote:

> On 08/15/2017 10:27 AM, Joseph Myers wrote:
> > On Tue, 15 Aug 2017, Martin Sebor wrote:
> > 
> > > It looks like the data loss extends beyond 8/14.  Bug 81840
> > > was created Sunday afternoon but is not in the database:
> > > 
> > >   https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01303.html
> > > 
> > > (Strangely, 81841 is there, as is 81839.)
> > 
> > That's another 81839 replacing the original 81839.  As I noted on
> > overseers, the cut-off for GCC Bugzilla appears to be between
> > <https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01289.html> and
> > <https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html>, early Sunday
> > morning UTC (and for sourceware Bugzilla it may well be similar).
> 
> Thanks for the update.  Can I subscribe to this list?

I believe it's open subscription.

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

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Wed, 16 Aug 2017, Eric Gallager wrote:

> I see Richi redid all his 7.2 release changes; does that imply that
> the server restore is now complete?

No, there's still a search process ongoing to identify corrupted or 
missing files by comparison with the last backup.

My expectation is that all the other Bugzilla changes from 13 and 14 
August UTC need redoing manually (recreating bugs with new numbers in the 
case of new bugs filed during that period, if those bugs are still 
relevant, repeating comments, etc. - and possibly recreating accounts for 
people who created accounts and filed bugs during that period).  But I 
haven't seen any official announcement from overseers to all affected 
projects (for both GCC and Sourceware Bugzillas) yet.

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

Re: [Bug web/?????] New: Fwd: failure notice: Bugzilla down.

[Joseph Myers]

On Wed, 16 Aug 2017, NightStrike wrote:

> On Mon, Aug 14, 2017 at 11:10 PM, Martin Sebor  wrote:
> > On 08/14/2017 04:22 PM, Eric Gallager wrote:
> >>
> >> I'm emailing this manually to the list because Bugzilla is down and I
> >> can't file a bug on Bugzilla about Bugzilla being down. The error
> >> message looks like this:
> >
> > Bugzilla and the rest of gcc.gnu.org have been down much of
> > the afternoon/evening due to a hard drive upgrade (the old disk
> > apparently failed).  You're not the only one who found out about
> 
> There's no RAID?

The problem was apparently a kernel bug (in the 2.6.32 RHEL6 kernel, may 
or may not be in current kernels) that arose when adding a new SSD mirror 
to the RAID with the old hard drives marked writemostly.  (Separately, one 
of the hard drives in the existing HDD RAID is showing signs of failing 
and needs to be replaced.)

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

Re: [Bug c/80730] bogus initializer element is not computable at load time converting a string to bool

[Joseph Myers]

On Mon, 15 May 2017, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80730
> 
> --- Comment #5 from Martin Sebor  ---
> I"m not sure I understand what you're saying.  Your comment that "the
> initializer *as 
> converted* must be a constant expression (and, thus, to be an address 
> constant, must be of pointer type)" makes it sound as an argument for 
> rejecting
> '_Bool b = "";' which would mean that you think '_Bool b = a;' should be
> rejected as well.  But your other comment that you'd "consider it appropriate
> to handle implicit conversions in initializers exactly the same as casts are
> handled" sounds as though you think '_Bool b = "";' should be accepted 
> (because
> '_Bool b = (_Bool)"";' is accepted).  So I'm not sure what to make of it.

I think both '_Bool b = "";' and '_Bool b = (_Bool)"";' should be handled 
the same, regarding what's accepted with what options and what 
diagnostics.  I don't think the standard should be interpreted in a way 
that handles them differently or that requires either of them to be 
accepted.  Actually accepting them is fairly harmless.  (Those particular 
cases don't involve anything *forbidden* in a constant expression, such as 
a function call, so don't actually require a pedwarn-if-pedantic, although 
I think such a diagnostic with -pedantic makes sense.)

> The most useful behavior is to accept all three with a pedantic warning.  It
> makes it easy to port code to GCC that was written to one of these compilers,
> while also making it possible to find out about portability problems when
> porting to other compilers.  Do you agree with this as a goal to work toward?

Yes.

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

other/928: Out of date preprocessor docs in extend.texi

[Joseph Myers]

>Number: 928
>Category:   other
>Synopsis:   Out of date preprocessor docs in extend.texi
>Confidential:   no
>Severity:   non-critical
>Priority:   low
>Responsible:unassigned
>State:  open
>Class:  doc-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 29 09:56:01 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: Joseph S. Myers
>Release:2.97 20001129 (experimental)
>Organization:
none
>Environment:
System: Linux decomino 2.2.17 #1 Mon Sep 4 20:22:16 UTC 2000 i686 unknown
Architecture: i686


host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: ../gcc-cvs/configure --prefix=/opt/gcc/snapshot --disable-shared 
--enable-threads=posix --with-system-zlib
>Description:

extend.texi contains documentation of preprocessor extensions -
GNU-style macro varargs, and the support of C++ comments in gnu89
(default) mode.  The documentation of macro varargs seems to be out of
date.

>How-To-Repeat:

Read both the GCC and CPP manuals and find them to be inconsistent.

>Fix:

Add a section to the cpp.texi manual summarising the non-deprecated
extensions in one place (with updated documentation of the acceptance
of C++ comments except when in strict C89 or traditional mode), and
point to there from extend.texi, removing the existing cpp-related
items from extend.texi.
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: ia64-elf and i386-elf fail to build

[Joseph Myers]

On Thu, 25 Aug 2016, Nick Clifton wrote:

>   The cause appears to be an attempt to register a builtin type using
>   the float128_type_node, which is NULL for these particular targets:
> 
> gcc/config/ia64/ia64.c:10373
> gcc/config/i386/i386.c:33347
> 
>   Presumably float128_type_node should not be NULL, but I am not sure
>   how to fix this.  Any suggestions ?

I think this indicates that i386 and ia64 need their own local version of 
float128_type_node, set up like float80_type_node (i.e. copied from the 
global one if that isn't NULL, otherwise set up locally) instead of using 
the global one unconditionally, because of the existence of i386 and ia64 
targets where the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P hook can return 
false for TFmode (in which case __float128 still exists, but not 
_Float128).  Though preferable would be to fix all the targets with 
IX86_NO_LIBGCC_TFMODE / IX86_MAYBE_NO_LIBGCC_TFMODE / 
IA64_NO_LIBGCC_TFMODE so that they include the relevant support code in 
libgcc and so no longer need the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 
hook overridden at all.

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

Re: ia64-elf and i386-elf fail to build

[Joseph Myers]

On Thu, 25 Aug 2016, Joseph Myers wrote:

> _Float128).  Though preferable would be to fix all the targets with 
> IX86_NO_LIBGCC_TFMODE / IX86_MAYBE_NO_LIBGCC_TFMODE / 
> IA64_NO_LIBGCC_TFMODE so that they include the relevant support code in 
> libgcc and so no longer need the TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P 
> hook overridden at all.

Which, I should say, should actually be very simple to do in a mechanical 
way (changing the long list of targets near the bottom of 
libgcc/config.host that use soft-fp for i386/x86_64 to i[34567]86-*-* 
x86_64-*-* would almost do the right thing for x86, except you'd need to 
exclude i[34567]86-*-elfiamcu and update the code for i[34567]86-*-rtems* 
because they also use soft-fp for SFmode and DFmode).

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

Re: ia64-elf and i386-elf fail to build

[Joseph Myers]

On Thu, 25 Aug 2016, Nick Clifton wrote:

> gcc/ChangeLog
> 2016-08-25  Nick Clifton  
> 
>   * config/ia64/ia64.c (ia64_init_builtins): Initialise the
>   float128_type_node if that has not been done already.
>   * config/i386/i386.c (ix86_init_builtin_types): Likewise.

No, this is wrong.  The global node must remain as NULL when the type is 
not fully supported.  You need a different name for the local node, e.g. 
i386_float128_type_node (and then update all back-end uses to use the 
local node).

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