Re: [PATCH, rs6000] fix PR86952 (p8-vec-xl-*.c tests)
Hi!
On Fri, Sep 07, 2018 at 04:27:34PM -0500, Will Schmidt wrote:
> The expected instructions for this test (p8-vec-xl-*) were incorrect for some
> of the power targets. Add codegen variations as appropriate for
> the targeted platform.
> pr86952/testsuite
I think you need to write this as PR (i.e. caps) followed by a space,
and the component of this bug is "target" in bugzilla (which is better
here), and the number is 86592. So:
PR target/86592
and it will automagically add a comment to the right bug :-)
> -/* { dg-final { scan-assembler-times "lvx" 4 } } */
> -/* { dg-final { scan-assembler-times "stvx" 4 } } */
> -/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */
> +/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M} 4 } } */
So you get xxpermdi when {l,st}xvd2x is generated? What platform is that
on? Is that the correct code to generate, or is this a regression? Is
this the difference between LE and BE code generation? So many questions,
I am sorry :-)
Segher
[PATCH, rs6000] fix PR86952 (p8-vec-xl-*.c tests)
Hi,
The expected instructions for this test (p8-vec-xl-*) were incorrect for some
of the power targets. Add codegen variations as appropriate for
the targeted platform.
Tested across power platforms. This appears to now run clean.
OK for trunk?
Thanks
-Will
[testsuite]
2018-09-06 Will Schmidt
pr86952/testsuite
* p8-vec-xl-xst-v2.c: Add and update expected codegen.
diff --git a/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c
b/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c
index cc68ceb..7327af7 100644
--- a/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c
+++ b/gcc/testsuite/gcc.target/powerpc/p8-vec-xl-xst-v2.c
@@ -57,8 +57,7 @@ void
bartle (vector unsigned short x, unsigned short * address)
{
vec_xst (x, 0, address);
}
-/* { dg-final { scan-assembler-times "lvx" 4 } } */
-/* { dg-final { scan-assembler-times "stvx" 4 } } */
-/* { dg-final { scan-assembler-times "xxpermdi" 0 } } */
+/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvd2x\M} 4 } } */
+/* { dg-final { scan-assembler-times {\mstvx\M|\mstxvd2x\M} 4 } } */
[PATCH, rs6000] fix PR87021 (fold-vec-splat-*.c tests)
Hi,
Update the fold-vec-splat-* tests to match current codegen results.
Due to codegen variations across assorted P7,p8,p9 targets, I've split
the -char test out into additional .p8 and .p9 versions with the common
parts contained in a .h included file. The assorted scan-assembly stanzas
for the rest of the tests have been simplified, corrected, commented.
This appears to now run clean across the sampling of hardware I
have handy. (p7,p8,p9).
OK for trunk?
Thanks,
-Will
[testsuite]
2018-09-07 Will Schmidt
* fold-vec-splat-char.h: New. Common parts for splat-char.p*.c
* fold-vec-splat-char.c: Simplify, include splat-char.h contents.
* fold-vec-splat-char.p8.c: New.
* fold-vec-splat-char.p9.c: New.
* fold-vec-splat-floatdouble.c: Updated counts, added commentary.
* fold-vec-splat-int.c: Updated, added P9 instructions to
scan-assembler stanza.
* fold-vec-splat-longlong.c: Same.
* fold-vec-splat-pixel.c: Same.
* fold-vec-splat-short.c: Combined stanzas.
diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-char.c
b/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-char.c
index d50d073..5e3ec29 100644
--- a/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-char.c
+++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-splat-char.c
@@ -5,51 +5,14 @@
/* { dg-require-effective-target powerpc_altivec_ok } */
/* { dg-options "-maltivec -O2" } */
#include
-vector bool char testb_0 (vector bool char x) { return vec_splat (x,
0b0); }
-vector bool char testb_1 (vector bool char x) { return vec_splat (x,
0b1); }
-vector bool char testb_2 (vector bool char x) { return vec_splat (x,
0b00010); }
-vector bool char testb_4 (vector bool char x) { return vec_splat (x,
0b00100); }
-vector bool char testb_8 (vector bool char x) { return vec_splat (x,
0b01000); }
-vector bool char testb_10 (vector bool char x) { return vec_splat (x,
0b1); }
-vector bool char testb_1e (vector bool char x) { return vec_splat (x,
0b0); }
-vector bool char testb_1f (vector bool char x) { return vec_splat (x,
0b1); }
-
-vector signed char tests_0 (vector signed char x) { return vec_splat (x,
0b0); }
-vector signed char tests_1 (vector signed char x) { return vec_splat (x,
0b1); }
-vector signed char tests_2 (vector signed char x) { return vec_splat (x,
0b00010); }
-vector signed char tests_4 (vector signed char x) { return vec_splat (x,
0b00100); }
-vector signed char tests_8 (vector signed char x) { return vec_splat (x,
0b01000); }
-vector signed char tests_10 (vector signed char x) { return vec_splat (x,
0b1); }
-vector signed char tests_1e (vector signed char x) { return vec_splat (x,
0b0); }
-vector signed char tests_1f (vector signed char x) { return vec_splat (x,
0b1); }
-
-vector unsigned char testu_0 (vector unsigned char x) { return vec_splat (x,
0b0); }
-vector unsigned char testu_1 (vector unsigned char x) { return vec_splat (x,
0b1); }
-vector unsigned char testu_2 (vector unsigned char x) { return vec_splat (x,
0b00010); }
-vector unsigned char testu_4 (vector unsigned char x) { return vec_splat (x,
0b00100); }
-vector unsigned char testu_8 (vector unsigned char x) { return vec_splat (x,
0b01000); }
-vector unsigned char testu_10 (vector unsigned char x) { return vec_splat (x,
0b1); }
-vector unsigned char testu_1e (vector unsigned char x) { return vec_splat (x,
0b0); }
-vector unsigned char testu_1f (vector unsigned char x) { return vec_splat (x,
0b1); }
-
-/* Similar tests as above, but the source vector is a known constant. */
-const vector bool char by =
{'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p'};
-const vector signed char sy =
{'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p'};
-const vector unsigned char uy =
{'a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p'};
-
-vector bool char test_bc (vector bool char x) { return vec_splat (by,
0b00010); }
-vector signed char test_sc (vector signed char x) { return vec_splat (sy,
0b00011); }
-vector unsigned char test_uc (vector unsigned char x) { return vec_splat (uy,
0b00110); }
-
-/* Similar tests as above, mask is greater than number of elements in the
- source vector. */
-vector bool char test_obc (vector bool char x) { return vec_splat (by,
0b10010); }
-vector signed char test_osc (vector signed char x) { return vec_splat (sy,
0b10011); }
-vector unsigned char test_ouc (vector unsigned char x) { return vec_splat (uy,
0b10110); }
-
-// vec_splat() using variable vectors should generate the vspltb instruction.
-/* { dg-final { scan-assembler-times "vspltb" 24 } } */
-// vec_splat() using a constant vector should generate a load.
-/* { dg-final { scan-assembler-times {\mlvx\M|\mlxvw4x\M} 6 } } */
+#include "fold-vec-splat-char.h"
+
+/* vec_splat() tests using a constant vector should generate a load, except on
+ newer targets where w
C++ PATCH to add RANGE_FOR_INIT_STMT to cxx_pretty_printer
Now that we have RANGE_FOR_INIT_STMT we should handle it in cxx_pretty_printer.
I don't actually know how to trigger it but it seems straightforward to add.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2018-09-07 Marek Polacek
* cxx-pretty-print.c (cxx_pretty_printer::statement) : Handle RANGE_FOR_INIT_STMT.
diff --git gcc/cp/cxx-pretty-print.c gcc/cp/cxx-pretty-print.c
index df81aa37ce8..8426c7246de 100644
--- gcc/cp/cxx-pretty-print.c
+++ gcc/cp/cxx-pretty-print.c
@@ -2021,6 +2021,12 @@ cxx_pretty_printer::statement (tree t)
pp_cxx_ws_string (this, "for");
pp_space (this);
pp_cxx_left_paren (this);
+ if (RANGE_FOR_INIT_STMT (t))
+ {
+ statement (RANGE_FOR_INIT_STMT (t));
+ pp_needs_newline (this) = false;
+ pp_cxx_whitespace (this);
+ }
statement (RANGE_FOR_DECL (t));
pp_space (this);
pp_needs_newline (this) = false;
Re: [PATCH] PR 53796 Improve INQUIRE(RECL=...) handling
On Fri, Sep 7, 2018 at 4:37 PM Bernhard Reutner-Fischer < rep.dot@gmail.com> wrote: > Janne, > > On Mon, 27 Nov 2017 at 20:57, Thomas Koenig wrote: > > > > Hi Janne, > > > > > PING > > > > Looks good for trunk. Thanks! > > AFAICS this removed the last user of > > static void > init_unsigned_integer > > which manifests itself as > ../../../../../src/gcc-9.0.mine/libgfortran/runtime/environ.c:104:1: > warning: ‘init_unsigned_integer’ defined but not used > [-Wunused-function] > 104 | init_unsigned_integer (variable * v) > | ^ > > and hence should be removed. > > thanks, > Thanks for noticing! Committed r264163 as obvious. Commit msg below: Remove unused init_unsigned_integer function. As pointed out by Bernhard Reutner-Fischer, this function is unused since the fix for PR 53796 in November 2017. 2018-09-07 Janne Blomqvist * runtime/environ.c (init_unsigned_integer): Remove. -- Janne Blomqvist
C++ PATCH to fix more FAILs in c++17/c++2a
Running make check-c++-all I noticed some more failures, mostly caused by me.
Tested on x86_64-linux, ok for trunk?
2018-09-07 Marek Polacek
* c-c++-common/array-init.c: Add dg-error.
* g++.dg/cpp0x/lambda/lambda-const-this.C: Add dg-warning.
* g++.dg/cpp0x/lambda/lambda-in-class-neg.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-in-class.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-nested.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-nsdmi1.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-nsdmi4.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-this.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-this17.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-this18.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-this2.C: Likewise.
* g++.dg/cpp0x/lambda/lambda-this8.C: Likewise.
* g++.dg/cpp1y/pr64382.C: Likewise.
* g++.dg/cpp1y/pr77739.C: Likewise.
* g++.dg/cpp1z/lambda-this1.C: Likewise.
* g++.dg/cpp1z/lambda-this2.C: Likewise.
* g++.dg/template/crash84.C: Adjust dg-error.
diff --git gcc/testsuite/c-c++-common/array-init.c
gcc/testsuite/c-c++-common/array-init.c
index 0624e708987..2562ec9928e 100644
--- gcc/testsuite/c-c++-common/array-init.c
+++ gcc/testsuite/c-c++-common/array-init.c
@@ -2,3 +2,4 @@
/* { dg-prune-output "sorry, unimplemented: non-trivial designated
initializers not supported" } */
char x[] = { [-1] = 1, 2, 3 }; /* { dg-error "array index in initializer
exceeds array bounds" "" { target c } } */
+// { dg-error "all initializer clauses should be designated" "" { target c++2a
} .-1 }
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const-this.C
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const-this.C
index 220ac911cdb..f51055d6e7d 100644
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const-this.C
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-const-this.C
@@ -5,5 +5,6 @@ struct S {
void f();
void g() const {
[=] { f(); } (); // { dg-error "no match|qualifiers" }
+// { dg-warning "implicit capture" "" { target c++2a } .-1 }
}
};
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class-neg.C
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class-neg.C
index 92a165d95bb..cff3d375682 100644
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class-neg.C
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class-neg.C
@@ -18,8 +18,9 @@ class C {
[&] () -> void { this->m_i = 3; } ();
assert(m_i == 3);
[=] () -> void { m_i = 4; } (); // copies 'this' or --copies-m_i--?
+// { dg-warning "implicit capture" "" { target c++2a } .-1 }
assert(m_i == 4);
- [=] () -> void { this->m_i = 5; } ();
+ [=] () -> void { this->m_i = 5; } (); // { dg-warning "implicit capture"
"" { target c++2a } }
assert(m_i == 5);
}
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class.C
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class.C
index 92981109fd8..f2b54e58ad3 100644
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class.C
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-in-class.C
@@ -18,8 +18,9 @@ class C {
[&] () -> void { this->m_i = 3; } ();
assert(m_i == 3);
[=] () -> void { m_i = 4; } (); // copies 'this' or --copies-m_i--?
+// { dg-warning "implicit capture" "" { target c++2a } .-1 }
assert(m_i == 4);
- [=] () -> void { this->m_i = 5; } ();
+ [=] () -> void { this->m_i = 5; } (); // { dg-warning "implicit capture"
"" { target c++2a } }
assert(m_i == 5);
}
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested.C
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested.C
index c8ea46a980f..3848938d55f 100644
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested.C
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nested.C
@@ -7,7 +7,7 @@ struct A {
A(): i(42) { }
int f() {
return [this]{
- return [=]{ return i; }();
+ return [=]{ return i; }(); // { dg-warning "implicit capture" "" {
target c++2a } }
}();
}
};
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi1.C
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi1.C
index 94dc254fd7c..b6972896ecb 100644
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi1.C
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi1.C
@@ -1,7 +1,7 @@
// PR c++/56464
// { dg-do run { target c++11 } }
-struct bug { bug*a = [&]{ return [=]{return this;}(); }(); };
+struct bug { bug*a = [&]{ return [=]{return this;}(); }(); }; // { dg-warning
"implicit capture" "" { target c++2a } }
int main()
{
bug b;
diff --git gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi4.C
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi4.C
index b592f155063..127bd26b953 100644
--- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi4.C
+++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-nsdmi4.C
@@ -10,5 +10,5 @@ struct function
struct testee
{
function l1 = []() { };
- function l2 = [=]() { l1; };
+ function l2 = [=]() { l1; }; // { dg-warning "implicit capture" "" { target
c++2a } }
Re: [PATCH] Use complete_array_type on flexible array member initializers
On 09/07/18 15:36, Bernd Edlinger wrote: > On 09/07/18 08:51, Bernd Edlinger wrote: >> On 09/07/18 00:26, Jeff Law wrote: >>> On 09/06/2018 04:16 PM, Jeff Law wrote: On 09/06/2018 04:01 PM, Jeff Law wrote: > On 09/06/2018 11:12 AM, Bernd Edlinger wrote: > >>> >> >> Ah, thanks a lot. >> >> Okay, this is the status of the STRING-CST semantic-v2 patches: >> >> [PATCH] Check the STRING_CSTs in varasm.c >> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01569.html >> => Unfortunately I forgot to change the Title to [PATCHv2] or so. >> Should I send a ping for this one? >> >> [PATCHv2] Handle overlength strings in the C FE >> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01566.html >> => Should I send a ping for this one? > No need to ping. I've got it here. What's odd is that it's regressing > 87053 . Which is probably a sign that we've got an incorrect test for NUL termination somewhere. >> >> It may be a sign that we should first fix the low level functions >> before the high level stuff. >> >>> I think I've found the issue. I've got more testing to do, but looks >>> like a thinko on my part. >>> >> >> Ah, I forgot, the regression on pr87053 and fortran.dg/pr45636.f90 >> is fixed by this patch: >> >> [PATCH] Adjust c_getstr/c_strlen to new STRING_CST semantic >> https://gcc.gnu.org/ml/gcc-patches/2018-08/msg02013.html >> >> This is a new regression since the patch was initially posted. >> > > Well, actually both patches seem to have a circular dependency. > > If you want we can break this dependency by adding this to the c_getstr > patch: > > --- gcc/fold-const.c 2018-09-07 14:22:50.047964775 +0200 > +++ gcc/fold-const.c 2018-09-07 15:06:46.656989904 +0200 > @@ -14611,6 +14611,10 @@ c_getstr (tree src, unsigned HOST_WIDE_I > unsigned HOST_WIDE_INT string_length = TREE_STRING_LENGTH (src); > unsigned HOST_WIDE_INT string_size = tree_to_uhwi (mem_size); > > + /* Ideally this would turn into a gcc_checking_assert over time. */ > + if (string_length > string_size) > + return NULL; > + > const char *string = TREE_STRING_POINTER (src); > > if (string_length == 0 > > > This should allow it to work with current semantics as well. > Oops, this does not work for strlenopt-49.c... Please make it: --- gcc/fold-const.c2018-09-07 19:39:19.88785 +0200 +++ gcc/fold-const.c2018-09-07 19:30:03.372583484 +0200 @@ -14611,6 +14611,10 @@ c_getstr (tree src, unsigned HOST_WIDE_I unsigned HOST_WIDE_INT string_length = TREE_STRING_LENGTH (src); unsigned HOST_WIDE_INT string_size = tree_to_uhwi (mem_size); + /* Ideally this would turn into a gcc_checking_assert over time. */ + if (string_length > string_size) +string_length = string_size; + const char *string = TREE_STRING_POINTER (src); if (string_length == 0 Bernd.
Re: Keep std::deque algos specializations in Debug mode
I realized that I was not checking the Debug implementations.
Doing so also have the advantage to show clearly which overload of the
algos is being used. If it is using the correct Debug overload I
consider that there are chances that it is also using the correct normal
overload. This is easier to check than using gdb.
This way I found out that I was not calling the expected std::fill
because I pass 0 rather than '\0'. I wonder if we could have the correct
behavior if we were simply using 0. It would be great if gcc was using
the fill deque iterator overload even if warning in case the pass int
value do not match the deque value type.
Ok to commit ?
François
On 09/06/2018 10:07 PM, François Dumont wrote:
On 09/04/2018 02:59 PM, Jonathan Wakely wrote:
template
void
- fill(const _Deque_iterator<_Tp, _Tp&, _Tp*>& __first,
- const _Deque_iterator<_Tp, _Tp&, _Tp*>& __last, const _Tp&
__value)
+ fill(const _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*>&
__first,
+ const _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&, _Tp*>& __last,
+ const _Tp& __value)
{
- typedef typename _Deque_iterator<_Tp, _Tp&, _Tp*>::_Self _Self;
-
- for (typename _Self::_Map_pointer __node = __first._M_node + 1;
- __node < __last._M_node; ++__node)
- std::fill(*__node, *__node + _Self::_S_buffer_size(), __value);
+ typedef typename _GLIBCXX_STD_C::_Deque_iterator<_Tp, _Tp&,
_Tp*>::_Self
+ _Self;
if (__first._M_node != __last._M_node)
{
std::fill(__first._M_cur, __first._M_last, __value);
+
+ for (typename _Self::_Map_pointer __node = __first._M_node + 1;
+ __node != __last._M_node; ++__node)
Is there any particular reason to change this from using < to != for
the comparison?
I consider that the reason for having a < comparison was that this
loop was done before checking __first._M_node != __last._M_node. As I
moved it inside the block I also prefer to use a usual condition when
iterating other iterators/pointers.
Isn't it a simpler operation ? Do you fear a compiler warning about it
like we used to have in vector implementation before introducing the
__builtin_unreachable calls ?
(This change is part of the reason I asked for the ChangeLog, but you
didn't mention it in the ChangeLog).
I had forgotten about it but I can add it in ChangeLog.
Moving it inside the condition makes sense (not only does it avoid a
branch in the single-page case, but means we fill the elements in
order).
Yes, it is the main reason I moved it, I should have signal it when I
submit the patch.
+ std::fill(*__node, *__node + _Self::_S_buffer_size(),
__value);
+
std::fill(__last._M_first, __last._M_cur, __value);
}
else
The rest of the code changes look fine, I just wondered about that
bit.
I do have some comments on the new tests though ...
+
+void test01()
+{
+ std::deque d;
+ for (char c = 0; c != std::numeric_limits::max(); ++c)
+ d.push_back(c);
+
+ std::deque dest(std::numeric_limits::max(), '\0');
These deques only have 127 or 255 elements (depending on
is_signed) which will fit on a single page of a deque (the
default is 512 bytes per page).
That means the tests don't exercise the logic for handling
non-contiguous blocks of memory.
Ideally we'd want to test multiple cases:
- a single page, with/without empty capacity at front/back
- multiple pages, with/without empty capacity at front/back
That would be 8 cases. I think we want to test at least a single
page and multiple pages.
I think I started to create the fill.cc which require usage of char to
make sure it uses __builtin_memset and then extrapolated to other algos.
But I had already reviewed those tests for a patch I'll submit after
this one so here is the revisited tests.
In this new proposal I also introduce a template alias to simplify the
C++11 overloads. I define it in __gnu_debug to avoid polluting std
namespace with a non-Standard thing.
* include/bits/stl_deque.h
(fill, copy, copy_backward, move, move_backward): Move overloads for
std::deque iterators in std namespace.
* include/bits/deque.tcc: Likewise.
(fill): Move loop on nodes inside branch when first and last nodes
are
different. Replace for loop < condition on nodes with a !=.
* include/debug/deque
(__gnu_debug::_SDeque_iterator<>,
__gnu_debug::_SDeque_const_iterator):
New template aliases.
(fill, copy, copy_backward, move, move_backward):
New overloads for std::__debug::deque iterators. Forward to normal
and
optimized implementations after proper debug checks.
* testsuite/23_containers/deque/copy.cc: New.
* testsuite/23_containers/deque/copy_backward.cc: New.
* testsuite/23_containers/deque/fill.cc: New.
* testsuite/23_containers/deque/move.cc: New.
* testsuite/23_containers/deque/move_backward.cc: New.
Tested under Linux x86_64.
Ok to commit ?
François
diff --git a/libstdc++
Re: [PATCH][GCC][AArch64] Add support for SVE stack clash probing [patch (2/7)]
Hi Richard,
Here's the updated patch and some comments inline below.
An example sequence is:
.cfi_startproc
mov x15, sp
cntbx16, all, mul #11
add x16, x16, 304
.cfi_def_cfa_register 15
.SVLPSRL0:
cmp x16, 65536
b.lt.BRRCHK0
sub sp, sp, 65536
str xzr, [sp, 1024]
sub x16, x16, 65536
b .SVLPSRL0
.BRRCHK0:
sub sp, sp, x16
cmp x16, 2048
b.lt.BERCHK0
str xzr, [sp, 1024]
.BERCHK0:
.cfi_escape 0xf,0xc,0x8f,0,0x92,0x2e,0,0x8,0x58,0x1e,0x23,0xb0,0x2,0x22
stp x29, x30, [sp]
Ok for trunk?
Thanks,
Tamar
gcc/
2018-09-07 Tamar Christina
PR target/86486
* config/aarch64/aarch64-protos.h
(aarch64_output_probe_sve_stack_clash): New.
* config/aarch64/aarch64.c (aarch64_output_probe_sve_stack_clash): New.
(aarch64_allocate_and_probe_stack_space): Add SVE specific section.
* config/aarch64/aarch64.md (probe_sve_stack_clash): New.
gcc/testsuite/
2018-09-07 Tamar Christina
PR target/86486
* gcc.target/aarch64/stack-check-prologue-16.c: New test
* gcc.target/aarch64/stack-check-cfa-3.c: New test.
The 08/28/2018 21:40, Richard Sandiford wrote:
> I'll leave the AArch64 maintainers to review, but some comments.
>
> Tamar Christina writes:
> > diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> > index
> > 06451f38b11822ea77323438fe8c7e373eb9e614..e7efde79bb111e820f4df44a276f6f73070ecd17
> > 100644
> > --- a/gcc/config/aarch64/aarch64.c
> > +++ b/gcc/config/aarch64/aarch64.c
> > @@ -3970,6 +3970,90 @@ aarch64_output_probe_stack_range (rtx reg1, rtx reg2)
> >return "";
> > }
> > +
> > + /* Test if BASE < LIMIT. */
> > + xops[1] = limit;
> > + output_asm_insn ("cmp\t%0, %1", xops);
>
> Think this should be ADJUSTMENT < LIMIT.
Actually it should be 2KB in this case. I've explained why in the updated patch.
>
> > + /* Branch to end. */
> > + fputs ("\tb.lt\t", asm_out_file);
> > + assemble_name_raw (asm_out_file, loop_end_lab);
> > + fputc ('\n', asm_out_file);
> > +
> > + /* Probe at BASE + LIMIT. */
> > + output_asm_insn ("str\txzr, [%0, %1]", xops);
>
> It looks like this would probe at LIMIT when ADJUSTMENT is exactly LIMIT,
> which could clobber the caller's frame.
>
Yeah, the comparison should have been a bit larger. Thanks.
> > +
> > + /* No probe leave. */
> > + ASM_OUTPUT_INTERNAL_LABEL (asm_out_file, loop_end_lab);
> > + return "";
>
> With the CFA stuff and constant load, I think this works out as:
>
> -
> # 12 insns
> mov r15, base
> mov adjustment, N
> 1:
> cmp adjustment, guard_size
> b.lt2f
> sub base, base, guard_size
> str xzr, [base, limit]
> sub adjustment, adjustment, guard_size
> b 1b
> 2:
> sub base, base, adjustment
> cmp adjustment, limit
> b.le3f
> str xzr, [base, limit]
> 3:
> -
>
> What do you think about something like:
>
> -
> # 10 insns
> mov adjustment, N
> sub r15, base, adjustment
> subsadjustment, adjustment, min_probe_threshold
> b.lo2f
> 1:
> add base, x15, adjustment
> str xzr, [base, 0]
> subsadjustment, adjustment, 16
> and adjustment, adjustment, ~(guard_size-1)
> b.hs1b
> 2:
> mov base, r15
> -
>
> or (with different trade-offs):
>
> -
> # 11 insns
> mov adjustment, N
> sub r15, base, adjustment
> subsadjustment, adjustment, min_probe_threshold
> b.lo2f
> # Might be 0, leading to a double probe
> and r14, adjustment, guard_size-1
> 1:
> add base, x15, adjustment
> str xzr, [base, 0]
> subsadjustment, adjustment, r14
> mov r14, guard_size
> b.hs1b
> 2:
> mov base, r15
> -
>
> or (longer, but with a simpler loop):
>
> -
> # 12 insns
> mov adjustment, N
> sub r15, base, adjustment
> subsadjustment, adjustment, min_probe_threshold
> b.lo2f
> str xzr, [base, -16]!
> sub adjustment, adjustment, 32
> and adjustment, adjustment, -(guard_size-1)
> 1:
> add base, x15, adjustment
> str xzr, [base, 0]
> subsadjustment, adjustment, guard_size
> b.hs1b
> 2:
> mov base, r15
> -
>
> with the CFA based on r15+offset?
>
> These loops probe more often than necessary in some cases,
> but
Re: [PATCH][GCC][AArch64] Updated stack-clash implementation supporting 64k probes. [patch (1/7)]
Hi Richard,
The 08/28/2018 21:58, Richard Sandiford wrote:
> Tamar Christina writes:
> > + HOST_WIDE_INT guard_used_by_caller = STACK_CLASH_CALLER_GUARD;
> > + /* When doing the final adjustment for the outgoing argument size we
> > can't
> > + assume that LR was saved at position 0. So subtract it's offset from
> > the
> > + ABI safe buffer so that we don't accidentally allow an adjustment that
> > + would result in an allocation larger than the ABI buffer without
> > + probing. */
> > + HOST_WIDE_INT min_probe_threshold
> > += final_adjustment_p
> > + ? guard_used_by_caller - cfun->machine->frame.reg_offset[LR_REGNUM]
> > + : guard_size - guard_used_by_caller;
> [...]
> > + if (residual)
> > +{
> > + aarch64_sub_sp (temp1, temp2, residual, frame_related_p);
> > + if (residual >= min_probe_threshold)
> > + {
> > + if (dump_file)
> > + fprintf (dump_file,
> > +"Stack clash AArch64 prologue residuals: "
> > +HOST_WIDE_INT_PRINT_DEC " bytes, probing will be required."
> > +"\n", residual);
> > + emit_stack_probe (plus_constant (Pmode, stack_pointer_rtx,
> > + STACK_CLASH_CALLER_GUARD));
>
> reg_offsets are nonnegative, so if LR_REGNUM isn't saved at position 0,
> min_probe_threshold will be less than STACK_CLASH_CALLER_GUARD. It looks
> like the probe would then write above the region.
>
> Using >= rather than > means that the same thing could happen when
> LR_REGNUM is at position 0, if the residual is exactly
> STACK_CLASH_CALLER_GUARD.
That's true. While addressing this we changed how the residuals are probed.
To address a comment you raised offline about the saving of LR when calling
a no-return function using a tail call and -fomit-frame-pointer, I think this
should
be safe as the code in frame_layout (line 4131-4136) would ensure that R30 is
saved.
I have added two new tests to check for this, so that if it does change in the
future they
would fail.
Attached is the updated patch and new changelog
Ok for trunk?
Thanks,
Tamar
gcc/
2018-09-07 Jeff Law
Richard Sandiford
Tamar Christina
PR target/86486
* config/aarch64/aarch64.md
(probe_stack_range): Add k (SP) constraint.
* config/aarch64/aarch64.h (STACK_CLASH_CALLER_GUARD,
STACK_CLASH_MAX_UNROLL_PAGES): New.
* config/aarch64/aarch64.c (aarch64_output_probe_stack_range): Emit
stack probes for stack clash.
(aarch64_allocate_and_probe_stack_space): New.
(aarch64_expand_prologue): Use it.
(aarch64_expand_epilogue): Likewise and update IP regs re-use criteria.
(aarch64_sub_sp): Add emit_move_imm optional param.
gcc/testsuite/
2018-09-07 Jeff Law
Richard Sandiford
Tamar Christina
PR target/86486
* gcc.target/aarch64/stack-check-12.c: New.
* gcc.target/aarch64/stack-check-13.c: New.
* gcc.target/aarch64/stack-check-cfa-1.c: New.
* gcc.target/aarch64/stack-check-cfa-2.c: New.
* gcc.target/aarch64/stack-check-prologue-1.c: New.
* gcc.target/aarch64/stack-check-prologue-10.c: New.
* gcc.target/aarch64/stack-check-prologue-11.c: New.
* gcc.target/aarch64/stack-check-prologue-12.c: New.
* gcc.target/aarch64/stack-check-prologue-13.c: New.
* gcc.target/aarch64/stack-check-prologue-14.c: New.
* gcc.target/aarch64/stack-check-prologue-15.c: New.
* gcc.target/aarch64/stack-check-prologue-2.c: New.
* gcc.target/aarch64/stack-check-prologue-3.c: New.
* gcc.target/aarch64/stack-check-prologue-4.c: New.
* gcc.target/aarch64/stack-check-prologue-5.c: New.
* gcc.target/aarch64/stack-check-prologue-6.c: New.
* gcc.target/aarch64/stack-check-prologue-7.c: New.
* gcc.target/aarch64/stack-check-prologue-8.c: New.
* gcc.target/aarch64/stack-check-prologue-9.c: New.
* gcc.target/aarch64/stack-check-prologue.h: New.
* lib/target-supports.exp
(check_effective_target_supports_stack_clash_protection): Add AArch64.
>
> Thanks,
> Richard
--
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index c1218503bab19323eee1cca8b7e4bea8fbfcf573..bfb6d92f5e665b14926514b864489cb3f2793336 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -84,6 +84,14 @@
#define LONG_DOUBLE_TYPE_SIZE 128
+/* This value is the amount of bytes a caller is allowed to drop the stack
+ before probing has to be done for stack clash protection. */
+#define STACK_CLASH_CALLER_GUARD 1024
+
+/* This value controls how many pages we manually unroll the loop for when
+ generating stack clash probes. */
+#define STACK_CLASH_MAX_UNROLL_PAGES 4
+
/* The architecture reserves all bits of the address for hardware use,
so the vbit must go into the delta field of pointer
[PATCH, i386]: Rewrite float patterns
Hello!
Attached patch rewrites float patterns. When disabled by
X87_ENABLE_FLOAT macro, generic expanders are able to correctly use
wider FPmode patterns and float truncation sequence, so there is no
need to do the same functionality manually in the expander.
The patch also re-enables floatdi2_i387_with_xmm
pattern, so we are able to avoid partial register stalls when
compiling DImode float conversion on 32bit targets, e.g.:
double test (long long x) { return x + 1; }
-O2 -m32 -msse2 -mtune=intel -mfpmath=387 produces following code:
addl$1, %eax
movd%eax, %xmm0
adcl$0, %edx
movd%edx, %xmm1
punpckldq %xmm1, %xmm0
movq%xmm0, (%esp)
fildq (%esp)
2018-09-07 Uros Bizjak
* config/i386/i386.md (float2) Enable
DImode for x87 on 32bit targets. Conditionally disable x87 modes
with X87_ENABLE_FLOAT. Remove preparation code.
(*float2): Rename from
*float2_mixed. Handle x87, SSE and mixed
math using "enabled" attribute.
(*floatdi2_i387): Rename from
*float2_i387. Handle only DImode and
enable for 32bit targets only.
(floatdi2_i387_with_xmm pre-reload splitter): New
splitter.
(floatdi2_i387_with_xmm): Use register_operand
as operand 1 predicate. Rewrite as define_insn_and_split.
(floatdi2_i387_with_xmm memory input splitter): Remove.
Patch was bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index a35c8a55cc6..cf920db27d7 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -5063,36 +5063,19 @@
(set_attr "znver1_decode" "double")
(set_attr "fp_int_src" "true")])
-(define_expand "float2"
+(define_expand "float2"
[(set (match_operand:MODEF 0 "register_operand")
- (float:MODEF (match_operand:SWI48 1 "nonimmediate_operand")))]
- "TARGET_80387 || (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"
-{
- if (!(SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)
- && !X87_ENABLE_FLOAT (mode, mode))
-{
- rtx reg = gen_reg_rtx (XFmode);
- rtx (*insn)(rtx, rtx);
-
- emit_insn (gen_floatxf2 (reg, operands[1]));
+ (float:MODEF (match_operand:SWI48x 1 "nonimmediate_operand")))]
+ "(TARGET_80387 && X87_ENABLE_FLOAT (mode, mode))
+ || (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH
+ && ((mode != DImode) || TARGET_64BIT))")
- if (mode == SFmode)
- insn = gen_truncxfsf2;
- else if (mode == DFmode)
- insn = gen_truncxfdf2;
- else
- gcc_unreachable ();
-
- emit_insn (insn (operands[0], reg));
- DONE;
-}
-})
-
-(define_insn "*float2_mixed"
+(define_insn "*float2"
[(set (match_operand:MODEF 0 "register_operand" "=f,v,v")
(float:MODEF
(match_operand:SWI48 1 "nonimmediate_operand" "m,r,m")))]
- "SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"
+ "(TARGET_80387 && X87_ENABLE_FLOAT (mode, mode))
+ || (SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH)"
"@
fild%Z1\t%1
%vcvtsi2\t{%1, %d0|%d0, %1}
@@ -5113,21 +5096,28 @@
(set_attr "znver1_decode" "double,*,*")
(set_attr "fp_int_src" "true")
(set (attr "enabled")
- (cond [(eq_attr "alternative" "0")
- (symbol_ref "TARGET_MIX_SSE_I387
- && X87_ENABLE_FLOAT (mode,
-mode)")
- ]
- (symbol_ref "true")))
+ (if_then_else
+ (match_test ("SSE_FLOAT_MODE_P (mode) && TARGET_SSE_MATH"))
+ (if_then_else
+(eq_attr "alternative" "0")
+ (symbol_ref "TARGET_MIX_SSE_I387
+ && X87_ENABLE_FLOAT (mode,
+ mode)")
+(symbol_ref "true"))
+ (if_then_else
+(eq_attr "alternative" "0")
+(symbol_ref "true")
+(symbol_ref "false"
(set (attr "preferred_for_speed")
(cond [(eq_attr "alternative" "1")
(symbol_ref "TARGET_INTER_UNIT_CONVERSIONS")]
(symbol_ref "true")))])
-(define_insn "*float2_i387"
+(define_insn "*floatdi2_i387"
[(set (match_operand:MODEF 0 "register_operand" "=f")
- (float:MODEF (match_operand:SWI48x 1 "nonimmediate_operand" "m")))]
- "TARGET_80387 && X87_ENABLE_FLOAT (mode, mode)"
+ (float:MODEF (match_operand:DI 1 "nonimmediate_operand" "m")))]
+ "!TARGET_64BIT
+ && TARGET_80387 && X87_ENABLE_FLOAT (mode, DImode)"
"fild%Z1\t%1"
[(set_attr "type" "fmov")
(set_attr "mode" "")
@@ -5242,32 +5232,34 @@
;; Avoid store forwarding (partial memory) stall penalty
;; by passing DImode value through XMM registers. */
-(define_insn "floatdi2_i387_with_xmm"
- [(set (match_operand:X87MODEF 0 "register_operand" "=f,f")
- (float:X87MODEF
- (match_operand:DI 1 "nonimmediate_operand" "m,?r")))
- (clobber (match_scratch:V4SI 3 "=X,x"))
- (clobber (match_scratch:V4SI 4 "=X,x"))
- (clobber (mat
C++ PATCH to fix direct-enum-init1.C
My recent changes regarding narrowing conversions removed the "inside {}"
part of the diagnostic, so this test needs to be updated.
Tested x86_64-linux, applying to trunk.
2018-09-07 Marek Polacek
* g++.dg/cpp1z/direct-enum-init1.C: Remove "inside" from diagnostic
messages.
diff --git gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C
gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C
index fa2934e2371..185025308ba 100644
--- gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C
+++ gcc/testsuite/g++.dg/cpp1z/direct-enum-init1.C
@@ -29,34 +29,34 @@ foo ()
D d6 { G }; // { dg-error "cannot convert 'A' to 'D' in
initialization" "" { target c++14_down } }
E e1 { 5 }; // { dg-error "cannot convert 'int' to 'E' in
initialization" "" { target c++14_down } }
E e2 { -1 }; // { dg-error "cannot convert 'int' to 'E' in
initialization" "" { target c++14_down } }
- // { dg-error "narrowing conversion of '-1' from 'int'
to 'unsigned char' inside" "" { target c++17 } .-1 }
+ // { dg-error "narrowing conversion of '-1' from 'int'
to 'unsigned char'" "" { target c++17 } .-1 }
E e3 { 5.0 };// { dg-error "cannot convert 'double' to 'E'
in initialization" "" { target c++14_down } }
- // { dg-error "narrowing conversion of '5.0e.0' from
'double' to 'unsigned char' inside" "" { target c++17 } .-1 }
+ // { dg-error "narrowing conversion of '5.0e.0' from
'double' to 'unsigned char'" "" { target c++17 } .-1 }
E e4 { 5.2 };// { dg-error "cannot convert 'double' to 'E'
in initialization" "" { target c++14_down } }
- // { dg-error "narrowing conversion of '5.\[0-9]*e.0'
from 'double' to 'unsigned char' inside" "" { target c++17 } .-1 }
+ // { dg-error "narrowing conversion of '5.\[0-9]*e.0'
from 'double' to 'unsigned char'" "" { target c++17 } .-1 }
B b2 = { 7 };// { dg-error "invalid conversion from 'int' to
'B'" }
C c2 = { C { 8 } }; // { dg-error "cannot convert 'int' to 'C' in
initialization" "" { target c++14_down } }
D *d7 = new D { 9 }; // { dg-error "cannot convert \[^\n\r]* to 'D' in
initialization" "" { target c++14_down } }
E *e5 = new E { -4 };// { dg-error "cannot convert \[^\n\r]* to 'E'
in initialization" "" { target c++14_down } }
- // { dg-error "narrowing conversion of '-4' from 'int'
to 'unsigned char' inside" "" { target c++17 } .-1 }
+ // { dg-error "narrowing conversion of '-4' from 'int'
to 'unsigned char'" "" { target c++17 } .-1 }
bar ({ 10 });// { dg-error "cannot convert \[^\n\r]* to 'E'"
}
bar (E { 9 }); // { dg-error "cannot convert 'int' to 'E' in
initialization" "" { target c++14_down } }
V v1 = { { 11 } }; // { dg-error "braces around scalar initializer for
type 'E'" }
V v2 = { E { 12 } }; // { dg-error "cannot convert 'int' to 'E' in
initialization" "" { target c++14_down } }
V v3 = { E { 5.0 } };// { dg-error "cannot convert 'double' to 'E'
in initialization" "" { target c++14_down } }
- // { dg-error "narrowing conversion of '5.0e.0' from
'double' to 'unsigned char' inside" "" { target c++17 } .-1 }
+ // { dg-error "narrowing conversion of '5.0e.0' from
'double' to 'unsigned char'" "" { target c++17 } .-1 }
V v4 = { 13 }; // { dg-error "cannot convert 'int' to 'E' in
initialization" }
if (B b3 { 5 }) // { dg-error "invalid conversion from 'int' to 'B'" ""
{ target c++14_down } }
;
if (B b4 { 4.0 })// { dg-error "cannot convert 'double' to 'B' in
initialization" "" { target c++14_down } }
-; // { dg-error "narrowing conversion of '4.0e.0' from
'double' to 'short int' inside" "" { target c++17 } .-1 }
+; // { dg-error "narrowing conversion of '4.0e.0' from
'double' to 'short int'" "" { target c++17 } .-1 }
C c3 { 8L }; // { dg-error "cannot convert 'long int' to 'C' in
initialization" "" { target c++14_down } }
B b4 {short (c + 5)};// { dg-error "invalid conversion from 'short
int' to 'B'" "" { target c++14_down } }
B b5 {c + 5};// { dg-error "invalid conversion from 'int' to
'B'" "" { target c++14_down } }
- // { dg-error "narrowing conversion of \[^\n\r]* from
'int' to 'short int' inside" "" { target c++17 } .-1 }
+ // { dg-error "narrowing conversion of \[^\n\r]* from
'int' to 'short int'" "" { target c++17 } .-1 }
C c4 { ll }; // { dg-error "cannot convert 'long long int' to 'C' in
initialization" "" { target c++14_down } }
- // { dg-error "narrowing conversion of 'll' from 'long
long int' to 'int' inside" "" { target c++17 } .-1 }
+ // { dg-error "narrowing conversion of '
Re: C++ PATCH for c++/57891, narrowing conversions in non-type template arguments
On Fri, Sep 07, 2018 at 01:40:53PM +0100, Jason Merrill wrote:
> > 2018-08-13 Marek Polacek
> >
> > PR c++/57891
> > * call.c (struct conversion): Add check_narrowing_const_only.
> > (build_converted_constant_expr): Set check_narrowing and
> > check_narrowing_const_only. Give error if expr is error node.
> > (convert_like_real): Pass it to check_narrowing.
> > * cp-tree.h (check_narrowing): Add a default parameter.
> > * decl.c (compute_array_index_type): Use input_location instead of
> > location_of.
> > * pt.c (convert_nontype_argument): Return NULL_TREE if tf_error.
> > * typeck2.c (check_narrowing): Don't warn for
> > instantiation-dependent
> > expressions. Call maybe_constant_value instead of
> > fold_non_dependent_expr. Don't mention { } in diagnostic. Only
> > check
> > narrowing for constants if CONST_ONLY.
>
> This seems to have broken cpp1z/direct-enum-init1.C with -std=c++17
> and above; please use make check-c++-all (or set
> GXX_TESTSUITE_STDS=98,11,14,17,2a) to test C++ patches in all
> conformance modes.
Sorry about that, I've updated my testing and will fix it shortly.
Marek
Re: C++ PATCH for c++/87150, wrong ctor with maybe-rvalue semantics
On Fri, Sep 07, 2018 at 12:04:47PM +0100, Jason Merrill wrote: > I finally found the recent discussion I mentioned earlier: > > http://lists.isocpp.org/core/2018/06/4562.php > > which hasn't made it into the issues list yet. > > This discussion seems to suggest that the standard is likely to change > to allow this example and 87109, so fixing G++ to reject them may not > be what we want to do right now. Thanks for the pointer. Agreed -- I've SUSPENDED the PR. Marek
Re: [PATCH] PR 53796 Improve INQUIRE(RECL=...) handling
Janne, On Mon, 27 Nov 2017 at 20:57, Thomas Koenig wrote: > > Hi Janne, > > > PING > > Looks good for trunk. Thanks! AFAICS this removed the last user of static void init_unsigned_integer which manifests itself as ../../../../../src/gcc-9.0.mine/libgfortran/runtime/environ.c:104:1: warning: ‘init_unsigned_integer’ defined but not used [-Wunused-function] 104 | init_unsigned_integer (variable * v) | ^ and hence should be removed. thanks,
Re: [PATCH] Use complete_array_type on flexible array member initializers
On 09/07/18 08:51, Bernd Edlinger wrote: > On 09/07/18 00:26, Jeff Law wrote: >> On 09/06/2018 04:16 PM, Jeff Law wrote: >>> On 09/06/2018 04:01 PM, Jeff Law wrote: On 09/06/2018 11:12 AM, Bernd Edlinger wrote: >> > > Ah, thanks a lot. > > Okay, this is the status of the STRING-CST semantic-v2 patches: > > [PATCH] Check the STRING_CSTs in varasm.c > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01569.html > => Unfortunately I forgot to change the Title to [PATCHv2] or so. > Should I send a ping for this one? > > [PATCHv2] Handle overlength strings in the C FE > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01566.html > => Should I send a ping for this one? No need to ping. I've got it here. What's odd is that it's regressing 87053 . >>> Which is probably a sign that we've got an incorrect test for NUL >>> termination somewhere. > > It may be a sign that we should first fix the low level functions > before the high level stuff. > >> I think I've found the issue. I've got more testing to do, but looks >> like a thinko on my part. >> > > Ah, I forgot, the regression on pr87053 and fortran.dg/pr45636.f90 > is fixed by this patch: > > [PATCH] Adjust c_getstr/c_strlen to new STRING_CST semantic > https://gcc.gnu.org/ml/gcc-patches/2018-08/msg02013.html > > This is a new regression since the patch was initially posted. > Well, actually both patches seem to have a circular dependency. If you want we can break this dependency by adding this to the c_getstr patch: --- gcc/fold-const.c2018-09-07 14:22:50.047964775 +0200 +++ gcc/fold-const.c2018-09-07 15:06:46.656989904 +0200 @@ -14611,6 +14611,10 @@ c_getstr (tree src, unsigned HOST_WIDE_I unsigned HOST_WIDE_INT string_length = TREE_STRING_LENGTH (src); unsigned HOST_WIDE_INT string_size = tree_to_uhwi (mem_size); + /* Ideally this would turn into a gcc_checking_assert over time. */ + if (string_length > string_size) +return NULL; + const char *string = TREE_STRING_POINTER (src); if (string_length == 0 This should allow it to work with current semantics as well. Bernd.
bootstrap with --werror=yes fails
Heads Due too -Wabi empty class std::intergal_constant warning compiling libstdc++/c++/cxx11-shim_facets.cc Graham
Re: C++ PATCH for c++/57891, narrowing conversions in non-type template arguments
On Mon, Aug 13, 2018 at 11:24 PM, Marek Polacek wrote:
> On Mon, Aug 13, 2018 at 10:14:21PM +1200, Jason Merrill wrote:
>> >> >> > --- gcc/cp/decl.c
>> >> >> > +++ gcc/cp/decl.c
>> >> >> > @@ -9581,7 +9581,7 @@ compute_array_index_type (tree name, tree
>> >> >> > size, tsubst_flags_t complain)
>> >> >> > {
>> >> >> >tree folded = cp_fully_fold (size);
>> >> >> >if (TREE_CODE (folded) == INTEGER_CST)
>> >> >> > - pedwarn (location_of (size), OPT_Wpedantic,
>> >> >> > + pedwarn (input_location, OPT_Wpedantic,
>> >> >>
>> >> >> It should work to use location_of (osize) here.
>> >> >
>> >> > I dropped this hunk altogether. Because location_of will use
>> >> > DECL_SOURCE_LOCATION for DECLs, the error message will point to the
>> >> > declaration
>> >> > itself, not the use. I don't really care either way.
>> >>
>> >> We want the message to point to the use, which location_of (osize)
>> >> will provide, since it should still have a location wrapper around a
>> >> DECL.
>> >
>> > location_of (osize) is actually the same as location_of (size) so that
>> > didn't
>> > change anything.
>>
>> Hunh, that's strange. Why isn't osize the unfolded expression? Where
>> is the location wrapper getting stripped?
>
> I actually see that it didn't have the location wrapper at the start.
> The array bound is parsed in cp_parser_direct_new_declarator, and we
> never called maybe_wrap_with_location to add the wrapper. I don't know
> where that's supposed to happen.
>
> This quick hack works
>
> --- a/gcc/cp/parser.c
> +++ b/gcc/cp/parser.c
> @@ -8681,6 +8681,7 @@ cp_parser_direct_new_declarator (cp_parser* parser)
>cp_parser_require (parser, CPP_CLOSE_SQUARE, RT_CLOSE_SQUARE);
>
>/* Add this bound to the declarator. */
> + expression = maybe_wrap_with_location (expression, token->location);
>declarator = make_array_declarator (declarator, expression);
>
>/* If the next token is not a `[', then there are no more
>
> but that feels too ad-hoc and beyond the scope of this fix.
>
>> > The code below uses input_location which is why I went with
>> > it in the first place. So, should I change this to input_location?
>>
>> I suppose so.
>
> Here's the version with input_location.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-08-13 Marek Polacek
>
> PR c++/57891
> * call.c (struct conversion): Add check_narrowing_const_only.
> (build_converted_constant_expr): Set check_narrowing and
> check_narrowing_const_only. Give error if expr is error node.
> (convert_like_real): Pass it to check_narrowing.
> * cp-tree.h (check_narrowing): Add a default parameter.
> * decl.c (compute_array_index_type): Use input_location instead of
> location_of.
> * pt.c (convert_nontype_argument): Return NULL_TREE if tf_error.
> * typeck2.c (check_narrowing): Don't warn for instantiation-dependent
> expressions. Call maybe_constant_value instead of
> fold_non_dependent_expr. Don't mention { } in diagnostic. Only check
> narrowing for constants if CONST_ONLY.
This seems to have broken cpp1z/direct-enum-init1.C with -std=c++17
and above; please use make check-c++-all (or set
GXX_TESTSUITE_STDS=98,11,14,17,2a) to test C++ patches in all
conformance modes.
Jason
Re: C++ PATCH for c++/87152, range-based for loops with initializer broken in templates
OK
On Fri, Sep 7, 2018 at 4:29 AM, Marek Polacek wrote:
> Turned out our range-based for loops with initializer are completely broken
> in templates, because I neglected to add the init-statement to RANGE_FOR_STMT.
> range-for18.C should verify we put it into the right scope.
>
> tsubst_expr then needs to recurse on it to avoid the ICE.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-09-06 Marek Polacek
>
> PR c++/87152 - range-based for loops with initializer broken in
> templates.
> * constexpr.c (potential_constant_expression_1) :
> Recur into RANGE_FOR_INIT_STMT.
> * cp-tree.def: Add RANGE_FOR_INIT_STMT to RANGE_FOR_STMT.
> * cp-tree.h (RANGE_FOR_INIT_STMT): Define.
> * dump.c (cp_dump_tree) : Also dump
> RANGE_FOR_INIT_STMT.
> * pt.c (tsubst_expr) : Recur into
> RANGE_FOR_INIT_STMT.
> * semantics.c (begin_range_for_stmt): Adjust call to build_stmt.
> Do put the init statement in RANGE_FOR_INIT_STMT.
> (finish_range_for_decl): Pop it for templates.
>
> * g++.dg/cpp2a/range-for11.C: New test.
> * g++.dg/cpp2a/range-for12.C: New test.
> * g++.dg/cpp2a/range-for13.C: New test.
> * g++.dg/cpp2a/range-for14.C: New test.
> * g++.dg/cpp2a/range-for15.C: New test.
> * g++.dg/cpp2a/range-for16.C: New test.
> * g++.dg/cpp2a/range-for17.C: New test.
> * g++.dg/cpp2a/range-for18.C: New test.
> * g++.dg/parse/error61.C (foo): Adjust dg-error.
>
> diff --git gcc/cp/constexpr.c gcc/cp/constexpr.c
> index f646519135f..6c2689064f3 100644
> --- gcc/cp/constexpr.c
> +++ gcc/cp/constexpr.c
> @@ -5767,6 +5767,8 @@ potential_constant_expression_1 (tree t, bool
> want_rval, bool strict, bool now,
>return true;
>
> case RANGE_FOR_STMT:
> + if (!RECUR (RANGE_FOR_INIT_STMT (t), any))
> + return false;
>if (!RECUR (RANGE_FOR_EXPR (t), any))
> return false;
>if (!RECUR (RANGE_FOR_BODY (t), any))
> diff --git gcc/cp/cp-tree.def gcc/cp/cp-tree.def
> index 1b0326f4e81..c64225ded6f 100644
> --- gcc/cp/cp-tree.def
> +++ gcc/cp/cp-tree.def
> @@ -301,9 +301,10 @@ DEFTREECODE (IF_STMT, "if_stmt", tcc_statement, 4)
> DEFTREECODE (FOR_STMT, "for_stmt", tcc_statement, 5)
>
> /* Used to represent a range-based `for' statement. The operands are
> - RANGE_FOR_DECL, RANGE_FOR_EXPR, RANGE_FOR_BODY, and RANGE_FOR_SCOPE,
> - RANGE_FOR_UNROLL respectively. Only used in templates. */
> -DEFTREECODE (RANGE_FOR_STMT, "range_for_stmt", tcc_statement, 5)
> + RANGE_FOR_DECL, RANGE_FOR_EXPR, RANGE_FOR_BODY, RANGE_FOR_SCOPE,
> + RANGE_FOR_UNROLL, and RANGE_FOR_INIT_STMT, respectively. Only used in
> + templates. */
> +DEFTREECODE (RANGE_FOR_STMT, "range_for_stmt", tcc_statement, 6)
>
> /* Used to represent a 'while' statement. The operands are WHILE_COND
> and WHILE_BODY, respectively. */
> diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
> index df441fca304..b78e9eb252b 100644
> --- gcc/cp/cp-tree.h
> +++ gcc/cp/cp-tree.h
> @@ -4923,6 +4923,7 @@ more_aggr_init_expr_args_p (const
> aggr_init_expr_arg_iterator *iter)
> #define RANGE_FOR_BODY(NODE) TREE_OPERAND (RANGE_FOR_STMT_CHECK (NODE), 2)
> #define RANGE_FOR_SCOPE(NODE) TREE_OPERAND (RANGE_FOR_STMT_CHECK (NODE), 3)
> #define RANGE_FOR_UNROLL(NODE) TREE_OPERAND (RANGE_FOR_STMT_CHECK (NODE), 4)
> +#define RANGE_FOR_INIT_STMT(NODE) TREE_OPERAND (RANGE_FOR_STMT_CHECK (NODE),
> 5)
> #define RANGE_FOR_IVDEP(NODE) TREE_LANG_FLAG_6 (RANGE_FOR_STMT_CHECK (NODE))
>
> #define SWITCH_STMT_COND(NODE) TREE_OPERAND (SWITCH_STMT_CHECK (NODE), 0)
> diff --git gcc/cp/dump.c gcc/cp/dump.c
> index 9c1e5fc781a..d9b868bfaef 100644
> --- gcc/cp/dump.c
> +++ gcc/cp/dump.c
> @@ -301,6 +301,7 @@ cp_dump_tree (void* dump_info, tree t)
>
> case RANGE_FOR_STMT:
>dump_stmt (di, t);
> + dump_child ("init", RANGE_FOR_INIT_STMT (t));
>dump_child ("decl", RANGE_FOR_DECL (t));
>dump_child ("expr", RANGE_FOR_EXPR (t));
>dump_child ("body", RANGE_FOR_BODY (t));
> diff --git gcc/cp/pt.c gcc/cp/pt.c
> index 0a618a5447d..892a387cbc5 100644
> --- gcc/cp/pt.c
> +++ gcc/cp/pt.c
> @@ -16815,6 +16815,7 @@ tsubst_expr (tree t, tree args, tsubst_flags_t
> complain, tree in_decl,
> stmt = (processing_template_decl
> ? begin_range_for_stmt (NULL_TREE, NULL_TREE)
> : begin_for_stmt (NULL_TREE, NULL_TREE));
> + RECUR (RANGE_FOR_INIT_STMT (t));
> decl = RANGE_FOR_DECL (t);
> decl = tsubst (decl, args, complain, in_decl);
> maybe_push_decl (decl);
> diff --git gcc/cp/semantics.c gcc/cp/semantics.c
> index 676de011868..f3e5d83b1ef 100644
> --- gcc/cp/semantics.c
> +++ gcc/cp/semantics.c
> @@ -1101,8 +1101,8 @@ begin_range_for_stmt (tree scope, tree init)
> {
>begin_maybe_infinite_loop (boolean_false_node);
>
> - tree r = build_stmt (input_location, RANGE_FOR_STMT,
> -
Re: [PATCH 2/2] z13 pipeline
On 06.09.2018 10:41, Robin Dapp wrote: > > Similar to zEC12, the change in latencies helps match the real machine's > behavior better. > > -- > > gcc/ChangeLog: > > 2018-09-06 Robin Dapp > > * config/s390/2964.md: Increase latencies for some FP instructions. Ok, thanks! Andreas
Re: [PATCH 1/2] zEC12 pipeline
On 06.09.2018 10:41, Robin Dapp wrote: > > Hi, > > this patch increases the latency of some floating point instructions to better > match the real machine's behavior. > > Regards > Robin > > -- > > gcc/ChangeLog: > > 2018-09-06 Robin Dapp > > * config/s390/2827.md: Increase latencies for some FP instructions. Ok, thanks! Andreas
Re: C++ PATCH for c++/87150, wrong ctor with maybe-rvalue semantics
I finally found the recent discussion I mentioned earlier:
http://lists.isocpp.org/core/2018/06/4562.php
which hasn't made it into the issues list yet.
This discussion seems to suggest that the standard is likely to change
to allow this example and 87109, so fixing G++ to reject them may not
be what we want to do right now.
On Fri, Sep 7, 2018 at 4:30 AM, Marek Polacek wrote:
> Another case where we weren't respecting the [class.copy.elision]/3 rule that
> "if the type of the first parameter of the selected constructor is not an
> rvalue reference to the object's type (possibly cv-qualified), overload
> resolution is performed again, considering the object as an lvalue." In this
> case the types differ because of the derived-to-base conversion. As a result,
> we chose the wrong ctor.
>
> It seems that if we set rvaluedness_matches_p for ck_base, build_over_call
> then correctly returns error_mark_node for such ctor, because if sees that
> the CONVERSION_RANK is unsuitable.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2018-09-06 Marek Polacek
>
> PR c++/87150 - wrong ctor with maybe-rvalue semantics.
> * call.c (struct conversion): Update commentary.
> (standard_conversion): Set rvaluedness_matches_p if
> LOOKUP_PREFER_RVALUE
> for ck_base.
>
> * g++.dg/cpp0x/move-return2.C: New test.
>
> diff --git gcc/cp/call.c gcc/cp/call.c
> index 942b2c204be..03b4c5ab224 100644
> --- gcc/cp/call.c
> +++ gcc/cp/call.c
> @@ -102,10 +102,10 @@ struct conversion {
>BOOL_BITFIELD base_p : 1;
>/* If KIND is ck_ref_bind, true when either an lvalue reference is
> being bound to an lvalue expression or an rvalue reference is
> - being bound to an rvalue expression. If KIND is ck_rvalue,
> + being bound to an rvalue expression. If KIND is ck_rvalue or ck_base,
> true when we are treating an lvalue as an rvalue (12.8p33). If
> - KIND is ck_base, always false. If ck_identity, we will be
> - binding a reference directly or decaying to a pointer. */
> + ck_identity, we will be binding a reference directly or decaying to
> + a pointer. */
>BOOL_BITFIELD rvaluedness_matches_p: 1;
>BOOL_BITFIELD check_narrowing: 1;
>/* Whether check_narrowing should only check TREE_CONSTANTs; used
> @@ -1425,6 +1425,9 @@ standard_conversion (tree to, tree from, tree expr,
> bool c_cast_p,
> type. A temporary object is created to hold the result of
> the conversion unless we're binding directly to a reference. */
>conv->need_temporary_p = !(flags & LOOKUP_NO_TEMP_BIND);
> + if (flags & LOOKUP_PREFER_RVALUE)
> + /* Tell convert_like_real to set LOOKUP_PREFER_RVALUE. */
> + conv->rvaluedness_matches_p = true;
> }
>else
> return NULL;
> diff --git gcc/testsuite/g++.dg/cpp0x/move-return2.C
> gcc/testsuite/g++.dg/cpp0x/move-return2.C
> index e69de29bb2d..681e9ecaca1 100644
> --- gcc/testsuite/g++.dg/cpp0x/move-return2.C
> +++ gcc/testsuite/g++.dg/cpp0x/move-return2.C
> @@ -0,0 +1,11 @@
> +// PR c++/87150
> +// { dg-do compile { target c++11 } }
> +
> +struct S1 { S1(S1 &&); };
> +struct S2 : S1 {};
> +
> +S1
> +f (S2 s)
> +{
> + return s; // { dg-error "use of deleted function" }
> +}
RFA: PATCH to fix crash with --enable-gather-detailed-mem-stats
Turning on --enable-gather-detailed-mem-stats was producing for me a
compiler that crashed before main() because initializing the
hash_table sem_item::m_type_hash_cache was trying to add to
hash_table_usage before the latter had been initialized. This patch
fixes this by changing hash_table_usage to be a function, so that it
is initialized on demand.
Tested x86_64-pc-linux-gnu. OK for trunk?
commit 8c58e31b5938f24f3730cda83d9556aad25324df
Author: Jason Merrill
Date: Tue Sep 4 17:12:26 2018 -0400
Fix --enable-gather-detailed-mem-stats.
* hash-table.c (hash_table_usage): Change from variable to function.
* hash-table.h: Adjust.
* Makefile.in: Add missing dependencies on hash-table.h.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e008f63b2ea..4b7cec82382 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2665,7 +2665,7 @@ build/version.o: version.c version.h \
build/errors.o : errors.c $(BCONFIG_H) $(SYSTEM_H) errors.h
build/gensupport.o: gensupport.c $(BCONFIG_H) $(SYSTEM_H) \
$(CORETYPES_H) $(GTM_H) $(RTL_BASE_H) $(OBSTACK_H) errors.h \
- $(HASHTAB_H) $(READ_MD_H) $(GENSUPPORT_H)
+ $(HASHTAB_H) $(READ_MD_H) $(GENSUPPORT_H) $(HASH_TABLE_H)
build/ggc-none.o : ggc-none.c $(BCONFIG_H) $(SYSTEM_H) $(CORETYPES_H) \
$(GGC_H)
build/min-insn-modes.o : min-insn-modes.c $(BCONFIG_H) $(SYSTEM_H) \
@@ -2680,7 +2680,7 @@ build/read-rtl.o: read-rtl.c $(BCONFIG_H) $(SYSTEM_H) $(CORETYPES_H) \
build/rtl.o: rtl.c $(BCONFIG_H) $(CORETYPES_H) $(GTM_H) $(SYSTEM_H) \
$(RTL_H) $(GGC_H) errors.h
build/vec.o : vec.c $(BCONFIG_H) $(SYSTEM_H) $(CORETYPES_H) $(VEC_H) \
- $(GGC_H) toplev.h $(DIAGNOSTIC_CORE_H)
+ $(GGC_H) toplev.h $(DIAGNOSTIC_CORE_H) $(HASH_TABLE_H)
build/hash-table.o : hash-table.c $(BCONFIG_H) $(SYSTEM_H) \
$(CORETYPES_H) $(HASH_TABLE_H) $(GGC_H) toplev.h $(DIAGNOSTIC_CORE_H)
build/sort.o : sort.cc $(BCONFIG_H) $(SYSTEM_H)
diff --git a/gcc/hash-table.c b/gcc/hash-table.c
index c86d84de217..bff9644ae81 100644
--- a/gcc/hash-table.c
+++ b/gcc/hash-table.c
@@ -98,7 +98,16 @@ hash_table_higher_prime_index (unsigned long n)
return low;
}
-mem_alloc_description hash_table_usage;
+/* Return a reference to the lazily initialized hash-table usage description.
+ This needs to be a function rather than a simple global variable so that it
+ is reliably initialized before hash table variables in other files such as
+ sem_item::m_type_hash_cache. */
+mem_alloc_description&
+hash_table_usage ()
+{
+ static mem_alloc_description usage;
+ return usage;
+}
/* Support function for statistics. */
void dump_hash_table_loc_statistics (void)
@@ -109,7 +118,6 @@ void dump_hash_table_loc_statistics (void)
for (unsigned i = HASH_TABLE_ORIGIN; i <= HASH_SET_ORIGIN; i++)
{
mem_alloc_origin origin = (mem_alloc_origin) i;
- hash_table_usage.dump (origin);
+ hash_table_usage ().dump (origin);
}
}
-
diff --git a/gcc/hash-table.h b/gcc/hash-table.h
index 706b2370e23..bd83345c7b8 100644
--- a/gcc/hash-table.h
+++ b/gcc/hash-table.h
@@ -561,7 +561,7 @@ private:
#include "mem-stats.h"
#include "hash-map.h"
-extern mem_alloc_description hash_table_usage;
+extern mem_alloc_description& hash_table_usage (void);
/* Support function for statistics. */
extern void dump_hash_table_loc_statistics (void);
@@ -580,7 +580,7 @@ hash_table::hash_table (size_t size, bool ggc, bool
size = prime_tab[size_prime_index].prime;
if (m_gather_mem_stats)
-hash_table_usage.register_descriptor (this, origin, ggc
+hash_table_usage ().register_descriptor (this, origin, ggc
FINAL_PASS_MEM_STAT);
m_entries = alloc_entries (size PASS_MEM_STAT);
@@ -600,7 +600,7 @@ hash_table::hash_table (const hash_table &h, bool ggc,
size_t size = h.m_size;
if (m_gather_mem_stats)
-hash_table_usage.register_descriptor (this, origin, ggc
+hash_table_usage ().register_descriptor (this, origin, ggc
FINAL_PASS_MEM_STAT);
value_type *nentries = alloc_entries (size PASS_MEM_STAT);
@@ -630,7 +630,7 @@ hash_table::~hash_table ()
ggc_free (m_entries);
if (m_gather_mem_stats)
-hash_table_usage.release_instance_overhead (this,
+hash_table_usage ().release_instance_overhead (this,
sizeof (value_type) * m_size,
true);
}
@@ -644,7 +644,7 @@ hash_table::alloc_entries (size_t n MEM_STAT_DECL) const
value_type *nentries;
if (m_gather_mem_stats)
-hash_table_usage.register_instance_overhead (sizeof (value_type) * n, this);
+hash_table_usage ().register_instance_overhead (sizeof (value_type) * n, this);
if (!m_ggc)
nentries = Allocator ::data_alloc (n);
@@ -736,7 +736,7 @@ hash_table::expand ()
value_type *nentries = alloc_entries (nsize);
if (m_gather_mem_stats)
-hash_table_usage.release_instance_overhead (this, sizeof (value_type)
+hash_table_usage ().release_instance_overhead (this, sizeof (value_type)
* osize);
avoid uninitialized use in -Walloca* pass
Semi obvious patch here...
As the comment for alloca_type_and_limit says:
// For ALLOCA_BOUND_MAYBE_LARGE and ALLOCA_BOUND_DEFINITELY_LARGE
// types, this field indicates the assumed limit if known or
// integer_zero_node if unknown. For any other alloca types, this
// field is undefined.
So, there's no sense in creating ALLOCA_BOUND_*_LARGE entries without a
limit, as doing so would trigger reading undefined memory later on.
We could put an assert here, but I'd rather just let the constructor
build the right thing.
OK for trunk?
gcc/
* gimple-ssa-warn-alloca.c
(alloca_type_and_limit::alloca_type_and_limit): Initialize limit
field for ALLOCA_BOUND_*_LARGE.
diff --git a/gcc/gimple-ssa-warn-alloca.c b/gcc/gimple-ssa-warn-alloca.c
index 4d5aed866e1..d1b1de4a2d5 100644
--- a/gcc/gimple-ssa-warn-alloca.c
+++ b/gcc/gimple-ssa-warn-alloca.c
@@ -128,7 +128,11 @@ struct alloca_type_and_limit {
alloca_type_and_limit ();
alloca_type_and_limit (enum alloca_type type,
wide_int i) : type(type), limit(i) { }
- alloca_type_and_limit (enum alloca_type type) : type(type) { }
+ alloca_type_and_limit (enum alloca_type type) : type(type)
+ { if (type == ALLOCA_BOUND_MAYBE_LARGE
+ || type == ALLOCA_BOUND_DEFINITELY_LARGE)
+ limit = wi::to_wide (integer_zero_node);
+ }
};
/* Return the value of the argument N to -Walloca-larger-than= or
Re: [PATCH,FORTRAN 00/29] Move towards stringpool, part 1
On Wed, 5 Sep 2018 at 20:57, Janne Blomqvist wrote: > > On Wed, Sep 5, 2018 at 5:58 PM Bernhard Reutner-Fischer > wrote: >> Bootstrapped and regtested on x86_64-foo-linux. >> >> I'd appreciate if someone could double check for regressions on other >> setups. Git branch: >> https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool >> >> Ok for trunk? > > > Hi, > > this is quite an impressive patch set. I have looked through all the patches, > and on the surface they all look ok. Thanks alot for your appreciation! > > Unfortunately I don't have any exotic target to test on either, so I think > you just have to commit it and check for regression reports. Though I don't > see this set doing anything which would work differently on other targets, > but you never know.. > > I'd say wait a few days in case anybody else wants to comment on it, then > commit it to trunk. Upon further testing i encountered a regression in module writing, manifesting itself in a failure to compile ieee_8.f90 (and only this). f951: Fatal Error: Reading module ‘foo’ at line 4310 column 25: Expected string where we write the following garbage: 366 res'BLE IN UNKNOWN-PROC UNKNOWN UNKNOWN 0 0 End of last year when i wrote these patches i diffed each and every module in my regtests and all these were identical, so it must be some recent "regression" in that area. Sorry for that, I'll have another look during the weekend. thanks,
