On November 20, 2021 7:03:02 AM GMT+01:00, apinski--- via Gcc-patches
wrote:
>From: Andrew Pinski
>
>The problem here is that int_fits_type_p will return false if we just
>change the sign of things like -2 (or 254) so we should accept the case
>where we just change the sign (and not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31531
--- Comment #16 from Andrew Pinski ---
The only patch which is needed now:
diff --git a/gcc/match.pd b/gcc/match.pd
index 37c5be9e5f4..ca6c9eff624 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -4729,10 +4729,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
--- Comment #21 from Aldy Hernandez ---
(In reply to Jeffrey A. Law from comment #20)
> Your c#19 was a bit hard to follow. But you hit the key issue.
Ughh sorry. I'm running on fumes here :-).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103226
Jeffrey A. Law changed:
What|Removed |Added
Priority|P1 |P4
--- Comment #20 from Jeffrey A.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103339
Bug ID: 103339
Summary: [modules] ICE in exporting module on use of outside
specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220
Andrew Pinski changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
From: Andrew Pinski
The problem here is that int_fits_type_p will return false if we just
change the sign of things like -2 (or 254) so we should accept the case
where we just change the sign (and not the precision) of the type.
OK? Bootstrapped and tested on x86_64-linux-gnu with no
Thanks for your reviews!
Here's the updated patch, ready for another review.
See comments/questions below.
I'll update the other patches over the weekend.
Le jeudi 20 mai 2021 à 15:29 -0400, David Malcolm a écrit :
> On Wed, 2021-05-19 at 20:32 -0400, Antoni Boucher via Jit wrote:
> > Hello.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102988
--- Comment #6 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:38e4a361e79a459947540920db645f3d7fa7221a
commit r12-5429-g38e4a361e79a459947540920db645f3d7fa7221a
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103338
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.1.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103338
Bug ID: 103338
Summary: ICE: in tsubst_pack_expansion, at cp/pt.c:13167
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96889
Antoni changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96889
--- Comment #2 from CVS Commits ---
The master branch has been updated by Antoni Boucher :
https://gcc.gnu.org/g:cfe8dbd9c08a5bce497646467c9d30942ec3efe0
commit r12-5428-gcfe8dbd9c08a5bce497646467c9d30942ec3efe0
Author: Antoni Boucher
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
--- Comment #5 from Dominique Martinet ---
Ah, this apparently needed the unused fields in the struct, and the extra
config_init() call.
Here's something trimmed down from the actual program instead of building back
up:
-
#define
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220
--- Comment #2 from Andrew Pinski ---
Simple fix:
diff --git a/gcc/match.pd b/gcc/match.pd
index 24a84e3b504..37c5be9e5f4 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1607,7 +1607,8 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(bitop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103220
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
Dominique Martinet changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
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).
>
> Here's the updated patch.
Sorry about the delay in responding.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325
--- Comment #3 from Antoni ---
No.
The only patch that is ready for review is "libgccjit: add some reflection
functions in the jit C api".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549
--- Comment #9 from jwjagersma at gmail dot com ---
Created attachment 51840
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51840=edit
diagnostics
This patch adds checks for:
- Top-level AS-qualifiers on fields, local variables, function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415
David Malcolm changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #4 from David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325
David Malcolm changed:
What|Removed |Added
Last reconfirmed||2021-11-20
Hi,
On Fri, Nov 19 2021, Iain Sandoe wrote:
> At least some version(s) of makeinfo (4.8) do not like @option {-}
> the brace has to follow the @option without any whitespace.
>
> makeinfo 4.8 is installed on Darwin systems and this breaks bootstrap.
> The amendment follows the style of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #7 from Martin Jambor ---
(In reply to hubicka from comment #5)
> > I like the idea of transformation phases better than putting
> > everything into tree-inline (and by extension ipa-param-manipulation)
> > but perhaps we have to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90941
Cristian Rodríguez changed:
What|Removed |Added
CC||crrodriguez at opensuse dot org
On Friday, 19 November 2021 23:26:57 CET Jason Merrill wrote:
> On 11/19/21 04:53, Matthias Kretz wrote:
> > My motivation for printing a function template specialization differently
> > is:
> >
> > 1. It's a different function definition that's being called. The user
> > (caller) might be
Snapshot gcc-10-2029 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-2029/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
Hi Richard,
Thanks for the detailed comment. I am attaching a newer version of the patch
which does have required fixes included. Bellow you can see my response to your
feedbacks:
> you need to check TYPE_OVERFLOW_WRAPS on TREE_TYPE (@0),
> otherwise you check on boolean.
Fixed it.
> no need
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:
Right, I had already added a `gcc_assert (!TMPL_ARGS_HAVE_MULTIPLE_LEVELS
(args))` to my new set_non_default_template_args_count function and found
On Thu, Nov 11, 2021 at 3:25 AM Kewen Lin wrote:
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.md (movdi_internal, movdf_internal): Fix split
> condition.
I had been hoping Max would reply (as I'm just doing legacy work
around this these days), but seeing that he hasn't. This is
This fixes a bogus -Wuninitialized warning: there's nothing to initialize
in empty classes, so don't add them into our uninitialized set.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/19808
gcc/cp/ChangeLog:
* init.c (emit_mem_initializers): Don't add
On 11/19/21 1:28 AM, Jojo R via Gcc wrote:
> We know gcc supply earlyclobber function to avoid register overlap,
>
> but it can not describe explicitly for specific source operand, is it
> right ?
You add the early clobber to the OUTPUT operand(s) that can clobber any of the
input
On Thu, Nov 18, 2021 at 06:45:42PM -0500, David Malcolm wrote:
> On Thu, 2021-11-18 at 14:08 -0600, Segher Boessenkool wrote:
> > We need some way to describe these things in Gimple and RTL as well,
> > and not just on function calls: also on other expressions. Adding
> > attributes that allow to
On Mon, 15 Nov 2021, Patrick Palka wrote:
> This makes fast_float handle the situation where std::from_chars is
> specified to return result_out_of_range, i.e. when the parsed value
> is outside the representable range of the floating-point type.
>
> libstdc++-v3/ChangeLog:
>
> *
On Mon, 15 Nov 2021, Patrick Palka wrote:
> This performs the following modifications to our local copy of fast_float
> in order to make it more readily usable in our std::from_chars
> implementation:
>
> * Remove system #includes
> * Replace stray call to assert
> * Use the standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #6 from Jan Hubicka ---
struct a{int a,b;};
int bar (struct a *a)
{
if (!a->a)
__builtin_abort ();
}
static
__attribute__ ((noinline))
int foo (struct a a)
{
struct a b = a;
bar ();
return b.a+b.b;
}
int
test()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #5 from hubicka at kam dot mff.cuni.cz ---
> I like the idea of transformation phases better than putting
> everything into tree-inline (and by extension ipa-param-manipulation)
> but perhaps we have to do aggregate constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101180
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b751b225e4f02cf0c446e659e7c3e204096468bf
commit r12-5426-gb751b225e4f02cf0c446e659e7c3e204096468bf
Author: Jakub Jelinek
Date:
At least some version(s) of makeinfo (4.8) do not like @option {-}
the brace has to follow the @option without any whitespace.
makeinfo 4.8 is installed on Darwin systems and this breaks bootstrap.
The amendment follows the style of the surrounding code.
tested on Darwin9, 18, 19, 20, 21,
On 19/11/2021 19.11, Olivier Hainque wrote:
> Hi Rasmus,
>
>> On 12 Nov 2021, at 17:35, Olivier Hainque wrote:
>
> Your error triggers on O2ggnu++0x.gch and we configure with
> --disable-libstdcxx-pch.
>
> Can you see if adding this to your configuration options helps
> on your end?
ISTR I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96004
--- Comment #1 from Óscar Fuentes ---
This looks like a duplicate of PR53637 / PR53637.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58487
Óscar Fuentes changed:
What|Removed |Added
CC||gcc_bugzilla at axeitado dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
PR analyzer/103217 reports a false positive from -Wanalyzer-malloc-leak.
The root cause is due to overzealous state merger, where the
state-merging code decided to merge these two states by merging
the stores:
state A:
clusters within frame: ‘main’@1
cluster for: one_3: CONJURED(val_4 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f573d35147ca8433c102e1721d8c99fc432cb44b
commit r12-5424-gf573d35147ca8433c102e1721d8c99fc432cb44b
Author: David Malcolm
Date:
Tested x86_64-linux, pushed to trunk.
This ensures all constructors are checked.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_istringstream/cons/char/1.cc: Check all
constructors.
* testsuite/27_io/basic_istringstream/cons/wchar_t/1.cc:
Likewise.
*
Tested x86_64-linux, pushed to trunk.
This replaces a __gthread_active_p() check with __is_single_threaded()
so that std::locale initialization doesn't use __gthread_once if it
happens before the first thread is created.
This means that _S_initialize_once() might now be called twice instead
of
Tested powerpc64le-linux (and x86_64-linux clang), pushed to trunk.
All writes into the allocated buffer need to be via traits_type::assign
to begin lifetimes.
libstdc++-v3/ChangeLog:
PR libstdc++/103295
* include/bits/basic_string.tcc (_M_construct): Use the
traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #19 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:1f8d01eb1476a997eb1fc686b60fccdf97747faa
commit r12-5421-g1f8d01eb1476a997eb1fc686b60fccdf97747faa
Author: Jonathan Wakely
Unfortunately dejagnu doesn't honor #if/#endif, so this test was failing
with -std=c++11:
FAIL: g++.dg/cpp0x/lambda/lambda-nested9.C -std=c++11 (test for errors, line
37)
Fixed thus.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/testsuite/ChangeLog:
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80556
--- Comment #64 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:d4943ce939d9654932624b9ece24c3a474ae4157
commit r12-5418-gd4943ce939d9654932624b9ece24c3a474ae4157
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87851
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
---
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added by
Mikael's fix for PR97896. In that case it is a 1-liner. :-)
That fix is available on mainline and on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336
--- Comment #2 from Andrew Pinski ---
If you want to have a consistency between platforms, it might be best if you
use _Float128 instead of long double but _Float128 is not supported on all
targets really. It is only supported on targets which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103337
Marek Polacek changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfirmed|
As described in detail in the PR, in C++20 implicitly capturing 'this'
via the '=' capture default is deprecated, but in C++17 explicitly
capturing 'this' alongside a '=' capture default is ill-formed. This
means it's impossible to write a C++17 lambda that captures 'this' and
that also has a '='
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103337
Bug ID: 103337
Summary: rejects-valid brace elision inside designated
initializer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Excerpts from Iain Sandoe's message of November 19, 2021 4:59 pm:
> Depending on the permutation of CPU, OS version and shared/non-
> shared library inclusion, we get can get two warnings from the
> external tools (ld64, dsymutil) which are not actually GCC issues
> but relate to the external
On Sat, Nov 20, 2021 at 12:31:19AM +0530, Siddhesh Poyarekar wrote:
> > Neither of these are equivalent to what it used to do before.
> > If some target has e.g. pointers wider than size_t, then previously we could
> > compute bytes that doesn't fit into size_t and would return NULL which
> >
On Fri, 19 Nov 2021, Martin Jambor wrote:
> can I add the following caveat to the gcc-12/changes.html file?
Of course you can. :-)
Actually, we should, and I'm glad you thought of it.
Thank you,
Gerald
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103231
--- Comment #12 from Andrew Macleod ---
Yes, ranger can currently create some very deep call chains, especially as it
evaluates values around back edges.
A general query on a stmt first checks if all the operands have been resolved,
and if
On 11/19/21 22:36, Jakub Jelinek wrote:
On Wed, Nov 10, 2021 at 12:31:29AM +0530, Siddhesh Poyarekar wrote:
* tree-object-size.h (compute_builtin_object_size): Return tree
instead of HOST_WIDE_INT.
* builtins.c (fold_builtin_object_size): Adjust.
* gimple-fold.c
On 11/19/21 13:13, Richard Biener wrote:
On November 19, 2021 4:00:01 PM GMT+01:00, Andrew MacLeod
wrote:
On 11/19/21 04:21, Richard Biener wrote:
On Thu, Nov 18, 2021 at 8:30 PM Andrew MacLeod via Gcc-patches
wrote:
At issue here is the dynamic approach we currently use for outgoing edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #18 from Jonathan Wakely ---
There's still one more fix needed for _M_construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103217
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
--- Comment #23 from Mikael Morin ---
(In reply to Richard Biener from comment #21)
> (In reply to Bernhard Reutner-Fischer from comment #17)
> > Do we want to address arrays always at position 0 (maybe to help graphite ?)
>
> Helping graphite
Tested x86_64-linux, pushed to trunk.
libstdc++-v3/ChangeLog:
PR libstdc++/103332
PR libstdc++/102958
* testsuite/21_strings/basic_string/capacity/char/1.cc: Add
-Wno-stringop-overflow.
* testsuite/21_strings/basic_string/operators/char/1.cc:
Tested powerpc64le-linux (and clang on x86_64-linux), pushed to trunk.
Clang gives errors for constexpr std::string because the memory returned
by std::allocator::allocate does not contain any objects yet, and
attempting to set them using char_traits::assign or char_traits::copy
fails with:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043
Mikael Morin changed:
What|Removed |Added
Attachment #51791|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227
--- Comment #4 from Martin Jambor ---
Still, the interaction between IPA-CP and IPA-SRA is bad here. Just
looking at the optimized dump, one of the "specialized functions"
starts with:
[local count: 62767467]:
# DEBUG D#203 s=> row
#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102958
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b8f2efaed02e8b03d215d74e42d3707761772f64
commit r12-5414-gb8f2efaed02e8b03d215d74e42d3707761772f64
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:b8f2efaed02e8b03d215d74e42d3707761772f64
commit r12-5414-gb8f2efaed02e8b03d215d74e42d3707761772f64
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #17 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:2d76292bd6719d687bc77051da265df8ed7f5a61
commit r12-5413-g2d76292bd6719d687bc77051da265df8ed7f5a61
Author: Jonathan Wakely
On Thu, Oct 21, 2021 at 12:22:12PM -0500, Paul A. Clarke wrote:
> Power10 ISA added `vextract*` instructions which are realized in the
> `vec_extractm` instrinsic.
>
> Use `vec_extractm` for `_mm_movemask_ps`, `_mm_movemask_pd`, and
> `_mm_movemask_epi8` compatibility intrinsics, when
On November 19, 2021 4:00:01 PM GMT+01:00, Andrew MacLeod
wrote:
>On 11/19/21 04:21, Richard Biener wrote:
>> On Thu, Nov 18, 2021 at 8:30 PM Andrew MacLeod via Gcc-patches
>> wrote:
>>> At issue here is the dynamic approach we currently use for outgoing edge
>>> calculations. It isn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102431
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
Hi Rasmus,
> On 12 Nov 2021, at 17:35, Olivier Hainque wrote:
> We have had to use for stdbool a similar trick as we had
> for stdint (need to preinclude yyvals.h), which we will need to
> propagate somehow. I'm not yet sure how to reconcile that with
> your observations.
>> In file included
Hi!
On Fri, Oct 22, 2021 at 12:28:49PM -0500, Paul A. Clarke wrote:
> Power9 ISA added `vabsdub` instruction which is realized in the
> `vec_absd` instrinsic.
>
> Use `vec_absd` for `_mm_sad_epu8` compatibility intrinsic, when
> `_ARCH_PWR9`.
>
> Also, the realization of `vec_sum2s` on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103332
--- Comment #2 from Jonathan Wakely ---
(In reply to Martin Sebor from comment #1)
> I suppressed a subset of these warnings in
> g:9a27acc30a34b7854db32eac562306cebac6fa1e.
Ah yes, I'll add the same again then, thanks.
Hi,
can I add the following caveat to the gcc-12/changes.html file?
Thanks,
Martin
diff --git a/htdocs/gcc-12/changes.html b/htdocs/gcc-12/changes.html
index 5f0214bd..fd7af717 100644
--- a/htdocs/gcc-12/changes.html
+++ b/htdocs/gcc-12/changes.html
@@ -72,6 +72,8 @@ a work-in-progress.
Hi,
On Fri, Nov 19 2021, Jan Hubicka wrote:
>> > Hi,
>> >
>> > On Fri, Nov 12 2021, Martin Jambor wrote:
>> > > Hi,
>> > >
>> > > using -fno-semantic-interposition has been reported by various people
>> > > to bring about considerable speed up at the cost of strict compliance
>> > > to the ELF
On Fri, 19 Nov 2021 at 16:04, Iain Sandoe via Libstdc++
wrote:
>
> Depending on the permutation of CPU, OS version and shared/non-
> shared library inclusion, we get can get warnings from the external
> tools (ld64, dsymutil) which are not actually libstdc++ issues but
> relate to the external
On Fri, Nov 19, 2021 at 3:47 AM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> On Fri, 28 Oct 2016 10:55:18 -0700
> Ian Lance Taylor wrote:
>
> > This patch to libgo redirects the output of a grep command in
> > mkrsysinfo.sh to /dev/null. The output otherwise appears in the
>
> grep -q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #14 from Bill Schmidt ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Bill Schmidt from comment #11)
> > As I mentioned privately, we could do with an audit of our implementation of
> > standard patterns in
Hi Jason,
> On 18 Nov 2021, at 23:42, Iain Sandoe wrote:
>
>
>
>> On 18 Nov 2021, at 22:13, Jason Merrill via Gcc-patches
>> wrote:
>>
>> On 11/5/21 11:46, Iain Sandoe wrote:
>>> The way in which a C++20 coroutine is specified discards any value
>>> tree aw_r = TREE_VEC_ELT (vec,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103336
Bug ID: 103336
Summary: [arm64] operations on long double generate calls to
libgcc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103335
Bug ID: 103335
Summary: new test case gcc.dg/tree-ssa/modref-dse-4.c fails
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #13 from Segher Boessenkool ---
(In reply to Bill Schmidt from comment #11)
> As I mentioned privately, we could do with an audit of our implementation of
> standard patterns in general, since we tend to find such missing cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #12 from Segher Boessenkool ---
When is the lowering done currently? Only for the ops that have no other way
of doing, and things are merged back to an __int128 immediately after that?
If that is what is going on, then that is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103299
Patrick Palka changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103312
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC|kargl at gcc dot gnu.org |
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #11 from Bill Schmidt ---
As I mentioned privately, we could do with an audit of our implementation of
standard patterns in general, since we tend to find such missing cases more
often than I'd like...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103316
--- Comment #10 from Bill Schmidt ---
FWIW, I think the vector lowering pass is reasonable. These things always look
horrible in isolation, but the lowering allows more optimization when the
target doesn't really support the data type.
This
On Wed, Nov 10, 2021 at 12:31:29AM +0530, Siddhesh Poyarekar wrote:
> * tree-object-size.h (compute_builtin_object_size): Return tree
> instead of HOST_WIDE_INT.
> * builtins.c (fold_builtin_object_size): Adjust.
> * gimple-fold.c (gimple_fold_builtin_strncat): Likewise.
>
1 - 100 of 291 matches
Mail list logo
