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(){
>
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 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
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
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
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 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
__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 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
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 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
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 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
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 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 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, 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
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
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
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
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
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
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
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
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
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
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:
-
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
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 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 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
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
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
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
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:
> >
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 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
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 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
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.
__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 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
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.
Hello.
The patch is approved, are you planning committing the changes?
Thanks,
Martin
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
> 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
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,
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 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
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,
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
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
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
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
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
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
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/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
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 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
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
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
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
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 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
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
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 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
__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);
}
```
[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
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
73 matches
Mail list logo
