Hi,
I forgot that IPA passes before ipa-inline must not return
TODO_cleanup_cfg from their transformation function because ordinary
CFG cleanup does not remove call graph edges associated with removed
call statements but must use
delete_unreachable_blocks_update_callgraph instead. This patch fixe
On Fri, 26 Nov 2021 at 12:43, Jonathan Wakely wrote:
>
> On Fri, 26 Nov 2021 at 12:39, Jakub Jelinek wrote:
> >
> > On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches
> > wrote:
> > > + // Internal version of std::is_constant_evaluated() for C++11.
> > > + // This can be u
Tested x86_64-linux, pushed to trunk.
This test was written to verify that the LWG 3265 changes work. But
those changes were superseded by LWG 3435, and the test is now incorrect
according to the current draft. The assignment operator is now
constrained to also require convertibility, which makes
Tested x86_64-linux, pushed to trunk.
When implementing constexpr std::vector I added a check for constant
evaluation in vector::_S_use_relocate(), so that we would not try to relocate
trivial objects by using memmove. But I put it in the constexpr function
that decides whether to relocate or not
Tested x86_64-linux, pushed to trunk.
The FE bug was fixed, so we don't need this workaround now.
libstdc++-v3/ChangeLog:
PR libstdc++/96592
* include/std/tuple (tuple::is_constructible): Remove.
---
libstdc++-v3/include/std/tuple | 4
1 file changed, 4 deletions(-)
diff
Le 26/11/2021 à 21:07, Harald Anlauf a écrit :
That should hopefully be the final version...
Yes it is OK. Thanks for your patience.
Mikael
On Linux/x86_64,
b41be002eda047093bbf4757cb65ffb4d525cc35 is the first bad commit
commit b41be002eda047093bbf4757cb65ffb4d525cc35
Author: Roger Sayle
Date: Fri Nov 26 17:22:10 2021 +
ivopts: Improve code generated for very simple loops.
caused
FAIL: gcc.dg/tree-ssa/ivopts-8.c scan-tr
Hi Mikael,
> Gesendet: Freitag, 26. November 2021 um 15:45 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , fort...@gcc.gnu.org
> Cc: gcc-patches@gcc.gnu.org
> Betreff: Re: [PATCH, v2] PR fortran/103411 - ICE in
> gfc_conv_array_initializer, at fortran/trans-array.c:6377
>
> Le 25/11/2021 à 22:
Hi!
On Tue, Nov 23, 2021 at 12:40:45PM -0600, Bill Schmidt wrote:
> When a built-in function required by an overloaded function name is not
> currently enabled, the diagnostic message is not as clear as it should be.
> Saying that one built-in "requires" another is somewhat misleading. It
On Fri, 26 Nov 2021, Gerald Pfeifer wrote:
> I have received a report of GCC builds now failing on FreeBSD/i386:
Ah, and here are the logs (IPv6 required, unfortunately):
Log URL:
http://beefy5.nyi.freebsd.org/data/122i386-default/9e1bda400030/logs/gcc12-devel-12.0.0.s20211121.log
Build URL:
http
Recent improvements to null address warnings notice that for
targets that do not support HAVE_ELF_STYLE_WEAKREF the dummy stub
implementation of __cxa_get_globals() means that the address can
never be null.
Fixed by removing the test for such targets.
tested on i686, x86_64, powerpc-darwin and x8
On 11/26/21 23:34, Jakub Jelinek wrote:
On Fri, Nov 26, 2021 at 11:29:41PM +0530, Siddhesh Poyarekar wrote:
The trees in object_sizes are each a TREE_VEC with the first element
being the bytes from the pointer to the end of the object and the
second, the size of the whole object. This allows an
On Fri, Nov 26, 2021 at 11:29:41PM +0530, Siddhesh Poyarekar wrote:
> > > The trees in object_sizes are each a TREE_VEC with the first element
> > > being the bytes from the pointer to the end of the object and the
> > > second, the size of the whole object. This allows analysis of negative
> > >
On Fri, 19 Nov 2021, David Malcolm via Gcc-patches wrote:
> On Mon, 2021-09-27 at 20:53 -0400, Antoni Boucher wrote:
>> I fixed an issue (it would show an error message when
>> gcc_jit_type_dyncast_function_ptr_type was called on a type different
>> than a function pointer type).
> The updated patc
On Fri, Nov 26, 2021 at 11:23:31PM +0530, Siddhesh Poyarekar wrote:
> On 11/26/21 22:16, Jakub Jelinek wrote:
> > On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
> > > A simple cleanup to allow inserting dynamic size code more easily.
> > >
> > > gcc/ChangeLog:
> > >
> > > *
On 11/26/21 22:26, Jakub Jelinek wrote:
On Fri, Nov 26, 2021 at 10:58:46AM +0530, Siddhesh Poyarekar wrote:
Transform tree-object-size to operate on tree objects instead of host
wide integers. This makes it easier to extend to dynamic expressions
for object sizes.
The compute_builtin_object_si
On 11/26/21 22:16, Jakub Jelinek wrote:
On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
A simple cleanup to allow inserting dynamic size code more easily.
gcc/ChangeLog:
* tree-object-size.c: New enum.
(object_sizes, computed, addr_object_size,
compu
Hi!
On Tue, Nov 23, 2021 at 01:14:05PM -0600, Bill Schmidt wrote:
> Paul Clarke pointed out to me that I had wrongly used a compile-time check
> instead of a run-time check in this executable test. This patch fixes
> that. I also fixed a typo in a string that caught my eye.
>
> Tested on powerp
From: Sören Tempel
The stddef.h header checks/sets various hardcoded toolchain/os specific
macro guards to prevent redefining types such as ptrdiff_t, wchar_t, or
size_t. However, without this patch, the file does not check/set the
typedef macro guards for musl libc. This causes types such as siz
On Fri, Nov 26, 2021 at 10:58:46AM +0530, Siddhesh Poyarekar wrote:
> Transform tree-object-size to operate on tree objects instead of host
> wide integers. This makes it easier to extend to dynamic expressions
> for object sizes.
>
> The compute_builtin_object_size interface also now returns a t
On Fri, Nov 26, 2021 at 10:58:45AM +0530, Siddhesh Poyarekar wrote:
> Put all accesses to object_sizes behind functions so that we can add
> dynamic capability more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c (object_sizes_grow, object_sizes_release,
> object_sizes_unknown_p,
On Fri, Nov 26, 2021 at 10:58:44AM +0530, Siddhesh Poyarekar wrote:
> A simple cleanup to allow inserting dynamic size code more easily.
>
> gcc/ChangeLog:
>
> * tree-object-size.c: New enum.
> (object_sizes, computed, addr_object_size,
> compute_builtin_object_size, expr_object
Hi!
On Thu, Nov 25, 2021 at 11:20:57AM +0800, Kewen.Lin wrote:
> This patch is to add a test case similar to the one in i386
> to add testing coverage for 510.parest_r hotspots.
> gcc/testsuite/ChangeLog:
> * gcc.target/powerpc/vect-gather-1.c: New test.
This is okay for trunk. Thanks!
* Jakub Jelinek:
> On Thu, Nov 25, 2021 at 09:35:14PM +0100, Florian Weimer wrote:
>> +struct dl_find_object
>> +{
>> + unsigned long long int dlfo_flags;/* Currently 0. */
>> + void *dlfo_map_start; /* Beginning of mapping containing
>> address. */
>> + void *dlfo_map_end
On Thu, Nov 25, 2021 at 09:42:53PM +0100, Florian Weimer wrote:
> I've included a simplified version below, based on the _dl_find_object
> patch for glibc.
>
> This is a bit difficult to test, but I ran a full toolchain bootstrap
> with GCC + glibc on all glibc-supported architectures (except Hurd
On Thu, Nov 25, 2021 at 09:35:14PM +0100, Florian Weimer wrote:
> +struct dl_find_object
> +{
> + unsigned long long int dlfo_flags; /* Currently 0. */
> + void *dlfo_map_start; /* Beginning of mapping containing
> address. */
> + void *dlfo_map_end;/* End of mappi
Restore status-quo how function template specializations were diagnosed.
Signed-off-by: Matthias Kretz
gcc/testsuite/ChangeLog:
* g++.dg/diagnostic/default-template-args-1.C: Adjust for
different presentation of function template specializations.
* g++.dg/ext/pretty1.C
The choice when to print a function template parameter was still
suboptimal. That's because sometimes the function template parameter
list only adds noise, while in other situations the lack of a function
template parameter list makes diagnostic messages hard to understand.
The general idea of th
On Friday, 19 November 2021 23:26:57 CET Jason Merrill wrote:
> On 11/19/21 04:53, Matthias Kretz wrote:
> > On Thursday, 18 November 2021 20:24:36 CET Jason Merrill wrote:
> >> On 11/17/21 17:51, Matthias Kretz wrote:
> > __FUNCTION__ was 'fun' all the time, but __PRETTY_FUNCTION__ was
> >
Tested x86_64-linux, pushed to trunk.
This is what the docs say is required.
libstdc++-v3/ChangeLog:
* testsuite/29_atomics/atomic_float/1.cc: Reorder directives.
---
libstdc++-v3/testsuite/29_atomics/atomic_float/1.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
Tested x86_64-linux, pushed to trunk.
An 'xfail' selector means the test is expected to fail at runtime, so is
ignored for a compile-only test. The way to mark a compile-only test as
failing is with dg-error (which these already do).
libstdc++-v3/ChangeLog:
*
testsuite/21_strings/basic
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/unordered_map/modifiers/move_assign.cc:
Change dg-do compile to run.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/lwg2499.cc:
Likewise.
---
.../23_containers/u
Le 25/11/2021 à 22:52, Harald Anlauf a écrit :
>
> Motivated by your reasoning I tried gfc_reduce_init_expr. That attempt
> failed miserably (many regressions), and I think it is not right.
> Then I found that array sections posed a problem that wasn't detected
> before. gfc_simplify_expr seeme
Hi,
IPA_JF_ANCESTOR jump functions are constructed also when the formal
parameter of the caller is first checked whether it is NULL and left
as it is if it is NULL, to accommodate C++ casts to an ancestor class.
The jump function type was invented for devirtualization and IPA-CP
propagation of tr
Hello Pierre-Marie,
On 11/10/2021 15:39, Pierre-Marie de Rodat via Gcc-patches wrote:
RTEMS supports attaching interrupt handlers to hardware interrupt
vectors, which is superior to the current approach of attaching handlers
to signals. Direct attachment of handlers removes the execution
overhe
On 11/26/21 13:34, Iain Buclaw wrote:
Thanks, looks OK to me, does it need backporting as well?
Yes, I guess so. I'm going to do it.
Martin
Hi,
while working on analyzing the previous miscomple I made dumps easier to
read by dumping cgraph_node name rather then cfun name in function being
analysed and I also fixed minor issue with ECF flags merging when
updating inline summary.
gcc/ChangeLog:
2021-11-26 Jan Hubicka
* ipa-
Hi
update_escape_summary_1 has thinko where it compues proper min_flags but then
stores original value (ignoring the fact whether there was a dereference
in the escape point).
Bootstrapped/regtested and comitted.
PR ipa/103432
* ipa-modref.c (update_escape_summary_1): Fix handling
Tested powerpc64le-linux, pushed to gcc-10.
When I backported r11-2760 as r10-8644 I simplified it and didn't add
the new _GLIBCXX11_DEPRECATED macro. That means that the macro used on
the old iostream members does nothing for C++98 mode, and so the test
fails. This adjusts the test to only expec
Tested powerpc64le-linux, pushed to gcc-10.
The __gnu_debug::array type isn't three-way comparable in constant
expressions. The __gnu-debug::array type has been removed in gcc-11
anyway, so just skip the test rather than fixing it.
libstdc++-v3/ChangeLog:
* testsuite/23_containers/array
Tested powerpc64le-linux, pushed to gcc-10.
When included from it's possible for
to be included without its prerequisites having
been included first. For gcc-11 this was fixed as part of r11-7604, this
fixes it for gcc-10 too.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h: Inc
Excerpts from Iain Sandoe's message of November 19, 2021 10:21 am:
> Hi Iain
>
>> On 19 Nov 2021, at 08:32, Iain Buclaw wrote:
>
>> This patch fixes a stage2 bootstrap failure in the D front-end on
>> darwin due to libgphobos being dynamically linked despite
>> -static-libphobos being on the com
Hi,
it turns out that I made testcase for value range propagation (which was
disabled by accidental return statement) but the testcase was confused
by partial inlininig. The right number of inlines is 2, since the
function in question is first split and then both function and the split
part should
On Fri, Nov 26, 2021 at 12:43:44PM +, Jonathan Wakely wrote:
> > On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches
> > wrote:
> > > + // Internal version of std::is_constant_evaluated() for C++11.
> > > + // This can be used without checking if the compiler supports t
On Fri, 26 Nov 2021 at 12:39, Jakub Jelinek wrote:
>
> On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches
> wrote:
> > + // Internal version of std::is_constant_evaluated() for C++11.
> > + // This can be used without checking if the compiler supports the
> > built-in.
>
Tested x86_64-linux, pushed to trunk.
Some of the checks in 20_util/pointer_traits/lwg3545.cc really belong in
20_util/to_address/lwg3545 instead.
This also fixes the ordering of the dg-options and dg-do directives.
libstdc++-v3/ChangeLog:
* testsuite/20_util/pointer_traits/lwg3545.cc:
On Fri, Nov 26, 2021 at 12:29:25PM +, Jonathan Wakely via Gcc-patches wrote:
> + // Internal version of std::is_constant_evaluated() for C++11.
> + // This can be used without checking if the compiler supports the built-in.
> + constexpr inline bool
> + __is_constant_evaluated() noexcept
>
On Fri, 26 Nov 2021 at 14:29, Jonathan Wakely via Libstdc++
wrote:
>
> I've bored of having to do preprocessor checks before using
> is_constant_evaluated, so I've come up with this approach. Anybody got a
> better idea, or objections to this?
None here, I like this improvement.
Excerpts from Martin Liška's message of November 25, 2021 3:09 pm:
> On 7/30/21 13:01, Iain Buclaw via Gcc-patches wrote:
>> |Covers cases where functions that handle the extracted strings ignore the
>> explicit length. This isn't something that's known to happen in the current
>> front-end, but
Excerpts from Martin Liška's message of November 25, 2021 2:59 pm:
> Fixes:
>
> ==129444==ERROR: AddressSanitizer: global-buffer-overflow on address
> 0x0666ca5c at pc 0x00ef094b bp 0x7fff8180 sp 0x7fff8178
> READ of size 4 at 0x0666ca5c thread T0
> #0 0xef094a in parse_o
I've bored of having to do preprocessor checks before using
is_constant_evaluated, so I've come up with this approach. Anybody got a
better idea, or objections to this?
An alternative to __is_constant_evaluated would be to define a function
called __builtin_is_constant_evaluated when it isn't supp
This implements a subset of -Wunreachable-code, unreachable code
after a return stmt. Contrary to the previous attemt at CFG
construction time this implements the bits during GIMPLE lowering
where there are still all GIMPLE return stmts in the IL.
The lowering phase keeps track of whether stmts c
*PING* -While I am not the patch author, I think it should be fixed. Thus:
Alexander, since you asked for the updated diff and commented, can you
have a look?
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568616.html [PR
target/99555]
Thanks,
Tobias
On 23.04.21 18:48, Tom de Vries wrot
Hi!
stringify_arg uses pfile->u_buff to create the string literal.
Unfortunately, paste_tokens -> _cpp_lex_direct -> lex_number ->
_cpp_unaligned_alloc
can in some cases use pfile->u_buff too, which results in losing everything
prepared for the string literal until the token pasting.
The followi
On Wed, Nov 24, 2021 at 3:32 PM Martin Liška wrote:
>
> On 11/24/21 15:14, Martin Liška wrote:
> > It likely miscompiles gcc.dg/loop-unswitch-5.c, working on that..
>
> Fixed that in the updated version.
Function level comments need updating it seems.
+static unsigned
+evaluate_insns (class loop
55 matches
Mail list logo
