gcc/ChangeLog:
* config.gcc: Remove cr16.
---
gcc/config.gcc | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 8e8e1d0513f..11045084888 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,8 +248,7 @@ md_file=
# Obsolet
On 8/30/22 18:54, Rainer Orth wrote:
> Hi Andrew,
>
>> On 26/08/2022 12:04, Jakub Jelinek wrote:
gcc/ChangeLog:
* doc/tm.texi: Regenerate.
* omp-simd-clone.cc (simd_clone_adjust_return_type): Allow zero
vecsize.
(simd_clone_adjust_argument_types): Likewise
Hi Richard, could you help to have a look for the patch ?
Ok for master ?
> Hi,
>
> The conditional mult reduction cannot be recognized with current GCC. The
> following loop cannot be vectorized.
> Now add MULT_EXPR recognition for conditional scalar reduction.
>
> float summa(int n, float *
Sending v3 of the patch that includes John's comments.
Ready to be installed?
Thanks,
Martin
ChangeLog:
* configure: Regenerate.
* configure.ac: Delete hpux9 and hpux10.
config/ChangeLog:
* mh-pa-hpux10: Removed.
contrib/ChangeLog:
* config-list.mk: Remove dep
Hi,
adding -save-temps as well as a '\t' in order for the tests to do what
they are supposed to do.
Going to push this as obvious in some days.
Regards
Robin
--
gcc/testsuite/ChangeLog:
* gcc.target/s390/vector/vperm-rev-z14.c: Add -save-temps.
* gcc.target/s390/ve
One call to dump_printf_loc had a stray left-over argument
from an earlier version of the patch. This went unnoticed
on aarch64-linux-gnu and x86_64-linux-gnu since the parameters
that actually mattered were passed in FPRs rather than GPRs,
but I assume this is the reason for the i686-linux-gnu fa
On Tue, Aug 30, 2022 at 06:54:49PM +0200, Rainer Orth wrote:
> > --- a/gcc/omp-simd-clone.cc
> > +++ b/gcc/omp-simd-clone.cc
> > @@ -504,7 +504,10 @@ simd_clone_adjust_return_type (struct cgraph_node
> > *node)
> > veclen = node->simdclone->vecsize_int;
> >else
> > veclen = node->sim
On 31/08/2022 09:29, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 06:54:49PM +0200, Rainer Orth wrote:
--- a/gcc/omp-simd-clone.cc
+++ b/gcc/omp-simd-clone.cc
@@ -504,7 +504,10 @@ simd_clone_adjust_return_type (struct cgraph_node *node)
veclen = node->simdclone->vecsize_int;
else
Hi!
The assertion ensures that we point within the image and at a byte
we haven't touched yet (or at least that it isn't the first byte
of an already stored tree), some static checker was unhappy about
first checking that it is zero and only afterwards checking that it
is within bounds.
Obviously
The PR65244 has an issue with code in init_from_control_deps
for which there's no direct testcase. The following adds one.
Pushed.
PR tree-optimization/65244
* gcc.dg/uninit-pr65244-1.c: New testcase.
---
gcc/testsuite/gcc.dg/uninit-pr65244-1.c | 20
1 file
Hi Peter,
Thanks for the patch! Some comments are inline as below.
on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
> machinery and we end
On Wed, 31 Aug 2022 at 05:38, François Dumont wrote:
>
> If I got your point correctly here is this patch again with just the
> change on '0' becoming 'nullptr' in assertions.
>
> libstdc++: [_GLIBCXX_DEBUG] Review nullptr assertion diagnostics
>
> Review null string checks to show:
>
Hi,
Commit r12-2266 updated the scanned assembly content from
"{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
to
"{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
for the test case pr86731-fwrapv-longlong.c unexpectedly.
It's meant to update "lxv" to "p?lxv" and should leave the
"lvx" unchanged. So this is to fix the typ
Hi,
Test case bswap64-4.c suffers the issue as its comments:
/* On some versions of dejagnu this test will fail when
biarch testing with RUNTESTFLAGS="--target_board=unix
'{-m64,-m32}'" due to -m32 being added on the command
line after the dg-options -mpowerpc64.
common/config/rs6000/
Hi!
On Wed, Aug 10, 2022 at 01:27:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Wed, Jul 27, 2022 at 11:33:29AM +0200, Jakub Jelinek via Gcc-patches wrote:
> > The following patch is partially a workaround for bogus warnings
> > when the compiler isn't able to fold _M_disjunct call into co
On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Yes, thanks for adding this.
>
> libstdc++-v3/ChangeLog:
>
> * testsuite/20_util/logical_traits/requirements/short_circuit.cc: New
> test.
> ---
> .../requir
On Wed, Aug 31, 2022 at 2:52 PM Kong, Lingling via Gcc-patches
wrote:
>
> Hi,
>
> Handle E_V8BFmode in expand_vec_perm_broadcast_1 and
> ix86_expand_vector_init_duplicate.
> Ok for trunk?
>
> gcc/ChangeLog:
>
> PR target/106742
> * config/i386/i386-expand.cc (ix86_expand_vector_in
On 8/30/22 17:36, Gaius Mulley wrote:
> Martin Liška writes:
>
>> On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
>>>
>>> Another very brief update to say that I'm now tidying up the code and
>>> primary platform testing
>>>
>>> regards,
>>> Gaius
>>
>> Hello.
>>
>> As you may know I'm work
I think we can model the signed zero problem by keeping track of a
sign property, similar to how we keep track of a NAN property. The
property can be yes, no, or unknown, and would apply to the entire
range.
[0.0, 0.0] SIGN => -0.0 singleton
[0.0, 0.0] !SIGN=> +0.0 singleton
[0.0, 0.0] VA
On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
>
> After a second thought here is an even cleaner version. No more function
> rename, current pretty_print is fine.
>
> libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
>
>Add _GLIBCXX_DEBUG_BACKTRACE macro to activat
On Fri, 26 Aug 2022 at 21:05, Jonathan Wakely wrote:
>
> On Tue, 23 Aug 2022 at 02:38, Patrick Palka via Libstdc++
> wrote:
> > +template
> > + constexpr void
> > + __tuple_for_each(_Fp&& __f, _Tuple&& __tuple)
> > + {
> > + std::apply([&](_Ts&&... __elts) {
> > +
On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> +constexpr
> +_Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base>
> __last)
> +{
> + if constexpr (!bidirectional_range<_Base>)
>
Hi Jakub,
Am 22.08.2022 um 17:35 schrieb Jakub Jelinek:
+/* Default values of ICVs according to the OpenMP standard. */
+struct gomp_default_icv_t gomp_default_icv_values = {
+ .run_sched_var = GFS_DYNAMIC,
+ .run_sched_chunk_size = 1,
+ .max_active_levels_var = 1,
+ .bind_var = omp_proc_bi
When uninit computes the actual predicates from the control dependence
edges it currently skips those that are assert-like (where one edge
leads to a block which ends in a noreturn call). That leads to
bogus uninit diagnostics when applied on the USE side.
Bootstrapped and tested on x86_64-unknow
The following makes predicate analysis handle case labels with
a non-singleton contiguous range.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/73550
* gimple-predicate-analysis.cc (predicate::init_from_control_deps):
Sanitize debug dumpi
On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
> This hunk now seems worth factoring out of the four places it occurs.
>
> It also seems the comment for _cpp_valid_utf8 needs to be updated: it
> currently says it's not called when parsing a string.
Ok, so like this?
2022-08-31 J
Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>
>> I was hoping Joseph would chime in here - I recollect debugging this kind
>> of thing and a thread about this a while back but unfortunately I do not
>> remember the
Fixes:
gcc/value-range.h:357:16: warning: 'set_nonnegative' overrides
a member function but is not marked 'override' [-Winconsistent-missing-override]
gcc/ChangeLog:
* value-range.h: Add override.
---
gcc/value-range.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/g
Part 2.
gcc/ChangeLog:
* value-range.h: Add more override keywords.
---
gcc/value-range.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gcc/value-range.h b/gcc/value-range.h
index b25dd30d88a..f7f3665be07 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.
Thanks.
On Wed, Aug 31, 2022 at 2:18 PM Martin Liška wrote:
>
> Fixes:
> gcc/value-range.h:357:16: warning: 'set_nonnegative' overrides
> a member function but is not marked 'override'
> [-Winconsistent-missing-override]
>
> gcc/ChangeLog:
>
> * value-range.h: Add override.
> ---
> gcc/
PR tree-optimization/106789
gcc/ChangeLog:
* range-op-float.cc (default_frelop_fold_range): Remove the
function.
---
gcc/range-op-float.cc | 16
1 file changed, 16 deletions(-)
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index d859309f86
We only stream out the FP properties for global float ranges
(currently only NAN). The following patch adds the endpoints as well.
gcc/ChangeLog:
* value-range-storage.cc (frange_storage_slot::set_frange): Save
endpoints.
(frange_storage_slot::get_frange): Restore endpoin
Martin Liška writes:
> How do you mean that? You should ideally generate .rst (Sphinx markup)
> instead of the *.texi files. These will be then included in the converted
> Sphinx manual similarly to how you include it now to the Texinfo manual.
>
> Does it make sense?
>
> Cheers,
> Martin
ah rig
r12-3640-g94c12ffac234b2 sneaked in a hack to avoid the diagnostic
for the testcase in PR90994 which sees non-call EH control flow
confusing predicate analysis. The following patch instead adjusts
the existing code handling EH to handle non-calls and do what I
think was intented.
Bootstrapped and
On 8/31/22 15:19, Gaius Mulley wrote:
> Martin Liška writes:
>
>> How do you mean that? You should ideally generate .rst (Sphinx markup)
>> instead of the *.texi files. These will be then included in the converted
>> Sphinx manual similarly to how you include it now to the Texinfo manual.
>>
>> D
On Wed, 31 Aug 2022, Jonathan Wakely wrote:
> On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
>
> > +constexpr
> > +_Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base>
> > __last)
On Wed, 31 Aug 2022 at 14:30, Patrick Palka wrote:
>
> On Wed, 31 Aug 2022, Jonathan Wakely wrote:
>
> > On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
> > wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> >
> > > +constexpr
> > > +_Iterator(_
Tested x86_64-linux, pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* testsuite/20_util/reference_wrapper/invoke-2.cc: Improve
comments.
* testsuite/20_util/reference_wrapper/invoke-3.cc: Likewise.
* testsuite/20_util/reference_wrapper/invoke.cc: Likewise.
---
Tested x86_64-linux, pushed to trunk.
-- >8 --
This isn't required by the standard, but there's an LWG issue suggesting
to add it.
Also use __invoke_result instead of result_of, to match the spec in
recent standards.
libstdc++-v3/ChangeLog:
* include/bits/refwrap.h (reference_wrapper::
Hi,
These functions were added in Fortran 2018:
https://gcc.gnu.org/wiki/Fortran2018Status
When it comes to floating-point and IEEE compliance, gfortran fully implements
the 2003 and 2008 standards. In a series of patch, as time permits, I would
like to add all Fortran 2018 features before the
On 8/31/22 4:22 AM, Kewen.Lin wrote:
> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>> - tree src_type = TREE_TYPE (src_ptr);
>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>> + ? build_pointer_type (vector_quad_type_node)
>> + :
Hi, Joseph,
Thanks a lot for your comment.
> On Aug 30, 2022, at 6:53 PM, Joseph Myers wrote:
>
> On Tue, 30 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>> Hi, Joseph and Nathan,
>>
>> Could you please review the C and C++ FE parts of the patch?
>>
>> https://gcc.gnu.org/pipermail/gcc-patch
On 8/31/22 07:14, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
This hunk now seems worth factoring out of the four places it occurs.
It also seems the comment for _cpp_valid_utf8 needs to be updated: it
currently says it's not called when parsing a string.
On 8/31/22 4:33 AM, Kewen.Lin wrote:
> @@ -1,7 +1,8 @@
> /* { dg-do compile { target { powerpc*-*-* } } } */
> /* { dg-skip-if "" { powerpc*-*-aix* } } */
> -/* { dg-options "-O2 -mpowerpc64" } */
> /* { dg-require-effective-target ilp32 } */
> +/* { dg-options "-O2 -mpowerpc64" } */
> +/* { dg-
On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:
> On 8/31/22 07:14, Jakub Jelinek wrote:
> > On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
> > > This hunk now seems worth factoring out of the four places it occurs.
> > >
> > > It also seems the comment for _cpp_vali
On 8/30/22 17:37, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 11:18:20PM +0200, Jakub Jelinek via Gcc-patches wrote:
On Tue, Aug 30, 2022 at 09:10:37PM +, Joseph Myers wrote:
I'm seeing build failures of glibc for powerpc64, as illustrated by the
following C code:
#if 0
\NARG
#endif
(the
Hum, slightly amended patch, after checking 32-bit results on another linux
machine.
The test for FMA has been made a bit less strict, because otherwise we have
surprised on 387 arithmetic due to excess precision.
Final patch is attached. Regression-tested on x86_64-pc-linux-gnu, both 32- and
6
On 8/31/22 10:15, Jakub Jelinek wrote:
On Wed, Aug 31, 2022 at 09:55:29AM -0400, Jason Merrill wrote:
On 8/31/22 07:14, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 05:51:26PM -0400, Jason Merrill wrote:
This hunk now seems worth factoring out of the four places it occurs.
It also seems the c
When processing USE predicates we can drop from the AND chain,
when procsssing DEF predicates we can drop from the OR chain. Do
that instead of giving up completely. This also removes cases
that should never trigger.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* gimple-
On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
> If
> #define z(x) 0
> #define a z(
> int x = a\NARG);
> is valid in C and C++ <= 20 then
> #define z(x) 0
> #define a z(
> int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
> is too and shall preprocess to int x = 0; too.
On 8/30/2022 8:50 AM, Richard Sandiford wrote:
Jeff Law via Gcc-patches writes:
On 8/25/2022 7:07 AM, Richard Sandiford via Gcc-patches wrote:
Currently SLP tries to force permute operations "down" the graph
from loads in the hope of reducing the total number of permutations
needed or (in t
The tests for sizeless SVE types include checks that the types
are handled for initialisation purposes in the same way as scalars.
GNU C and C2x now allow scalars to be initialised using empty braces,
so this patch updates the SVE tests to match.
Tested on aarch64-linux-gnu & pushed.
Richard
gc
On 8/31/22 10:35, Jakub Jelinek wrote:
On Tue, Aug 30, 2022 at 11:37:07PM +0200, Jakub Jelinek via Gcc-patches wrote:
If
#define z(x) 0
#define a z(
int x = a\NARG);
is valid in C and C++ <= 20 then
#define z(x) 0
#define a z(
int x = a\N{LATIN SMALL LETTER A WITH ACUTE});
is too and shall prepr
On 8/31/22 4:33 AM, Kewen.Lin via Gcc-patches wrote:
> Commit r12-2266 updated the scanned assembly content from
>
> "{\mlvx\M|\mlxv\M|\mlxvd2x\M}"
>
> to
>
> "{\mp?lxv\M|\mlxv\M|\mlxvd2x\M}"
>
> for the test case pr86731-fwrapv-longlong.c unexpectedly.
>
> It's meant to update "lxv" to "p
On Tue, 30 Aug 2022 10:48:30 PDT (-0700), Vineet Gupta wrote:
CM_PIC is no longer doing anything directly. Removing it might
potentially affect USE_LOAD_ADDRESS_MACRO() but seems unlikely.
At least in the short term, there's kind of a mess here that needs to
get sorted out but just removing CM
On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
Came across this deprecated symbol when looking around for
-mexplicit-relocs handling in code
Signed-off-by: Vineet Gupta
---
gcc/config/riscv/riscv-c.cc | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/riscv/riscv-c
On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
> It could be more explicit, but I think we can assume that from the existing
> wording; it says it designates the named character. If there is no such
> character, that cannot be satisfied, so it must be ill-formed.
Ok.
> > So, we c
On Wed, Aug 31, 2022 at 05:33:21PM +0800, Kewen.Lin wrote:
> It's meant to update "lxv" to "p?lxv" and should leave the
> "lvx" unchanged. So this is to fix the typo accordingly.
>
> I'll push this soon if no objections.
Please go ahead. Out of interest, did you see failures from this, was
it j
On 8/29/2022 7:54 AM, Jakub Jelinek via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
For convenience, singleton_p() returns false for a NAN. IMO, it makes
the implementation cleaner, but I'm not wed to the idea if someone
objects.
If singleton_p() is us
On 8/29/2022 8:15 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 4:08 PM Toon Moene wrote:
On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote:
For convenience, singleton_p() returns false for a NAN. IMO
On 8/29/2022 8:42 AM, Toon Moene wrote:
On 8/29/22 16:36, Aldy Hernandez wrote:
On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote:
On 8/29/22 16:15, Aldy Hernandez wrote:
But even with -ffinite-math-only, is there any benefit to propagating
a known NAN? For example:
The original inten
On 8/29/2022 8:30 AM, Aldy Hernandez via Gcc-patches wrote:
On Mon, Aug 29, 2022 at 4:27 PM Jakub Jelinek wrote:
On Mon, Aug 29, 2022 at 04:20:16PM +0200, Aldy Hernandez wrote:
Sure, I can add the HONOR_NANS, but can we even "see" a NAN in the IL
for -ffinite-math-only?
Sure, you can, e.g.
On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote:
> Test case bswap64-4.c suffers the issue as its comments:
>
> /* On some versions of dejagnu this test will fail when
>biarch testing with RUNTESTFLAGS="--target_board=unix
>'{-m64,-m32}'" due to -m32 being added on the command
>
On Wed, Aug 31, 2022 at 05:07:29PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Given what you said above, I think that is what we want for the last 2
> for C++23, the question is if it is ok also for C++20/C17 etc. and whether
> it should depend on -pedantic or -pedantic-errors or GNU vs. ISO mod
On Aug 31, 2022, Xi Ruoyao wrote:
> On Sat, 2022-07-09 at 10:11 -0600, Jeff Law via Gcc-patches wrote:
>> Once Alex is OK with this patch, then it'll be good to go.
>>
>> jeff
> Gentle ping as a distro maintainer :).
Oops, thanks, sorry, I seem to have missed it the first time around.
The pat
Could you also clean up all __riscv_cmodel_pic checking in
gcc/testsuite/gcc.target/riscv/predef-*.c?
On Wed, Aug 31, 2022 at 10:58 PM Palmer Dabbelt wrote:
>
> On Tue, 30 Aug 2022 10:48:29 PDT (-0700), Vineet Gupta wrote:
> > Came across this deprecated symbol when looking around for
> > -mexpli
On 8/31/2022 1:21 AM, Martin Liška wrote:
Sending v3 of the patch that includes John's comments.
Ready to be installed?
Thanks,
Martin
ChangeLog:
* configure: Regenerate.
* configure.ac: Delete hpux9 and hpux10.
config/ChangeLog:
* mh-pa-hpux10: Removed.
contrib/C
On 8/23/2022 5:49 AM, Surya Kumari Jangala via Gcc-patches wrote:
sched1: Fix -fcompare-debug issue in schedule_region [PR105586]
In schedule_region(), a basic block that does not contain any real insns
is not scheduled and the dfa state at the entry of the bb is not copied
to the fallthru ba
On 8/28/2022 5:09 AM, Jan-Benedict Glaw wrote:
Hi!
The nvptx backend defines ASM_OUTPUT_DEF along with
ASM_OUTPUT_DEF_FROM_DECLS. Much like the rs6000 coff target, nvptx
triggers an unused variable warning:
/usr/lib/gcc-snapshot/bin/g++ -fno-PIE -c -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_S
On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> Should *any* explicit command line flag ever be disabled like that?
> (Not talking about things like -m32 -m64, ...
In a general sense, I'd agree that the answer is no, but we do have
dependent options like -maltivec and -mvsx, etc., so a -mno-altiv
On 8/22/2022 3:39 AM, Martin Liška wrote:
On 4/28/22 18:10, Jeff Law via Gcc-patches wrote:
As I mentioned in the original thread, my change to pr94157_0 was an attempt to
avoid these warnings by passing a magic flag to the linker. Of course we may
not be using GNU ld. Or we may be on a n
On 8/25/2022 3:42 AM, Martin Liška wrote:
Hi.
I wrote a scipt that runs autoconf in all folders that have configure.ac
file and same for autoheader (where AC_CONFIG_HEADERS is present) and
this is the output.
The script can be seen here:
https://github.com/marxin/script-misc/blob/master/gcc-
Hi!
On Fri, Aug 26, 2022 at 10:50:00PM -0500, Peter Bergner wrote:
> When we expand an MMA disassemble built-in with C++ using a pointer that
> is casted to a valid MMA type, the type isn't passed down to the expand
(The perfect tense of cast is "cast").
> machinery and we end up using the base
On 8/17/2022 5:11 AM, Richard Biener via Gcc-patches wrote:
The following started as making the backward threader m_imports
use the tree representation. Since that interfaces to a list
representation bitmap in ranger by copying rewriting the tree
to list to perform the copy is inefficient in
On 8/29/2022 2:11 PM, Jan-Benedict Glaw wrote:
Hi Jeff!
On Sun, 2022-08-28 15:32:53 -0600, Jeff Law via Gcc-patches
wrote:
On 8/28/2022 1:50 AM, Jan-Benedict Glaw wrote:
On Tue, 2021-09-21 16:25:19 +0200, Richard Biener via Gcc-patches
wrote:
This makes defaults.h choose DWARF2_DEBUG i
On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> On 8/31/22 10:24 AM, Segher Boessenkool wrote:
> > Should *any* explicit command line flag ever be disabled like that?
> > (Not talking about things like -m32 -m64, ...
>
> In a general sense, I'd agree that the answer is no, but we
On 8/25/2022 3:39 AM, Kong, Lingling via Gcc-patches wrote:
Hi,
The conditional mult reduction cannot be recognized with current GCC. The
following loop cannot be vectorized.
Now add MULT_EXPR recognition for conditional scalar reduction.
float summa(int n, float *arg1, float *arg2)
{
On 8/31/22 11:07, Jakub Jelinek wrote:
On Wed, Aug 31, 2022 at 10:52:49AM -0400, Jason Merrill wrote:
It could be more explicit, but I think we can assume that from the existing
wording; it says it designates the named character. If there is no such
character, that cannot be satisfied, so it mu
On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too. Those were so
niche that I doubt anyone else would notice.
That should be okay. I have never heard of anyone building these. There is no
config for these in config.gcc.
hppa*-*-openbsd* an
On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
>> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
>
> Oh? Why should it disable -maltivec? -mvsx makes a little sense on
> one hand, but totally none on the other
On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
> >
> >> I was hoping Joseph would chime in here - I recollect debugging this kind
> >> of thing and a thread
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > "a GNU extension" suggests a particular language feature, but I think
> > you're actually referring here to a whole language version rather than an
> > individual feature.
>
> Is “not supported by GNU extension GNU89” better?
There are
On 8/31/2022 10:40 AM, John David Anglin wrote:
On 2022-08-31 11:35 a.m., Jeff Law wrote:
It looks like you removed the pa-bsd and pa-osf targets too. Those
were so niche that I doubt anyone else would notice.
That should be okay. I have never heard of anyone building these.
There is no co
This adds new F2018 features, that are not really enabled (because their
runtime support is optional).
1. Add the new IEEE_AWAY rounding mode. It is unsupported on all known targets,
but could be supported by glibc and AIX as part of the C2x proposal. Testing
for now is minimal, but once a targ
On 8/31/22 8:59 AM, Peter Bergner wrote:
> On 8/31/22 4:22 AM, Kewen.Lin wrote:
>> on 2022/8/27 11:50, Peter Bergner via Gcc-patches wrote:
>>> - tree src_type = TREE_TYPE (src_ptr);
>>> + tree src_type = (fncode == RS6000_BIF_DISASSEMBLE_ACC)
>>> + ? build_pointer_type (v
> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>>> "a GNU extension" suggests a particular language feature, but I think
>>> you're actually referring here to a whole language version rather than an
>>> individual feature.
>>
>
Excerpts from Joseph Myers's message of August 31, 2022 7:16 pm:
> On Wed, 31 Aug 2022, Iain Buclaw via Gcc-patches wrote:
>
>> Excerpts from Joseph Myers's message of August 30, 2022 11:53 pm:
>> > On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>> >
>> >> I was hoping Joseph would ch
> On Aug 31, 2022, at 2:55 PM, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Aug 31, 2022, at 1:21 PM, Joseph Myers wrote:
>>
>> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>>
"a GNU extension" suggests a particular language feature, but I think
you're actually refer
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__advance_fn::operator()): Add
parentheses in assert condition to avoid -Wparentheses warning.
* include/std/ranges: (take_view::take_view): Uglify 'base'.
On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
> > How is level 3 (thus -fstrict-flex-array) interpreted when you specify
> > -std=c89? How for -std=gnu89?
>
> 1. what’s the major difference between -std=c89 and -std=gnu89 on flexible
> array? (Checked online, cannot find a concrete ans
On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> On 8/31/22 11:05 AM, Segher Boessenkool wrote:
> > On Wed, Aug 31, 2022 at 10:48:26AM -0500, Peter Bergner wrote:
> >> Ditto for -msoft-float better disable any -maltivec and -mvsx, etc.
> >
> > Oh? Why should it disable -maltivec?
On 31/08/22 12:11, Jonathan Wakely wrote:
On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
After a second thought here is an even cleaner version. No more function
rename, current pretty_print is fine.
libstdc++: [_GLIBCXX_DEBUG] Add backtrace generation on demand
Add _GLIBC
> On Aug 31, 2022, at 3:29 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao via Gcc-patches wrote:
>
>>> How is level 3 (thus -fstrict-flex-array) interpreted when you specify
>>> -std=c89? How for -std=gnu89?
>>
>> 1. what’s the major difference between -std=c89 and -std=gnu89 on
On Wed, 31 Aug 2022, Qing Zhao wrote:
> Does the above mean that -std=gnu89 does not support C99 flexible array
> member, then
No.
Flexible array members are supported by GCC in all C standards modes. The
C90 standard doesn't support them, but that's irrelevant to what GCC
supports; it just
On 8/31/22 2:28 PM, Segher Boessenkool wrote:
> On Wed, Aug 31, 2022 at 12:00:14PM -0500, Peter Bergner wrote:
> No. Instead, it just works!
>
> Try this:
> ===
> typedef float vf __attribute__((vector_size(16)));
> vf f(float x)
> {
> x *= 42;
> return (vf){x, x, x, x};
> }
> ===
> w
> On Aug 31, 2022, at 3:52 PM, Joseph Myers wrote:
>
> On Wed, 31 Aug 2022, Qing Zhao wrote:
>
>> Does the above mean that -std=gnu89 does not support C99 flexible array
>> member, then
>
> No.
>
> Flexible array members are supported by GCC in all C standards modes. The
> C90 standard d
On Wed, 31 Aug 2022 at 20:33, François Dumont wrote:
>
> On 31/08/22 12:11, Jonathan Wakely wrote:
> > On Wed, 31 Aug 2022 at 06:05, François Dumont wrote:
> >> After a second thought here is an even cleaner version. No more function
> >> rename, current pretty_print is fine.
> >>
> >> libs
On Wed, 31 Aug 2022 at 20:27, Patrick Palka via Libstdc++
wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK, thanks.
On Wed, 31 Aug 2022, Qing Zhao wrote:
> >> When -std=gnu89 + -fstrict-flex-array=3 (ONLY C99 flexible array member
> >> [] is treated as a valid flexible array) present together,
> >
> > That seems reasonable enough without a warning. If people want a warning
> > for flexible array members in
I missed this testsuite fix in the libstdc++ commit.
Tested x86_64-linux, pushed to trunk.
-- >8 --
std::string now has [[nodiscard]] attributes on most members, causing
-Wunused-result warnings for this test.
gcc/testsuite/ChangeLog:
PR testsuite/106795
* g++.dg/tree-ssa/empty
1 - 100 of 139 matches
Mail list logo
