[libstdc++,doc] doc/xml/manual/debug.xml: Adjust link to ThreadSanitizer
The site at code.google.com redirects to github now. Applied. Gerald 2017-02-19 Gerald Pfeifer * doc/xml/manual/debug.xml: Adjust link to ThreadSanitizer. Index: doc/xml/manual/debug.xml === --- doc/xml/manual/debug.xml(revision 245571) +++ doc/xml/manual/debug.xml(working copy) @@ -234,7 +234,7 @@ xlink:href="http://valgrind.org/docs/manual/hg-manual.html";> Helgrind, and http://www.w3.org/1999/xlink"; - xlink:href="https://code.google.com/p/data-race-test/";> + xlink:href="https://github.com/google/sanitizers";> ThreadSanitizer (this refers to ThreadSanitizer v1, not the new "tsan" feature built-in to GCC itself).
New German PO file for 'gcc' (version 7.1-b20170101)
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-b20170101.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.
[wwwdocs] projects/cfg.html - use doi.org instead of citeseer.ist.psu.edu
citeseer has been acting interestingly for a while, and now is blocking clients based on geography (verified as blocking from three different systems/networks in Austria and Germany on the one hand¹, and working from the gcc.gnu.org host and another one in North America on the other). So, based on Joseph's point earlier this month, I am converting a number of references to doi.org with this patch. (I did not find a link for reference [3], which also does not appear as crucial.) Applied. Gerald ¹ The error message is "This site has been blocked by the network administrator" which makes it appear to be on the user's end, which alas is not the case. Index: projects/cfg.html === RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cfg.html,v retrieving revision 1.21 diff -u -r1.21 cfg.html --- projects/cfg.html 28 May 2016 12:59:43 - 1.21 +++ projects/cfg.html 19 Feb 2017 14:17:03 - @@ -451,22 +451,20 @@ [1] -http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.43.6404";>Branch +https://doi.org/10.1145/155090.155119";>Branch Prediction for Free; Ball and Larus; PLDI '93. [2] -http://citeseer.ist.psu.edu/wu94static.html";>Static +https://doi.org/10.1145/192724.192725";>Static Branch Frequency and Program Profile Analysis; Wu and Larus; MICRO-27. [3] -http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.37.7180";>Design -and Analysis of Profile-Based Optimization in Compaq's Compilation -Tools for Alpha; Journal of Instruction-Level Parallelism 3 (2000) -1-25 +Design and Analysis of Profile-Based Optimization in Compaq's +Compilation Tools for Alpha; Journal of Instruction-Level Parallelism 3 +(2000) 1-25. [4] @@ -477,20 +475,18 @@ [5] -http://citeseer.ist.psu.edu/young97nearoptimal.html";>Near-optimal +https://doi.org/10.1145/258916.258932";>Near-optimal Intraprocedural Branch Alignment; Cliff Young, David S. Johnson, David R. Karger, Michael D. Smith, ACM 1997 [6] -http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.50.2235";>Software +https://doi.org/10.1145/305138.305178";>Software Trace Cache; International Conference on Supercomputing, 1999 [7] -http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.14.4115";>Using +https://doi.org/10.1002/spe.4380211204";>Using Profile Information to Assist Classic Code Optimizations; Pohua P. Chang, Scott A. Mahlke, and Wen-mei W. Hwu, 1991 @@ -503,8 +499,7 @@ [9] -http://citeseer.ist.psu.edu/warter93reverse.html";>Reverse +https://doi.org/10.1145/173262.155118";>Reverse If-Conversion; Nancy J. Warter, Scott A. Mahlke, Wen-mei W. Hwu, B. Ramakrishna Rau; ACM SIGPLAN Notices, 1993
[v3 PATCH] Make optional's comparisons be two-parameter templates.
This has not been adopted by LEWG/LWG yet, but was submitted
as a proposed resolution for a new LWG issue; optional can't
current be compared to a T, and an optional can't be compared
to something non-T that is comparable to a T. This approach fixes
both of those problems, allowing optional's comparisons to actually
work like the comparisons of the underlying type.
Tested on Linux-x64.
2017-02-19 Ville Voutilainen
Make optional's comparisons be two-parameter templates.
* include/std/optional
(operator==(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator==(const optional<_Tp>&, const optional<_Up>&).
(operator!=(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator!=(const optional<_Tp>&, const optional<_Up>&).
(operator<(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator<(const optional<_Tp>&, const optional<_Up>&.
(operator>(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator>(const optional<_Tp>&, const optional<_Up>&.
(operator<=(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator<=(const optional<_Tp>&, const optional<_Up>&).
(operator>=(const optional<_Tp>&, const optional<_Tp>&)):
Turn into operator>=(const optional<_Tp>&, const optional<_Up>&).
(operator==(const optional<_Tp>&, const _Tp&)):
Turn into operator==(const optional<_Tp>&, const _Up&).
(operator==(const _Tp&, const optional<_Tp>&)):
Turn into operator==(const _Up&, const optional<_Tp>&).
(operator!=(const optional<_Tp>&, const _Tp&)):
Turn into operator!=(const optional<_Tp>&, const _Up&).
(operator!=(const _Tp&, const optional<_Tp>&)):
Turn into operator!=(const _Up&, const optional<_Tp>&).
(operator<(const optional<_Tp>&, const _Tp&)):
Turn into operator<(const optional<_Tp>&, const _Up&).
(operator<(const _Tp&, const optional<_Tp>&)):
Turn into operator<(const _Up&, const optional<_Tp>&).
(operator>(const optional<_Tp>&, const _Tp&)):
Turn into operator>(const optional<_Tp>&, const _Up&).
(operator>(const _Tp&, const optional<_Tp>&)):
Turn into operator>(const _Up&, const optional<_Tp>&).
(operator<=(const optional<_Tp>&, const _Tp&)):
Turn into operator<=(const optional<_Tp>&, const _Up&).
(operator<=(const _Tp&, const optional<_Tp>&)):
Turn into operator<=(const _Up&, const optional<_Tp>&).
(operator>=(const optional<_Tp>&, const _Tp&)):
Turn into operator>=(const optional<_Tp>&, const _Up&).
(operator>=(const _Tp&, const optional<_Tp>&)):
Turn into operator>=(const _Up&, const optional<_Tp>&).
* testsuite/20_util/optional/relops/7.cc: New.
diff --git a/libstdc++-v3/include/std/optional
b/libstdc++-v3/include/std/optional
index 905bc0a..c700515 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -737,52 +737,52 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
enable_if_t::value, bool>;
// Comparisons between optional values.
- template
+ template
constexpr auto
-operator==(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() == declval<_Tp>())>
+operator==(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() == declval<_Up>())>
{
return static_cast(__lhs) == static_cast(__rhs)
&& (!__lhs || *__lhs == *__rhs);
}
- template
+ template
constexpr auto
-operator!=(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() != declval<_Tp>())>
+operator!=(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() != declval<_Up>())>
{
return static_cast(__lhs) != static_cast(__rhs)
|| (static_cast(__lhs) && *__lhs != *__rhs);
}
- template
+ template
constexpr auto
-operator<(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() < declval<_Tp>())>
+operator<(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() < declval<_Up>())>
{
return static_cast(__rhs) && (!__lhs || *__lhs < *__rhs);
}
- template
+ template
constexpr auto
-operator>(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() > declval<_Tp>())>
+operator>(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() > declval<_Up>())>
{
return static_cast(__lhs) && (!__rhs || *__lhs > *__rhs);
}
- template
+ template
constexpr auto
-operator<=(const optional<_Tp>& __lhs, const optional<_Tp>& __rhs)
--> __optional_relop_t() <= declval<_Tp>())>
+operator<=(const optional<_Tp>& __lhs, const optional<_Up>& __rhs)
+-> __optional_relop_t() <= declval<_Up>())>
{
return !__lhs || (static_cast(__rhs) && *__lhs <= *__rhs);
}
- template
+ template
constexpr auto
-operator>=(const optional<_Tp>& _
Re: [v3 PATCH] Implement C++17 GB50 resolution
On 18/02/17 20:48 +, Dinka Ranns wrote:
Comments addressed. Please find the new diff attached to this e-mail.
Changelog after review comments :
2017-02-18 Dinka Ranns
GNU ChangeLog rules say two spaces after the date and after your name.
C++17 GB50 resolution
* include/std/chrono:
(duration::operator++()): Add _GLIBCXX17_CONSTEXPR.
(duration::operator++(int)): Likewise
(duration::operator--()): Likewise
(duration::operator--(int)): Likewise
(duration::operator+=(const duration&)): Likewise
(duration::operator-=(const duration&)): Likewise
(duration::operator*=(const rep&)): Likewise
(duration::operator/=(const rep&)): Likewise
(duration::operator%=(const rep&)): Likewise
(duration::operator%=(const duration&)): Likewise
(time_point::operator+=(const duration&)): Likewise
(time_point::operator-=(const duration&)): Likewise
* testsuite/20_util/duration/arithmetic/constexpr_c++17.cc: new tests
* testsuite/20_util/time_point/arithmetic/constexpr.cc: new tests
I also tweaked the ChangeLog entry to add some full stops.
@@ -401,7 +401,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
// DR 934.
template
- typename enable_if::value,
+ _GLIBCXX17_CONSTEXPR typename
enable_if::value,
duration&>::type
operator%=(const rep& __rhs)
{
@@ -410,7 +410,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
}
template
- typename enable_if::value,
+ _GLIBCXX17_CONSTEXPR typename
enable_if::value,
duration&>::type
operator%=(const duration& __d)
{
I added line breaks to these two signatures to keep the line shorter
than 80 columns, and to keep the "duration&" lined up with the first
argument to enable_if. That meant 20_util/duration/literals/range.cc
started to FAIL because the expected error was on a different line, so
I adjusted that test.
The attached patch includes those tweaks and is what I've tested and
committed. Thanks for your first contribution to libstdc++!
commit eac82ba48c414d10806453a68785225dc4f86971
Author: Jonathan Wakely
Date: Sun Feb 19 14:19:17 2017 +
C++17 GB50 resolution (P0505R0)
2017-02-19 Dinka Ranns
C++17 GB50 resolution
* include/std/chrono (duration::operator++()): Add
_GLIBCXX17_CONSTEXPR.
(duration::operator++(int)): Likewise.
(duration::operator--()): Likewise.
(duration::operator--(int)): Likewise.
(duration::operator+=(const duration&)): Likewise.
(duration::operator-=(const duration&)): Likewise.
(duration::operator*=(const rep&)): Likewise.
(duration::operator/=(const rep&)): Likewise.
(duration::operator%=(const rep&)): Likewise.
(duration::operator%=(const duration&)): Likewise.
(time_point::operator+=(const duration&)): Likewise.
(time_point::operator-=(const duration&)): Likewise.
* testsuite/20_util/duration/arithmetic/constexpr_c++17.cc: New test.
* testsuite/20_util/duration/literals/range.cc: Adjust dg-error.
* testsuite/20_util/time_point/arithmetic/constexpr.cc: New test.
diff --git a/libstdc++-v3/include/std/chrono b/libstdc++-v3/include/std/chrono
index 2c33be0..b3dc430 100644
--- a/libstdc++-v3/include/std/chrono
+++ b/libstdc++-v3/include/std/chrono
@@ -349,50 +349,50 @@ _GLIBCXX_END_NAMESPACE_VERSION
operator-() const
{ return duration(-__r); }
- duration&
+ _GLIBCXX17_CONSTEXPR duration&
operator++()
{
++__r;
return *this;
}
- duration
+ _GLIBCXX17_CONSTEXPR duration
operator++(int)
{ return duration(__r++); }
- duration&
+ _GLIBCXX17_CONSTEXPR duration&
operator--()
{
--__r;
return *this;
}
- duration
+ _GLIBCXX17_CONSTEXPR duration
operator--(int)
{ return duration(__r--); }
- duration&
+ _GLIBCXX17_CONSTEXPR duration&
operator+=(const duration& __d)
{
__r += __d.count();
return *this;
}
- duration&
+ _GLIBCXX17_CONSTEXPR duration&
operator-=(const duration& __d)
{
__r -= __d.count();
return *this;
}
- duration&
+ _GLIBCXX17_CONSTEXPR duration&
operator*=(const rep& __rhs)
{
__r *= __rhs;
return *this;
}
- duration&
+ _GLIBCXX17_CONSTEXPR duration&
operator/=(const rep& __rhs)
{
__r /= __rhs;
@@ -401,6 +401,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
// DR 934.
template
+ _GLIBCXX17_CONSTEXPR
typename enable_if::value,
duration&>::type
operator%=(const rep& __rhs)
@@ -410,6 +411,7 @@ _GLIBCXX_END_NAMESPACE_VERSION
}
template
+ _GLIBCXX17_CONSTEXPR
typename enable_if::value,
duration&>::type
operator%=(const duration& __d)
@@ -631,14 +633,14 @@ _GLIBCXX_END_NAMESPACE_VERSION
{ return __d; }
// arithmetic
- time_point&
+ _GLIBCXX17_CONSTEXPR time_point&
operator+=(const duration& __dur)
{
__d += __dur;
return *this;
}
- time_po
Re: gcc.css colors
Hi Markus,
On Wed, 1 Feb 2017, Markus Trippelsdorf wrote:
> Some colors on e.g. https://gcc.gnu.org/gcc-7/changes.html are nearly
> unreadable. So what about the following patch?
>
> -.boldcyan{ font-weight:bold; color:cyan; }
> -.boldlime{ font-weight:bold; color:lime; }
> +.boldcyan{ font-weight:bold; color:#25a9a9; }
> +.boldlime{ font-weight:bold; color:green;}
just want to follow-up on this and the discussion that ensued.
Based on the feedback you got from Jakub and others, I am not
comfortable making this change (so if we had a patch tracker,
would label this as "declined").
Gerald
Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem
Ping!
this time with correct PR number: 79229.
On Tue, 7 Feb 2017 08:31:22 +0100
Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes the issue of 79229 (which is not a regression).
> The issue was that the code generating the checking was expecting a
> pointer type, but got an indirect ref to it. This is fixed now.
>
> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
>
> Regards,
> Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
gcc/testsuite/ChangeLog:
2017-02-07 Andre Vehreschild
PR fortran/79229
* gfortran.dg/class_allocate_24.f90: New test.
gcc/fortran/ChangeLog:
2017-02-07 Andre Vehreschild
PR fortran/79229
* trans-expr.c (gfc_trans_assignment_1): Deref indirect refs when
compiling with -fcheck=mem to check the pointer and not the data.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 138af56..fcd6f16 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -9959,13 +9959,16 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
tree cond;
const char* msg;
+ tmp = INDIRECT_REF_P (lse.expr)
+ ? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+
/* We should only get array references here. */
- gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR
- || TREE_CODE (lse.expr) == ARRAY_REF);
+ gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
+ || TREE_CODE (tmp) == ARRAY_REF);
/* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR)
or the array itself(ARRAY_REF). */
- tmp = TREE_OPERAND (lse.expr, 0);
+ tmp = TREE_OPERAND (tmp, 0);
/* Provide the address of the array. */
if (TREE_CODE (lse.expr) == ARRAY_REF)
diff --git a/gcc/testsuite/gfortran.dg/class_allocate_24.f90 b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
new file mode 100644
index 000..883247d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/class_allocate_24.f90
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-fcheck=mem" }
+!
+! Compile time check only, to test that the ICE is fixed in the assignment of the
+! default initializer of the class to sf.
+
+implicit none
+
+type :: t
+ integer, pointer :: data => null ()
+end type
+
+class(t), dimension(:), allocatable :: sf
+allocate (t :: sf (1))
+end
+
Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem
On 02/19/2017 08:42 AM, Andre Vehreschild wrote: Ping! this time with correct PR number: 79229. On Tue, 7 Feb 2017 08:31:22 +0100 Andre Vehreschild wrote: Hi all, attached patch fixes the issue of 79229 (which is not a regression). The issue was that the code generating the checking was expecting a pointer type, but got an indirect ref to it. This is fixed now. Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk? Regards, Andre This is OK, Jerry
Re: [RFC PATCH, i386]: Use "lock orl $0, -4(%esp)" in mfence_nosse
On Fri, Feb 17, 2017 at 5:59 PM, Uros Bizjak wrote:
> On Fri, Feb 17, 2017 at 5:30 PM, Jakub Jelinek wrote:
>> On Sun, May 29, 2016 at 11:10:15PM +0200, Uros Bizjak wrote:
>>> As explained in PR71245, comment #3 [1], it is better to use offset -4
>>> to a %esp to implement a non-SSE memory fence instruction:
>>>
>>> -q-
>>>
>>> I guess it costs a code byte for a disp8 in the addressing mode, but
>>> it avoids adding a lot of latency to a critical path involving a
>>> spill/reload to (%esp), in functions where there is something at
>>> (%esp).
>>>
>>> If it's an object larger than 4B, the lock orl could even cause a
>>> store-forwarding stall when the object is reloaded. (e.g. a double or
>>> a vector).
>>>
>>> Ideally we could do the lock orl on some padding between two locals,
>>> or on something in memory that wasn't going to be loaded soon, to
>>> avoid touching more stack memory (which might be in the next page
>>> down). But we still want to do it on a cache line that's hot, so
>>> going way up above our own stack frame isn't good either.
>>
>> Unfortunately this makes valgrind unhappy about that:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1423434
>> I assume it will complain now on anything pre-SSE2 that contains the memory
>> barrier in 32-bit code.
>> Perhaps we should decrement and increment %esp around it or something
>> similar (or push/pop)? Of course, that would mean we need to take care
>> of async unwind info.
>
> Or, we can simply revert the patch? Not that the barrier performance
> of non-SSE 32bit targets matter...
Attached patch was committed to mainline to revert 2016-05-30 change.
2017-02-19 Uros Bizjak
Revert:
2016-05-30 Uros Bizjak
* config/i386/sync.md (mfence_nosse): Use "lock orl $0, -4(%esp)".
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}
Uros.
--cut here--
Index: config/i386/sync.md
===
--- config/i386/sync.md (revision 245574)
+++ config/i386/sync.md (working copy)
@@ -98,7 +98,7 @@
(unspec:BLK [(match_dup 0)] UNSPEC_MFENCE))
(clobber (reg:CC FLAGS_REG))]
"!(TARGET_64BIT || TARGET_SSE2)"
- "lock{%;} or{l}\t{$0, -4(%%esp)|DWORD PTR [esp-4], 0}"
+ "lock{%;} or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}"
[(set_attr "memory" "unknown")])
--cut here--
Re: Ping [Patch, fortran] PR79402 - ICE with submodules: module procedure interface defined in parent module
Hi Everybody, With Jerry's OK for a commit to trunk, committed as revision 245580. I will wait a few weeks before a commit to 6-branch. Cheers Paul On 11 February 2017 at 13:24, Paul Richard Thomas wrote: > Ping! > > On 8 February 2017 at 16:00, Paul Richard Thomas > wrote: >> Dear All, >> >> The attached rework of the patch functions in the same way as >> yesterday's but is based in resolve.c rather than trans-decl.c. It >> looks to me to be by far cleaner. >> >> Bootstraps and regtests on FC23/x86_64 - OK for trunk? >> >> Cheers >> >> Paul >> >> 2017-02-08 Paul Thomas >> >> PR fortran/79344 >> * resolve.c (fixup_unique_dummy): New function. >> (gfc_resolve_expr): Call it for dummy variables with a unique >> symtree name. >> >> 2017-02-08 Paul Thomas >> >> PR fortran/79344 >> * gfortran.dg/submodule_23.f90: New test. >> >> >> >> On 7 February 2017 at 16:06, Paul Richard Thomas >> wrote: >>> Dear All, >>> >>> This bug generates an ICE because the symbol for dummy 'n' in the >>> specification expression for the result of 'fun1' is not the same as >>> the symbol in the formal arglist. For some reason that I have been >>> unable to uncover, this false dummy is associated with a unique >>> symtree. The odd thing is that the dump of the parse tree for the >>> failing module procedure case is identical to that where the interface >>> is explcitely reproduced in the submodule. The cause of the ICE is >>> that the false dummy has no backend_decl as it should. >>> >>> This patch hits the problem directly on the head by using the >>> backend_decl from the symbol in the namespace of the formal arglist, >>> as described in the comment in the patch. If it is deemed to be more >>> hygenic, the chunk of code can be lifted out and deposited in a >>> separate function. >>> >>> Bootstraps and regtests on FC23/x86_64 - OK for trunk? >>> >>> Cheers >>> >>> Paul >>> >>> 2017-02-07 Paul Thomas >>> >>> PR fortran/79344 >>> * trans-decl.c (gfc_get_symbol_decl): If a dummy apparently has >>> a null backend_decl, look for a replacement symbol in the >>> namespace of the 1st formal argument and use its backend_decl. >>> >>> 2017-02-07 Paul Thomas >>> >>> PR fortran/79344 >>> * gfortran.dg/submodule_23.f90: New test. >> >> >> >> -- >> "If you can't explain it simply, you don't understand it well enough" >> - Albert Einstein > > > > -- > "If you can't explain it simply, you don't understand it well enough" > - Albert Einstein -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [Ping, PATCH, Fortran, 79229, v1] [7 Regression] ICE in gfc_trans_assignment_1 with -fcheck=mem
Hi Jerry, hi all,
thanks for the review. Committed as r245581.
Regards,
Andre
On Sun, 19 Feb 2017 08:58:46 -0800
Jerry DeLisle wrote:
> On 02/19/2017 08:42 AM, Andre Vehreschild wrote:
> > Ping!
> >
> > this time with correct PR number: 79229.
> >
> > On Tue, 7 Feb 2017 08:31:22 +0100
> > Andre Vehreschild wrote:
> >
> >> Hi all,
> >>
> >> attached patch fixes the issue of 79229 (which is not a regression).
> >> The issue was that the code generating the checking was expecting a
> >> pointer type, but got an indirect ref to it. This is fixed now.
> >>
> >> Bootstraps and regtests ok on x86_64-linux/f25. Ok for trunk?
> >>
> >> Regards,
> >>Andre
> >
> >
>
> This is OK,
>
> Jerry
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: gcc/fortran/ChangeLog
===
--- gcc/fortran/ChangeLog (Revision 245580)
+++ gcc/fortran/ChangeLog (Arbeitskopie)
@@ -7,6 +7,12 @@
2017-02-19 Andre Vehreschild
+ PR fortran/79229
+ * trans-expr.c (gfc_trans_assignment_1): Deref indirect refs when
+ compiling with -fcheck=mem to check the pointer and not the data.
+
+2017-02-19 Andre Vehreschild
+
PR fortran/79335
* trans-array.c (duplicate_allocatable_coarray): Ensure attributes
passed are properly initialized.
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c (Revision 245580)
+++ gcc/fortran/trans-expr.c (Arbeitskopie)
@@ -9961,13 +9961,16 @@
tree cond;
const char* msg;
+ tmp = INDIRECT_REF_P (lse.expr)
+ ? gfc_build_addr_expr (NULL_TREE, lse.expr) : lse.expr;
+
/* We should only get array references here. */
- gcc_assert (TREE_CODE (lse.expr) == POINTER_PLUS_EXPR
- || TREE_CODE (lse.expr) == ARRAY_REF);
+ gcc_assert (TREE_CODE (tmp) == POINTER_PLUS_EXPR
+ || TREE_CODE (tmp) == ARRAY_REF);
/* 'tmp' is either the pointer to the array(POINTER_PLUS_EXPR)
or the array itself(ARRAY_REF). */
- tmp = TREE_OPERAND (lse.expr, 0);
+ tmp = TREE_OPERAND (tmp, 0);
/* Provide the address of the array. */
if (TREE_CODE (lse.expr) == ARRAY_REF)
Index: gcc/testsuite/ChangeLog
===
--- gcc/testsuite/ChangeLog (Revision 245580)
+++ gcc/testsuite/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2017-02-19 Andre Vehreschild
+
+ PR fortran/79229
+ * gfortran.dg/class_allocate_24.f90: New test.
+
2017-02-19 Paul Thomas
PR fortran/79402
Index: gcc/testsuite/gfortran.dg/class_allocate_24.f90
===
--- gcc/testsuite/gfortran.dg/class_allocate_24.f90 (nicht existent)
+++ gcc/testsuite/gfortran.dg/class_allocate_24.f90 (Arbeitskopie)
@@ -0,0 +1,16 @@
+! { dg-do compile }
+! { dg-options "-fcheck=mem" }
+!
+! Compile time check only, to test that the ICE is fixed in the assignment of the
+! default initializer of the class to sf.
+
+implicit none
+
+type :: t
+ integer, pointer :: data => null ()
+end type
+
+class(t), dimension(:), allocatable :: sf
+allocate (t :: sf (1))
+end
+
Re: [Patch, fortran] PR79447 - [F08] gfortran rejects valid & accepts invalid internal subprogram in a submodule
Hi Jerry, Committed as revision 245582. Thanks for the review. Paul On 16 February 2017 at 00:37, Jerry DeLisle wrote: > On 02/15/2017 10:01 AM, Paul Richard Thomas wrote: >> Dear All, >> >> This patch is straightforward, verging on 'obvious'. >> >> Bootstraps and regtests on FC23/x86_64 - OK for trunk and 6 branch? >> > Yes, OK > > Jerry -- "If you can't explain it simply, you don't understand it well enough" - Albert Einstein
Re: [C++ RFC] Fix up attribute handling in templates (PR c++/79502)
On 02/17/2017 09:53 PM, Jason Merrill wrote: On Thu, Feb 16, 2017 at 6:13 PM, Martin Sebor wrote: On 02/16/2017 12:49 PM, Jason Merrill wrote: On Thu, Feb 16, 2017 at 11:33 AM, Jakub Jelinek wrote: PR c++/79502 * pt.c (apply_late_template_attributes): If there are no dependent attributes, set *p to attributes. If there were some attributes in *p previously with or without dependent attributes, chain them after the new attributes. Here's the variant of your patch that I'm applying. Sorry to butt in but I feel like I'm missing something basic. Are these attributes (nodiscard, noreturn, maybe_unused, and deprecated) meant to apply to templates? The text in for nodiscard suggests they're not: The attribute-token nodiscard may be applied to the declarator-id in a function declaration or to the declaration of a class or enumeration. Noreturn also doesn't mention templates: The attribute may be applied to the declarator-id in a function declaration. Deprecated explicitly mentions template specializations but not primary templates: The attribute may be applied to the declaration of a class, a typedef-name, a variable, a non-static data member, a function, a namespace, an enumeration, an enumerator, or a template specialization. I can certainly see how applying attributes to the primary template would be useful so it's puzzling to me that the standard seems to preclude it. I don't think it's precluded; a /template-declaration/ syntactically includes a /declaration/, so in general any statement about e.g. a function declaration also applies to a function template declaration. I'm sure you're right that it's not meant to be precluded, otherwise the standard library couldn't declare noreturn the throw_with_nested function template (the only template declared noreturn in the library I could find). FWIW, a context where noreturn clearly is not applicable is function pointers. G++ accepts it there but then ignores it. Clang rejects it. I would think accepting it on function pointers would be useful as well. GCC (in C mode) accepts __attribute__ noreturn on function pointers and treats them as such (G++ does not). Another interesting context is the explicit instantiation directive. Again, the standard seems clear that noreturn isn't allowed but GCC and Microsoft Visual C++ both accept it. Clang and EDG reject it. I think rejecting it here makes sense and accepting is a bug. I ask also because I was just looking at bug 79021 and scratching my head about what to thing about it. While trying to understand how GCC handles attributes for the primary template I came across what doesn't make sense to me. Why would it apply the attribute from the primary to the explicit specialization when the two are distinct entities? Is that a bug? This seems like a Core issue; the standard says nothing about how attributes on a template affect specializations. Yes, I thought so as well. Thanks for confirming that. Unless you would prefer to bring it up yourself let me post it to the core reflector and suggest to open a new issue for it. I think that as a general rule, not applying attributes from the template to specializations makes sense. There will be some exceptions, such as the abi_tag attribute which is a property of the name rather than a particular declaration. That makes sense to me. Thanks Martin
[wwwdocs] PATCH Re: DWARF Version 5 Standard Released
On Wed, 15 Feb 2017, Michael Eager wrote: > The DWARF Debugging Information Format Standards Committee is pleased > to announce the availability of Version 5 of the DWARF Debugging Format > Standard. This patch, which I just applied, updates the GCC 7 release notes accordingly. (Now it's only GCC 7 that is upcoming, not DWARF 5 as well. ;-) Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.64 diff -u -r1.64 changes.html --- changes.html16 Feb 2017 17:46:55 - 1.64 +++ changes.html19 Feb 2017 21:54:05 - @@ -141,7 +141,7 @@ UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on arithmetic operations with generic vectors. - The upcoming version 5 of the Version 5 of the http://www.dwarfstd.org/Download.php";>DWARF debugging information standard is supported through the -gdwarf-5 option. The DWARF version 4 debugging information remains the
Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.
That was quite a bit; thanks for doing that, Jakub! In the patch below I try to streamline language a bit, document options being implied by -Os (in addition to -O2 or higher), fix grammar in a few places, and change a textual link to being a real one. I have _not_ applied this yet, and would appreciate your feedback. Gerald Index: changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v retrieving revision 1.65 diff -u -r1.65 changes.html --- changes.html19 Feb 2017 21:55:56 - 1.65 +++ changes.html19 Feb 2017 22:00:59 - @@ -50,41 +50,44 @@ -fprintf-return-value option. A new store merging pass has been added. It merges constant stores to adjacent memory locations into fewer, wider, stores. - It can be enabled by using the -fstore-merging option and is + It is enabled by the -fstore-merging option and is enabled by default at the -O2 optimization - level or higher (including -Os). + level or higher (and -Os). A new code hoisting optimization has been added to the partial redundancy elimination pass. It attempts to move evaluation of expressions executed on all paths to the function exit as early as possible, which helps primarily for code size, but can be useful for - speed of generated code as well. It can be enabled by using the + speed of generated code as well. It is enabled by the -fcode-hoisting option and is enabled by default at - the -O2 optimization level or higher. + the -O2 optimization level or higher (and + -Os). A new interprocedural bitwise constant propagation optimization has been added, which propagates knowledge about which bits of variables are known to be zero (including pointer alignment information) across - the call graph. It can be enabled by using the -fipa-bit-cp + the call graph. It is enabled by the -fipa-bit-cp option if -fipa-cp is enabled as well, and is enabled by - default at the -O2 optimization level and higher. + default at the -O2 optimization level and higher (and + -Os). A new interprocedural value range propagation optimization has been added, which propagates integral ranges that variable values can be proven - to be within across the call graph. It can be enabled by using the + to be within across the call graph. It is enabled by the -fipa-vrp option and is enabled by default at the - -O2 optimization level and higher. + -O2 optimization level and higher (and + -Os). A new loop splitting optimization pass has been added. It splits certain loops if they contain a condition that is always true on one side of the iteration space and always false on the other into two loops where each of the new two loops iterates just on one of the sides of the iteration space and the condition does not need to be checked - inside of the loop. It can be enabled by using the + inside of the loop. It is enabled by the -fsplit-loops option and is enabled by default at the -O3 optimization level or higher. - Shrink-wrapping optimization can now separate portions of + The shrink-wrapping optimization can now separate portions of prologues and epilogues to improve performance if some of the work done traditionally by prologues and epilogues is not needed on certain paths. This is controlled by the @@ -138,7 +141,7 @@ The -fsanitize=signed-integer-overflow suboption of the - UndefinedBehavior Sanitizer now diagnose arithmetic overflows even on + UndefinedBehavior Sanitizer now diagnoses arithmetic overflows even on arithmetic operations with generic vectors. Version 5 of the New __builtin_add_overflow_p, __builtin_sub_overflow_p, __builtin_mul_overflow_p built-in functions have been added. - These work similarly to earlier added built-in functions without the - _p suffix, but don't actually store the result of the + These work similarly to their siblings without the + _p suffix, but do not actually store the result of the arithmetics anywhere, just return whether the operation would overflow. These builtins allow easy checking for overflows e.g. in C++ constexpr contexts. @@ -566,7 +569,7 @@ (suffixed fN or fNx) for the new types: __builtin_copysign, __builtin_fabs, __builtin_huge_val, __builtin_inf, __builtin_nan, __builtin_nans. - Compilation with -fopenmp is now compatible with + Compilation with -fopenmp is now compatible with the C11 _Atomic keyword. @@ -730,8 +733,8 @@ Version 4.5 of the http://www.openmp.org/specifications/"; >OpenMP specification is now partially supported also in the - Fortran compilers, largest missing support in the Fortran frontend - is structure element mapping. + Fortran compiler; the largest missing item is structure element + mapping. User-defined derived-type input/output (UDTIO) is added. @@ -752,11 +755,13 @@
C++ PATCH for c++/79503 (inherited ctor taking base class)
In the old inheriting constructor scheme, copy constructors were not
inherited. In the new scheme we needed a rule to get a similar
effect; I proposed that an inherited constructor should not be viable
if it has a single parameter of a type reference-related to the
derived type. Richard Smith proposed a further refinement that this
would apply only if the base type is also reference-related to the
parameter type. This testcase demonstrates why this refinement is
needed.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 5e1645da2601d0c31a2fd0a5687224d6e3087824
Author: Jason Merrill
Date: Sun Feb 19 16:22:43 2017 -0500
PR c++/79503 - inherited ctor taking base class
* call.c (add_function_candidate): Also check that
DECL_INHERITED_CTOR_BASE is reference-related to the parameter type.
diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index 4ef444b..d6d3a8f 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -2057,7 +2057,9 @@ add_function_candidate (struct z_candidate **candidates,
{
tree ptype = non_reference (TREE_VALUE (parmlist));
tree dtype = DECL_CONTEXT (fn);
- if (reference_related_p (ptype, dtype))
+ tree btype = DECL_INHERITED_CTOR_BASE (fn);
+ if (reference_related_p (ptype, dtype)
+ && reference_related_p (btype, ptype))
{
viable = false;
reason = inherited_ctor_rejection ();
diff --git a/gcc/testsuite/g++.dg/cpp0x/inh-ctor26.C
b/gcc/testsuite/g++.dg/cpp0x/inh-ctor26.C
new file mode 100644
index 000..e1e6b9e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/inh-ctor26.C
@@ -0,0 +1,21 @@
+// PR c++/79503
+// { dg-do compile { target c++11 } }
+
+struct payload {};
+
+struct base: private payload {
+base(payload) {}
+};
+
+struct derived: base {
+using base::base;
+};
+
+int main()
+{
+payload data;
+// error: no matching function for call to 'derived::derived(payload&)'
+// note: candidate: base::base(payload)
+// note: an inherited constructor is not a candidate for initialization
from an expression of the same or derived type
+derived demo(data);
+}
C++ PATCH for c++/79580, ICE with compound literal
We were treating a compound literal type defined in the initializer
for a static data member as though it were a member of the class.
Fixed by ignoring classes when defining a type from within an
expression.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 23c08aed737764678bbe1af31ddaa16b2d0a4061
Author: Jason Merrill
Date: Sun Feb 19 16:50:38 2017 -0500
PR c++/79580 - ICE with compound literal
* parser.c (cp_parser_class_head): If we're in the middle of an
expression, use ts_within_enclosing_non_class.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index feeafce..4656b4f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -22771,7 +22771,10 @@ cp_parser_class_head (cp_parser* parser,
/* If the class was unnamed, create a dummy name. */
if (!id)
id = make_anon_name ();
- type = xref_tag (class_key, id, /*tag_scope=*/ts_current,
+ tag_scope tag_scope = (parser->in_type_id_in_expr_p
+? ts_within_enclosing_non_class
+: ts_current);
+ type = xref_tag (class_key, id, tag_scope,
parser->num_template_parameter_lists);
}
diff --git a/gcc/testsuite/g++.dg/ext/complit15.C
b/gcc/testsuite/g++.dg/ext/complit15.C
new file mode 100644
index 000..f12752d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/ext/complit15.C
@@ -0,0 +1,8 @@
+// PR c++/79580
+// { dg-options "-flto -std=c++98" }
+
+class a
+{
+ static const double b;
+};
+const double a::b ((union { double c; }){}.c);
C++ PATCH for c++/79500, ICE with non-template deduction guide
DECL_TEMPLATE_RESULT doesn't work on a non-template, so let's use
STRIP_TEMPLATE instead.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9f99104a12b72006253c0ce5f0b046ada82eb354
Author: Jason Merrill
Date: Sun Feb 19 14:01:51 2017 -0800
PR c++/79500 - ICE with non-template deduction guide
* pt.c (do_class_deduction): Use STRIP_TEMPLATE rather than
DECL_TEMPLATE_RESULT.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 9e6ce8d..46e6498 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -25118,7 +25118,7 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
int flags,
{
tree t = cands;
for (; t; t = OVL_NEXT (t))
- if (DECL_NONCONVERTING_P (DECL_TEMPLATE_RESULT (OVL_CURRENT (t
+ if (DECL_NONCONVERTING_P (STRIP_TEMPLATE (OVL_CURRENT (t
break;
if (t)
{
@@ -25126,7 +25126,7 @@ do_class_deduction (tree ptype, tree tmpl, tree init,
int flags,
for (t = cands; t; t = OVL_NEXT (t))
{
tree f = OVL_CURRENT (t);
- if (!DECL_NONCONVERTING_P (DECL_TEMPLATE_RESULT (f)))
+ if (!DECL_NONCONVERTING_P (STRIP_TEMPLATE (f)))
pruned = build_overload (f, pruned);
}
cands = pruned;
diff --git a/gcc/testsuite/g++.dg/cpp1z/class-deduction29.C
b/gcc/testsuite/g++.dg/cpp1z/class-deduction29.C
new file mode 100644
index 000..efffe3d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1z/class-deduction29.C
@@ -0,0 +1,6 @@
+// PR c++/79500
+// { dg-options -std=c++1z }
+
+template struct A {};
+A(...) -> A;
+A a = {};
C++ PATCH for c++/79470, partial ordering with reference parameters
We have code in unify to handle the implicit indirection through a
reference, but it couldn't handle when that indirection was wrapped in
an EXPR_PACK_EXPANSION.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 75e6ade977ea2d229d5ccd4fdaaf812c634c4d41
Author: Jason Merrill
Date: Sun Feb 19 14:28:39 2017 -0800
PR c++/79470 - partial ordering with reference parameters
* pt.c (unify) [INDIRECT_REF]: Handle pack expansions.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 46e6498..0a9f5d5 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20918,8 +20918,13 @@ unify (tree tparms, tree targs, tree parm, tree arg,
int strict,
case INDIRECT_REF:
if (REFERENCE_REF_P (parm))
{
+ bool pexp = PACK_EXPANSION_P (arg);
+ if (pexp)
+ arg = PACK_EXPANSION_PATTERN (arg);
if (REFERENCE_REF_P (arg))
arg = TREE_OPERAND (arg, 0);
+ if (pexp)
+ arg = make_pack_expansion (arg);
return unify (tparms, targs, TREE_OPERAND (parm, 0), arg,
strict, explain_p);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic-ref1.C
b/gcc/testsuite/g++.dg/cpp0x/variadic-ref1.C
new file mode 100644
index 000..441d386
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic-ref1.C
@@ -0,0 +1,10 @@
+// PR c++/79470
+// { dg-do compile { target c++11 } }
+
+template < const int&... > struct AA;
+
+template < > struct AA<> { };
+
+template < const int& II, const int&... Is >
+struct AA { };
+
C++ PATCH for c++/79400, confusing suggestion of 'noexcept'
It was pointed out that suggesting noexcept as an alternative to throw(type) doesn't make much sense, since throw(type) would imply noexcept(false), which is the default. So let's just remove the suggestion. Tested x86_64-pc-linux-gnu, applying to trunk. commit 41d5a30463d1f62dfb64ec953b662e1eda5faf74 Author: Jason Merrill Date: Sun Feb 19 14:47:17 2017 -0800 PR c++/79400 - confusing suggestion of 'noexcept' * parser.c (cp_parser_exception_specification_opt): Remove suggestion for deprecated dynamic exception-specification. diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c index 4656b4f..72597f3 100644 --- a/gcc/cp/parser.c +++ b/gcc/cp/parser.c @@ -23926,8 +23926,8 @@ cp_parser_exception_specification_opt (cp_parser* parser) } else if (cxx_dialect >= cxx11 && !in_system_header_at (loc)) warning_at (loc, OPT_Wdeprecated, - "dynamic exception specifications are deprecated in C++11;" - " use % instead"); + "dynamic exception specifications are deprecated in " + "C++11"); } /* In C++17, throw() is equivalent to noexcept (true). throw() is deprecated in C++11 and above as well, but is still widely used,
C++ PATCH for c++/79566, elaborated type-specifier in range for
In the parser, declares_class_or_enum is set to 1 for an elaborated
type-specifier, or 2 for a class or enum definition. We only want to
complain about a type definition in the latter case.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 8b366b7f80be1f160bd31501aa436e4d300cd753
Author: Jason Merrill
Date: Sun Feb 19 14:52:03 2017 -0800
PR c++/79566 - elaborated-type-specifier in range for
* parser.c (cp_parser_simple_declaration): Fix check for type
definition.
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 72597f3..0146596 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12883,7 +12883,7 @@ cp_parser_simple_declaration (cp_parser* parser,
break;
else if (maybe_range_for_decl)
{
- if (declares_class_or_enum && token->type == CPP_COLON)
+ if ((declares_class_or_enum & 2) && token->type == CPP_COLON)
permerror (decl_specifiers.locations[ds_type_spec],
"types may not be defined in a for-range-declaration");
break;
diff --git a/gcc/testsuite/g++.dg/cpp0x/range-for34.C
b/gcc/testsuite/g++.dg/cpp0x/range-for34.C
new file mode 100644
index 000..2041848
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/range-for34.C
@@ -0,0 +1,16 @@
+// PR c++/79566
+// { dg-do compile { target c++11 } }
+
+struct X {
+ struct Y { };
+
+ Y* begin();
+ Y* end();
+};
+
+void f()
+{
+ X x;
+ for (struct X::Y& y : x)
+;
+}
C++ PATCH for c++/79607, ICE with T{} initializer
type_dependent_init_p was overlooking the possibility of a CONSTRUCTOR
with a dependent type, which we can get from T{}.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 060f95851e7f6d6737937b786c0a6b29cda3c454
Author: Jason Merrill
Date: Sun Feb 19 15:40:39 2017 -0800
PR c++/79607 - ICE with T{} initializer
* decl.c (type_dependent_init_p): Check the type of a CONSTRUCTOR.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 70c44fb..e5c2bab 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -6662,6 +6662,9 @@ type_dependent_init_p (tree init)
else if (TREE_CODE (init) == CONSTRUCTOR)
/* A brace-enclosed initializer, e.g.: int i = { 3 }; ? */
{
+ if (dependent_type_p (TREE_TYPE (init)))
+ return true;
+
vec *elts;
size_t nelts;
size_t i;
diff --git a/gcc/testsuite/g++.dg/template/init11.C
b/gcc/testsuite/g++.dg/template/init11.C
new file mode 100644
index 000..ef337c0
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/init11.C
@@ -0,0 +1,9 @@
+// PR c++/79607
+// { dg-do compile { target c++11 } }
+
+template struct A
+{
+ static const int i = int{T{}};
+};
+
+A a;
C++ PATCH for c++/79606, ICE with this->base_member in NSDMI
build_base_path knows that it should limit what it tries to do within
a template, but that handling wasn't being used within an NSDMI, only
within a template function.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 7a11cba1268aa91df1bc253c43deb2dcbfd5b091
Author: Jason Merrill
Date: Sun Feb 19 15:55:10 2017 -0800
PR c++/79606 - ICE with this->base_member in NSDMI
* class.c (build_base_path): Check processing_template_decl.
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index 1442b55..9e4b4c4 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -375,6 +375,7 @@ build_base_path (enum tree_code code,
set up properly yet, and the value doesn't matter there either; we're
just interested in the result of overload resolution. */
if (cp_unevaluated_operand != 0
+ || processing_template_decl
|| in_template_function ())
{
expr = build_nop (ptr_target_type, expr);
diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-template16.C
b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template16.C
new file mode 100644
index 000..58dec7b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template16.C
@@ -0,0 +1,14 @@
+// PR c++/79606
+// { dg-do compile { target c++11 } }
+
+struct A
+{
+ int i = 0;
+};
+
+template struct B : A
+{
+ int j = this->i;
+};
+
+B<0> b;
C++ PATCH for c++/78282, auto template and pack expansion
When looking for parameter packs mentioned within an expression, we
were wrongly walking into the type of a TEMPLATE_DECL mentioned in the
expression. We're only interested in packs in the type of a template
template-parameter, not other kinds of template.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 1835d19d99d5e89155c566d6305c878ca0c75678
Author: Jason Merrill
Date: Sun Feb 19 16:08:29 2017 -0800
PR c++/78282 - auto template and pack expansion
* pt.c (find_parameter_packs_r): Don't walk into the type of
templates other than template template-parameters.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 0a9f5d5..2cac24f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -3576,8 +3576,12 @@ find_parameter_packs_r (tree *tp, int *walk_subtrees,
void* data)
*walk_subtrees = 0;
return NULL_TREE;
-case CONSTRUCTOR:
case TEMPLATE_DECL:
+ if (!DECL_TEMPLATE_TEMPLATE_PARM_P (t))
+ return NULL_TREE;
+ gcc_fallthrough();
+
+case CONSTRUCTOR:
cp_walk_tree (&TREE_TYPE (t),
&find_parameter_packs_r, ppd, ppd->visited);
return NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/cpp1y/auto-fn36.C
b/gcc/testsuite/g++.dg/cpp1y/auto-fn36.C
new file mode 100644
index 000..f89c092
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp1y/auto-fn36.C
@@ -0,0 +1,26 @@
+// PR c++/78282
+// { dg-do compile { target c++14 } }
+
+struct null_node
+{
+ null_node(const null_node&);
+};
+
+extern null_node null;
+
+template
+auto get() { return null; }
+
+template
+struct inheritor: Ts...
+{
+ inheritor(const inheritor& outer)
+: Ts(get())...
+{ }
+};
+
+void test()
+{
+ extern inheritor example;
+ inheritor result(example);
+}
Ping Re: [patch, doc] copy-edit ARC options documentation
On 02/13/2017 11:14 PM, Sandra Loosemore wrote: 2017-02-13 Sandra Loosemore gcc/ * doc/invoke.texi (ARC Options): Copy-edit to fix punctuation, markup, and similar issues. Remove @opindex entries for things that aren't options. Target maintainers, any comment on this patch? -Sandra
