On Wed, Oct 6, 2021 at 12:38 AM Indu Bhagat via Gcc-patches
wrote:
>
> Hello,
>
> This patch fixes an outstanding issue with memory cleanup in the CTF
> container.
> Earlier the two hash tables in the CTF container were not cleaned up in
> ctfc_delete_container (). With this patch, we first free
[Andrew, ranger comment embedded below.]
On 10/7/21 1:06 AM, Jeff Law wrote:
On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...every single change to the threading code shines the
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
On 9/20/21 11:24, Stefan Schulze Frielinghaus wrote:
> This patch implements the rawmemchr expander as introduced in
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579649.html
>
> Bootstrapped and regtested in conjunction with the patch from above on
> IBM Z. Ok for mainline?
>
> Fr
On Thu, Oct 7, 2021 at 2:09 AM Kito Cheng wrote:
>
> __builtin___clear_cache was able to accept constant address for the
> argument, but it seems no longer accept recently, and it even not
> accept constant address which is hold in variable when optimization is
> enable:
>
> ```
> void foo3(){
>
On 10/5/21 20:44, Jason Merrill wrote:
That is the usual approach, yes. I was giving up on that, but perhaps it's
better to stick with it. Martin, want to make that fix for
save_opt_decoded_options?
Yes, I'm going to install the following patch once it survives regression tests
and bootstra
I've committed this patch to allow GCC to adapt to the different
variants of the LLVM amdgcn assembler. Unfortunately they keep making
changes without maintaining backwards compatibility.
GCC should now work with LLVM 9, LLVM 12, and LLVM 13 in terms of CLI
usage, however only LLVM 9 is well t
I've committed this patch to implement the -msram-ecc=any feature that
has been stubbed out awaiting LLVM support for a while now.
When the LLVM assembler supports the "any" feature (v13+) GCC will now
make use of it. Otherwise, GCC will continue to treat "any" the same as
"on".
Using the "a
I've committed this patch to fix another case of LLVM assembler
incompatibility. Marcel previously posted a patch to fix up the
global_load and global_store instructions, following a
non-backwards-compatible change in the assembler.
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572987.ht
Also updated my email address to the one I actually use for gcc, which
unfortunately is not the same as the one I use for glibc. Oh well...
ChangeLog:
* MAINTAINERS: Add myself to DCO section and update email
address.
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 d
This makes VN not CSE .DEFERRED_INIT which confuses uninit
analysis which reports the wrong decl when facing copies
of not initialized data.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-10-07 Richard Biener
PR tree-optimization/102608
* tree-ssa-sccvn.c (v
On 05/10/2021 14:56, Tamar Christina via Gcc-patches wrote:
-Original Message-
From: Richard Earnshaw
Sent: Tuesday, October 5, 2021 2:52 PM
To: Tamar Christina ; gcc-patches@gcc.gnu.org
Cc: nd ; rguent...@suse.de
Subject: Re: [PATCH]middle-end convert negate + right shift into com
Hi!
I believe we need no changes to the compiler for P2316R2, seems we treat
character literals the same between preprocessor and C++ expressions,
here is a testcase that should verify it.
Tested on x86_64-linux, ok for trunk?
Note, seems the internal charset for GCC can be either UTF-8 or UTF-E
On 10/7/21 09:00, Jakub Jelinek wrote:
Hi!
I believe we need no changes to the compiler for P2316R2, seems we treat
character literals the same between preprocessor and C++ expressions,
here is a testcase that should verify it.
Tested on x86_64-linux, ok for trunk?
Note, seems the internal cha
On Thu, Oct 07, 2021 at 09:12:15AM -0400, Jason Merrill wrote:
> > And another thing, if HOST_CHARSET == HOST_CHARSET_EBCDIC, how does the
> > libcpp/lex.c
> > static const cppchar_t utf8_signifier = 0xC0;
> > ...
> >if (*buffer->cur >= utf8_signifier)
> > {
> >if (_cp
On 10/7/2021 6:26 AM, Richard Biener via Gcc-patches wrote:
This makes VN not CSE .DEFERRED_INIT which confuses uninit
analysis which reports the wrong decl when facing copies
of not initialized data.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-10-07 Richard Biener
Hi,
this patch fixes omitted case in contains_p which later trigger a sanity
check since merging is not symmetric.
Bootstrapped/regtested x86_64-linux, comitted.
Honza
gcc/ChangeLog:
2021-10-07 Jan Hubicka
PR ipa/102581
* ipa-modref-tree.h (modref_access_node::contains_p): H
We're implementing [temp.param]/10 at parse time but not also at
substitution time.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/61355
gcc/cp/ChangeLog:
* pt.c (convert_template_argument): Perform array/function to
pointer conver
On Thu, Oct 7, 2021 at 9:01 AM Jakub Jelinek via Gcc-patches
wrote:
> And another thing, if HOST_CHARSET == HOST_CHARSET_EBCDIC, how does the
> libcpp/lex.c
> static const cppchar_t utf8_signifier = 0xC0;
> ...
> if (*buffer->cur >= utf8_signifier)
> {
> if (_cpp_valid_utf
On 10/7/2021 2:15 AM, Aldy Hernandez wrote:
[Andrew, ranger comment embedded below.]
On 10/7/21 1:06 AM, Jeff Law wrote:
On 10/6/2021 7:47 AM, Aldy Hernandez via Gcc-patches wrote:
The pending patch I have from Richi fixes this. Even so, it's the
uninit code that's confused.
Sigh...ever
Hi all,
this patch add support for "strictly-structured blocks" introduced in OpenMP
5.1,
basically allowing BLOCK constructs to serve as the body for directives:
!$omp target
block
...
end block
[!$omp end target] !! end directive is optional
!$omp parallel
block
...
end block
...
!$omp e
The pdecl and poff arguments were added to allow their use in
compute_objsize in builtins.c. That use has been gone for a while now
since compute_objsize does its own size estimation, so drop these
arguments to simplify code.
gcc/ChangeLog:
* tree-object-size.c (addr_object_size,
On Thu, Oct 07, 2021 at 07:45:04PM +0530, Siddhesh Poyarekar wrote:
> The pdecl and poff arguments were added to allow their use in
> compute_objsize in builtins.c. That use has been gone for a while now
> since compute_objsize does its own size estimation, so drop these
Since r11-1517-g5acc654e3
Hi,
On Wed, Oct 06 2021, Jan Hubicka wrote:
>> Recursive call graph edges, even when they are hot and important for
>> the compiled program, can never have frequency bigger than one, even
>> when the actual time savings in the next recursion call are not
>> realized just once but depend on the dep
On Wed, 6 Oct 2021, Jason Merrill wrote:
> On 10/6/21 15:52, Patrick Palka wrote:
> > On Wed, 6 Oct 2021, Patrick Palka wrote:
> >
> > > On Tue, 5 Oct 2021, Jason Merrill wrote:
> > >
> > > > On 10/5/21 15:17, Patrick Palka wrote:
> > > > > On Mon, 4 Oct 2021, Patrick Palka wrote:
> > > > >
> >
> Hi,
> >
> > If you boost every self fed value by factor of 6, I wonder how quickly
> > we run into exponential explosion of the cost (since the frequency
> > should be close to 1 and 6^9=10077696
>
> The factor of six is applied once for an entire SCC, so we'd reach this
> huge number only i
Hi Sandra,
On 06.10.21 23:37, Sandra Loosemore wrote:
This patch is for PR fortran/54753, to add a diagnostic for violations
of this constraint in the 2018 standard:
C839 If an assumed-size or nonallocatable nonpointer assumed-rank
array is an actual argument that corresponds to a dummy arg
Hello.
The patch is approved, are you planning committing the changes?
Thanks,
Martin
On Thu, Oct 7, 2021 at 8:35 AM Martin Liška wrote:
>
> Hello.
>
> The patch is approved, are you planning committing the changes?
>
> Thanks,
> Martin
Hongtao is on holiday. He will be back later today.
--
H.J.
Hi Chung-Lin,
On 07.10.21 15:59, Chung-Lin Tang wrote:
this patch add support for "strictly-structured blocks" introduced in
OpenMP 5.1,
basically allowing BLOCK constructs to serve as the body for directives:
!$omp target
block
...
end block
[!$omp end target] !! end directive is optional
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
Hi Andrew:
> Seems like this error should be an gcc_assert at this point. The
> error message should have come from expand_builtin___clear_cache
> already.
Actually it will emit errors here, so put gcc_assert will cause ICE :p
> And the check for VOIDmode should really be a check for CONST_INT.
On 10/7/21 11:17, Patrick Palka wrote:
On Wed, 6 Oct 2021, Jason Merrill wrote:
On 10/6/21 15:52, Patrick Palka wrote:
On Wed, 6 Oct 2021, Patrick Palka wrote:
On Tue, 5 Oct 2021, Jason Merrill wrote:
On 10/5/21 15:17, Patrick Palka wrote:
On Mon, 4 Oct 2021, Patrick Palka wrote:
When p
On 10/7/21 09:31, Patrick Palka wrote:
We're implementing [temp.param]/10 at parse time but not also at
substitution time.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
PR c++/61355
gcc/cp/ChangeLog:
* pt.c (convert_template_argument):
On Thu, Oct 07, 2021 at 09:59:00PM +0800, Chung-Lin Tang wrote:
> this patch add support for "strictly-structured blocks" introduced in OpenMP
> 5.1,
> basically allowing BLOCK constructs to serve as the body for directives:
>
> !$omp target
> block
> ...
> end block
> [!$omp end target] !! en
libstdc++-v3/ChangeLog:
PR libstdc++/102377
* include/bits/atomic_wait.h (__waiter_pool_base:_S_align):
Hardcode to 64 instead of using non-constant constant.
Tested x86_64-linux. Committed to trunk.
commit 0e90799071ee78f712f3b58fca7000bc0a258ade
Author: Jonathan Wakely
On Tue, 2021-10-05 at 21:49 -0400, Eric Gallager wrote:
> On Tue, Oct 5, 2021 at 1:28 PM Luís Ferreira
> wrote:
> >
> > On Tue, 2021-10-05 at 09:00 -0600, Jeff Law wrote:
> > >
> > >
> > > On 10/4/2021 10:52 AM, Luís Ferreira wrote:
> > > > On Thu, 2021-09-23 at 09:50 -0600, Jeff Law wrote:
> >
On Linux/x86_64,
555fa3545efe23393ff21fe0928aa3942e1b90ed is the first bad commit
commit 555fa3545efe23393ff21fe0928aa3942e1b90ed
Author: Roger Sayle
Date: Thu Oct 7 15:42:09 2021 +0100
Introduce smul_highpart and umul_highpart RTX for high-part multiplications
caused
FAIL: gcc.target/i3
Document the new __regio_symbol variable qualifier for PRU target.
Pushed.
Signed-off-by: Dimitar Dimitrov
---
htdocs/gcc-12/changes.html | 9 +
1 file changed, 9 insertions(+)
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 4f7bbd33..22839f2d 100644
--- a/ht
This moves the "classic" contents of to a new header, so that
, etc. can get use durations and clocks without
calendar types, time zones, and chrono I/O.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/std/chron
On 10/3/21 07:14, Nick Huang wrote:
I made a little improvement of my fix by including template
type parameter to not dropping cv-const because they are similar to dependent
type which you cannot determine whether they are top-level cv-qualifier or not
until instantiation.
+ if (processi
On Thu, Oct 7, 2021 at 9:47 AM Kito Cheng wrote:
>
> Hi Andrew:
>
> > Seems like this error should be an gcc_assert at this point. The
> > error message should have come from expand_builtin___clear_cache
> > already.
>
> Actually it will emit errors here, so put gcc_assert will cause ICE :p
The
On Wed, 6 Oct 2021, H.J. Lu via Gcc-patches wrote:
> I am checking in these patches to merge with upstream commit:
Thus breaking bootstrap on FreeBSD:
GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:370:36:
error: 'MD5_CTX' was not declared in this scope
370 | cons
On Thu, Oct 7, 2021 at 2:41 PM Gerald Pfeifer wrote:
>
> On Wed, 6 Oct 2021, H.J. Lu via Gcc-patches wrote:
> > I am checking in these patches to merge with upstream commit:
>
> Thus breaking bootstrap on FreeBSD:
>
> GCC-HEAD/libsanitizer/sanitizer_common/sanitizer_platform_limits_freebsd.cpp:370
This patchset implements the __builtin_dynamic_object_size builtin for
gcc. The primary motivation to have this builtin in gcc is to enable
_FORTIFY_SOURCE=3 support with gcc, thus allowing greater fortification
in use cases where the potential performance tradeoff is acceptable.
Semantics:
-
Recognize the __builtin_dynamic_object_size builtin, but simply
replace it with -1 or 0 for now.
gcc/ChangeLog:
* builtins.c (expand_builtin, fold_builtin_2): Add
BUILT_IN_DYN_OBJECT_SIZE.
(fold_builtin_dyn_object_size): New function.
(valid_object_size_args): New
A new pass is added to execute just before the tree-object-size pass
to recognize and simplify __builtin_dynamic_object_size. Some key
ideas (such as multipass object size collection to detect reference
loops) have been taken from tree-object-size but is distinct from it
to ensure minimal impact o
Where the target object is a PHI node, set the size to be a PHI node
with sizes of the target object. All object size information is now
split into an SSA name and its size expression. This allows non-SSA
size expressions to be evaluated all at once in the end and generated
statements inserted in
Follow assignment operations and pointer-plus operations to get the
effective object size. Unlike tree-object-size, this pass handles
negative offsets correctly and returns a size within the bounds of the
parent object; offsets > SIZE_MAX / 2 are considered negative to
emulate ssize_t.
To make ne
This is the beginnings of support for ADDR_EXPR objects and is partly
based on the implementation in tree-object-size, splitting out
functions for readability.
One key difference from constant-size ADDR_EXPR computation is the
computation of residual sizes based on offset. This pass attempts to
c
Handle either static sizes in function parameters or hints provided by
__attribute__ ((access (...))) to compute sizes for objects.
gcc/ChangeLog:
* tree-dynamic-object-size.c: Include tree-dfa.h.
(emit_size_stmts): New argument osi. Handle GIMPLE_NOP.
(eval_size_expr, gi
Adapt subobject computation logic from tree-object-size to make it
work with variable sizes.
gcc/ChangeLog:
* tree-dynamic-object-size.c (build_cond_branch): New function.
(compute_object_offset): Use it.
(get_closest_subobject): New function.
(addr_dyn_object_size
Wrap most tests for __builtin_object_size with
__builtin_dynamic_object_size to get better coverage. At the moment
only one test does not work correctly with
__builtin_dynamic_object_size, viz. builtin-object-size-5.c. The test
expects abort() calls to be optimized away, which does not happen wit
Hi!
On Mon, Aug 23, 2021 at 02:03:04PM -0500, Paul A. Clarke wrote:
> v3: Add "nmmintrin.h". _mm_cmpgt_epi64 is part of SSE4.2
There should not be a "v3" in the commit message. The easy way to
achieve this is put it inside the [] in the subject (as you did), and to
mention the version history af
On Mon, Aug 30, 2021 at 04:16:43PM -0500, Paul A. Clarke wrote:
> The confusing thing is that _builtin_mffsl is explicitly supported on earlier
> processors, if I read the code right (from gcc/config/rs6000/rs6000.md):
Yes. It is very simple to implement everywhere, not significantly
slower than
On Mon, Aug 23, 2021 at 02:03:05PM -0500, Paul A. Clarke wrote:
> No attempt is made to optimize writing the FPSCR (by checking if the new
> value would be the same), other than using lighter weight instructions
> when possible.
__builtin_set_fpscr_rn makes optimised code (using mtfsb[01])
automat
On Mon, 16 Aug 2021, Dragan Mladjenovic via Gcc-patches wrote:
> I'll respin the tests for mips64r2 and mips64 just in case.
>
> This check would fail for -mips64. GAS accepts jr.hb for both '.set mips64'
> and
> '.set mips64r2' and '.set mips32' for that matter. mips-opc.c has the
> following
On Thu, Oct 07, 2021 at 05:25:54PM -0500, Segher Boessenkool wrote:
> On Mon, Aug 23, 2021 at 02:03:04PM -0500, Paul A. Clarke wrote:
> > v3: Add "nmmintrin.h". _mm_cmpgt_epi64 is part of SSE4.2
>
> There should not be a "v3" in the commit message. The easy way to
> achieve this is put it inside
On Thu, Oct 07, 2021 at 06:39:06PM -0500, Segher Boessenkool wrote:
> On Mon, Aug 23, 2021 at 02:03:05PM -0500, Paul A. Clarke wrote:
> > No attempt is made to optimize writing the FPSCR (by checking if the new
> > value would be the same), other than using lighter weight instructions
> > when poss
Ping, thanks.
On 2021/9/17 13:25, Xionghu Luo wrote:
> These two patches are updated version from:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579490.html
>
> Changes:
> 1. Fix alignment error in md files.
> 2. Replace rtx_equal_p with match_dup.
> 3. Use register_operand instead
On Fri, Oct 1, 2021 at 6:13 PM Gerald Pfeifer wrote:
>
> On Fri, 24 Sep 2021, Hongtao Liu via Gcc-patches wrote:
> > + New ISA extension support for Intel AVX512-FP16 was added to GCC.
> > + AVX512FP16 intrinsics are available [...]
>
> So, is it AVX512-FP16 or AVX512FP16?
Sorry for the conf
Hi Andrew:
> The error message would have been emitted from
> expand_builtin___clear_cache and maybe_emit_call_builtin___clear_cache
> would not have been called from user code.
> All other uses of maybe_emit_call_builtin___clear_cache are internal
> to gcc and should have the correct mode so ass
On Thu, Oct 7, 2021 at 11:38 PM H.J. Lu via Gcc-patches
wrote:
>
> On Thu, Oct 7, 2021 at 8:35 AM Martin Liška wrote:
> >
> > Hello.
> >
> > The patch is approved, are you planning committing the changes?
Committed.
> >
> > Thanks,
> > Martin
>
> Hongtao is on holiday. He will be back later toda
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
This libgcc patch changes the morestack support to use the
.init_array. section for the constructor rather than the
.ctors.65535 section, if the target supports .init_array. This should
avoid pointless mixing .ctors and .init_array. Bootstrapped and ran
Go and split-stack tests on x86_64-pc-l
On 10/8/21 03:44, Siddhesh Poyarekar wrote:
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 133b82eef38..082d167cd65 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12777,6 +12777,17 @@ assert (__builtin_object_size (q, 1) == sizeof
(var.b));
@end smallexample
@en
This "announce_function" is not a purely readonly
function. Instead it calls tsubst which modifies
global variable "current_function_decl". If it is
placed at parser code directory level, recursion
might happen and set/reset variable might interleave
and can cause ICE. No test case is provided beca
I merged trunk revision f49e3d28be44179f07b8a06159139ce77096dda7 to
the gccgo branch.
Ian
This "announce_function" is not a purely readonly
function. Instead it calls tsubst which modifies
global variable "current_function_decl". If it is
placed at parser code directory level, recursion
might happen and set/reset variable might interleave
and can cause ICE. No test case is provided beca
I am terribly sorry for my typo of wrong PR #, it should be 102624.
Please ignore this email thread and I resend the patch in next email
with correct subject:
[PATCH] c++: Comment out announce_function to prevent ICE [PR102624]
Once again my apologies for spam.
On Fri, Oct 8, 2021 at 12:31 AM qin
On 10/8/21 03:44, Siddhesh Poyarekar wrote:
(from about 4% to 70% in bash), but that could well be due to the _chk
I should also clarify that this is for memcpy. For all fortifiable
functions, the coverage percentage went from 30.81% to 84.5% for bash.
Below is the full table. Please note t
On Thu, Oct 7, 2021 at 6:45 PM Kito Cheng wrote:
>
> __builtin___clear_cache was able to accept constant address for the
> argument, but it seems no longer accept recently, and it even not
> accept constant address which is hold in variable when optimization is
> enable:
>
> ```
> void foo3(){
>
On Fri, Oct 8, 2021 at 4:40 AM Kito Cheng wrote:
>
> __builtin___clear_cache was able to accept constant address for the
> argument, but it seems no longer accept recently, and it even not
> accept constant address which is hold in variable when optimization is
> enable:
>
> ```
> void foo3(){
>
73 matches
Mail list logo
