[Bug other/58312] libssp configure check for "usable vsnprintf" is broken on cross-compilers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58312 --- Comment #6 from Brooks Moses --- (In reply to Eric Gallager from comment #5) > Is that patch still relevant? The relevant part of the libssp configure.ac hasn't changed much (if at all) since I posted the patch, so I think it's still worth applying just on basic of general correctness and avoiding unnecessary runtime checks in configure files for things that may be cross-compiled. However, our particular use-case for it is now gone; the relevant precompiled binary file was deleted from our source tree a few months ago. And apparently nobody else has run into the issue.
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020
Jerry DeLisle changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #8 from Jerry DeLisle ---
OK yes we are not doing anything with the return values of the calls to
'remove'.
The error machinery of generate_error takes care of actually assigning the
values to iostat or iomsg. I suggest the following patch.
diff --git a/libgfortran/io/close.c b/libgfortran/io/close.c
index cbcbf4e71a1..c5167bcbbc7 100644
--- a/libgfortran/io/close.c
+++ b/libgfortran/io/close.c
@@ -99,7 +99,11 @@ st_close (st_parameter_close *clp)
else
{
#if HAVE_UNLINK_OPEN_FILE
- remove (u->filename);
+
+ if (remove (u->filename))
+ generate_error (>common, LIBERROR_OS,
+ "File can not be deleted, possibly in use by"
+ " another process");
#else
path = strdup (u->filename);
#endif
@@ -112,7 +116,10 @@ st_close (st_parameter_close *clp)
#if !HAVE_UNLINK_OPEN_FILE
if (path != NULL)
{
- remove (path);
+ if (remove (u->filename))
+ generate_error (>common, LIBERROR_OS,
+ "File can not be deleted, possibly in use by"
+ " another process");
free (path);
}
#endif
I have not dreamt up a way to test this in a test case. I suppose I could
recreate the virtualbox environment Luke found this in. Reardless we should at
a minimum try to check for an OS error here. There are many possibilities so I
think the generic LIBERROR_OS we already have is sufficient. (The iostat code
will be 5000)
BTW I have seen where Windows 10 will essentially lock a file under weird
conditions where it thinks a file is being used by some process, including
simply haveing a folder open somewhere where the file resides. Even though this
environment is under Virtualbox under Ubunto, it is ultiately running NTFS and
the access rights in this environment can be obscure. As an example, I have
mounted NTFS systems using linux and been unable to change the priviliges of
the files.
Luke, do you ever build gcc?
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253
--- Comment #25 from Matthijs van Duin ---
I wasn't referring to the warnings though but incorrect code generation. Since
is exhibited by pretty trivial test cases (testsuite/g++.dg/cpp0x/initlist86.C
confirms that { i++, i++ } works but the analogous test for { ++i, ++i } fails)
yet was first reported long after this bug was marked "FIXED" I kind of assumed
it was a regression, but apparently it was just never really fixed to begin
with.
[Bug c++/70792] Incorrect sequence point warning with uniform initializer syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70792
--- Comment #8 from Matthijs van Duin ---
(In reply to Matthijs van Duin from comment #4)
> return std::pair{ ++i, ++i }.first;
My bad! This isn't an exhibit of the bug. I simply forgot that std::pair is not
really a struct, and this isn't aggregate initialization: the constructor takes
references, so correct code is generated in this case.
And in fact, if you do use an aggregate, the test works correctly.
However, if you replace std::pair by a class whose constructor takes (int,
int), similar to the one used in the existing testcase
(g++.dg/cpp0x/initlist86.C) then it fails again.
Looking at the disassembly (on ARM since I don't know x86 asm) shows that gcc
loads both arguments from the storage allocated for i, after both increments
have been done. Effectively it's copy-constructing the first argument too late.
The more general issue appears to be that if the arguments are trivially
copyable lvalues, then gcc keeps these as lvalues and copy-constructs the
actual arguments way too late. If I look at this disassembly of this code:
struct Foo {
char x[64]; // too big to pass in register
Foo( Foo const ) = default; // but still trivially copyable
Foo ();
};
struct Pair {
Pair( Foo x, Foo y );
};
void test( Foo ) {
Pair{ foo.mutate(), foo.mutate() };
}
Then test() effectively does:
Foo = foo.mutate();
Foo = foo.mutate();
Pair{ temp1, temp2 } // copy-construct arguments and call Pair constructor
(Also, interestingly, temp2 is copy-constructed before temp1 is!)
If Foo is not trivially copyable, even if merely due to the presence of a
destructor, then the problem disappears.
Re: [C++ PATCH] [PR87770] test partial specializations for type dependence
On Jan 24, 2019, Jason Merrill wrote:
> The latter; you can't have a partial specialization in a function.
*nod* (though not entirely reflected in the patch below, I see)
>> Any suggestion of a good name for the inline function (or would you
>> prefer it to be a macro?) that tests whether a decl satisfies this
>> predicate? primary_or_partial_spec_p?
> Sounds good.
I was not entirely clear on what the predicate was supposed to be when I
wrote the above. I hadn't fully realized we were testing properties of
a template instantiation by inspecting mostly properties of the
template, rather than of the instantiation proper. Once I realized
that, I hesitated between introducing a function to test properties of
the base template directly, or a function to test the instantiation for
those properties. It wasn't clear to me that having e.g. only
DECL_TI_TEMPLATE as an argument would be enough to test everything we
needed: we wouldn't have the context (should be the same) or the
template args (certainly not the same, but sharing the same depth?) of
the instantiation we were supposed to assess to begin with.
So I went with a different name that reflected more closely the test I
implemented: instantiates_primary_template_p.
Now, maybe we're better off with something that tests the template
rather than the instantiation, to use at other places where
PRIMARY_TEMPLATE_P is found insufficient. If that's the case, I'll have
to figure out whether taking just the template is enough, or whether we
need the tinfo object or are better off taking additional arguments.
But since that will take additional investigation and you had nodded to
the logic that involved the args of the instantiation, I'm leaving it at
this for now. Please let me know whether the alternate form would be
preferred.
This patch bootstrapped on x86_64- and i686-linux-gnu, and is undergoing
regression testing ATM. Ok to install if it passes?
for gcc/cp/ChangeLog
PR c++/87770
* pt.c (instantiates_primary_template_p): New.
(type_dependent_expression_p): Use it.
for gcc/testsuite/ChangeLog
PR c++/87770
* g++.dg/pr87770.C: New.
---
gcc/cp/pt.c| 55 +++-
gcc/testsuite/g++.dg/pr87770.C | 11
2 files changed, 65 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/pr87770.C
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 48c180cc13b3..d413fa81c59e 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -400,6 +400,59 @@ template_class_depth (tree type)
return depth;
}
+/* Return TRUE if NODE instantiates a template that has arguments of
+ its own, be it directly a primary template or indirectly through a
+ partial specializations. */
+static inline bool
+instantiates_primary_template_p (tree node)
+{
+ tree tinfo;
+ if (!DECL_P (node))
+tinfo = CLASSTYPE_TEMPLATE_INFO (node);
+ else if (DECL_LANG_SPECIFIC (node))
+tinfo = DECL_TEMPLATE_INFO (node);
+ else
+tinfo = NULL_TREE;
+
+ if (!tinfo)
+return false;
+
+ tree tmpl = TI_TEMPLATE (tinfo);
+ if (PRIMARY_TEMPLATE_P (tmpl))
+return true;
+
+ if (!DECL_TEMPLATE_SPECIALIZATION (tmpl))
+return false;
+
+ /* So now we know we have a specialization, but it could be a full
+ or a partial specialization. To tell which, compare the depth of
+ its template arguments with those of its context. ??? How do we
+ tell apart a partial from a full explicit specialization in a
+ non-template context? */
+
+ tree ctxt;
+ if (!DECL_P (node))
+ctxt = TYPE_CONTEXT (node);
+ else
+ctxt = DECL_CONTEXT (node);
+
+ tree ctinfo;
+ if (!DECL_P (ctxt))
+ctinfo = CLASSTYPE_TEMPLATE_INFO (ctxt);
+ else if (DECL_LANG_SPECIFIC (ctxt))
+ctinfo = DECL_TEMPLATE_INFO (ctxt);
+ else
+ctinfo = NULL_TREE;
+
+ int cdepth;
+ if (!ctinfo)
+cdepth = 0;
+ else
+cdepth = TMPL_ARGS_DEPTH (TI_ARGS (ctinfo));
+
+ return (TMPL_ARGS_DEPTH (TI_ARGS (tinfo)) > cdepth);
+}
+
/* Subroutine of maybe_begin_member_template_processing.
Returns true if processing DECL needs us to push template parms. */
@@ -25622,7 +25675,7 @@ type_dependent_expression_p (tree expression)
that come from the template-id; the template arguments for the
enclosing class do not make it type-dependent unless they are used in
the type of the decl. */
- if (PRIMARY_TEMPLATE_P (DECL_TI_TEMPLATE (expression))
+ if (instantiates_primary_template_p (expression)
&& (any_dependent_template_arguments_p
(INNERMOST_TEMPLATE_ARGS (DECL_TI_ARGS (expression)
return true;
diff --git a/gcc/testsuite/g++.dg/pr87770.C b/gcc/testsuite/g++.dg/pr87770.C
new file mode 100644
index ..69eff4a786fe
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr87770.C
@@ -0,0 +1,11 @@
+// { dg-do compile }
+
+template struct d {
+ template d(e);
+};
+template <> template d::d(e);
+template <> template
Re: PING [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125, 88886, 86308)
It's also broken the build of the glibc testsuite, e.g.: ../time/time.h:88:15: error: mismatch in argument 1 type of built-in function 'strftime'; expected 'char *' [-Werror=builtin-declaration-mismatch] 88 | extern size_t strftime (char *__restrict __s, size_t __maxsize, (presence or absence of qualifiers on a parameter is not part of the function type and should not be compared here). -- Joseph S. Myers jos...@codesourcery.com
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 --- Comment #4 from Matthew Wuensche --- (In reply to Andrew Pinski from comment #2) > >Built by MinGW-W64 project > > Can you make sure you downloaded all of the correct binaries. Hi, um... I just uninstalled my online download... then downloaded i686-8.1.0-release-win32-sjlj-rt_v6-rev0.7z and after running 7-zip and installing it to the same directory so that the paths would still be valid, I receive the same response when running gcc in N:\nesys\asm6\src; however, I still receive an exe if I run gcc from its folder. Though, the line is adjusted to: gcc -v n:\nesys\asm6\src\myfile.c -o myfile It just doesn't work when it has to use the path to find gcc. I wish it would use the path successfully. That cc1.exe line is now, when not using the path: C:/Program Files (x86)/mingw-w64/i686-8.1.0-win32-sjlj-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686-8.1.0-win32-w64-mingw32/8.1.0/cc1.exe -quiet -v -iprefix C:/Program Files (x86)/mingw-w64/i686-8.1.0-win32-sjlj-rt_v6-rev0/ming32/bin/../lib/gcc/i686-w64-mingw32/8.1.0/ -U_REENTRANT n:\nesys\asm6\src\myfile.c -quiet -dumpbase myfile.c -mtune=generic -march=i686 -auxbase myfile -version -o C:\Users\auser\AppData\Local\Temp\cc14fjys.s and then it says: GNU C17 (i686-win32-sjlj-rev0, Built by MinGW-W64 project) version 8.1.0 (i686-w64-mingw32) compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP and then two sections of "GCC heuristics" follow.
[Bug fortran/87566] ICE with class(*) and select
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 --- Comment #11 from Antony Lewis --- I posted remaining ICE in 9.0.0 20190119 as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
[Bug fortran/89069] New: ICE in select type with function returning class array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069 Bug ID: 89069 Summary: ICE in select type with function returning class array pointer Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: --- Follow up to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566, seg fault ICE with gfortran 6.5-9.0 module test contains function getP() class(*), pointer :: getP(:) end function getP subroutine SegFaulter() class(*), pointer :: Pt => null() select type (P=>getP()) type is (real) end select end subroutine end module test
[Bug target/89063] [x86] lack of support for BEXTR from BMI extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89063 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #1 from Peter Cordes --- Unfortunately Intel Haswell/Skylake implement BEXTR as 2 uops with 2c latency. Presumably those uops are a shift + bzhi, so 1p06 + 1p15 would explain Agner Fog's experimental result of 2p0156 for BEXTR, with 0.5c throughput. On AMD Excavator/Ryzen, it's 1 uop with 1c latency. On Steamroller and earlier, it's 2 uops but 1c latency. (I assume that's latency from the non-control input to the output. So maybe one of the uops pre-processes the control input, otherwise you'd expect 2c latency from either operand.) Ryzen dropped support for AMD TBM, so only Excavator (bdver4) has 1-uop bextr imm16 which would avoid the need for mov reg,imm32 with the control operand. But mov-imm + bextr can still be a win on Ryzen, lower latency than RORX+AND BMI2 RORX is single-uop on all CPUs that support it. If we already need a 2nd uop to mask anyway, we can use RORX+AND-immediate to duplicate the functionality and performance of BEXTR-immediate, with the smaller code-size if the AND-mask fits in an imm8. (5+5 vs. 6+3 or 6+4 if the AND needs a REX) Without an immediate-source BEXTR (like AMD TBM has/had), the only advantage mov-immediate+bextr has (on Intel) over mov-reg+shift+and is that can deal with wide bitfields using a count instead of an immediate AND mask. (Especially if it doesn't fit in 32 bits). If you can reuse the same control-register in a loop, BEXTR is good-ish for copy-and-extract. PEXT is 1 uop on Intel CPUs even though the simpler-looking BEXTR is 2. But PEXT is extremely slow on Ryzen (7 uops, 18c lat and tput). So for 32-bit constants at least, mov r32,imm32 + PEXT to copy-and-extract is better than BEXTR on Intel. movabs imm64 is too big and can cause front-end problems (slower to read from the uop cache, if that effect from Sandybridge is still present on Haswell/Skylake), and has no advantage vs. RORX + AND unless the bitfield you're extracting is wider than 32 bits. PEXT has 3 cycle latency, though, and can only run on port 1 on SnB-family. (All integer uops with latency > 1 are p1-only). It's potentially good for throughput, but worse than RORX+AND for latency. Unfortunately x86 bitfield instructions are pretty weak compared to ARM / AArch64 ubfx or PowerPC rlwinm and friends, where the bit-positions are simply specified as immediates. Only AMD's immediate version of BEXTR (1 uop on Excavator) matched them. Having a bunch of different control operands for BEXTR or PEXT in registers might be usable in a loop, but a lot more rarely useful than immediate controls. : 0: c4 e3 fb f0 c7 2a rorx $0x2a,%rdi,%rax# $(64-22) 6: c4 e3 fb f0 d7 35 rorx $0x35,%rdi,%rdx# $(64-11) c: 83 e7 3fand$0x3f,%edi f: 83 e0 3fand$0x3f,%eax 12: 83 e2 3fand$0x3f,%edx 15: 01 f8 add%edi,%eax # 32-bit operand-size because we can prove it can't overflow 17: 01 d0 add%edx,%eax # missed optimization in both gcc's versions. 19: c3 retq Not counting the ret, this is 7 uops for Skylake and Ryzen. **I'm pretty sure this is our best bet for -march=skylake, and for tune=generic -mbmi2** The BEXT intrinsics version is 9 uops for SKL, 7 for Ryzen, but is 2 bytes larger. (not counting the savings from avoiding a REX prefix on the ADD instructions; that missed optimization applies equally to both.) OTOH, the critical path latency for BEXTR on Ryzen is better by 1 cycle, so we could still consider it for -march=znver1. Or for tune=generic -mbmi without BMI2. The legacy mov+shr+and version is 10 uops because gcc wasted a `mov %rdi,%rax` instruction; it *should* be 9 uops for all normal CPUs. --- With only BMI1 but not BMI2 enabled, we should probably use the mov-imm + BEXTR version. It's not worse than the mov+shr+and version on SnB-family or bd/zn, and it's better on some AMD. And it's probably smaller code-size. And in future if Intel designs CPUs that can handle BEXTR as a single uop with 1c latency, mov+bextr will become good-ish everywhere. For code-size, BEXTR has a definite advantage for bitfields wider than 1 byte, because AND $imm32, %r32 is 6 bytes long instead of 3.
[Bug c++/89068] Nested inline anonymous namespaces are erroneously reported as conflicting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89068 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Marek Polacek --- Already fixed by r264016 which was backported to 8, too.
[Bug fortran/89067] Inaccurate error message: 'i' at (1) is not a member of the 'x' structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067 --- Comment #1 from Antony Lewis --- The error message on this code subroutine test type x end type type, extends(x):: y integer ii end type type(y) yy yy%i=1 end subroutine is Error: 'i' at (1) is not a member of the 'x' structure But it should refer to the 'y' structure, not the base class 'x'. Obviously minor and low priority, but more less helpful if y is a deep derived class.
[Bug c++/89068] New: Nested inline anonymous namespaces are erroneously reported as conflicting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89068
Bug ID: 89068
Summary: Nested inline anonymous namespaces are erroneously
reported as conflicting
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: eric.niebler at gmail dot com
Target Milestone: ---
The following valid code is rejected by g++ -std=c++XY for any XY >= 11:
inline namespace {
inline namespace {}
}
inline namespace {}
The error message I get is:
:4:8: error: 'namespace { }' conflicts with a previous declaration
inline namespace {}
^
:1:8: note: previous declaration 'namespace { }'
inline namespace {
^
Compiler returned: 1
Re: C++ PATCH for c++/89024 - ICE with incomplete enum type
On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote:
> On 1/25/19 12:09 PM, Marek Polacek wrote:
> > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote:
> > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote:
> > > >
> > > > On 1/24/19 2:16 PM, Marek Polacek wrote:
> > > > > This test ICEs since r159006 which added
> > > > >
> > > > > type = ENUM_UNDERLYING_TYPE (type);
> > > > >
> > > > > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null
> > > > > because we
> > > > > haven't yet parsed '}' of the enum and the underlying type isn't
> > > > > fixed, and
> > > > > so checking TYPE_UNSIGNED crashed.
> > > > >
> > > > > I've added some checks to the test to see if the types seem to be OK;
> > > > > clang++
> > > > > agrees.
> > > > >
> > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7?
> > > > >
> > > > > 2019-01-24 Marek Polacek
> > > > >
> > > > >PR c++/89024 - ICE with incomplete enum type.
> > > > >* cvt.c (type_promotes_to): Check if prom is non-null.
> > > >
> > > > 9.6/6: An enumeration whose underlying type is not fixed is an
> > > > incomplete type from its point of declaration to immediately after the
> > > > closing } of its enum-specifier, at which point it becomes a complete
> > > > type.
> > > >
> > > > So the conversion is ill-formed.
> > > >
> > > > Jason
> > >
> > > But the conversion in the example (in
> > > decltype(__test_aux<_To1>(declval<_From1>(
> > > is in a SFINAE context, so shouldn't it gracefully fall back to the
> > > `(...)` overload?
> >
> > I think so, and clang++ and icc also compile the testcase fine (and we used
> > to
> > too, before r159006).
>
> Absolutely, the conversion being ill-formed means substitution fails, and we
> reject that candidate. I meant that we shouldn't get as far as
> type_promotes_to for an incomplete type.
Makes sense. So here's another attempt:
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-01-25 Marek Polacek
PR c++/89024 - ICE with incomplete enum type.
* call.c (standard_conversion): When converting an
ARITHMETIC_TYPE_P to an incomplete type, return NULL.
* g++.dg/cpp0x/enum37.C: New test.
diff --git gcc/cp/call.c gcc/cp/call.c
index 515a9420032..c74d1b4ebdf 100644
--- gcc/cp/call.c
+++ gcc/cp/call.c
@@ -1412,6 +1412,13 @@ standard_conversion (tree to, tree from, tree expr, bool
c_cast_p,
|| (fcode == REAL_TYPE && !(flags & LOOKUP_NO_NON_INTEGRAL)))
|| SCOPED_ENUM_P (from))
return NULL;
+
+ /* If we're parsing an enum with no fixed underlying type, we're
+dealing with an incomplete type, which renders the conversion
+ill-formed. */
+ if (!COMPLETE_TYPE_P (from))
+ return NULL;
+
conv = build_conv (ck_std, to, conv);
/* Give this a better rank if it's a promotion. */
diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C
gcc/testsuite/g++.dg/cpp0x/enum37.C
new file mode 100644
index 000..6aa3d4015d7
--- /dev/null
+++ gcc/testsuite/g++.dg/cpp0x/enum37.C
@@ -0,0 +1,24 @@
+// PR c++/89024
+// { dg-do compile { target c++11 } }
+
+template struct same;
+template struct same {};
+
+template T&& declval();
+
+template
+void __test_aux(_To1);
+
+template(declval<_From1>()))>
+char __test(int);
+
+template
+int __test(...);
+
+enum E {
+x = decltype(__test(0))(0)
+};
+
+same s;
+same s2;
[Bug fortran/89067] New: Inaccurate error message: 'i' at (1) is not a member of the 'x' structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067 Bug ID: 89067 Summary: Inaccurate error message: 'i' at (1) is not a member of the 'x' structure Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Target Milestone: ---
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 --- Comment #3 from Matthew Wuensche --- I ran the online installer... and received this file mingw-w64-install.exe. And I reran the file to make sure all of those files were added. I found cc1 and added that path before submitting my "bug" report. PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;"C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static";"C:\Program Files (x86)\Common Files\lenovo\easyplussdk\bin";C:\WINDOWS\System32\OpenSSH\;C:\Users\auser\AppData\Local\Microsoft\WindowsApps;"C:\Program Files (x86)\mingw-w64\i686-8.1.0-win32-sjlj-rt_v6-rev0\mingw32\bin";"C:\Program Files (x86)\mingw-w64\i686-8.1.0-win32-sjlj-rt_v6-rev0\mingw32\libexec\gcc\i686-w64-mingw32\8.1.0" see the last path? That's where cc1.exe is. :)
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 --- Comment #2 from Andrew Pinski --- >Built by MinGW-W64 project Can you make sure you downloaded all of the correct binaries.
Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64
On Thu, Jan 24, 2019 at 11:17:45PM +, Steve Ellcey wrote:
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -9294,6 +9294,44 @@ aarch64_mask_and_shift_for_ubfiz_p (scalar_int_mode
> mode, rtx mask,
>& ((HOST_WIDE_INT_1U << INTVAL (shft_amnt)) - 1)) == 0;
> }
>
> +/* Return true if the masks and a shift amount from an RTX of the form
> + ((x & MASK1) | ((y << SHIFT_AMNT) & MASK2)) are valid to combine into
> + a BFI instruction of mode MODE. See *arch64_bfi patterns. */
> +
> +bool
> +aarch64_masks_and_shift_for_aarch64_bfi_p (scalar_int_mode mode, rtx mask1,
> +rtx shft_amnt, rtx mask2)
> +{
> + unsigned HOST_WIDE_INT m1, m2, s, t;
> +
> + if (!CONST_INT_P (mask1) || !CONST_INT_P (mask2) || !CONST_INT_P
> (shft_amnt))
> +return false;
> +
> + m1 = UINTVAL (mask1);
> + m2 = UINTVAL (mask2);
> + s = UINTVAL (shft_amnt);
> +
> + /* Verify that there is no overlap in what bits are set in the two masks.
> */
> + if ((m1 + m2 + 1) != 0)
> +return false;
Wouldn't that be clearer to test
if (m1 + m2 != HOST_WIDE_INT_1U)
return false;
?
You IMHO also should test
if ((m1 & m2) != 0)
return false;
> +
> + /* Verify that the shift amount is less than the mode size. */
> + if (s >= GET_MODE_BITSIZE (mode))
> +return false;
> +
> + /* Verify that the mask being shifted is contigious and would be in the
> + least significant bits after shifting by creating a mask 't' based on
> + the number of bits set in mask2 and the shift amount for mask2 and
> + comparing that to the actual mask2. */
> + t = popcount_hwi (m2);
> + t = (1 << t) - 1;
This should be (HOST_WIDE_INT_1U << t), otherwise if popcount of m2 is
>= 32, there will be UB.
> + t = t << s;
> + if (t != m2)
> +return false;
> +
> + return true;
> +}
> +
> +;; Match a bfi instruction where the shift of OP3 means that we are
> +;; actually copying the least significant bits of OP3 into OP0 by way
> +;; of the AND masks and the IOR instruction.
> +
> +(define_insn "*aarch64_bfi4_shift"
> + [(set (match_operand:GPI 0 "register_operand" "=r")
> +(ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0")
> + (match_operand:GPI 2 "const_int_operand" "n"))
> + (and:GPI (ashift:GPI
> + (match_operand:GPI 3 "register_operand" "r")
> + (match_operand:GPI 4
> "aarch64_simd_shift_imm_" "n"))
> + (match_operand:GPI 5 "const_int_operand" "n"]
> + "aarch64_masks_and_shift_for_aarch64_bfi_p (mode, operands[2],
> operands[4], operands[5])"
Too long lines.
> +{
> + return "bfi\t%0, %3, %4, %P5";
> +}
> + [(set_attr "type" "bfm")]
> +)
As mentioned in rs6000.md, I believe you also need a similar pattern where
the two ANDs are swapped, because they have the same priority.
> +
> +;; Like the above instruction but with no shifting, we are just copying the
> +;; least significant bits of OP3 to OP0.
> +
> +(define_insn "*aarch64_bfi4_noshift"
> + [(set (match_operand:GPI 0 "register_operand" "=r")
> +(ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0")
> + (match_operand:GPI 2 "const_int_operand" "n"))
> + (and:GPI (match_operand:GPI 3 "register_operand" "r")
> + (match_operand:GPI 4 "const_int_operand" "n"]
> + "aarch64_masks_and_shift_for_aarch64_bfi_p (mode, operands[2],
> const0_rtx, operands[4])"
Too long line.
I guess this one has similar issue that you might need two patterns for both
AND orderings (though the "0" needs to be on the right argument in each
case).
Jakub
[Bug driver/89066] After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 Andrew Pinski changed: What|Removed |Added Target|*-mingw* *-cygwin* |i686-w64-mingw32 Component|c |driver Host||i686-w64-mingw32 Build||i686-w64-mingw32 --- Comment #1 from Andrew Pinski --- > cc1 -E -quiet -v -iprefix > N:/nesys/asm6/src/../lib/gcc/i686-w64-mingw32/8.1.0/ -U_REENTRANT good.c > -mtune=generic -march=i686 -fpch-preprocess -o good.i >gcc: error: CreateProcess: No such file or directory This is the problem the GCC driver can't find cc1. The replacement of \ to / is valid transformation for Windows.
[Bug c++/89056] Optimizer generates bad code for non-void function that fails to return a value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89056
--- Comment #6 from Darryl Okahata ---
(OK, at this point, I'm just whinging, so please feel free to ignore this.)
I just wish the C++ standard instead just allowed an undefined value to be
returned, instead of generating bad optimized code. With the current state, I
either have to add compiler-specific extensions or unreachable return
statements to insure that correct code is generated (unexpected and violates
POLA). The issue is that g++ (understandably) can't always detect if there is
always a proper return statement (execution can never hit the end of the
function). Grossly-oversimplified example (real code is much more
complicated):
enum E { A, B };
bool bah(const enum E a)
{
if (a == A)
return false;
if (a == B)
return true;
}
Compiling with (8.2.0):
g++ -S -O badbad.cc
gives:
badbad.cc: In function 'bool bah(E)':
badbad.cc:10:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
Understandable, as I don't expect g++ to figure out complicated code
machinations. However, I don't know all the circumstances under which this
warning means that g++ is generating bad code. As a result, I have to add
unreachable return statements to insure that g++ does not generate bad
optimized code. Our code runs on multiple platforms, and so I'd rather avoid
the use of g++ extensions (e.g., __builtin_unreachable() or attributes) and
cluttering #ifdefs. Adding an unreachable return is undesirable but simple and
portable:
enum E { A, B };
bool bah(const enum E a)
{
if (a == A)
return false;
if (a == B)
return true;
return false; // UNREACHABLE
}
[Bug c/89066] New: After creating valid paths, the \ in source directory are / which creates "No such file or directory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89066 Bug ID: 89066 Summary: After creating valid paths, the \ in source directory are / which creates "No such file or directory" Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: icypawn at aol dot com Target Milestone: --- In my direcory: N:\nesys\asm6\src after typing: gcc -v -save-temps good.c -o good > ok.txt 2>&1 ok.txt reads: Using built-in specs. COLLECT_GCC=gcc Target: i686-w64-mingw32 Configured with: ../../../src/gcc-8.1.0/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32 --enable-shared --enable-static --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-exceptions --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch-32=i686 --with-arch-64=nocona --with-tune-32=generic --with-tune-64=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw810/prerequisites/i686-w64-mingw32-static --with-pkgversion='i686-win32-sjlj-rev0, Built by MinGW-W64 project' --with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS=' -I/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/include -I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' LDFLAGS='-pipe -fno-ident -L/c/mingw810/i686-810-win32-sjlj-rt_v6-rev0/mingw32/opt/lib -L/c/mingw810/prerequisites/i686-zlib-static/lib -L/c/mingw810/prerequisites/i686-w64-mingw32-static/lib -Wl,--large-address-aware' Thread model: win32 gcc version 8.1.0 (i686-win32-sjlj-rev0, Built by MinGW-W64 project) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'good.exe' '-mtune=generic' '-march=i686' cc1 -E -quiet -v -iprefix N:/nesys/asm6/src/../lib/gcc/i686-w64-mingw32/8.1.0/ -U_REENTRANT good.c -mtune=generic -march=i686 -fpch-preprocess -o good.i gcc: error: CreateProcess: No such file or directory *eof And so I think this happens because the second to last line beginning with "cc1" has the directory after -iprefix "N:/nesys/asm6/src/.." and in cmd the directories have to use \. I noticed this after looking though someone else's post in a forum citing output from a "gcc -v" line. Their text had "-iprefix c:\mingw.4.7.2\bin\../lib/gcc/i686-pc-mingw32/4.7.2/" and my slashes from my -v response, in the source directory, are backwards... so I think it's a bug. Sorry, if this isn't a bug. Matthew p.s. The -save-temps didn't return a *.i* file; I think that's because good.c is 0kb or empty. I received the exact same -v response when using my source file and didn't think this "bug" has anything to do with the gcc compiler compiling... so I substituted my empty good.c. Hope that's ok. :)
gcc-8-20190125 is now available
Snapshot gcc-8-20190125 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20190125/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 268281 You'll find: gcc-8-20190125.tar.xzComplete GCC SHA256=c0dd87a33a7af607bf139bf5396696c21dc8252e9433d2c4a567097c398b87ab SHA1=8e3d5c24cae5ab33ef971f8e42818ac20be910d0 Diffs from 8-20190118 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug rtl-optimization/88846] [9 Regression] pr69776-2.c failure on 32 bit AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846 --- Comment #6 from Vladimir Makarov --- Sorry, I wrote wrong PR number in the ChangeLog entry (I already fix the number). Here is the info about the patch I've committed Author: vmakarov Date: Fri Jan 25 22:13:43 2019 New Revision: 268280 URL: https://gcc.gnu.org/viewcvs?rev=268280=gcc=rev Log: 2019-01-25 Vladimir Makarov PR rtl-optimization/46 * ira.c (process_set_for_memref_referenced_p): New. (memref_referenced_p): Add new param. Use process_set_for_memref_referenced_p. Add new switch cases. (memref_used_between_p): Pass new arg to memref_referenced_p. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug libstdc++/89065] set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Marc Glisse --- .
patch to fix PR88846
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88846
The patch was successfully bootstrapped and tested on x86-64 and ppc64.
Committed as rev. 268280
Index: ChangeLog
===
--- ChangeLog (revision 268279)
+++ ChangeLog (working copy)
@@ -1,3 +1,11 @@
+2019-01-25 Vladimir Makarov
+
+ PR rtl-optimization/46
+ * ira.c (process_set_for_memref_referenced_p): New.
+ (memref_referenced_p): Add new param. Use
+ process_set_for_memref_referenced_p. Add new switch cases.
+ (memref_used_between_p): Pass new arg to memref_referenced_p.
+
2019-01-25 Richard Earnshaw
PR target/88469
Index: ira.c
===
--- ira.c (revision 268279)
+++ ira.c (working copy)
@@ -3140,10 +3140,30 @@ equiv_init_movable_p (rtx x, int regno)
return 1;
}
-/* TRUE if X references a memory location that would be affected by a store
- to MEMREF. */
-static int
-memref_referenced_p (rtx memref, rtx x)
+static bool memref_referenced_p (rtx memref, rtx x, bool read_p);
+
+/* Auxiliary function for memref_referenced_p. Process setting X for
+ MEMREF store. */
+static bool
+process_set_for_memref_referenced_p (rtx memref, rtx x)
+{
+ /* If we are setting a MEM, it doesn't count (its address does), but any
+ other SET_DEST that has a MEM in it is referencing the MEM. */
+ if (MEM_P (x))
+{
+ if (memref_referenced_p (memref, XEXP (x, 0), true))
+ return true;
+}
+ else if (memref_referenced_p (memref, x, false))
+return true;
+
+ return false;
+}
+
+/* TRUE if X references a memory location (as a read if READ_P) that
+ would be affected by a store to MEMREF. */
+static bool
+memref_referenced_p (rtx memref, rtx x, bool read_p)
{
int i, j;
const char *fmt;
@@ -3159,30 +3179,51 @@ memref_referenced_p (rtx memref, rtx x)
case CC0:
case HIGH:
case LO_SUM:
- return 0;
+ return false;
case REG:
return (reg_equiv[REGNO (x)].replacement
&& memref_referenced_p (memref,
- reg_equiv[REGNO (x)].replacement));
+ reg_equiv[REGNO (x)].replacement, read_p));
case MEM:
- if (true_dependence (memref, VOIDmode, x))
- return 1;
+ /* Memory X might have another effective type than MEMREF. */
+ if (read_p || true_dependence (memref, VOIDmode, x))
+ return true;
break;
case SET:
- /* If we are setting a MEM, it doesn't count (its address does), but any
- other SET_DEST that has a MEM in it is referencing the MEM. */
- if (MEM_P (SET_DEST (x)))
- {
- if (memref_referenced_p (memref, XEXP (SET_DEST (x), 0)))
- return 1;
- }
- else if (memref_referenced_p (memref, SET_DEST (x)))
- return 1;
+ if (process_set_for_memref_referenced_p (memref, SET_DEST (x)))
+ return true;
+
+ return memref_referenced_p (memref, SET_SRC (x), true);
+
+case CLOBBER:
+case CLOBBER_HIGH:
+ if (process_set_for_memref_referenced_p (memref, XEXP (x, 0)))
+ return true;
+
+ return false;
+
+case PRE_DEC:
+case POST_DEC:
+case PRE_INC:
+case POST_INC:
+ if (process_set_for_memref_referenced_p (memref, XEXP (x, 0)))
+ return true;
+
+ return memref_referenced_p (memref, XEXP (x, 0), true);
+
+case POST_MODIFY:
+case PRE_MODIFY:
+ /* op0 = op0 + op1 */
+ if (process_set_for_memref_referenced_p (memref, XEXP (x, 0)))
+ return true;
+
+ if (memref_referenced_p (memref, XEXP (x, 0), true))
+ return true;
- return memref_referenced_p (memref, SET_SRC (x));
+ return memref_referenced_p (memref, XEXP (x, 1), true);
default:
break;
@@ -3193,17 +3234,17 @@ memref_referenced_p (rtx memref, rtx x)
switch (fmt[i])
{
case 'e':
- if (memref_referenced_p (memref, XEXP (x, i)))
- return 1;
+ if (memref_referenced_p (memref, XEXP (x, i), read_p))
+ return true;
break;
case 'E':
for (j = XVECLEN (x, i) - 1; j >= 0; j--)
- if (memref_referenced_p (memref, XVECEXP (x, i, j)))
- return 1;
+ if (memref_referenced_p (memref, XVECEXP (x, i, j), read_p))
+ return true;
break;
}
- return 0;
+ return false;
}
/* TRUE if some insn in the range (START, END] references a memory location
@@ -3224,7 +3265,7 @@ memref_used_between_p (rtx memref, rtx_i
if (!NONDEBUG_INSN_P (insn))
continue;
- if (memref_referenced_p (memref, PATTERN (insn)))
+ if (memref_referenced_p (memref, PATTERN (insn), false))
return 1;
/* Nonconst functions may access memory. */
[Bug libstdc++/89065] set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065 --- Comment #2 from baltic <1000hz.radiowave at gmail dot com> --- Ok, i see 26.2.6.6 section of the standard: iterator of an associative container is of the bidirectional iterator category. For associative containers where the value type is the same as the key type, both iterator and const_iterator are constant iterators. Weird though. I think this could be closed as invalid. Thanks!
Re: [Patch] PR rtl-optimization/87763 - generate more bfi instructions on aarch64
On Fri, 2019-01-25 at 10:32 +, Richard Earnshaw (lists) wrote: > > Do we need another variant pattern to handle the case where the > insertion is into the top of the destination? In that case the > immediate mask on the shifted operand is technically redundant as the > bottom bits are known zero and there are no top bits. I am not sure about this. Do you have an example where this might be needed? I updated my patch to address your other comments and have bootstrapped and tested this on aarch64. Does this version look good for checkin? I had to modify the two tests because with my new instructions we sometimes generate bfi instructions where we used to generate bfxil instructions. The only regression this is fixing is combine_bfi_1.c, combine_bfxil.c was passing before but still needed to be changed in order to keep passing. Steve Ellcey sell...@marvell.com 2018-01-25 Steve Ellcey PR rtl-optimization/87763 * config/aarch64/aarch64-protos.h (aarch64_masks_and_shift_for_bfi_p): New prototype. * config/aarch64/aarch64.c (aarch64_masks_and_shift_for_bfi_p): New function. * config/aarch64/aarch64.md (*aarch64_bfi4_shift): New instruction. (*aarch64_bfi4_noshift): Ditto. 2018-01-25 Steve Ellcey PR rtl-optimization/87763 * gcc.target/aarch64/combine_bfi_1.c: Change some bfxil checks to bfi. * gcc.target/aarch64/combine_bfxil.c: Ditto.
[Bug libstdc++/89065] set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065 --- Comment #1 from Marc Glisse --- iterator and const_iterator are the same type for std::set, the elements are always immutable...
Re: About GSOC.
On Sat, 26 Jan 2019, Tejas Joshi wrote: > function with byte-byte comparison which also include mpfr. (Correct > me if I am wrong.) What is the significance of mpfr related to these > internal representations? real.c provides a fixed-size representation of floating-point numbers that allows for various non-IEEE formats supported by GCC, and also allows functions from dfp.c to be used for decimal floating-point formats. MPFR is used in GCC to provide operations that are nontrivial to implement, especially those that are nontrivial to implement in such a fixed-size context. real.c operations wrap around MPFR ones where appropriate, doing whatever's needed in cases where there are non-IEEE semantics or sets of values. -- Joseph S. Myers jos...@codesourcery.com
[Bug fortran/88810] gcc/fortran/dependency.c:2200: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88810 --- Comment #8 from kargl at gcc dot gnu.org --- Created attachment 45533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45533=edit patch The attached patch re-arranges the code to hopefully clarify the logic. 2019-01-26 Steven G. Kargl PR fortran/88810 * dependency.c (gfc_dep_resolver): Re-arrange code to make the logic a bit more transparent. Fix 2 nearby formatting issues. Note, as the code is correct in its current form, I will hold this patch until stage 1 opens for gcc 10.
[Bug libstdc++/89065] New: set::find always returns const iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89065
Bug ID: 89065
Summary: set::find always returns const iterator
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: 1000hz.radiowave at gmail dot com
Target Milestone: ---
by the standard there are 2 overloads of find:
iterator find( const Key& key );
const_iterator find( const Key& key ) const;
However, libstdc++ seem to return const iterator even on non const object.
Consider the example:
#include
#include
struct FatKey { int x; int ref_count; };
bool operator<(const FatKey& fk1, const FatKey& fk2) { return fk1.x < fk2.x; }
int main()
{
std::set example = { {1, 0 }, {2, 0 }, {3, 0 }, {4, 0 } };
auto search = example.find({1, 0});
if (search != example.end()) {
search->ref_count++;
std::cout << "Found " << search->x << '\n';
} else {
std::cout << "Not found\n";
}
}
It fails to compile with the error:
main.cpp: In function 'int main()':
main.cpp:11:26: error: increment of member 'FatKey::ref_count' in read-only
object
search->ref_count++;
While it shouldn't.
Re: C++ PATCH for c++/78244 - narrowing conversion in template not detected, part 2
On Fri, Jan 25, 2019 at 10:05:00AM -0500, Jason Merrill wrote:
> On 1/24/19 7:17 PM, Marek Polacek wrote:
> > On Wed, Jan 23, 2019 at 03:34:04PM -0500, Jason Merrill wrote:
> > > On Wed, Jan 23, 2019 at 12:57 PM Marek Polacek wrote:
> > > >
> > > > On Wed, Jan 23, 2019 at 09:00:36AM -0500, Jason Merrill wrote:
> > > > > I was talking about digest_init, not reshape_init. digest_init calls
> > > > > convert_for_initialization.
> > > >
> > > > /facepalm
> > > >
> > > > So yes, digest_init calls convert_for_initialization which will end up
> > > > calling perform_implicit_conversion_flags which could call
> > > > convert_like_real
> > > > where the narrowing warnings are given, but it doesn't, we go to this
> > > > case:
> > > >
> > > >else if (processing_template_decl && conv->kind != ck_identity)
> > > > {
> > > >/* In a template, we are only concerned about determining the
> > > > type of non-dependent expressions, so we do not have to
> > > > perform the actual conversion. But for initializers, we
> > > > need to be able to perform it at instantiation
> > > > (or instantiate_non_dependent_expr) time. */
> > > >expr = build1 (IMPLICIT_CONV_EXPR, type, expr);
> > > >
> > > > finish_decltype_type throws away the expression because it's not
> > > > dependent, and
> > > > only uses its type. So narrowing remains undetected. Not sure if I
> > > > should mess
> > > > with perform_implicit_conversion_flags.
> > >
> > > Let's try that; this is a situation where the comment is incorrect.
> > > Perhaps just call check_narrowing here if appropriate, rather than go
> > > through the whole conversion machinery.
> >
> > I have not been successful.
> >
> > First, I modified perform_implicit_conversion_flags to go the convert_like
> > route when dealing with something non-dependent. That breaks e.g. in
> > build_value_init:
> > 346 /* The AGGR_INIT_EXPR tweaking below breaks in templates. */
> > 347 gcc_assert (!processing_template_decl
> > 348 || (SCALAR_TYPE_P (type) || TREE_CODE (type) ==
> > ARRAY_TYPE));
> > Even if I restrict the convert_like way for non-dependent exprs in a
> > template
> > for scalars, it still breaks elsewhere, e.g. constexpr-template3.C where it
> > complains about taking the address of an rvalue.
> >
> > Second, I added check_narrowing to the processing_template_decl case in
> > perform_implicit_conversion_flags. That works except it breaks
> > constexpr-inst1.C -- we no longer get the error. That's because currently
> > check_narrowing in finish_compound_literal calls maybe_constant_init, which
> > calls instantiate_constexpr_fns and we get the desired diagnostic. But if
> > I move check_narrowing to perform_implicit_conversion_flags, we no longer
> > call it in this case -- processing_template_decl is 0 so we call
> > convert_like
> > but that doesn't do the trick.
> >
> > So, back to the patch that leaves check_narrowing in
> > finish_compound_literal?
>
> That patch still needs a test for the aggregate case.
Ok, this is a version with Wnarrowing16.C added.
...but we still don't warn for the TYPE_NON_AGGREGATE_CLASS case in
finish_compound_literal, so the nightmare continues.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-01-25 Marek Polacek
PR c++/88815 - narrowing conversion lost in decltype.
PR c++/78244 - narrowing conversion in template not detected.
* cp-tree.h (CONSTRUCTOR_IS_DEPENDENT): New.
* pt.c (instantiation_dependent_r): Consider a CONSTRUCTOR with
CONSTRUCTOR_IS_DEPENDENT instantiation-dependent.
* semantics.c (finish_compound_literal): When the compound literal
isn't instantiation-dependent and the type isn't type-dependent,
fall back to the normal processing. Don't only call check_narrowing
for scalar types. Set CONSTRUCTOR_IS_DEPENDENT.
* g++.dg/cpp0x/Wnarrowing15.C: New test.
* g++.dg/cpp0x/Wnarrowing16.C: New test.
* g++.dg/cpp0x/constexpr-decltype3.C: New test.
* g++.dg/cpp1y/Wnarrowing1.C: New test.
diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index cd902ce1cf6..77e1425b435 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -424,6 +424,7 @@ extern GTY(()) tree cp_global_trees[CPTI_MAX];
DECL_FINAL_P (in FUNCTION_DECL)
QUALIFIED_NAME_IS_TEMPLATE (in SCOPE_REF)
DECLTYPE_FOR_INIT_CAPTURE (in DECLTYPE_TYPE)
+ CONSTRUCTOR_IS_DEPENDENT (in CONSTRUCTOR)
TINFO_USED_TEMPLATE_ID (in TEMPLATE_INFO)
PACK_EXPANSION_SIZEOF_P (in *_PACK_EXPANSION)
OVL_USING_P (in OVERLOAD)
@@ -4205,6 +4206,11 @@ more_aggr_init_expr_args_p (const
aggr_init_expr_arg_iterator *iter)
B b{1,2}, not B b({1,2}) or B b = {1,2}. */
#define CONSTRUCTOR_IS_DIRECT_INIT(NODE) (TREE_LANG_FLAG_0 (CONSTRUCTOR_CHECK
(NODE)))
+/* True if this CONSTRUCTOR is instantiation-dependent and needs to be
+ substituted. */
[Bug fortran/34871] Flavor VARIABLE vs. FUNCTION: Accepts invalid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34871 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #5 from Harald Anlauf --- If the example in comment #0 is changed as follows: MODULE TESTS dimension :: k(4) CONTAINS function k() result (kk) kk = 35 end function k END MODULE TESTS the code - although still invalid - still compiles, but the dump-tree is completely different. I also see big differences in the dump-tree between comment #0 and the above for 9-trunk, but not for 8-branch. ISTR a patch (Steve) that fixed a related issue with RESULT(), maybe that is the place to look for a fix?
[Bug libstdc++/89044] libstdc++-6.dll is installed in the wrong directory cross-compiling with a multilib configuration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89044 --- Comment #5 from Jonathan Wakely --- OK thanks, I'll try to take a look into it.
[Bug testsuite/89064] New: [9 regression] libgomp.graphite/force-parallel-5.c fails starting with r268257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89064 Bug ID: 89064 Summary: [9 regression] libgomp.graphite/force-parallel-5.c fails starting with r268257 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Does this test case need updating? spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ /home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.graphite/force-parallel-5.c -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -ansi -pedantic-errors -O2 -ftree-parallelize-loops=4 -floop-parallelize-all -fdump-tree-parloops-details -fdump-tree-optimized -fno-loop-strip-mine -fno-loop-block -fdump-tree-graphite-all -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -lm -o ./force-parallel-5.exe Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ offload_gcn37385.c -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -foffload=amdgcn-unknown-amdhsa -S -o offload_gcn37385.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc -B/home/seurer/gcc/build/gcc-test2/gcc/ offload_gcn37385.c -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/ -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/../../include -I/home/seurer/gcc/gcc-test2/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics-color=never -fopenmp -foffload=amdgcn-unknown-amdhsa -S -o offload_gcn37385.s xgcc: fatal error: GCC is not configured to support amdgcn-unknown-amdhsa as offload target compilation terminated. compiler exited with status 1 PASS: libgomp.graphite/force-parallel-5.c (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgomp/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test2/./isl/.libs:/home/seurer/gcc/build/gcc-test2/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] PASS: libgomp.graphite/force-parallel-5.c execution test libgomp.graphite/force-parallel-5.c: pattern found 0 times FAIL: libgomp.graphite/force-parallel-5.c scan-tree-dump-times graphite "2 loops carried no dependency" 1 PASS: libgomp.graphite/force-parallel-5.c scan-tree-dump-times optimized "loopfn.0" 4 PASS: libgomp.graphite/force-parallel-5.c scan-tree-dump-times optimized "loopfn.1" 4 testcase /home/seurer/gcc/gcc-test2/libgomp/testsuite/libgomp.graphite/graphite.exp completed in 1 seconds === libgomp Summary === # of expected passes4 # of unexpected failures1 r268257 | rguenth | 2019-01-25 02:13:34 -0600 (Fri, 25 Jan 2019) | 10 lines 2019-01-25 Richard Biener PR tree-optimization/86865 * graphite-scop-detection.c (scop_detection::can_represent_loop): Reject non-do-while loops. * gcc.dg/graphite/pr86865.c: New testcase. * gcc.dg/graphite/pr69728.c: XFAIL. * gcc.dg/graphite/scop-21.c: Likewise.
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on 8- and 9-branches. Thanks for the report. Paul
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 --- Comment #8 from Paul Thomas --- Author: pault Date: Fri Jan 25 20:08:58 2019 New Revision: 268279 URL: https://gcc.gnu.org/viewcvs?rev=268279=gcc=rev Log: 2019-01-25 Paul Thomas PR fortran/87336 * trans-array.c (gfc_get_array_span): Try to get the element length of incomplete types. Return NULL_TREE otherwise. (gfc_conv_expr_descriptor): Only set the 'span' field if the above does not return NULL_TREE. Set 'span' field if possible for all new descriptors. 2019-01-25 Paul Thomas PR fortran/87336 * gfortran.dg/pointer_array_10.f90 : New test. * gfortran.dg/assign_10.f90 : Increase 'parm' count to 20. * gfortran.dg/transpose_optimization_2.f90 : Increase 'parm' count to 72. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pointer_array_10.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gfortran.dg/assign_10.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/transpose_optimization_2.f90
[Bug fortran/88961] valgrind error in resolve_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88961 David Binderman changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Binderman --- This bug seems fixed by the time we get to revision 268250.
[Bug target/89063] New: [x86] lack of support for BEXTR from BMI extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89063
Bug ID: 89063
Summary: [x86] lack of support for BEXTR from BMI extension
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wojciech_mula at poczta dot onet.pl
Target Milestone: ---
Instruction BEXTR extracts an arbitrary unsigned bit field from 32- or 64-bit
value. As I see in `config/i386.md`, there's support for the immediate
variant available in AMD's TBM (TARGET_TBM).
Intel's variant gets parameters from a register. Although this variant
won't be profitable in all cases -- as we need an extra move to setup
the bit-field parameters in a register -- I bet bit-field-intensive
code might benefit from BEXTR.
---bextr.c---
#include
#include
uint64_t test(uint64_t x) {
const uint64_t a0 = (x & 0x3f);
const uint64_t a1 = (x >> 11) & 0x3f;
const uint64_t a2 = (x >> 22) & 0x3f;
return a0 + a1 + a2;
}
uint64_t test_intrinsics(uint64_t x) {
const uint64_t a0 = (x & 0x3f);
const uint64_t a1 = _bextr_u64(x, 11, 6);
const uint64_t a2 = _bextr_u64(x, 22, 6);
return a0 + a1 + a2;
}
---eof---
$ gcc --version
gcc (GCC) 9.0.0 20190117 (experimental)
$ gcc -O3 -mbmi -march=skylake bextr.c -c && objdump -d bextr.o
:
0: 48 89 famov%rdi,%rdx
3: 48 c1 ea 0b shr$0xb,%rdx
7: 48 89 f8mov%rdi,%rax
a: 48 89 d1mov%rdx,%rcx
d: 48 c1 e8 16 shr$0x16,%rax
11: 83 e0 3fand$0x3f,%eax
14: 83 e1 3fand$0x3f,%ecx
17: 48 8d 14 01 lea(%rcx,%rax,1),%rdx
1b: 83 e7 3fand$0x3f,%edi
1e: 48 8d 04 3a lea(%rdx,%rdi,1),%rax
22: c3 retq
0030 :
30: b8 0b 06 00 00 mov$0x60b,%eax
35: c4 e2 f8 f7 d7 bextr %rax,%rdi,%rdx
3a: b8 16 06 00 00 mov$0x616,%eax
3f: c4 e2 f8 f7 c7 bextr %rax,%rdi,%rax
44: 83 e7 3fand$0x3f,%edi
47: 48 01 d0add%rdx,%rax
4a: 48 01 f8add%rdi,%rax
4d: c3 retq
Re: About GSOC.
It took some time to get know using GDB, but upto some end I got it to work. The enum real_value_class is used to classify the number into zero, normal, infinity and NaN. This class is represented by r->cl in real_value and values in struct real_value are used as flags or representations while string to real conversion (real_from_string) in real.c and other functions. The decimal/hex string value is converted into real in real_from_string function with byte-byte comparison which also include mpfr. (Correct me if I am wrong.) What is the significance of mpfr related to these internal representations? Thanks. -Tejas On Wed, 23 Jan 2019 at 23:06, Joseph Myers wrote: > > On Wed, 23 Jan 2019, Tejas Joshi wrote: > > > But I really dont know how to inspect a file like real.h > > (real_value)/real.c? > > Use cc1 to build a test program with selected floating-point constants in > it. Set breakpoints on appropriate functions in real.c (e.g. related to > converting strings for real constants into the internal representation). > Look at the representation produced for those constants to determine the > particular conventions being used. > > -- > Joseph S. Myers > jos...@codesourcery.com
[Bug c++/88969] [9 Regression] ICE in build_op_delete_call, at cp/call.c:6509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #7 from Paolo Carlini --- Foxed.
[Bug c++/88969] [9 Regression] ICE in build_op_delete_call, at cp/call.c:6509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88969 --- Comment #6 from paolo at gcc dot gnu.org --- Author: paolo Date: Fri Jan 25 19:50:55 2019 New Revision: 268278 URL: https://gcc.gnu.org/viewcvs?rev=268278=gcc=rev Log: /cp 2019-01-25 Paolo Carlini PR c++/88969 * call.c (build_op_delete_call): Implement 7.6.2.5/(10.1). * decl2.c (coerce_delete_type): Use build_pointer_type instead of TYPE_POINTER_TO. /testsuite 2019-01-25 Paolo Carlini PR c++/88969 * g++.dg/cpp2a/destroying-delete2.C: New. * g++.dg/cpp2a/destroying-delete3.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp2a/destroying-delete2.C trunk/gcc/testsuite/g++.dg/cpp2a/destroying-delete3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/80708] [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #3) > > Code compiles if I delete the suspicious code. > Unfortunately, there is a regression in the testsuite, and even more unfortunate, the regression comes in code that involves CLASS, which I have zero experience with.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #3 from ensadc at mailnesia dot com --- I think this should be treated as a different bug from bug 87709. In bug 87709, the error is emitted in cp_parser_type_id_1. In this bug, the error is produced by grokdeclarator.
[Bug middle-end/67946] Function multiversioning ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67946 --- Comment #4 from Stupachenko Evgeny --- fixed starting from gcc 6
[Bug lto/66835] C++ openMP test failed after switching to C++14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66835 --- Comment #5 from Stupachenko Evgeny --- Yes, It is fixed starting from 5.3.
[PATCH v2] C++ concepts: fix ICE with requires on dtors (PR c++/89036)
On Fri, 2019-01-25 at 08:59 -0800, Nathan Sidwell wrote:
> On 1/25/19 8:48 AM, David Malcolm wrote:
> > PR c++/89036 reports an ICE due to this assertion failing
> >
> > 1136 /* A class should never have more than one
> > destructor. */
> > 1137 gcc_assert (!current_fns || via_using ||
> > !DECL_DESTRUCTOR_P (method));
> >
> > on this template with a pair of dtors, with
> > mutually exclusive "requires" clauses:
> >
> > template
> > struct Y {
> > ~Y() requires(true) = default;
> > ~Y() requires(false) {}
> > };
> >
> > (is this valid? my knowledge of this part of C++ is fairly hazy)
>
> Yes. A more sensible example would have 'true' and 'false' replaced
> by
> something determined from the template parms.
>
> >
> > Nathan introduced this assertion as part of:
> >
> >ca9219bf18c68a001d62ecb981bc9176b0feaf12 (aka r251340):
> > 2017-08-24 Nathan Sidwell
> > Conversion operators kept on single overload set
>
> I'd just drop the assert at this point.
>
> nathan
Thanks. Here's a version of the patch which drops the assertion.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/cp/ChangeLog:
PR c++/89036
* class.c (add_method): Drop destructor assertion.
gcc/testsuite/ChangeLog:
PR c++/89036
* g++.dg/concepts/pr89036.C: New test.
---
gcc/cp/class.c | 3 ---
gcc/testsuite/g++.dg/concepts/pr89036.C | 8
2 files changed, 8 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/pr89036.C
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index e8773c2..6e9dac9 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1133,9 +1133,6 @@ add_method (tree type, tree method, bool via_using)
}
}
- /* A class should never have more than one destructor. */
- gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
-
current_fns = ovl_insert (method, current_fns, via_using);
if (!COMPLETE_TYPE_P (type) && !DECL_CONV_FN_P (method)
diff --git a/gcc/testsuite/g++.dg/concepts/pr89036.C
b/gcc/testsuite/g++.dg/concepts/pr89036.C
new file mode 100644
index 000..f83ef8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/pr89036.C
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-fconcepts" }
+
+template
+struct Y {
+ ~Y() requires(true) = default;
+ ~Y() requires(false) {}
+};
--
1.8.5.3
[Bug fortran/85603] ICE with character array substring assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Paul Thomas --- Fixed on trunk. Thanks for the report. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 85603, which changed state. Bug 85603 Summary: ICE with character array substring assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85603 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 --- Comment #7 from Steve Kargl --- On Fri, Jan 25, 2019 at 06:40:14PM +, jvdelisle at gcc dot gnu.org wrote: > > --- Comment #6 from Jerry DeLisle --- > (In reply to Steve Kargl from comment #5) > --- snip --- > > > > Of course, I could be missing something obvious. Jerry? > > Hi Steve, I have time today to have a look at this. Does seem a bit unusual on > the surface. > Thanks. I was expecting to see something like result = remove(...) /* returns 0, -1, and set errno. */ if (iostat is present) iostat = result; /* could also set to errno. */ if (iomsg is present) iomsg = strerror (errno); /* Look up errno error message. */
Re: [PATCH] Revert a hunk from r261322 (PR lto/88876).
> Hi.
>
> The patch puts back ::get_create for a node that can be seen first time.
> It's due to -O0 optimize attribute. It was unable to write properly
> LTO test-case for it.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> 2019-01-18 Martin Liska
>
> PR lto/88876
> * ipa-pure-const.c (propagate_pure_const): Revert hunk as
> we need default values of funct_state for a function that
> is not optimized.
I think you want to test if y enables pure_const prior calling get
becuase get_create will just create empty info that will likely have
IPA_CONST (which is 0) and not IPA_NEITHER. There are multiple copies
of this code in other propagators and I think they all needs to check if
the pass is enabled for particular symbol and if not resort to
propagating nothing.
Honza
> ---
> gcc/ipa-pure-const.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>
> diff --git a/gcc/ipa-pure-const.c b/gcc/ipa-pure-const.c
> index 8227eed29bc..b8fd08c0a7e 100644
> --- a/gcc/ipa-pure-const.c
> +++ b/gcc/ipa-pure-const.c
> @@ -1498,7 +1498,8 @@ propagate_pure_const (void)
> }
> if (avail > AVAIL_INTERPOSABLE)
> {
> - funct_state y_l = funct_state_summaries->get (y);
> + funct_state y_l = funct_state_summaries->get_create (y);
> +
> if (dump_file && (dump_flags & TDF_DETAILS))
> {
> fprintf (dump_file,
>
[Bug fortran/80708] [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #3 from kargl at gcc dot gnu.org ---
The problematic code is in resolve.c at lines 8028-8040.
This code was added in r241885 by vehre. I don't see
how this code can possible work for an allocation of
an array of derived types as all information about the
array shape of mold has been striped.
if (code->expr3 && code->expr3->mold
&& code->expr3->ts.type == BT_DERIVED)
{
/* Default initialization via MOLD (non-polymorphic). */
gfc_expr *rhs = gfc_default_initializer (>expr3->ts);
if (rhs != NULL)
{
gfc_resolve_expr (rhs);
gfc_free_expr (code->expr3);
code->expr3 = rhs;
}
}
Prior to the if statement one has
(gdb) p *code->expr3
$3 = {expr_type = EXPR_VARIABLE, ts = {type = BT_DERIVED, kind = 0, u = {
derived = 0x20306f600, cl = 0x20306f600, pad = 50787840}, interface =
0x0,
is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false,
interop_kind = 0x0}, rank = 1, shape = 0x2031689f0, symtree = 0x2023a45d0,
ref = 0x203149300, where = {nextc = 0x20308a9cc, lb = 0x20308a960}, base_expr
= 0x0,
is_boz = 0, is_snan = 0, error = 0, user_operator = 0, mold = 1,
must_finalize = 0,
no_bounds_check = 0, external_blas = 0, do_not_resolve_again = 0,
representation = {
length = 0, string = 0x0}, value = {logical = 0, iokind = M_READ, integer =
{{
_mp_alloc = 0, _mp_size = 0, _mp_d = 0x0}}, real = {{_mpfr_prec = 0,
_mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, complex = {{re = {{
_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0}}, im
= {{
_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d = 0x0,
op = {
op = GFC_INTRINSIC_BEGIN, uop = 0x0, op1 = 0x0, op2 = 0x0}, function = {
actual = 0x0, name = 0x0, isym = 0x0, esym = 0x0}, compcall = {actual =
0x0,
name = 0x0, base_object = 0x0, tbp = 0x0, ignore_pass = 0, assign = 0},
character = {length = 0, string = 0x0}, constructor = 0x0}, param_list =
0x0}
after the if () completes, one has
$4 = {expr_type = EXPR_STRUCTURE, ts = {type = BT_DERIVED, kind = 0, u = {
derived = 0x20306f600, cl = 0x20306f600, pad = 50787840}, interface =
0x0,
is_c_interop = 0, is_iso_c = 0, f90_type = BT_UNKNOWN, deferred = false,
interop_kind = 0x0}, rank = 0, shape = 0x0, symtree = 0x0, ref = 0x0, where
= {
nextc = 0x20306a1d0, lb = 0x20306a190}, base_expr = 0x0, is_boz = 0,
is_snan = 0,
error = 0, user_operator = 0, mold = 0, must_finalize = 0, no_bounds_check =
0,
external_blas = 0, do_not_resolve_again = 0, representation = {length = 0,
string = 0x0}, value = {logical = 51159296, iokind = 51159296, integer = {{
_mp_alloc = 51159296, _mp_size = 2, _mp_d = 0x0}}, real = {{
_mpfr_prec = 8641093888, _mpfr_sign = 0, _mpfr_exp = 0, _mpfr_d =
0x0}},
complex = {{re = {{_mpfr_prec = 8641093888, _mpfr_sign = 0, _mpfr_exp = 0,
_mpfr_d = 0x0}}, im = {{_mpfr_prec = 0, _mpfr_sign = 0, _mpfr_exp =
0,
_mpfr_d = 0x0, op = {op = 51159296, uop = 0x0, op1 = 0x0, op2 =
0x0},
function = {actual = 0x2030ca100, name = 0x0, isym = 0x0, esym = 0x0},
compcall = {
actual = 0x2030ca100, name = 0x0, base_object = 0x0, tbp = 0x0,
ignore_pass = 0,
assign = 0}, character = {length = 8641093888, string = 0x0},
constructor = 0x2030ca100}, param_list = 0x0}
Code compiles if I delete the suspicious code.
[Bug fortran/87151] allocating array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- I cleared up a load of ASSOCIATE related bugs on trunk. Attempts to apply a composite patch don't apply cleanly and so I am marking this as fixed. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 87151, which changed state. Bug 87151 Summary: allocating array of character https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87151 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/87336] [8/9 regression] wrong output for pointer dummy assiocated to target actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87336 --- Comment #7 from Paul Thomas --- (In reply to Harald Anlauf from comment #6) > The patch in comment #3 seems to apply to gcc-8, but I haven't regtested it. > Paul, do you intend to backport it? It is regtesting on 8-branch as I write. Paul
[Bug fortran/87937] [8 Regression] LHS reallocation broken inside "select type" and "associate"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Paul Thomas --- The regression is fixed on 8- and 9-branches. Paul
[Bug libfortran/89020] close(status='DELETE') does not remove file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89020 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- (In reply to Steve Kargl from comment #5) --- snip --- > > Of course, I could be missing something obvious. Jerry? Hi Steve, I have time today to have a look at this. Does seem a bit unusual on the surface.
Re: [PATCH] Revert yet another ::get_create for IPA summary (PR ipa/88958).
> Hi.
>
> This is one very similar patch.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
> From adf577edd5a1d2b6ed78c1cc18feaff23fbfdd1c Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Thu, 24 Jan 2019 16:07:29 +0100
> Subject: [PATCH] Revert yet another ::get_create for IPA summary (PR
> ipa/88958).
>
> gcc/ChangeLog:
>
> 2019-01-24 Martin Liska
>
> PR ipa/88958
> * ipa-fnsummary.c (estimate_edge_devirt_benefit): Use
> ::get_create as the symbol can be not seen yet.
Using get_create will create empty fnsummary which is invalid and we do
not want to use it anyway, so turning get into get_creates is not right
fix in general. Here you just want to return false if isummary is NULL.
Honza
>
> gcc/testsuite/ChangeLog:
>
> 2019-01-24 Martin Liska
>
> PR ipa/88958
> * gcc.dg/ipa/pr88985.c: New test.
> ---
> gcc/ipa-fnsummary.c| 2 +-
> gcc/testsuite/gcc.dg/ipa/pr88985.c | 13 +
> 2 files changed, 14 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.dg/ipa/pr88985.c
>
> diff --git a/gcc/ipa-fnsummary.c b/gcc/ipa-fnsummary.c
> index 535b3f22d49..af741f04eb2 100644
> --- a/gcc/ipa-fnsummary.c
> +++ b/gcc/ipa-fnsummary.c
> @@ -2581,7 +2581,7 @@ estimate_edge_devirt_benefit (struct cgraph_edge *ie,
>callee = callee->function_symbol ();
>if (avail < AVAIL_AVAILABLE)
> return false;
> - isummary = ipa_fn_summaries->get (callee);
> + isummary = ipa_fn_summaries->get_create (callee);
>return isummary->inlinable;
> }
>
> diff --git a/gcc/testsuite/gcc.dg/ipa/pr88985.c
> b/gcc/testsuite/gcc.dg/ipa/pr88985.c
> new file mode 100644
> index 000..8253a893cf6
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/ipa/pr88985.c
> @@ -0,0 +1,13 @@
> +void f (void)
> +{
> +}
> +__attribute__((__optimize__("O2")))
> +void g (void f())
> +{
> + f();
> +}
> +__attribute__((__optimize__("O2")))
> +void h (void)
> +{
> + g(f);
> +}
> --
> 2.20.1
>
Re: [PR ipa/88933] Careful CFG cleanup in IPA-CP function transformation
Dne 2019-01-25 19:10, Martin Jambor napsal:
Hi,
the following patch fixes a verification ICE because of mismatching BB
and cgraph_edge counts arising as a consequence of cleaning-up CFG
after
IPA-CP transformation, which is currently done as if it was a normal
tree pass, and which IPA passes should not attempt exaclty because of
this reason.
Fixed (hopefully) exactly as I was told by Honza in Bugzilla, by
resorting to calling delete_unreachable_blocks_update_callgraph
instead. The aforementioned function had to be made public and in the
process was moved to a more suitable file.
Bootstrapped and tested on x86_64-linux. OK for trunk?
OK,
Honza
Thanks,
Martin
2019-01-25 Martin Jambor
* tree-inline.c: Include tree-cfgcleanup.h.
(delete_unreachable_blocks_update_callgraph): Move...
* tree-cfgcleanup.c (delete_unreachable_blocks_update_callgraph):
...here, make externally visible, make second argument bool, adjust
all callers.
* tree-cfgcleanup.c: Include cgraph.h.
* tree-cfgcleanup.h (delete_unreachable_blocks_update_callgraph):
Declare.
* ipa-prop.c: Include tree-cfgcleanup.h.
(ipcp_transform_function): Call
delete_unreachable_blocks_update_callgraph instead of cleaning uo CFG.
testsuite/
* gfortran.dg/gomp/pr88933.f90: New test.
---
gcc/ipa-prop.c | 10 +--
gcc/testsuite/gfortran.dg/gomp/pr88933.f90 | 39 +++
gcc/tree-cfgcleanup.c | 75 +++-
gcc/tree-cfgcleanup.h | 2 +
gcc/tree-inline.c | 80 ++
5 files changed, 125 insertions(+), 81 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/gomp/pr88933.f90
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 40ab130b750..d86c2f3db55 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3. If not see
#include "dbgcnt.h"
#include "domwalk.h"
#include "builtins.h"
+#include "tree-cfgcleanup.h"
/* Function summary where the parameter infos are actually stored. */
ipa_node_params_t *ipa_node_params_sum = NULL;
@@ -5173,10 +5174,11 @@ ipcp_transform_function (struct cgraph_node
*node)
if (!something_changed)
return 0;
- else if (cfg_changed)
-return TODO_update_ssa_only_virtuals | TODO_cleanup_cfg;
- else
-return TODO_update_ssa_only_virtuals;
+
+ if (cfg_changed)
+delete_unreachable_blocks_update_callgraph (node, false);
+
+ return TODO_update_ssa_only_virtuals;
}
#include "gt-ipa-prop.h"
diff --git a/gcc/testsuite/gfortran.dg/gomp/pr88933.f90
b/gcc/testsuite/gfortran.dg/gomp/pr88933.f90
new file mode 100644
index 000..e4f30ae9f3e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/pr88933.f90
@@ -0,0 +1,39 @@
+! PR ipa/88933
+! { dg-do compile }
+! { dg-options "-O1 -fexceptions -fipa-cp -fnon-call-exceptions
-fopenmp -fno-inline-functions-called-once" }
+
+!$omp parallel
+!$omp single
+ call a
+!$omp end single
+!$omp end parallel
+contains
+ subroutine b (c, d, e, f, g, h, i, j, k, m)
+character (*) c
+character d
+integer, dimension (m) :: e
+integer, dimension (m) :: f
+character g
+character h
+real, dimension (:, :, :) :: i
+double precision, dimension (:, :, :) :: j
+integer, dimension (:, :, :) :: k
+
+integer, dimension (m) :: l
+!$omp task firstprivate (k) firstprivate (l)
+!$omp end task
+ c = ''
+ end
+ subroutine a
+character c
+character d
+integer, dimension (7) :: e
+integer, dimension (7) :: f
+character g
+character h
+real, dimension (5, 6, 7) :: i
+double precision, dimension (6, 6, 7) :: j
+integer, dimension (5, 7, 6) :: k
+call b (c, d, e, f, g, h, i, j, k, 7)
+ end
+end
diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
index 2adb3953d6b..f2e8b96ee8e 100644
--- a/gcc/tree-cfgcleanup.c
+++ b/gcc/tree-cfgcleanup.c
@@ -43,7 +43,7 @@ along with GCC; see the file COPYING3. If not see
#include "gimple-match.h"
#include "gimple-fold.h"
#include "tree-ssa-loop-niter.h"
-
+#include "cgraph.h"
/* The set of blocks in that at least one of the following changes
happened:
-- the statement at the end of the block was changed
@@ -1380,3 +1380,76 @@ make_pass_cleanup_cfg_post_optimizing
(gcc::context *ctxt)
}
+/* Delete all unreachable basic blocks and update callgraph.
+ Doing so is somewhat nontrivial because we need to update all
clones and
+ remove inline function that become unreachable. */
+
+bool
+delete_unreachable_blocks_update_callgraph (cgraph_node *dst_node,
+ bool update_clones)
+{
+ bool changed = false;
+ basic_block b, next_bb;
+
+ find_unreachable_blocks ();
+
+ /* Delete all unreachable basic blocks. */
+
+ for (b = ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb; b
+ != EXIT_BLOCK_PTR_FOR_FN (cfun); b = next_bb)
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 --- Comment #2 from Barry Revzin --- This may or may not be the same bug as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87709, I do not know.
[Bug c++/89062] class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-01-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On Freitag, 25. Januar 2019 07:22:36 CET Nikhil Benesch wrote: > Does anyone have advice to offer? Has anyone tried convincing the build > system to compile some of the other target libraries (like libstdc++ or > libgfortran) with -flto? > Make sure the static versions of the libraries are partially linked before being archived so they do not have LTO code in the final libraries. gcc -r -o libname.o ar x libname.a libname.o Never done it with gcc libraries though. 'Allan
[Bug c++/89062] New: class template argument deduction failure with parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
Bug ID: 89062
Summary: class template argument deduction failure with
parentheses
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Reduced from StackOverflow https://stackoverflow.com/q/54369677/2069064:
template
struct Foo {
Foo(T) {}
};
template
struct Bar {
Bar(T) {};
};
Foo foo(Bar{1});
This fails with:
:11:9: error: 'auto' parameter not permitted in this context
Foo foo(Bar{1});
^~~
Compiler returned: 1
Every other alternative is fine:
Foo foo(Bar(1)); // ok
Foo foo{Bar{1}}; // ok
Foo foo{Bar(1)}; // ok
Foo foo(Bar(1)); // ok
Foo foo(Bar{1}); // ok
Foo> foo(Bar{1}); // ok
[Bug ipa/88933] ICE: verify_cgraph_node failed (Error: caller edge count does not match BB count)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88933 --- Comment #17 from Martin Jambor --- OK, I did that too and proposed a patch in https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01525.html
[PR ipa/88933] Careful CFG cleanup in IPA-CP function transformation
Hi,
the following patch fixes a verification ICE because of mismatching BB
and cgraph_edge counts arising as a consequence of cleaning-up CFG after
IPA-CP transformation, which is currently done as if it was a normal
tree pass, and which IPA passes should not attempt exaclty because of
this reason.
Fixed (hopefully) exactly as I was told by Honza in Bugzilla, by
resorting to calling delete_unreachable_blocks_update_callgraph
instead. The aforementioned function had to be made public and in the
process was moved to a more suitable file.
Bootstrapped and tested on x86_64-linux. OK for trunk?
Thanks,
Martin
2019-01-25 Martin Jambor
* tree-inline.c: Include tree-cfgcleanup.h.
(delete_unreachable_blocks_update_callgraph): Move...
* tree-cfgcleanup.c (delete_unreachable_blocks_update_callgraph):
...here, make externally visible, make second argument bool, adjust
all callers.
* tree-cfgcleanup.c: Include cgraph.h.
* tree-cfgcleanup.h (delete_unreachable_blocks_update_callgraph):
Declare.
* ipa-prop.c: Include tree-cfgcleanup.h.
(ipcp_transform_function): Call
delete_unreachable_blocks_update_callgraph instead of cleaning uo CFG.
testsuite/
* gfortran.dg/gomp/pr88933.f90: New test.
---
gcc/ipa-prop.c | 10 +--
gcc/testsuite/gfortran.dg/gomp/pr88933.f90 | 39 +++
gcc/tree-cfgcleanup.c | 75 +++-
gcc/tree-cfgcleanup.h | 2 +
gcc/tree-inline.c | 80 ++
5 files changed, 125 insertions(+), 81 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/gomp/pr88933.f90
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 40ab130b750..d86c2f3db55 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -52,6 +52,7 @@ along with GCC; see the file COPYING3. If not see
#include "dbgcnt.h"
#include "domwalk.h"
#include "builtins.h"
+#include "tree-cfgcleanup.h"
/* Function summary where the parameter infos are actually stored. */
ipa_node_params_t *ipa_node_params_sum = NULL;
@@ -5173,10 +5174,11 @@ ipcp_transform_function (struct cgraph_node *node)
if (!something_changed)
return 0;
- else if (cfg_changed)
-return TODO_update_ssa_only_virtuals | TODO_cleanup_cfg;
- else
-return TODO_update_ssa_only_virtuals;
+
+ if (cfg_changed)
+delete_unreachable_blocks_update_callgraph (node, false);
+
+ return TODO_update_ssa_only_virtuals;
}
#include "gt-ipa-prop.h"
diff --git a/gcc/testsuite/gfortran.dg/gomp/pr88933.f90
b/gcc/testsuite/gfortran.dg/gomp/pr88933.f90
new file mode 100644
index 000..e4f30ae9f3e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/gomp/pr88933.f90
@@ -0,0 +1,39 @@
+! PR ipa/88933
+! { dg-do compile }
+! { dg-options "-O1 -fexceptions -fipa-cp -fnon-call-exceptions -fopenmp
-fno-inline-functions-called-once" }
+
+!$omp parallel
+!$omp single
+ call a
+!$omp end single
+!$omp end parallel
+contains
+ subroutine b (c, d, e, f, g, h, i, j, k, m)
+character (*) c
+character d
+integer, dimension (m) :: e
+integer, dimension (m) :: f
+character g
+character h
+real, dimension (:, :, :) :: i
+double precision, dimension (:, :, :) :: j
+integer, dimension (:, :, :) :: k
+
+integer, dimension (m) :: l
+!$omp task firstprivate (k) firstprivate (l)
+!$omp end task
+ c = ''
+ end
+ subroutine a
+character c
+character d
+integer, dimension (7) :: e
+integer, dimension (7) :: f
+character g
+character h
+real, dimension (5, 6, 7) :: i
+double precision, dimension (6, 6, 7) :: j
+integer, dimension (5, 7, 6) :: k
+call b (c, d, e, f, g, h, i, j, k, 7)
+ end
+end
diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
index 2adb3953d6b..f2e8b96ee8e 100644
--- a/gcc/tree-cfgcleanup.c
+++ b/gcc/tree-cfgcleanup.c
@@ -43,7 +43,7 @@ along with GCC; see the file COPYING3. If not see
#include "gimple-match.h"
#include "gimple-fold.h"
#include "tree-ssa-loop-niter.h"
-
+#include "cgraph.h"
/* The set of blocks in that at least one of the following changes happened:
-- the statement at the end of the block was changed
@@ -1380,3 +1380,76 @@ make_pass_cleanup_cfg_post_optimizing (gcc::context
*ctxt)
}
+/* Delete all unreachable basic blocks and update callgraph.
+ Doing so is somewhat nontrivial because we need to update all clones and
+ remove inline function that become unreachable. */
+
+bool
+delete_unreachable_blocks_update_callgraph (cgraph_node *dst_node,
+ bool update_clones)
+{
+ bool changed = false;
+ basic_block b, next_bb;
+
+ find_unreachable_blocks ();
+
+ /* Delete all unreachable basic blocks. */
+
+ for (b = ENTRY_BLOCK_PTR_FOR_FN (cfun)->next_bb; b
+ != EXIT_BLOCK_PTR_FOR_FN (cfun); b = next_bb)
+{
+ next_bb = b->next_bb;
+
+ if
[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85780 kargl at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #11 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing.
[Bug c/89061] GCC 9 introduces false positive in -Wjump-misses-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89061 --- Comment #1 from joseph at codesourcery dot com --- Guessing this might be another issue from pushdecl being called for compound literals (r259641). (Technically of course it's true that the jump misses the initialization of the anonymous object for the compound literal, that's just a useless warning.)
[Bug fortran/85780] ICE in resolve_fl_procedure, at fortran/resolve.c:12504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85780 --- Comment #10 from kargl at gcc dot gnu.org --- Author: kargl Date: Fri Jan 25 17:55:25 2019 New Revision: 268277 URL: https://gcc.gnu.org/viewcvs?rev=268277=gcc=rev Log: 2019-01-25 Steven G. Kargl PR fortran/85780 * decl.c (gfc_match_subroutine): Check for conflict between BIND(C) and alternative return. 2019-01-25 Steven G. Kargl PR fortran/85780 * gfortran.dg/pr85780.f90: Update testcase for error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr85780.f90
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
Richard, regarding your first mail, I'm afraid I'm not sure what you mean. Isn't this exactly the section of configure.ac that handles CC_FOR_TARGET? The Makefile is dumb and just passes the autoconf-substituted value for CC_FOR_TARGET directly through. (I agree the patch will need some tweaks to work for all the build/host/target combination possibilities.) On Fri, Jan 25, 2019 at 12:18 PM Joseph Myers wrote: > > On Fri, 25 Jan 2019, Nikhil Benesch wrote: > > > I am attempting to convince GCC to build target libraries with link-time > > optimizations enabled. I am primarily interested in libgo, but this > > discussion > > Note that as far as I know issues with host-dependencies of LTO bytecode > (bug 41526) may still exist, so this wouldn't work with Canadian cross > compilers. Ack, thanks for the heads up. For now I'm only interested in turning on LTO during native builds. > > I have a simple patch to the top-level configure.ac that resolves the issue > > by > > teaching the build system to use the gcc-ar and gcc-ranlib wrappers which > > were > > built earlier and know how to pass the linker plugin to the underlying > > ar/ranlib > > commands. The patch is small enough that I've included it at the end of this > > email. > > Will those wrappers properly wrap round tools for the target that were > configured using --with-build-time-tools? That's a good question. I think the answer is no. I'll investigate further. On Fri, Jan 25, 2019 at 12:39 PM Richard Biener wrote: > > On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers > wrote: > >On Fri, 25 Jan 2019, Nikhil Benesch wrote: > > > >> I am attempting to convince GCC to build target libraries with > >link-time > >> optimizations enabled. I am primarily interested in libgo, but this > >discussion > > > >Note that as far as I know issues with host-dependencies of LTO > >bytecode > >(bug 41526) may still exist, so this wouldn't work with Canadian cross > >compilers. > > I was expecting the LTO byte code not to be retained in the built libraries. > > >> I have a simple patch to the top-level configure.ac that resolves the > >issue by > >> teaching the build system to use the gcc-ar and gcc-ranlib wrappers > >which were > >> built earlier and know how to pass the linker plugin to the > >underlying ar/ranlib > >> commands. The patch is small enough that I've included it at the end > >of this > >> email. > > > >Will those wrappers properly wrap round tools for the target that were > >configured using --with-build-time-tools? >
Re: [PATCH] rs6000: Add support for the vec_sbox_be, vec_cipher_be etc. builtins.
Hi!
On Wed, Jan 23, 2019 at 03:57:28AM -0600, luo...@linux.vnet.ibm.com wrote:
> The 5 new builtins vec_sbox_be, vec_cipher_be, vec_cipherlast_be,
> vec_ncipher_be
> and vec_ncipherlast_be only support vector unsigned char type parameters.
> Add new instruction crypto_vsbox_ and crypto__ to handle
> them accordingly, where the new mode CR_vqdi can be expanded to vector
> unsigned
> long long for none _be postfix builtins or vector unsigned char for _be
> postfix
> builtins.
Hrm, can't you use the existing CR_mode iterator here?
> 2019-01-23 Xiong Hu Luo
>
> * gcc/testsuite/gcc.target/powerpc/crypto-builtin-1.c
> (crpyto1_be, crpyto2_be, crpyto3_be, crpyto4_be, crpyto5_be):
> New testcases.
Typoes ("crypto"). And that last line is indented incorrectly.
With those things fixed, okay for trunk, with the new iterator if CR_mode
isn't usable here. Thanks!
Segher
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On January 25, 2019 6:17:54 PM GMT+01:00, Joseph Myers wrote: >On Fri, 25 Jan 2019, Nikhil Benesch wrote: > >> I am attempting to convince GCC to build target libraries with >link-time >> optimizations enabled. I am primarily interested in libgo, but this >discussion > >Note that as far as I know issues with host-dependencies of LTO >bytecode >(bug 41526) may still exist, so this wouldn't work with Canadian cross >compilers. I was expecting the LTO byte code not to be retained in the built libraries. >> I have a simple patch to the top-level configure.ac that resolves the >issue by >> teaching the build system to use the gcc-ar and gcc-ranlib wrappers >which were >> built earlier and know how to pass the linker plugin to the >underlying ar/ranlib >> commands. The patch is small enough that I've included it at the end >of this >> email. > >Will those wrappers properly wrap round tools for the target that were >configured using --with-build-time-tools?
[PATCH] Add myself to MAINTAINERS
This adds me to the Write After Approval list in MAINTAINERS. Committed to trunk in r268276. Index: MAINTAINERS === --- MAINTAINERS (revision 268275) +++ MAINTAINERS (working copy) @@ -634,6 +634,7 @@ Canqun Yang Fei Yang Jeffrey Yasskin Joey Ye +Kwok Cheung Yeung Greta Yorsh David Yuste Adhemerval Zanella
[Bug c++/89024] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 Marek Polacek changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #6 from Marek Polacek --- Nope, changing it back.
[Bug middle-end/88560] [9 Regression] armv8_2-fp16-move-1.c and related regressions after r266385
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88560 --- Comment #11 from Tamar Christina --- Hi Vladimir, I've tested the patch and checked the testcases. The code is now better in most cases so no issue there. The testcases will need to be updated but I can do that after the patch is committed. I've kicked off an overnight native regression test and will inspect the result and any failing tests and update you first thing monday.
Re: [backtrace] Avoid segfault
On Fri, Jan 25, 2019 at 12:15:28PM -0500, Nathan Sidwell wrote: > On 1/25/19 5:28 AM, Tom de Vries wrote: > > > > This patch fixes it by passing "" instead of NULL, in the call to > > elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at > > line 3044 (for .gnu_debuglink) mentioned above. > > > > Nathan, does this fix the problem for you? If not, can you provide a > > reproducer, or give a hint on how one could be constructed? > > I still hit the problem, and am installing this as sufficiently obvious. > I'm on a fedora system debugging pr88995. The debuglink_name is > "../../.dwz/isl-0.16.1-7.fc29.x86_64" > > I'm not sure why this is triggering now -- maybe my debuginfo packages are > out of date? I'm seeing this too. I've resolved it by uninstalling libmpc-debuginfo. If I put it back, the crash in libbacktrace reappears. Again the problem was a null filename and so strchr crashed. Thanks for looking into this Nathan. Marek
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On Fri, 25 Jan 2019, Nikhil Benesch wrote: > I am attempting to convince GCC to build target libraries with link-time > optimizations enabled. I am primarily interested in libgo, but this discussion Note that as far as I know issues with host-dependencies of LTO bytecode (bug 41526) may still exist, so this wouldn't work with Canadian cross compilers. > I have a simple patch to the top-level configure.ac that resolves the issue by > teaching the build system to use the gcc-ar and gcc-ranlib wrappers which were > built earlier and know how to pass the linker plugin to the underlying > ar/ranlib > commands. The patch is small enough that I've included it at the end of this > email. Will those wrappers properly wrap round tools for the target that were configured using --with-build-time-tools? -- Joseph S. Myers jos...@codesourcery.com
Re: [backtrace] Avoid segfault
On 1/25/19 5:28 AM, Tom de Vries wrote: This patch fixes it by passing "" instead of NULL, in the call to elf_add at line 3083 (for .gnu_debugaltlink), not the call to elf_add at line 3044 (for .gnu_debuglink) mentioned above. Nathan, does this fix the problem for you? If not, can you provide a reproducer, or give a hint on how one could be constructed? I still hit the problem, and am installing this as sufficiently obvious. I'm on a fedora system debugging pr88995. The debuglink_name is "../../.dwz/isl-0.16.1-7.fc29.x86_64" I'm not sure why this is triggering now -- maybe my debuginfo packages are out of date? nathan -- Nathan Sidwell 2019-01-25 Nathan Sidwell * elf.c (elf_add): Pass "" filename to recursive call with separated debug. Index: elf.c === --- elf.c (revision 268272) +++ elf.c (working copy) @@ -3041,7 +3041,7 @@ elf_add (struct backtrace_state *state, if (debugaltlink_view_valid) backtrace_release_view (state, _view, error_callback, data); - ret = elf_add (state, NULL, d, base_address, error_callback, data, + ret = elf_add (state, "", d, base_address, error_callback, data, fileline_fn, found_sym, found_dwarf, NULL, 0, 1, NULL, 0); if (ret < 0)
Re: C++ PATCH for c++/89024 - ICE with incomplete enum type
On 1/25/19 12:09 PM, Marek Polacek wrote: On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote: On 1/24/19 2:16 PM, Marek Polacek wrote: This test ICEs since r159006 which added type = ENUM_UNDERLYING_TYPE (type); to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we haven't yet parsed '}' of the enum and the underlying type isn't fixed, and so checking TYPE_UNSIGNED crashed. I've added some checks to the test to see if the types seem to be OK; clang++ agrees. Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7? 2019-01-24 Marek Polacek PR c++/89024 - ICE with incomplete enum type. * cvt.c (type_promotes_to): Check if prom is non-null. 9.6/6: An enumeration whose underlying type is not fixed is an incomplete type from its point of declaration to immediately after the closing } of its enum-specifier, at which point it becomes a complete type. So the conversion is ill-formed. Jason But the conversion in the example (in decltype(__test_aux<_To1>(declval<_From1>( is in a SFINAE context, so shouldn't it gracefully fall back to the `(...)` overload? I think so, and clang++ and icc also compile the testcase fine (and we used to too, before r159006). Absolutely, the conversion being ill-formed means substitution fails, and we reject that candidate. I meant that we shouldn't get as far as type_promotes_to for an incomplete type. Jason
[aarch64] Fix ABI breakage with 128-bit bitfield types.
This is pretty unlikely in real code, but similar to Arm, the AArch64
ABI has a bug with the handling of 128-bit bit-fields, where if the
bit-field dominates the overall alignment the back-end code may end up
passing the argument correctly. This is a regression that started in
gcc-6 when the ABI support code was updated to support overaligned
types. The fix is very similar in concept to the Arm fix. 128-bit
bit-fields are fortunately extremely rare, so I'd be very surprised if
anyone has been bitten by this.
PR target/88469
gcc/
* config/aarch64/aarch64.c (aarch64_function_arg_alignment): Add new
argument ABI_BREAK. Set to true if the calculated alignment has
changed in gcc-9. Check bit-fields for their base type alignment.
(aarch64_layout_arg): Warn if argument passing has changed in gcc-9.
(aarch64_function_arg_boundary): Likewise.
(aarch64_gimplify_va_arg_expr): Likewise.
gcc/testsuite/
* gcc.target/aarch64/aapcs64/test_align-10.c: New test.
* gcc.target/aarch64/aapcs64/test_align-11.c: New test.
* gcc.target/aarch64/aapcs64/test_align-12.c: New test.
Committed to trunk.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index 5df5a8b7843..d6a9955804f 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -3765,12 +3765,16 @@ aarch64_vfp_is_call_candidate (cumulative_args_t pcum_v, machine_mode mode,
/* Given MODE and TYPE of a function argument, return the alignment in
bits. The idea is to suppress any stronger alignment requested by
- the user and opt for the natural alignment (specified in AAPCS64 \S 4.1).
- This is a helper function for local use only. */
+ the user and opt for the natural alignment (specified in AAPCS64 \S
+ 4.1). ABI_BREAK is set to true if the alignment was incorrectly
+ calculated in versions of GCC prior to GCC-9. This is a helper
+ function for local use only. */
static unsigned int
-aarch64_function_arg_alignment (machine_mode mode, const_tree type)
+aarch64_function_arg_alignment (machine_mode mode, const_tree type,
+bool *abi_break)
{
+ *abi_break = false;
if (!type)
return GET_MODE_ALIGNMENT (mode);
@@ -3786,9 +3790,22 @@ aarch64_function_arg_alignment (machine_mode mode, const_tree type)
return TYPE_ALIGN (TREE_TYPE (type));
unsigned int alignment = 0;
+ unsigned int bitfield_alignment = 0;
for (tree field = TYPE_FIELDS (type); field; field = DECL_CHAIN (field))
if (TREE_CODE (field) == FIELD_DECL)
- alignment = std::max (alignment, DECL_ALIGN (field));
+ {
+ alignment = std::max (alignment, DECL_ALIGN (field));
+ if (DECL_BIT_FIELD_TYPE (field))
+ bitfield_alignment
+ = std::max (bitfield_alignment,
+ TYPE_ALIGN (DECL_BIT_FIELD_TYPE (field)));
+ }
+
+ if (bitfield_alignment > alignment)
+{
+ *abi_break = true;
+ return bitfield_alignment;
+}
return alignment;
}
@@ -3805,6 +3822,7 @@ aarch64_layout_arg (cumulative_args_t pcum_v, machine_mode mode,
int ncrn, nvrn, nregs;
bool allocate_ncrn, allocate_nvrn;
HOST_WIDE_INT size;
+ bool abi_break;
/* We need to do this once per argument. */
if (pcum->aapcs_arg_processed)
@@ -3881,25 +3899,28 @@ aarch64_layout_arg (cumulative_args_t pcum_v, machine_mode mode,
entirely general registers. */
if (allocate_ncrn && (ncrn + nregs <= NUM_ARG_REGS))
{
-
gcc_assert (nregs == 0 || nregs == 1 || nregs == 2);
/* C.8 if the argument has an alignment of 16 then the NGRN is
- rounded up to the next even number. */
+ rounded up to the next even number. */
if (nregs == 2
&& ncrn % 2
/* The == 16 * BITS_PER_UNIT instead of >= 16 * BITS_PER_UNIT
comparison is there because for > 16 * BITS_PER_UNIT
alignment nregs should be > 2 and therefore it should be
passed by reference rather than value. */
- && aarch64_function_arg_alignment (mode, type) == 16 * BITS_PER_UNIT)
+ && (aarch64_function_arg_alignment (mode, type, _break)
+ == 16 * BITS_PER_UNIT))
{
+ if (abi_break && warn_psabi && currently_expanding_gimple_stmt)
+ inform (input_location, "parameter passing for argument of type "
+ "%qT changed in GCC 9.1", type);
++ncrn;
gcc_assert (ncrn + nregs <= NUM_ARG_REGS);
}
/* NREGS can be 0 when e.g. an empty structure is to be passed.
- A reg is still generated for it, but the caller should be smart
+ A reg is still generated for it, but the caller should be smart
enough not to use it. */
if (nregs == 0 || nregs == 1 || GET_MODE_CLASS (mode) == MODE_INT)
pcum->aapcs_reg = gen_rtx_REG (mode, R0_REGNUM + ncrn);
@@ -3931,9 +3952,18 @@ aarch64_layout_arg (cumulative_args_t pcum_v, machine_mode mode,
on_stack:
pcum->aapcs_stack_words = size / UNITS_PER_WORD;
- if (aarch64_function_arg_alignment (mode, type) == 16 * BITS_PER_UNIT)
-pcum->aapcs_stack_size
Re: C++ PATCH for c++/89024 - ICE with incomplete enum type
On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote: > > > > On 1/24/19 2:16 PM, Marek Polacek wrote: > > > This test ICEs since r159006 which added > > > > > > type = ENUM_UNDERLYING_TYPE (type); > > > > > > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we > > > haven't yet parsed '}' of the enum and the underlying type isn't fixed, > > > and > > > so checking TYPE_UNSIGNED crashed. > > > > > > I've added some checks to the test to see if the types seem to be OK; > > > clang++ > > > agrees. > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7? > > > > > > 2019-01-24 Marek Polacek > > > > > > PR c++/89024 - ICE with incomplete enum type. > > > * cvt.c (type_promotes_to): Check if prom is non-null. > > > > 9.6/6: An enumeration whose underlying type is not fixed is an > > incomplete type from its point of declaration to immediately after the > > closing } of its enum-specifier, at which point it becomes a complete type. > > > > So the conversion is ill-formed. > > > > Jason > > But the conversion in the example (in > decltype(__test_aux<_To1>(declval<_From1>( > is in a SFINAE context, so shouldn't it gracefully fall back to the > `(...)` overload? I think so, and clang++ and icc also compile the testcase fine (and we used to too, before r159006). Marek
[Bug target/88469] [7/8 regression] AAPCS/AAPCS64 - Struct with 64-bit bitfield (128-bit on AArch64) may be passed in wrong registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88469 --- Comment #11 from Richard Earnshaw --- Author: rearnsha Date: Fri Jan 25 17:09:33 2019 New Revision: 268273 URL: https://gcc.gnu.org/viewcvs?rev=268273=gcc=rev Log: This is pretty unlikely in real code, but similar to Arm, the AArch64 ABI has a bug with the handling of 128-bit bit-fields, where if the bit-field dominates the overall alignment the back-end code may end up passing the argument correctly. This is a regression that started in gcc-6 when the ABI support code was updated to support overaligned types. The fix is very similar in concept to the Arm fix. 128-bit bit-fields are fortunately extremely rare, so I'd be very surprised if anyone has been bitten by this. PR target/88469 gcc/ * config/aarch64/aarch64.c (aarch64_function_arg_alignment): Add new argument ABI_BREAK. Set to true if the calculated alignment has changed in gcc-9. Check bit-fields for their base type alignment. (aarch64_layout_arg): Warn if argument passing has changed in gcc-9. (aarch64_function_arg_boundary): Likewise. (aarch64_gimplify_va_arg_expr): Likewise. gcc/testsuite/ * gcc.target/aarch64/aapcs64/test_align-10.c: New test. * gcc.target/aarch64/aapcs64/test_align-11.c: New test. * gcc.target/aarch64/aapcs64/test_align-12.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/test_align-10.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/test_align-11.c trunk/gcc/testsuite/gcc.target/aarch64/aapcs64/test_align-12.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89055] wrong location with predefined macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89055
David Malcolm changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org
--- Comment #1 from David Malcolm ---
The location ("loc") for the diagnostic is coming from here in
compute_array_index_type_loc:
9644 location_t loc = cp_expr_loc_or_loc (size, name ? name_loc :
input_location);
For the 2nd example:
(gdb) p /x loc
$4 = 0x8001
(gdb) p /x line_table->location_adhoc_data_map.data[1]
$7 = {locus = 0x285e0, src_range = {m_start = 0x7fff, m_finish = 0x28640},
data = 0x0}
i.e. we have regular locations for the caret and finish, but a macro location
for the "start":
(gdb) call inform (line_table->location_adhoc_data_map.data[1].locus, "caret")
t.C:2:21: note: caret
2 | char b[__SIZE_MAX__ << 1];
| ^
(gdb) call inform
(line_table->location_adhoc_data_map.data[1].src_range.m_start, "start")
t.C:2:8: note: start
2 | char b[__SIZE_MAX__ << 1];
|^~~~
(gdb) call inform
(line_table->location_adhoc_data_map.data[1].src_range.m_finish, "finish")
t.C:2:24: note: finish
2 | char b[__SIZE_MAX__ << 1];
|^
When printing "loc", diagnostic-show-locus.c's layout::maybe_add_location_range
generates a sane layout_range:
(gdb) p ri
$15 = {m_start = {m_line = 2, m_column = 8}, m_finish = {m_line = 2, m_column =
24},
m_range_display_kind = SHOW_RANGE_WITH_CARET, m_caret = {m_line = 2, m_column
= 21}, m_original_idx = 0, m_label = 0x0}
but then sanitizes it to just the caret location here:
973 if (start.line > finish.line
974 || !compatible_locations_p (src_range.m_start, m_primary_loc)
975 || !compatible_locations_p (src_range.m_finish, m_primary_loc))
976 {
977 /* Is this the primary location? */
978 if (m_layout_ranges.length () == 0)
979 {
980 /* We want to print the caret for the primary location, but
981 we must sanitize away m_start and m_finish. */
982 ri.m_start = ri.m_caret;
983 ri.m_finish = ri.m_caret;
984 }
due to:
compatible_locations_p (src_range.m_start, m_primary_loc)
returning false.
As noted in compatible_locations_p, it may be "too strong a condition" (but I'm
loathe to weaken that sanitization in stage 4; it exists due to e.g. PR c/68473
and PR c++/70105).
If I hack out that sanitization, the 2nd is printed, sanely, as:
t.C:2:21: error: size of array ‘b’ is negative
2 | char b[__SIZE_MAX__ << 1];
|~^~~~
(It's also not clear to me that it's a good idea to be building a compound
location containing macro locations in the first place)
Re: [PATCH] C++ concepts: fix ICE with requires on dtors (PR c++/89036)
On 1/25/19 8:48 AM, David Malcolm wrote:
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
mutually exclusive "requires" clauses:
template
struct Y {
~Y() requires(true) = default;
~Y() requires(false) {}
};
(is this valid? my knowledge of this part of C++ is fairly hazy)
Yes. A more sensible example would have 'true' and 'false' replaced by
something determined from the template parms.
Nathan introduced this assertion as part of:
ca9219bf18c68a001d62ecb981bc9176b0feaf12 (aka r251340):
2017-08-24 Nathan Sidwell
Conversion operators kept on single overload set
I'd just drop the assert at this point.
nathan
--
Nathan Sidwell
[Bug middle-end/89037] checking ice emitting 128-bit bit-field initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89037 --- Comment #4 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Jan 25 16:57:32 2019 New Revision: 268272 URL: https://gcc.gnu.org/viewcvs?rev=268272=gcc=rev Log: Fix output_constructor_bitfield handling of wide bitfields (PR89037) The testcase was failing because we were trying to access TREE_INT_CST_ELT (x, 1) of a 128-bit integer that was small enough to need only a single element. 2019-01-25 Richard Sandiford gcc/ PR middle-end/89037 * varasm.c (output_constructor_bitfield): Use wi::extract_uhwi instead of accessing TREE_INT_CST_ELT directly. gcc/testsuite/ PR middle-end/89037 * gcc.dg/pr89037.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr89037.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
Re: C++ PATCH for c++/89024 - ICE with incomplete enum type
On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill wrote: > > On 1/24/19 2:16 PM, Marek Polacek wrote: > > This test ICEs since r159006 which added > > > > type = ENUM_UNDERLYING_TYPE (type); > > > > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we > > haven't yet parsed '}' of the enum and the underlying type isn't fixed, and > > so checking TYPE_UNSIGNED crashed. > > > > I've added some checks to the test to see if the types seem to be OK; > > clang++ > > agrees. > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7? > > > > 2019-01-24 Marek Polacek > > > > PR c++/89024 - ICE with incomplete enum type. > > * cvt.c (type_promotes_to): Check if prom is non-null. > > 9.6/6: An enumeration whose underlying type is not fixed is an > incomplete type from its point of declaration to immediately after the > closing } of its enum-specifier, at which point it becomes a complete type. > > So the conversion is ill-formed. > > Jason But the conversion in the example (in decltype(__test_aux<_To1>(declval<_From1>( is in a SFINAE context, so shouldn't it gracefully fall back to the `(...)` overload?
Re: [PATCH] libgfortran: Use proper gthr.h API
On 25 January 2019 12:44:30 CET, Sebastian Huber
wrote:
>libgfortran/
>
> * io/async.c (init_adv_cond): Use
> __GTHREAD_COND_INIT_FUNCTION().
LGTM.
Please CC the FORTRAN list for FORTRAN patches.
thanks,
>---
> libgfortran/io/async.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/libgfortran/io/async.c b/libgfortran/io/async.c
>index 3394e595a8b..e3d1d01122e 100644
>--- a/libgfortran/io/async.c
>+++ b/libgfortran/io/async.c
>@@ -224,7 +224,7 @@ init_adv_cond (struct adv_cond *ac)
> {
> ac->pending = 0;
> __GTHREAD_MUTEX_INIT_FUNCTION (>lock);
>- __gthread_cond_init_function (>signal);
>+ __GTHREAD_COND_INIT_FUNCTION (>signal);
> }
>
> /* Initialize an asyncronous unit, returning zero on success,
[Bug c++/89024] [7/8/9 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 Marek Polacek changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #5 from Marek Polacek --- Jason says this is invalid, changing the keywords.
Re: Enabling LTO for target libraries (e.g., libgo, libstdc++)
On January 25, 2019 7:22:36 AM GMT+01:00, Nikhil Benesch wrote: >I am attempting to convince GCC to build target libraries with >link-time >optimizations enabled. I am primarily interested in libgo, but this >discussion >seems like it would be applicable to libstdc++, libgfortran, etc. The >benchmarking I've done suggests that LTOing libgo yields a 5-20% >speedup on >various Go programs, which is quite substantial. > >The trouble is convincing GCC's build system to apply the various LTO >flags to >the correct places. Ian Taylor suggested the following to plumb -flto >into >libgo compilation: > >$ make GOCFLAGS_FOR_TARGET="-g -O3 -flto" > >This nearly works, and I believe there are analogous options that would >apply to >the other target libraries that GCC builds. > >The trouble is that while building libgo, the build system uses ar and >ranlib >directly from binutils, without providing them with the LTO plugin that >was >built earlier. This means that the LTO information is dropped on the >floor, and >attempting to link with the built libgo archive will fail. > >I have a simple patch to the top-level configure.ac that resolves the >issue by >teaching the build system to use the gcc-ar and gcc-ranlib wrappers >which were >built earlier and know how to pass the linker plugin to the underlying >ar/ranlib >commands. The patch is small enough that I've included it at the end of >this >email. > >My question is whether this is a reasonable thing to do. It seems like >using >the gcc-ar and gcc-ranlib wrappers strictly improves the situation, and >won't >impact compilations that don't specify -flto. But I'm not familiar >enough with >the build system to say for sure. > >Does anyone have advice to offer? Has anyone tried convincing the build >system >to compile some of the other target libraries (like libstdc++ or >libgfortran) >with -flto? Using the built gcc-ar and ranlib sounds good but the patch looks not Form a quick look. I think we want to change the top level makefile to pass down the appropriate ar/ranlib_FOR_TARGET similar to how we pass CC_FOR_tARGET. Richard. >diff --git a/configure.ac b/configure.ac >index 87f2aee05008..1c38ac5979ff 100644 >--- a/configure.ac >+++ b/configure.ac >@@ -3400,7 +3400,8 @@ >ACX_CHECK_INSTALLED_TARGET_TOOL(WINDMC_FOR_TARGET, windmc) > > RAW_CXX_FOR_TARGET="$CXX_FOR_TARGET" > >-GCC_TARGET_TOOL(ar, AR_FOR_TARGET, AR, [binutils/ar]) >+GCC_TARGET_TOOL(ar, AR_FOR_TARGET, AR, >+ [gcc/gcc-ar -B$$r/$(HOST_SUBDIR)/gcc/]) > GCC_TARGET_TOOL(as, AS_FOR_TARGET, AS, [gas/as-new]) >GCC_TARGET_TOOL(cc, CC_FOR_TARGET, CC, [gcc/xgcc >-B$$r/$(HOST_SUBDIR)/gcc/]) > dnl see comments for CXX_FOR_TARGET_FLAG_TO_PASS >@@ -3424,7 +3425,8 @@ GCC_TARGET_TOOL(nm, NM_FOR_TARGET, NM, >[binutils/nm-new]) >GCC_TARGET_TOOL(objcopy, OBJCOPY_FOR_TARGET, OBJCOPY, >[binutils/objcopy]) >GCC_TARGET_TOOL(objdump, OBJDUMP_FOR_TARGET, OBJDUMP, >[binutils/objdump]) > GCC_TARGET_TOOL(otool, OTOOL_FOR_TARGET, OTOOL) >-GCC_TARGET_TOOL(ranlib, RANLIB_FOR_TARGET, RANLIB, [binutils/ranlib]) >+GCC_TARGET_TOOL(ranlib, RANLIB_FOR_TARGET, RANLIB, >+ [gcc/gcc-ranlib -B$$r/$(HOST_SUBDIR)/gcc/]) >GCC_TARGET_TOOL(readelf, READELF_FOR_TARGET, READELF, >[binutils/readelf]) > GCC_TARGET_TOOL(strip, STRIP_FOR_TARGET, STRIP, [binutils/strip-new]) >GCC_TARGET_TOOL(windres, WINDRES_FOR_TARGET, WINDRES, >[binutils/windres])
Re: Fix output_constructor_bitfield handling of wide bitfields (PR89037)
On January 25, 2019 1:12:07 PM GMT+01:00, Richard Sandiford
wrote:
>The testcase was failing because we were trying to access
>TREE_INT_CST_ELT (x, 1) of a 128-bit integer that was small enough
>to need only a single element.
>
>Tested on aarch64-linux-gnu, aarch64_be-elf and x86_64-linux-gnu.
>OK to install?
OK..
Richard.
>Richard
>
>
>2019-01-25 Richard Sandiford
>
>gcc/
> PR middle-end/89037
> * varasm.c (output_constructor_bitfield): Use wi::extract_uhwi
> instead of accessing TREE_INT_CST_ELT directly.
>
>gcc/testsuite/
> PR middle-end/89037
> * gcc.dg/pr89037.c: New test.
>
>Index: gcc/varasm.c
>===
>--- gcc/varasm.c 2019-01-04 11:39:27.182246717 +
>+++ gcc/varasm.c 2019-01-25 12:10:23.969006336 +
>@@ -5349,7 +5349,7 @@ output_constructor_bitfield (oc_local_st
> {
> int this_time;
> int shift;
>- HOST_WIDE_INT value;
>+ unsigned HOST_WIDE_INT value;
> HOST_WIDE_INT next_byte = next_offset / BITS_PER_UNIT;
> HOST_WIDE_INT next_bit = next_offset % BITS_PER_UNIT;
>
>@@ -5381,15 +5381,13 @@ output_constructor_bitfield (oc_local_st
> this_time = end - shift + 1;
> }
>
>-/* Now get the bits from the appropriate constant word. */
>-value = TREE_INT_CST_ELT (local->val, shift /
>HOST_BITS_PER_WIDE_INT);
>-shift = shift & (HOST_BITS_PER_WIDE_INT - 1);
>+/* Now get the bits we want to insert. */
>+value = wi::extract_uhwi (wi::to_widest (local->val),
>+ shift, this_time);
>
> /* Get the result. This works only when:
>1 <= this_time <= HOST_BITS_PER_WIDE_INT. */
>-local->byte |= (((value >> shift)
>- & (((HOST_WIDE_INT) 2 << (this_time - 1)) - 1))
>-<< (BITS_PER_UNIT - this_time - next_bit));
>+local->byte |= value << (BITS_PER_UNIT - this_time - next_bit);
> }
> else
> {
>@@ -5406,15 +5404,13 @@ output_constructor_bitfield (oc_local_st
> this_time
> = HOST_BITS_PER_WIDE_INT - (shift & (HOST_BITS_PER_WIDE_INT -
>1));
>
>-/* Now get the bits from the appropriate constant word. */
>-value = TREE_INT_CST_ELT (local->val, shift /
>HOST_BITS_PER_WIDE_INT);
>-shift = shift & (HOST_BITS_PER_WIDE_INT - 1);
>+/* Now get the bits we want to insert. */
>+value = wi::extract_uhwi (wi::to_widest (local->val),
>+ shift, this_time);
>
> /* Get the result. This works only when:
>1 <= this_time <= HOST_BITS_PER_WIDE_INT. */
>-local->byte |= (((value >> shift)
>- & (((HOST_WIDE_INT) 2 << (this_time - 1)) - 1))
>-<< next_bit);
>+local->byte |= value << next_bit;
> }
>
> next_offset += this_time;
>Index: gcc/testsuite/gcc.dg/pr89037.c
>===
>--- /dev/null 2019-01-24 08:42:49.147091464 +
>+++ gcc/testsuite/gcc.dg/pr89037.c 2019-01-25 12:10:23.965006370 +
>@@ -0,0 +1,24 @@
>+/* { dg-do run { target int128 } } */
>+/* { dg-options "" } */
>+
>+struct s
>+{
>+ __int128 y : 66;
>+};
>+typedef struct s T;
>+T a[] = { 1, 1, 0x12345, 0xff01, 1ULL << 63, (__int128) 1 <<
>64,
>+((__int128) 1 << 64) | 1 };
>+
>+int
>+main (void)
>+{
>+ if (a[0].y != 1
>+ || a[1].y != 1
>+ || a[2].y != 0x12345
>+ || a[3].y != 0xff01
>+ || a[4].y != (1ULL << 63)
>+ || a[5].y != ((__int128) 1 << 64)
>+ || a[6].y != (((__int128) 1 << 64) | 1))
>+__builtin_abort ();
>+ return 0;
>+}
[Bug c++/89036] [8/9 Regression] ICE if destructor has a requires
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89036 --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01513.html
[PATCH] C++ concepts: fix ICE with requires on dtors (PR c++/89036)
PR c++/89036 reports an ICE due to this assertion failing
1136 /* A class should never have more than one destructor. */
1137 gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
on this template with a pair of dtors, with
mutually exclusive "requires" clauses:
template
struct Y {
~Y() requires(true) = default;
~Y() requires(false) {}
};
(is this valid? my knowledge of this part of C++ is fairly hazy)
Nathan introduced this assertion as part of:
ca9219bf18c68a001d62ecb981bc9176b0feaf12 (aka r251340):
2017-08-24 Nathan Sidwell
Conversion operators kept on single overload set
which, amongst other changes to add_method had this:
/* A class should never have more than one destructor. */
- if (current_fns && DECL_MAYBE_IN_CHARGE_DESTRUCTOR_P (method))
-return false;
+ gcc_assert (!current_fns || !DECL_DESTRUCTOR_P (method));
The following patch generalizes the assertion to allow for multiple
dtors if they have "requires" clauses. (I already generalized
the assertion in another way in r268041 to fix PR c++/88699;
alternatively, is this too much like whack-a-mole, and would
dropping the assertion altogether be better?)
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/cp/ChangeLog:
PR c++/89036
* class.c (add_method): Generalize assertion to allow for
multiple dtors if they have "requires" clauses.
gcc/testsuite/ChangeLog:
PR c++/89036
* g++.dg/concepts/pr89036.C: New test.
---
gcc/cp/class.c | 11 +--
gcc/testsuite/g++.dg/concepts/pr89036.C | 8
2 files changed, 17 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/concepts/pr89036.C
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index e8773c2..fb46f92 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1133,8 +1133,15 @@ add_method (tree type, tree method, bool via_using)
}
}
- /* A class should never have more than one destructor. */
- gcc_assert (!current_fns || via_using || !DECL_DESTRUCTOR_P (method));
+ /* A class should never have more than one destructor... */
+ gcc_assert (!current_fns
+ || via_using
+ || !DECL_DESTRUCTOR_P (method)
+ /* ...unless the destructors are constrained by "requires"
+clauses. */
+ || (flag_concepts
+ && get_constraints (method)
+ && CI_DECLARATOR_REQS (get_constraints (method;
current_fns = ovl_insert (method, current_fns, via_using);
diff --git a/gcc/testsuite/g++.dg/concepts/pr89036.C
b/gcc/testsuite/g++.dg/concepts/pr89036.C
new file mode 100644
index 000..f83ef8b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/pr89036.C
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++11 } }
+// { dg-options "-fconcepts" }
+
+template
+struct Y {
+ ~Y() requires(true) = default;
+ ~Y() requires(false) {}
+};
--
1.8.5.3
[Bug c++/59813] tail-call elimination didn't fire for left-shift of char to cout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 Jakub Jelinek changed: What|Removed |Added CC||vanyacpp at gmail dot com --- Comment #7 from Jakub Jelinek --- *** Bug 77938 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/77938] missing tailcall optimization in case when local variable escapes that goes out of scope before the possible tail call site
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77938 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #6 from Jakub Jelinek --- Let's track all of this in one PR. *** This bug has been marked as a duplicate of bug 59813 ***
[Bug c++/59813] tail-call elimination didn't fire for left-shift of char to cout
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59813 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- *** Bug 89060 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 59813 ***
[Bug rtl-optimization/87639] GCC fails to consider end of automatic object lifetime when determining sibcall eligibility
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87639 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Jakub Jelinek --- . *** This bug has been marked as a duplicate of bug 89060 ***
[Bug tree-optimization/89060] Improve tail call optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89060 Jakub Jelinek changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #5 from Jakub Jelinek --- *** Bug 87639 has been marked as a duplicate of this bug. ***
[Bug fortran/80708] [f08] ALLOCATE with MOLD error if source-expr is a derived type with null-init pointer component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80708 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #2 from Vladimir Fuka --- Here https://stackoverflow.com/questions/54356803/can-gfortran-allocate-with-mold-or-not/54368355#54368355 the error appears for an allocatable component. Does not have to be an array. I can also confirm the same for an initialized pointer component.
RFA: PATCH to gimple-fold.c for c++/80916, bogus "static but not defined" warning
Here we warn because i::dispatch has internal linkage (because l
does) and is never instantiated (because the vtable is never emitted).
The regression happened because devirtualization started adding it to
cgraph as a possible target. I think the way to fix this is to avoid
adding an undefined internal function to cgraph as a possible target,
since it is not, in fact, possible for it to be the actual target.
I think that the best place to fix this would be in
can_refer_decl_in_current_unit_p, since the same reasoning applies to
other possible references. But we could fix it only in
gimple_get_virt_method_for_vtable.
First patch tested x86_64-pc-linux-gnu.
commit 3a02b58301c2c11620c2adc1aee4db1b7e8e36f2
Author: Jason Merrill
Date: Fri Jan 25 09:09:17 2019 -0500
PR c++/80916 - spurious "static but not defined" warning.
* gimple-fold.c (can_refer_decl_in_current_unit_p): Return false
for an internal function with no definition.
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 92d3fb4a9e0..20564e26de1 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -135,6 +135,12 @@ can_refer_decl_in_current_unit_p (tree decl, tree from_decl)
return !node || !node->global.inlined_to;
}
+ /* This function is internal and not defined, so nothing can refer to it. */
+ if (!TREE_PUBLIC (decl) && DECL_EXTERNAL (decl)
+ && TREE_CODE (decl) == FUNCTION_DECL
+ && DECL_INITIAL (decl) == NULL_TREE)
+return false;
+
/* We will later output the initializer, so we can refer to it.
So we are concerned only when DECL comes from initializer of
external var or var that has been optimized out. */
diff --git a/gcc/testsuite/g++.dg/warn/unused-fn1.C b/gcc/testsuite/g++.dg/warn/unused-fn1.C
new file mode 100644
index 000..aabc01b3f44
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/unused-fn1.C
@@ -0,0 +1,16 @@
+// PR c++/80916
+// { dg-options "-Os -Wunused" }
+
+struct j {
+ virtual void dispatch(void *) {}
+};
+template
+struct i : j {
+ void dispatch(void *) {} // warning: 'void i< >::dispatch(void*) [with = {anonymous}::l]' declared 'static' but never defined [-Wunused-function]
+};
+namespace {
+ struct l : i {};
+}
+void f(j *k) {
+ k->dispatch(0);
+}
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 92d3fb4a9e0..8d63d815a5e 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -7146,7 +7146,10 @@ gimple_get_virt_method_for_vtable (HOST_WIDE_INT token,
devirtualize. This can happen in WHOPR when the actual method
ends up in other partition, because we found devirtualization
possibility too late. */
- if (!can_refer_decl_in_current_unit_p (fn, vtable))
+ if (!can_refer_decl_in_current_unit_p (fn, vtable)
+ || (!TREE_PUBLIC (decl) && DECL_EXTERNAL (decl)
+ && TREE_CODE (decl) == FUNCTION_DECL
+ && DECL_INITIAL (decl) == NULL_TREE))
{
if (can_refer)
{
[Bug tree-optimization/89049] [8/9 Regression] Unexpected vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89049 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #8 from Segher Boessenkool --- (In reply to Richard Biener from comment #5) > So combine can see [ snip, 11 ] > with its uses [ snip, 13 and 25 ] > but somehow it only tries 11 -> 13: combine only tries to combine something with its first use. Trying second (or third, etc.) uses as well would easily take exponential time complexity. I do however want combine to try to combine an insn together with its first two uses. That is just as linear as even simple 1+1 combinations, and it is likely to succeed (in fact there is at least one other PR where I wanted this).
