On 9/8/22 11:02, Jan-Benedict Glaw wrote:
Hi!
The mingw32 port is the only port to have TARGET_OVERRIDES_FORMAT_ATTRIBUTES
defined. When this macro is defined, it will never evaluate to NULL, so this
check just leads to a warning:
/usr/lib/gcc-snapshot/bin/g++ -fcf-protection -fno-PIE -c
Jason,
Thank for your suggestion. The patch is updated (attached).
Thanks,
Eugene
-Original Message-
From: Jason Merrill
Sent: Thursday, September 08, 2022 10:26 AM
To: Eugene Rozenfeld ; gcc-patches@gcc.gnu.org
Cc: Andi Kleen ; Jan Hubicka
Subject: Re: [EXTERNAL] Re: [PING][PATCH]
On Tue, Sep 06, 2022 at 10:38:12PM -0400, Jason Merrill wrote:
> On 9/3/22 12:42, Marek Polacek wrote:
> > This patch implements https://wg21.link/p2266, which, once again,
> > changes the implicit move rules. Here's a brief summary of various
> > changes in this area:
> >
> > r125211:
This patch is a rewrite of the patch submitted on August 18th:
| https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599988.html
This patch reworks the conversions between 128-bit binary floating point types.
Previously, we would call rs6000_expand_float128_convert to do all conversions.
Now,
Changes from v3:
(xtensa_expand_prologue): Changed to exclude debug insns from DF use chain
analysis.
---
In the example below, 'x' is once placed on the stack frame and then read
into registers as the argument value of bar():
/* example */
struct foo {
int a, b;
};
Hello
This patch adds support for some additional floating-point operations,
in scalar and vector modes, which are natively supported by the AMD GCN
instruction set, but haven't been implemented in GCC yet. With the
exception of frexp, these implement standard RTL names, and should be
On 9/8/22 14:01, Martin Liška wrote:
On 9/8/22 18:23, Jason Merrill wrote:
It seems to me that the warning is pointing out that comparing the address of
the array is nonsensical, and we should remove it and just have the memcmp.
Yes, thanks for the pointer. We should always compare the array
C2x adds a macro unreachable to stddef.h, with the same semantics as
__builtin_unreachable. Define this macro accordingly.
Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to commit?
gcc/
* ginclude/stddef.h [__STDC_VERSION__ > 201710L] (unreachable):
New macro.
Hello:
I sent a pull request. Please review and merge.
Branch name:
patch/rc6000/fixtypo
Log:
commit d55c6c49e0f7760c0b85ee74eb9c2b4e68275a26 (HEAD -> patch/rc6000/fixtypo)
Author: Takahashi Akari
Date: Fri Sep 9 03:37:34 2022 +0900
[Fix typo] Add parentheses for if statement in line
These are all trivial bit-twiddling operations that don't need the
overhead of a function call in unoptimized code.
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/c_global/cstddef (byte): Add always_inline attribute
to all operator
Tested powerpc64le-linux, pushed to trunk.
-- >8 --
The new proposed resolution for LWG 3629 says that std::error_code and
std::error_condition should only use ADL to find their customization
points. This means we need to use a poison pill to prevent lookup from
finding overloads in the
On Thu, 8 Sep 2022, 18:51 François Dumont via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> On 05/09/22 20:30, Will Hawkins wrote:
> > Based on Jonathan's work, here is a patch for the implementation of
> operator+
> > on std::string that makes sure we always use the best allocation
> strategy.
>
On 9/8/22 18:23, Jason Merrill wrote:
> It seems to me that the warning is pointing out that comparing the address of
> the array is nonsensical, and we should remove it and just have the memcmp.
Yes, thanks for the pointer. We should always compare the array types with
memcmp.
Ready to be
On 05/09/22 20:30, Will Hawkins wrote:
Based on Jonathan's work, here is a patch for the implementation of operator+
on std::string that makes sure we always use the best allocation strategy.
I have attempted to learn from all the feedback that I got on a previous
submission -- I hope I did the
On 9/1/22 18:22, Eugene Rozenfeld wrote:
Jason,
I made another small change in addressing your feedback (attached).
Thanks,
Eugene
-Original Message-
From: Gcc-patches On
Behalf Of Eugene Rozenfeld via Gcc-patches
Sent: Thursday, September 01, 2022 1:49 PM
To: Jason Merrill ;
On Thu, 8 Sept 2022 at 17:12, Jason Merrill wrote:
>
> On 9/8/22 08:56, Jonathan Wakely wrote:
> > On Wed, 7 Sept 2022 at 16:11, Jason Merrill wrote:
> >>
> >> On 9/7/22 08:18, Jonathan Wakely wrote:
> >>> @@ -12080,23 +12098,37 @@ finish_trait_expr (location_t loc,
> >>> cp_trait_kind kind,
On 9/8/22 11:29, Chung-Lin Tang wrote:
Hi Joseph,
Jan-Benedict reported a build-bot error for the nios2 port under
--enable-werror-always:
options-save.cc: In function 'bool cl_target_option_eq(const cl_target_option*,
const cl_target_option*)':
options-save.cc:9291:38: error: comparison
On 9/8/22 08:56, Jonathan Wakely wrote:
On Wed, 7 Sept 2022 at 16:11, Jason Merrill wrote:
On 9/7/22 08:18, Jonathan Wakely wrote:
@@ -12080,23 +12098,37 @@ finish_trait_expr (location_t loc, cp_trait_kind
kind, tree type1, tree type2)
case CPTK_HAS_TRIVIAL_COPY:
case
Martin Liška writes:
> Note I've just converted the current Modula-2 manual to RST (Sphinx):
> https://splichal.eu/scripts/sphinx/
>
> It contains some minor issues, but in general it should be pretty fine. Note
> pygments
> contains a corresponding lexer:
>
On Mon, Aug 29, 2022 at 11:24:52AM +0200, Tobias Burnus wrote:
> PR fortran/106670
>
> gcc/fortran/ChangeLog:
>
> * scanner.cc (skip_fixed_omp_sentinel): Add -Wsurprising warning
> for 'omx' sentinels with -fopenmp.
> * invoke.texi (-Wsurprising): Document additional
On Fri, Sep 02, 2022 at 09:37:57AM +0200, Tobias Burnus wrote:
> Update the OpenMP status for features that were added in the last months.
>
> Comments/suggestions? Okay to commit?
>
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
>
On Mon, Aug 29, 2022 at 12:54:33PM +0200, Tobias Burnus wrote:
> I had this patch lying around since about half a year. I did tweak and
> agumented it
> a bit today, but finally want to get rid of it (locally - by getting it
> committed) ...
>
> This patch changes -misa to -march for nvptx (the
Hi Joseph,
Jan-Benedict reported a build-bot error for the nios2 port under
--enable-werror-always:
options-save.cc: In function 'bool cl_target_option_eq(const cl_target_option*,
const cl_target_option*)':
options-save.cc:9291:38: error: comparison between two arrays
[-Werror=array-compare]
On Thu, Sep 08, 2022 at 05:21:08PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Otherwise LGTM.
Oh, and what Harald wrote, it might be better to split the nowait-4.f90 test
into 2, one for all the valid nowait cases and one for the invalid ones,
such that the first one can be compile tested all
This patch adds an #undef of MUSL_DYNAMIC_LINKER before its #define in
config/nios2/linux.h.
This makes the nios2-linux build pass when the compiler is configured with
--enable-werror-always.
Patch pushed to master at 0697bd070c4fffb33468976c93baff9493922fb3
Chung-LinFrom
On Fri, Aug 26, 2022 at 08:21:26PM +0200, Tobias Burnus wrote:
> I did run into some issues related to this; those turned out to be
> unrelated, but I end ended up implementing this feature.
>
> Side remark: 'omp parallel workshare' seems to actually permit 'nowait'
> now, but I guess that's an
Fix a stupid typo in my vect_optimize_slp_pass patch.
Tested on aarch64-linux-gnu, pushed as obvious.
Richard
gcc/
PR tree-optimization/106886
* tree-vect-slp.cc (vect_optimize_slp_pass::get_result_with_layout):
Fix copying of scalar stmts.
gcc/testsuite/
PR
This was incidentally fixed by r13-806-g221acd67ca50f8.
PR c++/99209
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval17.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/lambda-uneval17.C | 17 +
1 file changed, 17 insertions(+)
create mode 100644
CFG cleanup resets the control altering flag for noreturn functions
when they are ECF_LEAF (like __builtin_unreachable ()). The
.ABNORMAL_DISPATCHER call built during CFG construction is not
marked as control altering. Several passes inserting traps or
unreachables fail to set the flag. And
> -Original Message-
> From: Christophe Lyon
> Sent: Wednesday, September 7, 2022 5:59 PM
> To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] arm: Fix constant immediates predicates and
> constraints for some MVE builtins
>
>
>
> On 9/7/22 15:42, Kyrylo Tkachov
> Which is this from the mail archives:
>
> https://gcc.gnu.org/pipermail/gcc-patches/1998-June/000308.html
>
> I would tend to agree that for equal cost that the constant would be
> preferred since that should be better from a scheduling/dependency
> standpoint. So it seems to me we can
On Wed, 7 Sept 2022 at 16:11, Jason Merrill wrote:
>
> On 9/7/22 08:18, Jonathan Wakely wrote:
> > @@ -12080,23 +12098,37 @@ finish_trait_expr (location_t loc, cp_trait_kind
> > kind, tree type1, tree type2)
> > case CPTK_HAS_TRIVIAL_COPY:
> > case CPTK_HAS_TRIVIAL_DESTRUCTOR:
> >
On 9/7/22 16:40, Patrick Palka wrote:
On Wed, 7 Sep 2022, Jason Merrill wrote:
On 9/7/22 15:41, Patrick Palka wrote:
Here the use of the constexpr member/variable specialization 'value'
from within an unevaluated context causes us to overeagerly instantiate
it, via maybe_instantiate_decl
On Thu, 25 Aug 2022, Andre Vieira (lists) wrote:
>
> On 17/08/2022 13:49, Richard Biener wrote:
> > Yes, of course. What you need to do is subtract DECL_FIELD_BIT_OFFSET
> > of the representative from DECL_FIELD_BIT_OFFSET of the original bitfield
> > access - that's the offset within the
Hi!
This patch implements doacross(sink: omp_cur_iteration - 1) that the
previous patchset emitted a sorry on during omp expansion.
It can be implemented with existing library functions.
To recap, depend(source)/doacross(source:)/doacross(source:omp_cur_iteration)
is implemented calling
The following avoids adding fallthru edges to the control chain from
the post-dominator walk.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/106881
* gimple-predicate-analysis.cc (compute_control_dep_chain_pdom):
Add only non-fallthru
Hi!
The mingw32 port is the only port to have TARGET_OVERRIDES_FORMAT_ATTRIBUTES
defined. When this macro is defined, it will never evaluate to NULL, so this
check just leads to a warning:
/usr/lib/gcc-snapshot/bin/g++ -fcf-protection -fno-PIE -c -DIN_GCC_FRONTEND
-DIN_GCC_FRONTEND
On ppc we see a doloop temp rather than ivtmp.
Tested on x86_64-unknown-linux-gnu and ppc64le, pushed.
PR testsuite/106872
* gcc.dg/uninit-pred-12.c: Adjust.
---
gcc/testsuite/gcc.dg/uninit-pred-12.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Sep 8, 2022 at 9:27 AM Richard Biener
wrote:
>
>
>
> > Am 08.09.2022 um 08:28 schrieb Aldy Hernandez :
> >
> > This is what I have in mind for the fpclassify-like methods on the
> > current implementation. I'll get to the removal of the tristates after
> > Cauldron.
> >
> > As you
Hi,
This patch re-adds tm.h to all D-specific target platform sources,
previously removed by an earlier change that fixed up tm_d.h generation.
The tm.h header would pull in config/elfos.h, which defines
TARGET_D_MINFO_SECTION needed for the D module support in the front-end
to emit data to the
Ping.
On 25/08/2022 10:09, Andre Vieira (lists) via Gcc-patches wrote:
On 17/08/2022 13:49, Richard Biener wrote:
Yes, of course. What you need to do is subtract DECL_FIELD_BIT_OFFSET
of the representative from DECL_FIELD_BIT_OFFSET of the original
bitfield
access - that's the offset
On Thu, 8 Sept 2022 at 06:03, François Dumont wrote:
>
> libstdc++: glibc mallinfo deprecated, use mallinfo2 when version =>
> 2.33
>
> glibc mallinfo is now deprecated resulting in make check-performance
> failure. When glibc => 2.33 prefer mallinfo2.
>
>
> Am 08.09.2022 um 00:05 schrieb Lewis Hyatt via Gcc-patches
> :
>
> The function rebuild_location_adhoc_htab() was meant to reconstruct the
> adhoc location hash map after restoring a line_maps instance from a
> PCH. However, the function has never performed as intended because it
> missed
> Am 08.09.2022 um 07:53 schrieb Kewen.Lin :
>
> Hi,
>
> As PR106833 shows, cv-qualified opaque type can cause ICE
> during LTO. It exposes that we missd to handle OPAQUE_TYPE
> well in type verification. As Richi pointed out, also
> assuming that target will always define
> Am 08.09.2022 um 08:28 schrieb Aldy Hernandez :
>
> This is what I have in mind for the fpclassify-like methods on the
> current implementation. I'll get to the removal of the tristates after
> Cauldron.
>
> As you mentioned, isnormal is kinda tricky, and likely to be confusing
> for the
This is what I have in mind for the fpclassify-like methods on the
current implementation. I'll get to the removal of the tristates after
Cauldron.
As you mentioned, isnormal is kinda tricky, and likely to be confusing
for the user. We can revisit it if it's important.
?? I assume maybe_inf()
46 matches
Mail list logo
