Re: C++ backports to 6
On 2017.03.14 at 17:08 +0100, Marek Polacek wrote: > I've backported the attached patches gcc-6. The PR79264 backport caused: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80091 -- Markus
Re: install.texi and arm
On Mon, 13 Mar 2017, Nick Clifton wrote:
>>> Okay to yank this?
>> Fine by me.
> Me too.
Okay, so I went ahead and committed the patch below.
> None. Are you intending to replace the requirement with a more recent
> version of the binutils, or just remove the requirement entirely ?
This is mostly about removing references to versions of binutils a
decade or so old. It's hard to imagine that anyone would give any
such old version a try in 2017 and fresher and shorter documentation
faces a better chance of actually being consumed.
Gerald
2017-03-18 Gerald Pfeifer
* doc/install.texi (Specific) : Remove old
requirement for binutils 2.13.
Index: doc/install.texi
===
--- doc/install.texi(revision 246253)
+++ doc/install.texi(working copy)
@@ -3367,10 +3367,7 @@
@end html
@anchor{arm-x-eabi}
@heading arm-*-eabi
-ARM-family processors. Subtargets that use the ELF object format
-require GNU binutils 2.13 or newer. Such subtargets include:
-@code{arm-*-netbsdelf}, @code{arm-*-*linux-*}
-and @code{arm-*-rtemseabi}.
+ARM-family processors.
Building the Ada frontend commonly fails (an infinite loop executing
@code{xsinfo}) if the host compiler is GNAT 4.8. Host compilers built from the
Re: [Patch, fortran] PR71838 - ICE with OpenCoarrays on submodule
Dear All, I have just noticed that this patch never went to the list because it contained some mime content. As it happens, Anton has tested it and it is relatively trivial. This is just as well because I have unwittingly gone ahead and committed it as revision 246255! Cheers Paul On 26 February 2017 at 15:58, Paul Richard Thomas wrote: > Dear All, > > The title in this PR turned out to be a red herring. The problem is with a > procedure being a dummy in a submodule module procedure declaration; most > particularly the abreviated form. > > The comments in the fix render the patch self-explanatory. > > Bootstrapped and regtested on FC23/x86_64 - OK for trunk and a few weeks > later 6-branch? > > Cheers > > Paul > > 2017-02-26 Paul Thomas > > PR fortran/71838 > * symbol.c (check_conflict): A dummy procedure in a submodule, > module procedure is not an error. > (gfc_add_flavor): Ditto. > > 2017-02-26 Paul Thomas > > PR fortran/71838 > * gfortran.dg/submodule_26.f08 : New test. > * gfortran.dg/submodule_27.f08 : New test. > > -- > "If you can't explain it simply, you don't understand it well enough" - > Albert Einstein
Re: [Patch, fortran] PR79676 - [submodules] Compilation/linking error when module procedures PRIVATE
Dear All, OK'd by Steve and committed as revision 246256. Cheers Paul On 27 February 2017 at 19:23, Paul Richard Thomas wrote: > Dear All, > > This bug resulted from a cock-up on my part. The mechanism for > suppressing .smod files depended on detecting the presence of a module > procedure by resetting a flag if the module_procedure attribute was > written. Of course, this didn't happen if the module procedure is > private, which rather defeats the requirement that private symbols be > present in an .smod file. The fix traverses the namespace and resets > the flag on finding a module procedure. > > Bootstraps and regtests on FC25/x86_64 - OK for trunk and 6-branch? > > Paul > > 2017-02-27 Paul Thomas > > PR fortran/79676 > * module.c (mio_symbol_attribute): Remove reset of the flag > 'no_module_procedures'. > (check_for_module_procedures): New function. Move declaration > of 'no_module_procedures' to above it. > (gfc_dump_module): Traverse namespace calling new function. > > 2017-02-27 Paul Thomas > > PR fortran/79676 > * gfortran.dg/submodule_28.f08 : New test. -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[PATCH] Streamline MAINTAINERS
...by removing entries in the Write After Approval section that are already listed as Reviewers. This came up in a conversation between Andrew and me when he added himself. Applied Gerald 2017-03-18 Gerald Pfeifer * MAINTAINERS (Write After Approval): Remove entries that are already covered under Reviewers. Index: MAINTAINERS === --- MAINTAINERS (revision 246256) +++ MAINTAINERS (working copy) @@ -312,10 +312,8 @@ Wolfgang Bangerth Charles Baylis Tejas Belagod -Andrey Belevantsev Jon Beniston Andrew Bennett -Peter Bergner Daniel Berlin Jan Beulich David Billinghurst @@ -328,7 +326,6 @@ Lynn Boger Ian Bolton Andrea Bona -Paolo Bonzini Neil Booth Robert Bowdidge Joel Brobecker @@ -355,7 +352,6 @@ R. Kelley Cook Christian Cornelssen Ludovic Courtès -Cary Coutant Lawrence Crowl Ian Dall David Daney @@ -399,7 +395,6 @@ Prachi Godbole Torbjorn Granlund Anthony Green -James Greenhalgh Doug Gregor Matthew Gretton-Dann Jon Grimm @@ -524,7 +519,6 @@ Peter O'Gorman Andrea Ornstein Patrick Palka -Seongbae Park Devang Patel Andris Pavenis Fernando Pereira @@ -531,7 +525,6 @@ Kaushik Phatak Nicolas Pitre Paul Pluzhnikov -Marek Polacek Antoniu Pop Vidya Praveen Thomas Preud'homme @@ -564,7 +557,6 @@ William Schmidt Tilo Schwarz Martin Sebor -Dodji Seketeli Svein Seldal Senthil Kumar Selvaraj Thiemo Seufer @@ -585,7 +577,6 @@ Jakub Staszak Graham Stott Andrew Stubbs -Mike Stump Jeff Sturm Robert Suchanek Andrew Sutton @@ -598,7 +589,6 @@ Kresten Krab Thorup Caroline Tice Kai Tietz -Kyrylo Tkachov Ilya Tocar Philipp Tomsich Konrad Trifunovic @@ -628,7 +618,6 @@ Kevin Williams Carlo Wood Chung-Ju Wu -Le-Chun Wu Mingjie Xing Chenghua Xu Canqun Yang @@ -638,13 +627,11 @@ Greta Yorsh David Yuste Kirill Yukhin -Kenneth Zadeck Adhemerval Zanella Yufeng Zhang Shujing Zhao Jon Ziegler Roman Zippel -Claudiu Zissulescu Josef Zlomek Bug database only accounts
New German PO file for 'gcc' (version 7.1-b20170226)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the German team of translators. The file is available at: http://translationproject.org/latest/gcc/de.po (This file, 'gcc-7.1-b20170226.de.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Combiner fix for PR79910
On Fri, Mar 17, 2017 at 04:23:57PM -0600, Jeff Law wrote:
> >>+ /* For combinations that may result in two insns, we have to gather
> >>+ some extra information about registers used, so that we can
> >>+ update all relevant LOG_LINKS later. */
> >
> >Please just refuse to do the combination in such cases instead.
> ?!? That would essentially mean we can't do 3->2 combinations.
No, only those that would lead to trouble.
> >So, no, I'm not okay with this. It is very expensive, it is doing open
> >heart surgery on combine's internal structures (in a way that may or may
> >not work), and all that to combine some insns in a case that should not
> >exist anyway.
> Please don't be dramatic. If you've got a better suggestion for how to
> fix this, be my guest. I don't like the compile-time cost either, but I
> don't see a better solution.
I'll commit the following monday or so:
Subject: [PATCH] combine: Fix 79910
If the dest of an I0 or I1 is used in an insn before I2, as can happen
in various uncommon cases, and we manage to do the combination, the set
is moved to I2, which is wrong. Don't allow combining the insns in this
case.
This fixes the PR79910 testcase. I also tested building Linux kernels
for all supported architectures: this fixes a bug for blackfin and
makes no changes on other architectures.
Bootstrapped and regression checked on x86_64-linux and powerpc64-linux
{-m32,-m64}.
Segher
2017-03-18 Segher Boessenkool
PR rtl-optimization/79910
* combine.c (can_combine_p): Do not allow combining an I0 or I1
if its dest is used by an insn before I2 (other than the combined
insns themselves, which are properly handled already).
---
gcc/combine.c | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/combine.c b/gcc/combine.c
index 3e5c439..24ecedf 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -1953,6 +1953,10 @@ can_combine_p (rtx_insn *insn, rtx_insn *i3, rtx_insn
*pred ATTRIBUTE_UNUSED,
|| (succ2 && FIND_REG_INC_NOTE (succ2, dest))
/* Don't substitute into a non-local goto, this confuses CFG. */
|| (JUMP_P (i3) && find_reg_note (i3, REG_NON_LOCAL_GOTO, NULL_RTX))
+ /* Make sure that DEST is not used after INSN but before SUCC, or
+between SUCC and SUCC2. */
+ || (succ && reg_used_between_p (dest, insn, succ))
+ || (succ2 && reg_used_between_p (dest, succ, succ2))
/* Make sure that DEST is not used after SUCC but before I3. */
|| (!all_adjacent
&& ((succ2
--
1.9.3
Re: C++ PATCH to fix ICE with noexcept and -fgnu-tm (PR c++/80059)
On Fri, Mar 17, 2017 at 10:45 AM, Marek Polacek wrote: > + cond = instantiate_non_dependent_expr_sfinae (cond, tf_none); Why this rather than instantiate_non_dependent_expr (and so tf_error)? Jason
Re: [PATCH] Document -fipa-vrp
On Fri, 17 Mar 2017, Martin Jambor wrote: > I have noticed that -fipa-vrp was not documented in gcc/doc/invoke.texi > so I propose the following. When at ti, I took the liberty of replacing > "ipa" with "interprocedural" in the description of -fipa-bit-cp. That's definitely a good change, thank you! (Richi already okayed, but as a general note, reducing "special lingo" in our documention generally is a good thing.) Gerald
[BUILDROBOT] Maybe uninitialized warnings in mips targets (was: [PATCH] Fix PR79345, better uninit warnings for memory)
Hi Richard, Catherine, Matthew On Thu, 2017-03-02 14:40:46 +0100, Richard Biener wrote: [...] > On IRC we decided to wait&see for the TREE_NO_WARNING issue. So the > following is what I committed. > > Bootstrapped / tested on x86_64-unknown-linux-gnu. [...] > 2017-03-02 Richard Biener > > PR tree-optimization/79345 > PR c++/42000 > * tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit > param and abort the walk, returning -1 if it is hit. > (walk_aliased_vdefs): Take a limit param and pass it on. > * tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param, > defaulting to 0 and return a signed int. > * tree-ssa-uninit.c (struct check_defs_data): New struct. > (check_defs): New helper. > (warn_uninitialized_vars): Use walk_aliased_vdefs to warn > about uninitialized memory. > > * fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid > bogus uninitialized warning. > (fixed_convert_from_real): Likewise. > > * g++.dg/warn/Wuninitialized-7.C: New testcase. > * c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized. > * gcc.dg/uninit-pr19430-2.c: Add expected warning. When building with config-list.mk, it seems to break for all of the listed MIPS targets, but not on any other architecture: [...] g++ -fno-PIE -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/scratch/4/jbglaw/configlist/repos/gcc/gcc -I/scratch/4/jbglaw/configlist/repos/gcc/gcc/. -I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../include -I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libcpp/include -I/opt/cfarm/mpc/include -I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libdecnumber -I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/scratch/4/jbglaw/configlist/repos/gcc/gcc/../libbacktrace -o mips.o -MT mips.o -MMD -MP -MF ./.deps/mips.TPo /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c In file included from /scratch/4/jbglaw/configlist/repos/gcc/gcc/hash-table.h:236:0, from /scratch/4/jbglaw/configlist/repos/gcc/gcc/coretypes.h:369, from /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c:26: /scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h: In function ‘mips_multi_member* mips_multi_add()’: /scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *slot = obj; ^ /scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h: In function ‘void mips_process_sync_loop(rtx_insn*, rtx_def**)’: /scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *slot = obj; ^ /scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *slot = obj; ^ /scratch/4/jbglaw/configlist/repos/gcc/gcc/vec.h:865:3: error: ‘empty’ may be used uninitialized in this function [-Werror=maybe-uninitialized] *slot = obj; ^ /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c: In function ‘bool mips_expand_vec_perm_const(rtx_def**)’: /scratch/4/jbglaw/configlist/repos/gcc/gcc/config/mips/mips.c:21362:10: error: ‘orig_perm’ may be used uninitialized in this function [-Werror=maybe-uninitialized] memcpy (d.perm, orig_perm, MAX_VECT_LEN); ~~~^ cc1plus: all warnings being treated as errors make[2]: *** [mips.o] Error 1 See eg. all the most recent builds: mips64el-st-linux-gnu: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699675 mips64orion-elf: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699678 mipsisa32r2-linux-gnu: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699702 mipsisa32-elfoabi: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699701 mipsisa64sb1-elf: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699724 mipsisa64sr71k-elf: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699726 mips-netbsd: http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=699750 MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: God put me on earth to accomplish a certain number of the second :things. Right now I am so far behind I will never die. signature.asc Description: Digital signature
Re: Updating config.guess
On Mon, 13 Mar 2017, Jeff Law wrote:
>> Here is the entire difference between the config.guess we have
>> and upstream.
> Yea, fine with me.
Cool, here is what I just installed.
(Richi, i386-unknown-freebsd* is now "gone", both in terms of
our release documentation and automatic target detection.)
Gerald
2017-03-18 Gerald Pfeifer
* config.guess: Import latest from upstream.
Index: config.guess
===
--- config.guess(revision 246257)
+++ config.guess(working copy)
@@ -1,8 +1,8 @@
#! /bin/sh
# Attempt to guess a canonical system name.
-# Copyright 1992-2016 Free Software Foundation, Inc.
+# Copyright 1992-2017 Free Software Foundation, Inc.
-timestamp='2016-10-02'
+timestamp='2017-03-05'
# This file is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
@@ -50,7 +50,7 @@
GNU config.guess ($timestamp)
Originally written by Per Bothner.
-Copyright 1992-2016 Free Software Foundation, Inc.
+Copyright 1992-2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -837,10 +837,11 @@
UNAME_PROCESSOR=`/usr/bin/uname -p`
case ${UNAME_PROCESSOR} in
amd64)
- echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e
's/[-(].*//'` ;;
- *)
- echo ${UNAME_PROCESSOR}-unknown-freebsd`echo
${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
+ UNAME_PROCESSOR=x86_64 ;;
+ i386)
+ UNAME_PROCESSOR=i586 ;;
esac
+ echo ${UNAME_PROCESSOR}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e
's/[-(].*//'`
exit ;;
i*:CYGWIN*:*)
echo ${UNAME_MACHINE}-pc-cygwin
@@ -1343,6 +1344,9 @@
NSR-?:NONSTOP_KERNEL:*:*)
echo nsr-tandem-nsk${UNAME_RELEASE}
exit ;;
+NSX-?:NONSTOP_KERNEL:*:*)
+ echo nsx-tandem-nsk${UNAME_RELEASE}
+ exit ;;
*:NonStop-UX:*:*)
echo mips-compaq-nonstopux
exit ;;
New French PO file for 'gcc' (version 7.1-b20170226)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the French team of translators. The file is available at: http://translationproject.org/latest/gcc/fr.po (This file, 'gcc-7.1-b20170226.fr.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [libstdc++,doc] Strip links to ANSI (web shop)
On Wed, 15 Feb 2017, Jonathan Wakely wrote: > The C++14 standard is: > http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2fIEC+14882%3a2014 Thanks, Jonathan! >> What do you think? > Should we make the FAQ link to the info in the manual, instead of just > removing it? Great idea. Unfortunately I do not know the Docbook magic to do this for the libstdc++ documentation, so I went ahead with the simple version below. Can you perhaps help making this a "real" link? Gerald 2017-03-18 Gerald Pfeifer * doc/xml/manual/appendix_contributing.xml: Convert link to ansi.org to https. Update link to the C++ standard at ansi.org. * doc/xml/faq.xml: Remove information redundant with the above; instead add a reference. Index: doc/xml/manual/appendix_contributing.xml === --- doc/xml/manual/appendix_contributing.xml(revision 246258) +++ doc/xml/manual/appendix_contributing.xml(working copy) @@ -45,9 +45,11 @@ the standard from their respective national standards organization. In the USA, this national standards organization is - http://www.w3.org/1999/xlink"; xlink:href="http://www.ansi.org";>ANSI. - (And if you've already registered with them you can - http://www.w3.org/1999/xlink"; xlink:href="http://webstore.ansi.org/RecordDetail.aspx?sku=INCITS%2fISO%2fIEC+14882-2012";>buy the standard on-line.) + http://www.w3.org/1999/xlink"; xlink:href="https://www.ansi.org";>ANSI. + (And if you've already registered with them you can http://www.w3.org/1999/xlink"; + xlink:href="https://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2fIEC+14882%3a2014";>buy + the standard on-line.) Index: doc/xml/faq.xml === --- doc/xml/faq.xml (revision 246258) +++ doc/xml/faq.xml (working copy) @@ -1177,25 +1177,7 @@ -Copies of the full ISO 14882 standard are available on line via -the ISO mirror site for committee members. Non-members, or those -who have not paid for the privilege of sitting on the committee -and sustained their two-meeting commitment for voting rights, may -get a copy of the standard from their respective national -standards organization. In the USA, this national standards -organization is ANSI and their website is -right http://www.w3.org/1999/xlink"; xlink:href="http://www.ansi.org";>here. (And if -you've already registered with them, clicking this link will take -you to directly to the place where you can -http://www.w3.org/1999/xlink"; xlink:href="http://webstore.ansi.org/RecordDetail.aspx?sku=ISO%2FIEC+14882:2003";>buy the standard on-line. - - -Who is your country's member body? Visit the -http://www.w3.org/1999/xlink"; xlink:href="http://www.iso.ch/";>ISO homepage and find out! - - -The 2003 version of the standard (the 1998 version plus TC1) is -available in print, ISBN 0-470-84674-7. +Please refer to the Contributing section in our manual.
[doc] Add Segher to contrib.texi
Applied. (Segher kindly reviewed this in draft form.) If anyone else is missing, now would be a good time to speak up. ;) Gerald 2017-03-18 Gerald Pfeifer * doc/contrib.texi (Contributors): Add Segher Boessenkool. Index: doc/contrib.texi === --- doc/contrib.texi(revision 246259) +++ doc/contrib.texi(working copy) @@ -89,6 +89,10 @@ Java work. @item +Segher Boessenkool for helping maintain the PowerPC port and the +instruction combiner plus various contributions to the middle end. + +@item Neil Booth for work on cpplib, lang hooks, debug hooks and other miscellaneous clean-ups.
Re: [PATCH][AArch64][wwwdocs] Summarise some more AArch64 changes for GCC6
On Wed, 27 Apr 2016, Kyrill Tkachov wrote: > Thanks, I've incorporated your and James' feedback. > Since James ok'd the content of the patch from an AArch64 perspective > I'll commit this later today if I receive no further feedback. Thanks, Kyrill, those were quite some additions! I made a few follow-up changes to simplify things (and avoided calling -mcpu=native a new option, since it already exists for other targets). Applied. Gerald Index: gcc-6/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v retrieving revision 1.97 diff -u -r1.97 changes.html --- gcc-6/changes.html 11 Mar 2017 22:48:21 - 1.97 +++ gcc-6/changes.html 18 Mar 2017 22:36:07 - @@ -392,11 +392,11 @@ A number of AArch64-specific options have been added. The most - important ones are summarised in this section but for usage - instructions please refer to the documentation. + important ones are summarised in this section; for more detailed + information please refer to the documentation. - The new command-line options -march=native, + The command-line options -march=native, -mcpu=native and -mtune=native are now available on native AArch64 GNU/Linux systems. Specifying these options causes GCC to auto-detect the host CPU and @@ -470,14 +470,14 @@ Improvements in the generation of conditional branches and literal - pools were made to allow the compiler to compile functions of a large + pools allow the compiler to compile functions of a large size. Constant pools are now placed into separate rodata sections. - The new option -mpc-relative-literal-loads is - introduced to generate per-function literal pools, limiting the maximum + The new option -mpc-relative-literal-loads + generates per-function literal pools, limiting the maximum size of functions to 1MiB. - Several correctness issues with generation of Advanced SIMD instructions + Several correctness issues generating Advanced SIMD instructions for big-endian targets have been fixed resulting in improved code generation for ACLE intrinsics with -mbig-endian.
[Patch, fortran] PR39239 EQUIVALENCE and BIND(C)
Hello everyone,
I submitted this patch a week ago, but I think it got lost. It adds an
error if BIND(C) is used with EQUIVALENCE.
Nicolas
Regression tested for x86_64-pc-linux-gnu.
2017-03-18 Nicolas Koenig
PR fortran/39239
* resolve.c (resolve_equivalence): report an error if
an equivalence variable is BIND(C).
2017-03-18 Nicolas Koenig
PR fortran/39239
* gfortran.dg/equiv_constraint_bind_c.f90: New test.
Index: resolve.c
===
--- resolve.c (revision 246070)
+++ resolve.c (working copy)
@@ -15675,6 +15675,13 @@ resolve_equivalence (gfc_equiv *eq)
&& !resolve_equivalence_derived (e->ts.u.derived, sym, e))
continue;
+ if (sym->attr.is_bind_c)
+ {
+ gfc_error ("EQUIVALENCE object %qs at %L cannot be BIND(C)",
+ sym->name, &e->where);
+ continue;
+ }
+
/* Check that the types correspond correctly:
Note 5.28:
A numeric sequence structure may be equivalenced to another sequence
! Testcase for using EQUIVALENCE with BIND(C)
! See PR fortran/39239
! { dg-do compile }
module m
use iso_c_binding
implicit none
integer(c_int) :: i1, i2
bind(C) :: i2
equivalence(i1,i2) ! { dg-error "cannot be BIND" }
end module m
Re: [doc] Add Segher to contrib.texi
On Sat, Mar 18, 2017 at 10:17:00PM +0100, Gerald Pfeifer wrote: > Applied. Thanks! You now have added two entries for me; fixed like this: 2017-03-18 Segher Boessenkool * doc/contrib.texi (Contributors): Remove duplicate entry for myself. --- gcc/doc/contrib.texi | 3 --- 1 file changed, 3 deletions(-) diff --git a/gcc/doc/contrib.texi b/gcc/doc/contrib.texi index 3fc7dc1..4f5ffc1 100644 --- a/gcc/doc/contrib.texi +++ b/gcc/doc/contrib.texi @@ -82,9 +82,6 @@ specifications. Janne Blomqvist for contributions to GNU Fortran. @item -Segher Boessenkool for various fixes. - -@item Hans-J. Boehm for his garbage collector, IA-64 libffi port, and other Java work. -- 1.9.3
Re: Combiner fix for PR79910
On Sat, Mar 18, 2017 at 11:23:56AM -0500, Segher Boessenkool wrote:
> Bootstrapped and regression checked on x86_64-linux and powerpc64-linux
> {-m32,-m64}.
Now also tested on aarch64-linux; no new failures.
Segher
> 2017-03-18 Segher Boessenkool
>
> PR rtl-optimization/79910
> * combine.c (can_combine_p): Do not allow combining an I0 or I1
> if its dest is used by an insn before I2 (other than the combined
> insns themselves, which are properly handled already).
