Re: [C++ PATCH] PR c++/35878
On Sun, Mar 19, 2017 at 6:19 PM, Ville Voutilainen wrote: > I ran the tests for g++.dg/init thus far. Does this patch make sense? The condition needs to be a lot more specific: DR 1748 only applies to the non-allocating forms in [new.delete.placement], not to other placement allocation functions. Jason
C++ PATCH for c++/80084, C++17 structured binding to invisiref parameter
Here, we had DECL_VALUE_EXPR of a structured binding referring to a
pass-by-invisible-reference parameter, but not being adjusted by
cp_genericize. We get here because we were looking through a
reference temporary. Removing that code doesn't seem to break
anything; I'm guessing that it isn't needed anymore because of my
change to support references better in constexpr evaluation.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 793633ca2cbbcd2ba9175320728745d6ebcba9e8
Author: Jason Merrill
Date: Sat Mar 18 23:47:50 2017 -0400
PR c++/80084 - wrong C++17 decomposition by reference of parameter.
* decl.c (cp_finish_decomp): Don't pull out the DECL_INITIAL of a
reference decomposition.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index bf24e8b..0a92566 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -7439,9 +7439,6 @@ cp_finish_decomp (tree decl, tree first, unsigned int
count)
if (TREE_CODE (type) == REFERENCE_TYPE)
{
- /* If e is a constant reference, use the referent directly. */
- if (DECL_INITIAL (decl))
- dexp = DECL_INITIAL (decl);
dexp = convert_from_reference (dexp);
type = TREE_TYPE (type);
}
diff --git a/gcc/testsuite/g++.dg/cpp1z/decomp27.C
b/gcc/testsuite/g++.dg/cpp1z/decomp27.C
new file mode 100644
index 000..f26722a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/decomp27.C
@@ -0,0 +1,26 @@
+// PR c++/80084
+// { dg-options -std=c++1z }
+// { dg-do run }
+
+struct A
+{
+ A() { }
+ A(const A&) { }
+};
+
+struct B
+{
+ A a;
+};
+
+void f(B b)
+{
+ auto& [a] = b;
+ if (&a != &b.a)
+__builtin_abort();
+}
+
+int main()
+{
+ f(B());
+}
C++ PATCH for c++/80077, constexpr and -fno-elide-constructors
My patch to exclude assignments in the actual initializer from being
considered constant-expressions broke this case, where we represent a
trivial copy constructor with a MODIFY_EXPR. Fixed by indicating that
we are effectively in a call to a constexpr function.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8df62c0b0c1c1e57bc5c043231d6bab9e9b5dae0
Author: Jason Merrill
Date: Fri Mar 17 14:55:46 2017 -0400
PR c++/80077 - error with constexpr and -fno-elide-constructors.
* constexpr.c (cxx_eval_call_expression): Set ctx->call while
expanding trivial constructor.
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 4136b34..3ca3560 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -1478,7 +1478,8 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
else
op = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (op)), op);
tree set = build2 (MODIFY_EXPR, TREE_TYPE (op), op, init);
- return cxx_eval_constant_expression (ctx, set, lval,
+ new_ctx.call = &new_call;
+ return cxx_eval_constant_expression (&new_ctx, set, lval,
non_constant_p, overflow_p);
}
}
@@ -1496,7 +1497,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
}
/* If in direct recursive call, optimize definition search. */
- if (ctx && ctx->call && ctx->call->fundef->decl == fun)
+ if (ctx && ctx->call && ctx->call->fundef && ctx->call->fundef->decl == fun)
new_call.fundef = ctx->call->fundef;
else
{
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial3.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial3.C
new file mode 100644
index 000..6833cd3
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-trivial3.C
@@ -0,0 +1,6 @@
+// PR c++/80077
+// { dg-do compile { target c++11 } }
+// { dg-options -fno-elide-constructors }
+
+struct X_t { X_t() = default; };
+constexpr X_t x = X_t();
[PATCH v3, doc] Revise GCC manual section 6.11, Additional Floating Types
On Fri, 2017-03-17 at 21:44 +, Joseph Myers wrote:
> On Fri, 17 Mar 2017, Bill Schmidt wrote:
>
> > Joseph, any further comments, or may I commit this?
>
> Is there a current patch version somewhere reflecting all comments so far?
>
The previous version had one comment against it, to remove "64-bit" from
the discussion of PowerPC Linux targets.
Here's a new patch with that resolved.
Thanks,
Bill
2017-03-19 Bill Schmidt
* doc/extend.texi (6.11 Additional Floating Types): Revise.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 246227)
+++ gcc/doc/extend.texi (working copy)
@@ -948,10 +948,28 @@ names can be used together with @code{_Complex} to
types.
As an extension, GNU C and GNU C++ support additional floating
-types, @code{__float80} and @code{__float128} to support 80-bit
-(@code{XFmode}) and 128-bit (@code{TFmode}) floating types; these are
-aliases for the type names @code{_Float64x} and @code{_Float128}.
-Support for additional types includes the arithmetic operators:
+types, which are not supported by all targets.
+@itemize @bullet
+@item @code{__float128} is available on i386, x86_64, IA-64, and
+hppa HP-UX, as well as on PowerPC GNU/Linux targets that enable
+the vector scalar (VSX) instruction set. @code{__float128} supports
+the 128-bit floating type. On i386, x86_64, PowerPC, and IA-64
+other than HP-UX, @code{__float128} is an alias for @code{_Float128}.
+On hppa and IA-64 HP-UX, @code{__float128} is an alias for @code{long
+double}.
+
+@item @code{__float80} is available on the i386, x86_64, and IA-64
+targets, and supports the 80-bit (@code{XFmode}) floating type. It is
+an alias for the type name @code{_Float64x} on these targets.
+
+@item @code{__ibm128} is available on PowerPC targets, and provides
+access to the IBM extended double format which is the current format
+used for @code{long double}. When @code{long double} transitions to
+@code{__float128} on PowerPC in the future, @code{__ibm128} will remain
+for use in conversions between the two types.
+@end itemize
+
+Support for these additional types includes the arithmetic operators:
add, subtract, multiply, divide; unary arithmetic operators;
relational operators; equality operators; and conversions to and from
integer and other floating types. Use a suffix @samp{w} or @samp{W}
@@ -958,6 +976,22 @@ integer and other floating types. Use a suffix @s
in a literal constant of type @code{__float80} or type
@code{__ibm128}. Use a suffix @samp{q} or @samp{Q} for @code{_float128}.
+In order to use @code{_Float128}, @code{__float128}, and @code{__ibm128}
+on PowerPC Linux systems, you must use the @option{-mfloat128} option. It is
+expected in future versions of GCC that @code{_Float128} and @code{__float128}
+will be enabled automatically.
+
+The @code{_Float128} type is supported on all systems where
+@code{__float128} is supported or where @code{long double} has the
+IEEE binary128 format. The @code{_Float64x} type is supported on all
+systems where @code{__float128} is supported. The @code{_Float32}
+type is supported on all systems supporting IEEE binary32; the
+@code{_Float64} and @code{_Float32x} types are supported on all systems
+supporting IEEE binary64. The @code{_Float16} type is supported on AArch64
+systems by default, and on ARM systems when the IEEE format for 16-bit
+floating-point types is selected with @option{-mfp16-format=ieee}.
+GCC does not currently support @code{_Float128x} on any systems.
+
On the i386, x86_64, IA-64, and HP-UX targets, you can declare complex
types using the corresponding internal complex type, @code{XCmode} for
@code{__float80} type and @code{TCmode} for @code{__float128} type:
@@ -967,16 +1001,6 @@ typedef _Complex float __attribute__((mode(TC))) _
typedef _Complex float __attribute__((mode(XC))) _Complex80;
@end smallexample
-In order to use @code{_Float128}, @code{__float128} and
-@code{__ibm128} on PowerPC Linux
-systems, you must use the @option{-mfloat128}. It is expected in
-future versions of GCC that @code{_Float128} and @code{__float128}
-will be enabled
-automatically. In addition, there are currently problems in using the
-complex @code{__float128} type. When these problems are fixed, you
-would use the following syntax to declare @code{_Complex128} to be a
-complex @code{__float128} type:
-
On the PowerPC Linux VSX targets, you can declare complex types using
the corresponding internal complex type, @code{KCmode} for
@code{__float128} type and @code{ICmode} for @code{__ibm128} type:
@@ -986,27 +1010,6 @@ typedef _Complex float __attribute__((mode(KC))) _
typedef _Complex float __attribute__((mode(IC))) _Complex_ibm128;
@end smallexample
-Not all targets support additional floating-point types.
-@code{__float80} and @code{__float128} types are supported on x86 and
-IA-64 targets. The @code{__float128} type is supported on hppa HP-UX.
-The @code{__
[Patch, fortran] PR69498 Fixing ICE with double free on symbol
Hello everyone,
a one-line-fix for one of the test cases in pr69498. The refs count of
the ppr@ symbol wasn't set properly. Attached are the patch & the test case.
If I understand the 'Write Access' page correctly, this would be the
kind of patch I would not have to bother the mailing list with but
instead could commit directly? Would this count as an "obvious fix"?
Nicolas
Regression tested for x86_64-pc-linux-gnu.
2017-03-18 Nicolas Koenig
PR fortran/69498
* decl.c (add_hidden_procptr_result): Fixed Refs count
of the created "ppr@" symbol.
2017-03-18 Nicolas Koenig
PR fortran/69498
* gfortran.dg/unexp_attribute.f90: New test
! { dg-do compile }
! This test used to result in an internal compiler error
function f()
interface
external f ! { dg-error "Unexpected attribute declaration statement in INTERFACE" }
end interface
end function
Index: decl.c
===
--- decl.c (revision 246260)
+++ decl.c (working copy)
@@ -5430,6 +5430,7 @@ add_hidden_procptr_result (gfc_symbol *sym)
gfc_get_sym_tree ("ppr@", gfc_current_ns->parent, &stree, false);
st2 = gfc_new_symtree (&gfc_current_ns->sym_root, "ppr@");
st2->n.sym = stree->n.sym;
+ stree->n.sym->refs++;
}
sym->result = stree->n.sym;
[C++ PATCH] PR c++/35878
I ran the tests for g++.dg/init thus far. Does this patch make sense?
2017-03-20 Ville Voutilainen
gcc/
PR c++/35878
* cp/init.c (build_new_1): Don't do a null check for
a placement new.
testsuite/
PR c++/35878
* testsuite/g++.dg/init/placement6.C: New.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 8bfcbde..d3ac96f 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -3450,7 +3450,7 @@ build_new_1 (vec **placement, tree type,
tree nelts,
rval = TARGET_EXPR_INITIAL (alloc_expr);
else
{
- if (check_new)
+ if (check_new && (nothrow || !placement_allocation_fn_p))
{
tree ifexp = cp_build_binary_op (input_location,
NE_EXPR, alloc_node,
diff --git a/gcc/testsuite/g++.dg/init/placement6.C
b/gcc/testsuite/g++.dg/init/placement6.C
new file mode 100644
index 000..5e43812
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/placement6.C
@@ -0,0 +1,21 @@
+// { dg-options "-O2 --std=gnu++11" }
+// { dg-do compile }
+// { dg-final { scan-assembler-not "test rdi, rdi" { target i?86-*-*
x86_64-*-* } } }
+#include
+#include
+
+struct s1{
+ int a;
+ int b;
+ int c;
+};
+
+void f1 (s1 * v, s1&& s)
+{
+ new (v) s1(std::move(s));
+}
+
+void f2 (s1 * v, s1&& s)
+{
+ *v = std::move(s);
+}
Re: [PATCH] Fix r242743 change of gcc/system.h
On 19/03/2017 22:17, Gunther Nikl wrote: > Hello Paolo! > > Building older GCC releases with clang tends to issue warnings. This > can be annoying especially when they originate from a header. While > backporting r242743 I noticed that the non-C++ cases of the changed > macro definitions in gcc/system.h are broken. Since GCC trunk is build > in C++ mode this is not an issue, but should be fixed nevertheless I > think. > > Regards, > Gunther Of course! If you have commit access, you can commit this as obvious I think. What is the warning like? Paolo > > gcc: > 2017-03-XX Gunther Nikl > > * system.h (HAVE_DESIGNATED_INITIALIZERS, > HAVE_DESIGNATED_UNION_INITIALIZERS): Fix non C++ case. > > > Index: gcc/system.h > === > --- gcc/system.h (revision 246106) > +++ gcc/system.h (working copy) > @@ -581,7 +581,7 @@ extern int vsnprintf (char *, size_t, const char * > #define HAVE_DESIGNATED_INITIALIZERS 0 > #else > #define HAVE_DESIGNATED_INITIALIZERS \ > - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > #endif > #endif > > @@ -590,7 +590,7 @@ extern int vsnprintf (char *, size_t, const char * > #define HAVE_DESIGNATED_UNION_INITIALIZERS (GCC_VERSION >= 4007) > #else > #define HAVE_DESIGNATED_UNION_INITIALIZERS \ > - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) > #endif > #endif > >
[PATCH] Fix r242743 change of gcc/system.h
Hello Paolo! Building older GCC releases with clang tends to issue warnings. This can be annoying especially when they originate from a header. While backporting r242743 I noticed that the non-C++ cases of the changed macro definitions in gcc/system.h are broken. Since GCC trunk is build in C++ mode this is not an issue, but should be fixed nevertheless I think. Regards, Gunther gcc: 2017-03-XX Gunther Nikl * system.h (HAVE_DESIGNATED_INITIALIZERS, HAVE_DESIGNATED_UNION_INITIALIZERS): Fix non C++ case. Index: gcc/system.h === --- gcc/system.h(revision 246106) +++ gcc/system.h(working copy) @@ -581,7 +581,7 @@ extern int vsnprintf (char *, size_t, const char * #define HAVE_DESIGNATED_INITIALIZERS 0 #else #define HAVE_DESIGNATED_INITIALIZERS \ - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) #endif #endif @@ -590,7 +590,7 @@ extern int vsnprintf (char *, size_t, const char * #define HAVE_DESIGNATED_UNION_INITIALIZERS (GCC_VERSION >= 4007) #else #define HAVE_DESIGNATED_UNION_INITIALIZERS \ - (((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) + ((GCC_VERSION >= 2007) || (__STDC_VERSION__ >= 199901L)) #endif #endif
Re: [wwwdocs] readings.html maintenance
On Sun, 19 Mar 2017, Richard Earnshaw (lists) wrote: >> HPPA and ARM maintainers on copy, if you want to add more appropriate >> links, we can definitely do so of course, though I'd argue with none >> of our users or developers raising this, probably not a lot of interest >> in those specifically? > All the ARM ABI documents can be found here. > > http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html Thanks for the pointer, Richard. I added this, alas not in the misc section, but under ARM this time. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.272 diff -u -r1.272 readings.html --- readings.html 19 Mar 2017 08:25:55 - 1.272 +++ readings.html 19 Mar 2017 20:25:19 - @@ -83,6 +83,7 @@ Manufacturer: Various, by license from ARM. CPUs include: ARM7TDMI, and the Cortex-A, Cortex-R and Cortex-M series. http://infocenter.arm.com/help/index.jsp";>ARM Documentation + http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/";>Application Binary Interface (ABI) for the ARM Architecture AVR
Re: [PATCH doc] use "cannot" consistently
On 03/15/2017 09:40 AM, Martin Sebor wrote: On 03/15/2017 05:00 AM, Richard Kenner wrote: First, I agree that the less formal language is becoming more acceptable. Some style guides explicitly allow contractions, but others advise against them. The technical specifications that significant parts of GCC aim to conform to, and those I happen to work with the most closely (the C, C++, and POSIX standards), avoid them. The IEEE Editorial Style Manual recommends against using them. The author of Engineer's Guide to Technical Writing, Kenneth Budinski, equates them with slang. How old are those documents? More recently, see They're all the latest versions (C++ 2011, C++ 2017, and the IEEE Editorial Style Manual is the 2016 update). But to get a more representative sample I've surveyed some other references I have sitting on my hard drive. I found none that uses contractions: ARM Compiler Toolchain 4.1 Reference (2011) Clang 5,0 Compiler User’s Manual(*) (2017) DWARF Debugging Information Format Version 5 (2017) HP aCC 6.20 C Programmer's Guide(**)(2008) IBM Power ISA Version 3.0 (2015) IBM XL C/C++ for Linux, V13.1 Compiler Reference (2014) Intel C++ Compiler 17.0 Developer Guide and Reference (2016) Intel 64 and IA-32 Architectures Software Developer’s Manual (2011) MIPS64 Architecture for Programmers (2010) Oracle Developer Studio 12.5 C/C++ Users Guide (2016) [*] Except for a few instances of don't. [**] "Can't" used in comments in coding examples. http://www.plainlanguage.gov/howto/guidelines/bigdoc/writeContract.cfm https://lawyerist.com/61487/is-it-time-for-contractions-in-legal-writing/ The latter references other documents, which advocate for more use of contractions even in formal writing. These are legal guides, obviously not relevant in the context of technical writing. I personally don't feel too strongly about it, but the change seems like an opportunity to improve not just the style of the manual but also increase its consistency. I could see one being indifferent to such changes but I have trouble understanding how they could be viewed as the wrong direction. What is your rationale against it and what would you consider the right direction for the manual? I think it's the wrong direction because I'd be in favor of gradually *introducing* contractions into to the manual instead of a change that eliminates them. I wouldn't be against a change that went in the other direction (used contractions consistently), but it would be good a large change, so I'm not advocating for doing that, but just instead using contractions in all new material and when modifying old material for other reasons. Interesting. I don't share that view and clearly neither do writers of any of the technical specifications I listed above but I will go along with whatever the documentation maintainers think is appropriate or preferable for GCC. I got behind on mail so I'm coming into this a few days late :-( The GCC manual isn't as formal a document as a language standards document. I think "can't" is OK, but OTOH I would write "cannot" myself, and since there's already a clear bias in favor of "cannot" in the text, I think the patch is OK, modulo fixing the one use in the example. -Sandra
Re: [wwwdocs] ns32k, RIP (readings.html)
On Sun, 19 Mar 2017, Jeff Law wrote: >> and finally a note in gcc-4.0/changes.html that NS32K has >> been declared obsolete. > We killed the n32k port eons ago. Yep, see how I referred to a note in gcc-4.0/changes.html above. However, at first my search failed since I was looking for ns32k (all lowercase), so I now also applied the simply change below. Gerald Index: gcc-4.0/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.0/changes.html,v retrieving revision 1.68 diff -u -r1.68 changes.html --- gcc-4.0/changes.html27 May 2016 19:29:47 - 1.68 +++ gcc-4.0/changes.html19 Mar 2017 19:05:36 - @@ -544,7 +544,7 @@ Intel i860 Ubicom IP2022 -National Semiconductor NS32K +National Semiconductor NS32K (ns32k) Texas Instruments TMS320C[34]x
Re: [wwwdocs] readings.html maintenance
On 2017-03-19, at 4:03 AM, Gerald Pfeifer wrote: > It turns out both the hp.com link and the arm.com link now redirect > to marketing pages, so instead of chasing forever, I decided to take > them out. Removal of hp.com link is OK. Dave -- John David Anglin dave.ang...@bell.net
Re: [doc] Add Segher to contrib.texi
On Sun, Mar 19, 2017 at 08:16:52AM +0100, Gerald Pfeifer wrote: > On Sat, 18 Mar 2017, Segher Boessenkool wrote: > > You now have added two entries for me; fixed like this: > > Oops! I missed the old one from four years ago since it wasn't > sorted in properly vs Hans Boehm. Fourteen years, and no one noticed all that time. > Well, perhaps a subtle attempt to get you to contribute twice as > much? ;-) Right, that's why I had to immediately fix this :-) Cheers, Segher
Re: [BUILDROBOT] Maybe uninitialized warnings in mips targets
On 03/18/2017 12:20 PM, Jan-Benedict Glaw wrote: 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: Yes. The improved uninitialized memory warnings are catching some things that were previously missed. I've got fixes for all the MIPS thingies in a local tree, but haven't submitted them (yet). jeff
Re: [wwwdocs] ns32k, RIP (readings.html)
On 03/19/2017 02:26 AM, Gerald Pfeifer wrote: Trying to find an updated link for this I noticed that the best matches are now on ti.com, the best link, a PDF, I found has an "Obsolete" watermark across all pages, we do not have a maintainer listed in our MAINTAINERS file, and config-list.mk does not list ns32k, and finally a note in gcc-4.0/changes.html that NS32K has been declared obsolete. So, here we go; applied. We killed the n32k port eons ago. jeff
Re: [wwwdocs] readings.html maintenance
On 19/03/17 08:03, Gerald Pfeifer wrote: > It turns out both the hp.com link and the arm.com link now redirect > to marketing pages, so instead of chasing forever, I decided to take > them out. > > HPPA and ARM maintainers on copy, if you want to add more appropriate > links, we can definitely do so of course, though I'd argue with none > of our users or developers raising this, probably not a lot of interest > in those specifically? > All the ARM ABI documents can be found here. http://infocenter.arm.com/help/topic/com.arm.doc.subset.swdev.abi/index.html > Gerald > > Index: readings.html > === > RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v > retrieving revision 1.270 > diff -u -r1.270 readings.html > --- readings.html 14 Mar 2017 20:19:40 - 1.270 > +++ readings.html 19 Mar 2017 07:56:34 - > @@ -231,8 +231,7 @@ > > pa >Manufacturer: HP > - href="http://h21007.www2.hp.com/portal/site/dspp/menuitem.1b39e60a9475acc915b49c108973a801/?chid=6dc55e210a66a010VgnVCM10275d6e10RCRD#topic_pa_risc_architecture";>PA-RISC > - is preferred over the older HPPA acronym > + PA-RISC is preferred over the older HPPA acronym >(Hewlett-Packard Precision Architecture). > href="https://parisc.wiki.kernel.org/index.php/Main_Page";>parisc.wiki.kernel.org >is another good source of PA-RISC documention. > @@ -618,8 +617,6 @@ > href="http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf";>System >V PowerPC ABI > > - http://www.arm.com/products/DevTools/ABI.html";>Application > Binary Interface for the ARM Architecture (EABI) > - >http://dwarfstd.org/";>DWARF Workgroup > > href="ftp://ftp.sgi.com/sgi/dev/davea/objectinfo.html";>Debugging/object > info by David B.Anderson (including links to some DWARF tools) >
Re: [Patch, fortran] PR39239 EQUIVALENCE and BIND(C)
Hi Nicolas, Is there some reason that you didn't use symbol.c(check_conflict)? The conflict check could be added at line 547. If this results in repetitions of the error message, then your patch is OK. Otherwise, I would pop it in there. Do you have commit rights? ie. have you done the FSF paperwork? Welcome aboard! Paul On 19 March 2017 at 00:15, Nicolas Koenig wrote: > 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. > -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
[committed] OpenACC diagnostic typo fixes (PR fortran/80010)
Hi!
I've committed the following patch to fix various OpenACC diagnostic typos.
2017-03-16 Jakub Jelinek
PR fortran/80010
* parse.c (gfc_ascii_statement): Use !$ACC for ST_OACC_ATOMIC
and ST_OACC_END_ATOMIC, instead of !ACC.
* trans-decl.c (finish_oacc_declare): Use !$ACC instead of $!ACC.
* openmp.c (gfc_match_oacc_declare, gfc_match_oacc_wait,
gfc_resolve_oacc_declare): Likewise.
* gfortran.dg/goacc/asyncwait-3.f95: Adjust expected diagnostic.
--- gcc/fortran/trans-decl.c(revision 246203)
+++ gcc/fortran/trans-decl.c(revision 246204)
@@ -6133,7 +6133,7 @@ finish_oacc_declare (gfc_namespace *ns,
continue;
if (block)
- gfc_error ("Sorry, $!ACC DECLARE at %L is not allowed "
+ gfc_error ("Sorry, !$ACC DECLARE at %L is not allowed "
"in BLOCK construct", &oc->loc);
--- gcc/fortran/parse.c (revision 246203)
+++ gcc/fortran/parse.c (revision 246204)
@@ -2128,10 +2128,10 @@ gfc_ascii_statement (gfc_statement st)
p = "!$ACC ROUTINE";
break;
case ST_OACC_ATOMIC:
- p = "!ACC ATOMIC";
+ p = "!$ACC ATOMIC";
break;
case ST_OACC_END_ATOMIC:
- p = "!ACC END ATOMIC";
+ p = "!$ACC END ATOMIC";
break;
case ST_OMP_ATOMIC:
p = "!$OMP ATOMIC";
--- gcc/fortran/openmp.c(revision 246203)
+++ gcc/fortran/openmp.c(revision 246204)
@@ -2059,7 +2059,7 @@ gfc_match_oacc_declare (void)
if (n->u.map_op != OMP_MAP_FORCE_ALLOC
&& n->u.map_op != OMP_MAP_FORCE_TO)
{
- gfc_error ("Invalid clause in module with $!ACC DECLARE at %L",
+ gfc_error ("Invalid clause in module with !$ACC DECLARE at %L",
&where);
return MATCH_ERROR;
}
@@ -2069,7 +2069,7 @@ gfc_match_oacc_declare (void)
if (s->attr.use_assoc)
{
- gfc_error ("Variable is USE-associated with $!ACC DECLARE at %L",
+ gfc_error ("Variable is USE-associated with !$ACC DECLARE at %L",
&where);
return MATCH_ERROR;
}
@@ -2077,7 +2077,7 @@ gfc_match_oacc_declare (void)
if ((s->attr.dimension || s->attr.codimension)
&& s->attr.dummy && s->as->type != AS_EXPLICIT)
{
- gfc_error ("Assumed-size dummy array with $!ACC DECLARE at %L",
+ gfc_error ("Assumed-size dummy array with !$ACC DECLARE at %L",
&where);
return MATCH_ERROR;
}
@@ -2172,7 +2172,7 @@ gfc_match_oacc_wait (void)
{
if (el->expr == NULL)
{
- gfc_error ("Invalid argument to $!ACC WAIT at %L",
+ gfc_error ("Invalid argument to !$ACC WAIT at %L",
&wait_list->expr->where);
return MATCH_ERROR;
}
@@ -5985,7 +5985,7 @@ gfc_resolve_oacc_declare (gfc_namespace
if (n->expr && n->expr->ref->type == REF_ARRAY)
{
gfc_error ("Array sections: %qs not allowed in"
- " $!ACC DECLARE at %L", n->sym->name, &oc->loc);
+ " !$ACC DECLARE at %L", n->sym->name, &oc->loc);
continue;
}
}
--- gcc/testsuite/gfortran.dg/goacc/asyncwait-3.f95 (revision 246203)
+++ gcc/testsuite/gfortran.dg/goacc/asyncwait-3.f95 (revision 246204)
@@ -23,7 +23,7 @@ program asyncwait
!$acc wait (1 ! { dg-error "Syntax error in OpenACC expression list at" }
- !$acc wait (1, *) ! { dg-error "Invalid argument to \\\$\\\!ACC WAIT" }
+ !$acc wait (1, *) ! { dg-error "Invalid argument to \\\!\\\$ACC WAIT" }
!$acc wait (1, a) ! { dg-error "WAIT clause at \\\(1\\\) requires a scalar
INTEGER expression" }
Jakub
Re: [wwwdocs] Remove "New in GCC 3.4.0" from bugs/index.html
On March 19, 2017 8:53:16 AM GMT+01:00, Gerald Pfeifer wrote: >GCC 3.4.0 dates back to 2004, and by now everyone really should >have updated their stuff to newer G++ / C++ standards. ;-) Maybe this place is a good one to refer to the various porting_to.HTML pages we have that list similar issues? Richard. >Committed. > >Gerald > >Index: bugs/index.html >=== >RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v >retrieving revision 1.118 >diff -u -r1.118 index.html >--- bugs/index.html21 Nov 2015 15:41:17 - 1.118 >+++ bugs/index.html19 Mar 2017 07:49:15 - >@@ -697,78 +697,7 @@ >However, some non-conforming constructs are allowed when the >command-line > option -fpermissive is used. > >-New in GCC 3.4.0 >- >-The new parser brings a lot of improvements, especially concerning >-name-lookup. >- >- >- >-The "implicit typename" extension got removed (it was already >deprecated >-since GCC 3.1), so that the following code is now rejected, see >[14.6]: >- >-templatestruct A >-{ >-typedef int X; >-}; >- >-template struct B >-{ >-A ::X x; // error >-typename A ::X y; // OK >-}; >- >-B b; >- >- >-For similar reasons, the following code now requires the >-template keyword, see [14.2]: >- >-template struct A >-{ >-template struct X {}; >-}; >- >-template struct B >-{ >-typename A ::X<0> x; // error >-typename A ::template X<0> y; // OK >-}; >- >-B b; >- >- >-We now have two-stage name-lookup, so that the following code is >-rejected, see [14.6]/9: >- >-template int foo() >-{ >-return i; // error >-} >- >- >-This also affects members of base classes, see [14.6.2]: >- >-template struct A >-{ >-int i, j; >-}; >- >-template struct B : A >-{ >-int foo1() { return i; } // error >-int foo2() { return this->i; } // OK >-int foo3() { return B ::i; } // OK >-int foo4() { return A ::i; } // OK >- >-using A ::j; >-int foo5() { return j; } // OK >-}; >- >- >- >- >-In addition to the problems listed above, the manual contains a >section on >+The manual contains a section on >href="https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html";> > Common Misunderstandings with GNU C++. >
Re: [PATCH] Add RISC-V Maintainers
ping. On Thu, Feb 9, 2017 at 2:50 AM, Palmer Dabbelt wrote: > 2017-02-08 Palmer Dabbelt > > * MAINTAINERS (CPU Port Maintainers): Add Kito Cheng, Palmer Dabbelt, > and Andrew Waterman as the RISC-V maintainers. > --- > ChangeLog | 5 + > MAINTAINERS | 3 +++ > 2 files changed, 8 insertions(+) > > diff --git a/ChangeLog b/ChangeLog > index d2c498a..2623a7d 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2017-02-08 Palmer Dabbelt > + > + * MAINTAINERS (CPU Port Maintainers): Add Kito Cheng, Palmer Dabbelt, > + and Andrew Waterman as the RISC-V maintainers. > + > 2017-02-07 Gerald Pfeifer > > * MAINTAINERS: Adjust bug reporting URL. > diff --git a/MAINTAINERS b/MAINTAINERS > index aad4231..6f29872 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -88,6 +88,9 @@ nios2 portSandra Loosemore > > nvptx port Bernd Schmidt > pdp11 port Paul Koning > picochip port Daniel Towner > +riscv port Kito Cheng > +riscv port Palmer Dabbelt > +riscv port Andrew Waterman > rl78 port DJ Delorie > rs6000/powerpc portDavid Edelsohn > rs6000/powerpc portSegher Boessenkool > -- > 2.10.2 >
[wwwdocs] ns32k, RIP (readings.html)
Trying to find an updated link for this I noticed that the best matches are now on ti.com, the best link, a PDF, I found has an "Obsolete" watermark across all pages, we do not have a maintainer listed in our MAINTAINERS file, and config-list.mk does not list ns32k, and finally a note in gcc-4.0/changes.html that NS32K has been declared obsolete. So, here we go; applied. Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.271 diff -u -r1.271 readings.html --- readings.html 19 Mar 2017 08:03:04 - 1.271 +++ readings.html 19 Mar 2017 08:20:43 - @@ -224,11 +224,6 @@ GDB includes a simulator. - ns32k - Manufacturer: National Semiconductor - http://www.national.com/pf/NS/NS32FX200.html";>NS32FX200 Home Page - - pa Manufacturer: HP PA-RISC is preferred over the older HPPA acronym
Re: install.texi and sparc-*-linux*
On Mär 19 2017, Gerald Pfeifer wrote:
> Index: doc/install.texi
> ===
> --- doc/install.texi (revision 246259)
> +++ doc/install.texi (working copy)
> @@ -4510,11 +4510,6 @@
> @anchor{sparc-x-linux}
> @heading sparc-*-linux*
>
> -GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
> -or newer on this platform. All earlier binutils and glibc
> -releases mishandled unaligned relocations on @code{sparc-*-*} targets.
> -
> -
> @html
>
> @end html
The section is now empty. Should it be removed at all?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
[wwwdocs] readings.html maintenance
It turns out both the hp.com link and the arm.com link now redirect to marketing pages, so instead of chasing forever, I decided to take them out. HPPA and ARM maintainers on copy, if you want to add more appropriate links, we can definitely do so of course, though I'd argue with none of our users or developers raising this, probably not a lot of interest in those specifically? Gerald Index: readings.html === RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v retrieving revision 1.270 diff -u -r1.270 readings.html --- readings.html 14 Mar 2017 20:19:40 - 1.270 +++ readings.html 19 Mar 2017 07:56:34 - @@ -231,8 +231,7 @@ pa Manufacturer: HP - http://h21007.www2.hp.com/portal/site/dspp/menuitem.1b39e60a9475acc915b49c108973a801/?chid=6dc55e210a66a010VgnVCM10275d6e10RCRD#topic_pa_risc_architecture";>PA-RISC - is preferred over the older HPPA acronym + PA-RISC is preferred over the older HPPA acronym (Hewlett-Packard Precision Architecture). https://parisc.wiki.kernel.org/index.php/Main_Page";>parisc.wiki.kernel.org is another good source of PA-RISC documention. @@ -618,8 +617,6 @@ http://refspecs.linux-foundation.org/elf/elfspec_ppc.pdf";>System V PowerPC ABI - http://www.arm.com/products/DevTools/ABI.html";>Application Binary Interface for the ARM Architecture (EABI) - http://dwarfstd.org/";>DWARF Workgroup ftp://ftp.sgi.com/sgi/dev/davea/objectinfo.html";>Debugging/object info by David B.Anderson (including links to some DWARF tools)
[wwwdocs] Remove "New in GCC 3.4.0" from bugs/index.html
GCC 3.4.0 dates back to 2004, and by now everyone really should have updated their stuff to newer G++ / C++ standards. ;-) Committed. Gerald Index: bugs/index.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/index.html,v retrieving revision 1.118 diff -u -r1.118 index.html --- bugs/index.html 21 Nov 2015 15:41:17 - 1.118 +++ bugs/index.html 19 Mar 2017 07:49:15 - @@ -697,78 +697,7 @@ However, some non-conforming constructs are allowed when the command-line option -fpermissive is used. -New in GCC 3.4.0 - -The new parser brings a lot of improvements, especially concerning -name-lookup. - - - -The "implicit typename" extension got removed (it was already deprecated -since GCC 3.1), so that the following code is now rejected, see [14.6]: - -templatestruct A -{ -typedef int X; -}; - -template struct B -{ -A ::X x; // error -typename A ::X y; // OK -}; - -B b; - - -For similar reasons, the following code now requires the -template keyword, see [14.2]: - -template struct A -{ -template struct X {}; -}; - -template struct B -{ -typename A ::X<0> x; // error -typename A ::template X<0> y; // OK -}; - -B b; - - -We now have two-stage name-lookup, so that the following code is -rejected, see [14.6]/9: - -template int foo() -{ -return i; // error -} - - -This also affects members of base classes, see [14.6.2]: - -template struct A -{ -int i, j; -}; - -template struct B : A -{ -int foo1() { return i; } // error -int foo2() { return this->i; } // OK -int foo3() { return B ::i; } // OK -int foo4() { return A ::i; } // OK - -using A ::j; -int foo5() { return j; } // OK -}; - - - - -In addition to the problems listed above, the manual contains a section on +The manual contains a section on https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html";> Common Misunderstandings with GNU C++.
Re: install.texi and sparc-*-linux*
On Sun, 12 Mar 2017, David Miller wrote:
>> Okay to yank it?
> No objections from me.
Thanks. Here is what I just committed.
Gerald
2017-03-19 Gerald Pfeifer
* doc/install.texi (Specific) : No longer refer
to age-old versions of binutils and glibc.
Index: doc/install.texi
===
--- doc/install.texi(revision 246259)
+++ doc/install.texi(working copy)
@@ -4510,11 +4510,6 @@
@anchor{sparc-x-linux}
@heading sparc-*-linux*
-GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
-or newer on this platform. All earlier binutils and glibc
-releases mishandled unaligned relocations on @code{sparc-*-*} targets.
-
-
@html
@end html
Re: [doc] Add Segher to contrib.texi
On Sat, 18 Mar 2017, Segher Boessenkool wrote: > You now have added two entries for me; fixed like this: Oops! I missed the old one from four years ago since it wasn't sorted in properly vs Hans Boehm. Well, perhaps a subtle attempt to get you to contribute twice as much? ;-) Thanks for catching and fixing, Segher. Gerald
