Re: [PATCH] Fix bootstrap with GCC 3.4 (and likely anything < 4.4 except 4.2.[0-3]) (PR bootstrap/84405)
On Fri, Feb 16, 2018 at 02:14:09PM -0700, Martin Sebor wrote:
> On 02/16/2018 01:44 PM, Jakub Jelinek wrote:
> > On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
> > > But the broken compilers will overwrite the memset data with possibly
> > > uninitialized fields of a TARGET_EXPR.
> >
> > Perhaps for hash-table.h we could use:
> > #ifndef BROKEN_VALUE_INITIALIZATION
> > for ( ; size; ++entries, --size)
> > *entries = value_type ();
> > #else
> > union U { char c[sizeof (value_type)]; value_type v; } u;
>
> In C++ 98 a type with a constructor cannot be a member of a union
> so the above wouldn't be valid but if I understand what you're
> trying to do you don't need the member. All you need is a buffer.
> Something like this?
>
> char __attribute__ ((aligned (__alignof__ (value_type
> buf [sizeof (value_type)] = "";
Note, this doesn't work, as G++ <= 4.2 rejects:
template
struct S
{
char __attribute__ ((__aligned__ (__alignof__ (value_type buf[sizeof
(value_type)];
};
S s;
with:
error: requested alignment is not a constant
The following works though, and has been successfully bootstrapped/regtested
on x86_64-linux and i686-linux. It will fail if we use hash_table on
overaligned value_type type with alignment > 64, but that is not completely
unlikely on any target I'm aware of. It uses __alignof__ which should be
supported by the system GCC's we support for which
BROKEN_VALUE_INITIALIZATION is true (i.e. >= 3.4 and <= 4.3), non-GCC
compilers shouldn't get here due to GCC_VERSION != 0 unless they pretend to
be GCC compatible.
Bootstrapped with system gcc34/g++34 on x86_64-linux, ok for trunk?
2018-02-17 Jakub Jelinek
PR bootstrap/84405
* vec.h (vec_default_construct): For BROKEN_VALUE_INITIALIZATION use
memset and value initialization afterwards.
* hash-table.h (hash_table::empty_slow): For
BROKEN_VALUE_INITIALIZATION use placement new into a previously
cleared appropriately aligned buffer.
--- gcc/vec.h.jj2018-02-16 19:39:03.637058918 +0100
+++ gcc/vec.h 2018-02-16 23:51:55.389582056 +0100
@@ -490,12 +490,11 @@ template
inline void
vec_default_construct (T *dst, unsigned n)
{
-#ifndef BROKEN_VALUE_INITIALIZATION
- for ( ; n; ++dst, --n)
-::new (static_cast(dst)) T ();
-#else
+#ifdef BROKEN_VALUE_INITIALIZATION
memset (dst, '\0', sizeof (T) * n);
#endif
+ for ( ; n; ++dst, --n)
+::new (static_cast(dst)) T ();
}
/* Copy-construct N elements in DST from *SRC. */
--- gcc/hash-table.h.jj 2018-02-16 19:39:03.660058934 +0100
+++ gcc/hash-table.h2018-02-17 00:01:24.207723925 +0100
@@ -808,7 +808,18 @@ hash_table::empty
for ( ; size; ++entries, --size)
*entries = value_type ();
#else
- memset (entries, 0, size * sizeof (value_type));
+ /* To workaround older GCC versions which don't handle value
+initialization right, use a placement new into previously
+cleared buffer. */
+ char buf[2 * sizeof (value_type) + 64];
+ gcc_assert (__alignof__ (value_type) <= sizeof (value_type) + 64);
+ char *q = (buf + sizeof (value_type) + 64
+- ((uintptr_t) buf % __alignof__ (value_type)));
+ memset (q, '\0', sizeof (value_type));
+ value_type *p = ::new (q) value_type ();
+ for ( ; size; ++entries, --size)
+ *entries = *p;
+ p->~value_type ();
#endif
}
m_n_deleted = 0;
Jakub
Re: [Patch, fortran] PR84115] [8 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'indirect_ref' in add_decl_as_local, at fortran/trans-decl.c:256
Thanks. Committed as revision 257781. Paul On 16 February 2018 at 15:21, Steve Kargl wrote: > On Fri, Feb 16, 2018 at 07:07:53AM +, Paul Richard Thomas wrote: >> > Oddly, the failing test in associate_35.f90 is the only one that works >> > in 7-branch. I have left the PR open and changed the title >> > accordingly. >> >> The attached patch fixes this. OK for trunk? >> > > Ok. > > -- > steve -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [ patch, testsuite, fortran] Replace "call abort" by "stop n"
Am 16.02.2018 um 09:11 schrieb Janne Blomqvist: as a result of this, you should be able to remove the vast majority of -fall-intrinsics extra options. Please do that as well. Done, in r257782. I actually liked the usage of "call abort" in testcases, as a failing testcase provided a backtrace with line number information and a core dump. With this change, one now has to check on which line the testcase failed, set a breakpoint there and run it again in the debugger. Oh well, I guess that convenience has to be sacrificed on the altar of standards conformance. Well, we get the output "STOP 1" for a STOP 1 statement. Should not be too hard to find in the source. Regards Thomas
*ping* [patch, fortran] Fix handling of assumed-size arrays in inline matmul
Am 12.02.2018 um 11:46 schrieb Thomas Koenig: Hello world, the attached patch fixes a regression where a rejects-valid would be issued. OK for the affected branches, trunk and gcc-7? PING ** (5.D0/7.D0) ?
Re: [PATCH v3 1/14] D: The front-end (DMD) language implementation and license.
On 25 October 2017 at 03:06, Jeff Law wrote: > On 10/18/2017 01:33 AM, Iain Buclaw wrote: >> On 6 October 2017 at 14:51, Ian Lance Taylor wrote: >>> On Fri, Oct 6, 2017 at 1:34 AM, Iain Buclaw wrote: Out of curiosity, I did have a look at some of the tops of gofrontend sources this morning. They are all copyright the Go Authors, and are licensed as BSD. So I'm not sure if having copyright FSF and distributing under GPL is strictly required. And from a maintenance point of view, it would be easier to merge in upstream changes as-is without some diff/merging tool. >>> >>> The GCC steering committee accepted the gofrontend code under a >>> non-GPL license with the understanding that the master code would live >>> in a separate repository that would be mirrored into the GCC repo (the >>> master repository for gofrontend is currently at >>> https://go.googlesource.com/gofrontend/). Personally I don't see a >>> problem with doing the same for the D frontend. >>> >>> Ian >> >> Should I request that maybe Donald from FSF chime in here? I'd rather >> avoid another stalemate on this. > Absolutely, though RMS should probably be included on any discussion > with Donald. I think the FSF needs to chime in and I think the steering > committee needs to chime in once we've got guidance from the FSF. > > The first and most important question that needs to be answered is > whether or not the FSF would be OK including the DMD bits with the > license (boost) as-is into GCC. > > If that's not acceptable, then we'd have to look at some kind of script > to fix the copyrights. > Jeff > Just touching base here, hope you all had a good New Year. So far, I've only had a general "Yes this is fine" from Ted who's managing the copyright assignments at the FSF. His his initial response being: --- If the D files are all Boost v.1 and we can get assignments from all contributors, there is no problem including the files as there are currently. Boost is compatible with GPLv3 or later since it is basically a [permissive license][0]. [0]: https://directory.fsf.org/wiki/License:Boost1.0 --- And subsequent follow-up: --- The questions that remain still are whether there are any unaccounted for contributors to this (but I don't believe this is the case from the first pass). We have the assignment for the past and future code from Digital Mars. The second question, which is outside of my discretion is deciding whether the Boost license is acceptable. It seems that it is compatible so it doesn't appear that incompatibility is a problem, but of course there are still policy considerations. These are currently being discussed on the mailing-list and I will add this message to the thread. --- I have asked for clarity on a few more finer points, but still haven't heard back after a number of attempts to get an answer back. Can we get discussion rolling again on this? Since the last message, upstream dmd has switched all copyrights to "The D Language Foundation", which has been reflected downstream in gdc. So, as a policy consideration from the SC, is it acceptable to have the following notice at the top of all dfrontend/* sources? --- Copyright (C) 2010-2018 by The D Language Foundation, All Rights Reserved All Rights Reserved, written by Walter Bright http://www.digitalmars.com Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE or copy at http://www.boost.org/LICENSE_1_0.txt) --- And if no, what should it instead be? There are no restrictions on changing the copyright to FSF and license as GPLv3+ Regards Iain.
Re: *ping* [patch, fortran] Fix handling of assumed-size arrays in inline matmul
On 02/17/2018 06:22 AM, Thomas Koenig wrote: Am 12.02.2018 um 11:46 schrieb Thomas Koenig: Hello world, the attached patch fixes a regression where a rejects-valid would be issued. OK for the affected branches, trunk and gcc-7? PING ** (5.D0/7.D0) ? Yes, OK Jerry
Re: [PATCH] Fix bootstrap with GCC 3.4 (and likely anything < 4.4 except 4.2.[0-3]) (PR bootstrap/84405)
On February 16, 2018 9:44:33 PM GMT+01:00, Jakub Jelinek
wrote:
>On Fri, Feb 16, 2018 at 09:25:30PM +0100, Richard Biener wrote:
>> But the broken compilers will overwrite the memset data with possibly
>uninitialized fields of a TARGET_EXPR.
>
>Perhaps for hash-table.h we could use:
>#ifndef BROKEN_VALUE_INITIALIZATION
> for ( ; size; ++entries, --size)
> *entries = value_type ();
>#else
> union U { char c[sizeof (value_type)]; value_type v; } u;
> memset (u.c, '\0', sizeof (u.c));
> value_type *p = ::new (static_cast(u.c)) value_type ();
> for ( ; size; ++entries, --size)
> *entries = *p;
> p->~value_type ();
>#endif
>or so, if it is valid C++, which could turn the hash-table.h case into
>the vec.h case.
I don't think a workaround for a non-conforming compiler has to be strictly
conforming. And the more complicated we make this the bigger the chances we hit
some other latent bug.
Richard.
> Jakub
Re: RFC (DECL_CONSTRUCTOR_P): C++ PATCH for c++/83911, ICE with multiversioned constructor
On 02/16/2018 05:48 PM, Jason Merrill wrote:
We hit the bug in this testcase because build_over_call replaces the
constructor with a dispatcher function, and then build_aggr_init_expr
doesn't recognize it as a constructor.
Messing with the DECL_NAME of the dispatcher seems messy, but copying
the DECL_CXX_CONSTRUCTOR_P flag is easy. So we can change the test in
build_aggr_init_expr, or change the definition of DECL_CONSTRUCTOR_P.
I lean toward the latter as more uniform, but not strongly. Do you
have an opinion?
Yeah, I think copying DECL_CXX_CONSTRUCTOR_P is the right approach. I wondered
about dtors, operator fns and conversion fns. They also rely on identifier flags.
dtors ICEs add_method (feel free to file a defect and assign to me). assignment
operator seems ok. That assop is ok, suggests the change to mangle.c isn;t
needed -- we mangle the name early enough?
[We could move CXX_{CON,DE}STRUCTOR_P functionality into the operator
enumeration to free up a couple of flags, but that's definitely a stage 1 change]
nathan
--
Nathan Sidwell
Re: [ patch, testsuite, fortran] Replace "call abort" by "stop n"
Hi Thomas,
>> as a result of this, you should be able to remove the vast majority of
>> -fall-intrinsics extra options. Please do that as well.
>
>
> Done, in r257782.
Regarding "-fall-intrinsics": Your commit has greatly reduced its
usage, but I still see a few cases that you left in, although the flag
does not really seem to be required.
Is there a reason why did not treat these? Would you mind if I applied
the patch in attachment?
Cheers,
Janus
Index: gcc/testsuite/gfortran.dg/io_real_boz2.f90
===
--- gcc/testsuite/gfortran.dg/io_real_boz2.f90 (revision 257784)
+++ gcc/testsuite/gfortran.dg/io_real_boz2.f90 (working copy)
@@ -1,6 +1,6 @@
! { dg-do run }
! { dg-shouldfail "Real BOZ not allowed" }
-! { dg-options "-fall-intrinsics -std=f2003" }
+! { dg-options "-std=f2003" }
! Test for invalid (F95/F2003) writing of real with octal edit descriptor
! PR fortran/29625
program real_boz
Index: gcc/testsuite/gfortran.dg/pointer_intent_3.f90
===
--- gcc/testsuite/gfortran.dg/pointer_intent_3.f90 (revision 257784)
+++ gcc/testsuite/gfortran.dg/pointer_intent_3.f90 (working copy)
@@ -1,5 +1,5 @@
! { dg-do compile }
-! { dg-options "-std=f2003 -fall-intrinsics" }
+! { dg-options "-std=f2003" }
! { dg-shouldfail "Invalid code" }
!
! Pointer intent test
Index: gcc/testsuite/gfortran.dg/proc_ptr_common_1.f90
===
--- gcc/testsuite/gfortran.dg/proc_ptr_common_1.f90 (revision 257784)
+++ gcc/testsuite/gfortran.dg/proc_ptr_common_1.f90 (working copy)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-options "-std=f2003 -fall-intrinsics" }
+! { dg-options "-std=f2003" }
!
! PR fortran/36592
!
Index: gcc/testsuite/gfortran.dg/protected_3.f90
===
--- gcc/testsuite/gfortran.dg/protected_3.f90 (revision 257784)
+++ gcc/testsuite/gfortran.dg/protected_3.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-options "-std=f95 -fall-intrinsics" }
+! { dg-options "-std=f95" }
! PR fortran/23994
!
! Test PROTECTED attribute. Within the module everything is allowed.
Index: gcc/testsuite/gfortran.dg/protected_4.f90
===
--- gcc/testsuite/gfortran.dg/protected_4.f90 (revision 257784)
+++ gcc/testsuite/gfortran.dg/protected_4.f90 (working copy)
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-shouldfail "Invalid Fortran 2003 code" }
-! { dg-options "-std=f2003 -fall-intrinsics" }
+! { dg-options "-std=f2003" }
! PR fortran/23994
!
! Test PROTECTED attribute. Within the module everything is allowed.
Index: gcc/testsuite/gfortran.dg/protected_5.f90
===
--- gcc/testsuite/gfortran.dg/protected_5.f90 (revision 257784)
+++ gcc/testsuite/gfortran.dg/protected_5.f90 (working copy)
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-shouldfail "Invalid Fortran 2003 code" }
-! { dg-options "-std=f2003 -fall-intrinsics" }
+! { dg-options "-std=f2003" }
! PR fortran/23994
!
! Test PROTECTED attribute. Within the module everything is allowed.
Index: gcc/testsuite/gfortran.dg/protected_6.f90
===
--- gcc/testsuite/gfortran.dg/protected_6.f90 (revision 257784)
+++ gcc/testsuite/gfortran.dg/protected_6.f90 (working copy)
@@ -1,6 +1,6 @@
! { dg-do compile }
! { dg-shouldfail "Invalid Fortran 2003 code" }
-! { dg-options "-std=f2003 -fall-intrinsics" }
+! { dg-options "-std=f2003" }
! PR fortran/23994
!
! Test PROTECTED attribute. Within the module everything is allowed.
Re: [PATCH] gold: Use autotools pthread macro
> The autotools library macro (AX_PTHREAD) is now used to detect if > pthreads is present and multi-threaded linking in gold is automatically > enabled if it is found. This enables multi-threaded gold on platforms > where pthreads is enabled via other methods than just -lpthread (e.g. > MinGW) > > Signed-off-by: Joshua Watt > --- > config/ax_pthread.m4 | 485 > gold/Makefile.am | 11 +- > gold/Makefile.in | 22 +- > gold/aclocal.m4| 1 + > gold/configure | 767 > +++-- > gold/configure.ac | 23 +- > gold/testsuite/Makefile.in | 8 +- > 7 files changed, 1254 insertions(+), 63 deletions(-) Thanks for the patch! I have a few preliminary questions and comments... First, do you or your company have a copyright assignment on file with FSF? I could be wrong, but I believe adding to config/ will require approval from a GCC config/ maintainer. The normal process, as I understand it, would be to add the file to the GCC tree, then sync it into the binutils tree. I'm not in a position to approve that, nor can I judge on the acceptability of the copyright notice in that file. I'd like to retain the ability to use --disable-threads as a configure option. If this is just to get MinGW on board, is there a lighter-weight way of doing that? Could we just add a configure option that switches between -lpthread and -pthread (or whatever option is needed)? I like the idea of fully automating it, but that's a pretty big m4 file! Anyway, I'd like to hear what the GCC folks think of adding ax_pthread.m4 to the config/ directory. (BTW, In the future, please omit diffs from generated files from your patch.) -cary
Re: [ patch, testsuite, fortran] Replace "call abort" by "stop n"
Hi Janus, Regarding "-fall-intrinsics": Your commit has greatly reduced its usage, but I still see a few cases that you left in, although the flag does not really seem to be required. Is there a reason why did not treat these? I was specifically chaning those cases which contained STOP [1-9] after my patch; I didn't look at any other use of -fall-intrinsics. Would you mind if I applied the patch in attachment? Not at all - if the test cases pass without the option, just go ahead and commit the patch. Regards Thomas
[PATCH v2] RISC-V: Support for FreeBSD
Hi all:
This patch is version 2 of FreeBSD supporting for RISC-V, Ruslan
(RISC-V FreeBSD maintainer) and me has been tested on FreeBSD 12
for building kernel and whole user space programs/libraries again :)
Hi Jim:
Ruslan and me just decide upstream GCC part only this time since
binutils need more work (mostly for ELF header info), but it's not
affect the correctness.
Changes since v1[1]:
- Remove dbxelf.h.
- Correct the copyright year info.
- Fix libgcc/config.host for riscv*-*-freebsd*.
Copyright part, Ruslan has sent to fsf-reco...@gnu.org but no echo,
I've forward that to ass...@gnu.org again.
gcc/ChangeLog
2018-01-29 Ruslan Bukin
Kito Cheng
* config.gcc (riscv*-*-freebsd*): New.
* config/riscv/freebsd.h: New.
libgcc/ChangeLog
2018-01-29 Ruslan Bukin
* libgcc/config.host: Support RISC-V FreeBSD.
[1] V1 patch: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02235.html
From 13781768c4f71eb83505f0d579de37d5f861ac7c Mon Sep 17 00:00:00 2001
From: Ruslan Bukin
Date: Wed, 3 Jan 2018 15:59:04 +
Subject: [PATCH] RISC-V: Add support for FreeBSD
gcc/ChangeLog
2018-02-18 Ruslan Bukin
Kito Cheng
* config.gcc (riscv*-*-freebsd*): New.
* config/riscv/freebsd.h: New.
libgcc/ChangeLog
2018-02-18 Ruslan Bukin
* libgcc/config.host: Support RISC-V FreeBSD.
---
gcc/config.gcc | 9
gcc/config/riscv/freebsd.h | 54 ++
libgcc/config.host | 4
3 files changed, 67 insertions(+)
create mode 100644 gcc/config/riscv/freebsd.h
diff --git a/gcc/config.gcc b/gcc/config.gcc
index c52fecf..01b5a92 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2086,6 +2086,15 @@ riscv*-*-elf* | riscv*-*-rtems*)
;;
esac
;;
+riscv*-*-freebsd*)
+ tm_file="${tm_file} elfos.h ${fbsd_tm_file} riscv/freebsd.h"
+ tmake_file="${tmake_file} riscv/t-riscv"
+ gnu_ld=yes
+ gas=yes
+ # Force .init_array support. The configure script cannot always
+ # automatically detect that GAS supports it, yet we require it.
+ gcc_cv_initfini_array=yes
+ ;;
mips*-*-netbsd*) # NetBSD/mips, either endian.
target_cpu_default="MASK_ABICALLS"
tm_file="elfos.h ${tm_file} mips/elf.h ${nbsd_tm_file} mips/netbsd.h"
diff --git a/gcc/config/riscv/freebsd.h b/gcc/config/riscv/freebsd.h
new file mode 100644
index 000..019b22f
--- /dev/null
+++ b/gcc/config/riscv/freebsd.h
@@ -0,0 +1,54 @@
+/* Definitions for RISC-V FreeBSD systems with ELF format.
+ Copyright (C) 2018 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+
[PATCH libgfortran] PR84412 [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error
Hi all,
The following patch is trivial and I plan to commit in the next day or
so to trunk and gcc 7.
Regression tested on x86_64-pc-gnu-linux.
Regards,
Jerry
2018-02-18 Jerry DeLisle
PR libgfortran/84412
* io/transfer.c (finalize_transfer): After completing
an internal unit I/O operation, clear internal_unit_kind.
diff --git a/gcc/testsuite/gfortran.dg/inquire_18.f90
b/gcc/testsuite/gfortran.dg/inquire_18.f90
new file mode 100644
index 000..9829688225b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/inquire_18.f90
@@ -0,0 +1,11 @@
+! { dg-do run }
+! PR84412 Wrong "Inquire statement identifies an internal file" error
+program bug
+ implicit none
+ integer :: i
+ character(len=1) :: s
+ write (s,'(i1)') 0
+ open(newUnit=i,file='inquire_18.txt',status='unknown')
+ inquire(unit=i)
+ close(i, status="delete")
+end program bug
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 8bc828c0214..df33bed1561 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -3993,6 +3993,10 @@ finalize_transfer (st_parameter_dt *dtp)
if (dtp->u.p.unit_is_internal)
{
+ /* The unit structure may be reused later so clear the
+internal unit kind. */
+ dtp->u.p.current_unit->internal_unit_kind = 0;
+
fbuf_destroy (dtp->u.p.current_unit);
if (dtp->u.p.current_unit
&& (dtp->u.p.current_unit->child_dtio == 0)
