On Linux/x86_64,
6692c400f207c68fb11b44182ae127856e8b9ad3 is the first bad commit
commit 6692c400f207c68fb11b44182ae127856e8b9ad3
Author: Martin Sebor
Date: Mon Nov 23 17:15:54 2020 -0700
Dump type attributes in dump_function_to_file.
caused
FAIL: gcc.dg/tree-ssa/pr23401.c
On Tue, Nov 24, 2020 at 12:05 AM Qing Zhao via Gcc-patches
wrote:
>
> Hi,
>
> Does gcc provide an iterator to traverse all the local variables that are
> declared in the current routine?
>
> If not, what’s the best way to traverse the local variables?
Depends on what for. There's the source
Nathan Sidwell writes:
> These are needed as they also serve to inform the mapper of a dependency
> edge.
Ok, that makes sense (and thanks for making it optional via a flag).
One thing that is still missing in this area is the dependency on
stdc-predef.h. In other words, we now can get
Marek Polacek writes:
> > +Only emit the module CMI, inhibiting any object file.
>
> Maybe say here that CMI is Compiled Module Interface.
FYI, SG15 (WG21 study group on tooling) seems to have settled
on BMI ("built module interface"):
On 23.11.20 22:38, Ilya Leoshkevich wrote:
> Commit 229752afe315 ("VEC_COND_EXPR optimizations") has improved code
> generation: we no longer need "vx x,x,-1", which turned out to be
> superfluous. Instead, we simply swap 0 and -1 arguments of the
> preceding "vsel".
>
> gcc/testsuite/ChangeLog:
From: Matt Thomas
Fix an ICE with the handling of RTL expressions like:
(subreg:QI (mem/c:SI (plus:SI (plus:SI (mult:SI (reg/v:SI 0 %r0 [orig:67 i ]
[67])
(const_int 4 [0x4]))
(reg/v/f:SI 7 %r7 [orig:59 doacross ] [59]))
(const_int 40 [0x28])) [1
Am 24.11.20 um 07:04 schrieb Maciej W. Rozycki:
I am going to give up at this point, as porting libgfortran to non-IEEE FP
is surely well beyond what I can afford to do right now.
Can you file a PR about this? Eliminating __builtin_inf and friends
sounds doable.
And does anybody know what we
On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
> > > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > > does not support it, but if you get rid of that macro, that particular
> > > problem should be solved.
> >
> > Thanks for the hint; I didn't look into it any further
On 11/23/20 9:49 PM, Hans-Peter Nilsson wrote:
> On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
>> This is the primary patch for cc0 removal on the H8 port.? It doesn't
>> have any of the optimization work and many patterns are simply disabled
>> at this time.? It's working well enough to
Jeff Law writes:
> On 11/18/20 12:28 AM, Richard Biener wrote:
>> On Tue, 17 Nov 2020, Jeff Law wrote:
>>
>>> Minor questions for Jan and Richi embedded below...
>>>
>>> On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
When investigating the issue from
On Tue, 24 Nov 2020, Maciej W. Rozycki wrote:
> > I don't know how or why __FLT_HAS_INFINITY is set for a target which
> > does not support it, but if you get rid of that macro, that particular
> > problem should be solved.
>
> Thanks for the hint; I didn't look into it any further not to
On Sun, 22 Nov 2020, Jeff Law via Gcc-patches wrote:
> This is the primary patch for cc0 removal on the H8 port.? It doesn't
> have any of the optimization work and many patterns are simply disabled
> at this time.? It's working well enough to not regress the testsuite.
>
> The H8 is similar to
Martin's recent changes added the return type to the dump file.
Naturally we have tests that count "int" or pointers, which can show up
in the return type.
This patch adjusts the tests to the current output. Pushed to the trunk.
Jeff
commit 4cd35cf3fdb70e2107f6b059f638f5bde4dae1c3
Author:
On 11/20/20 4:14 PM, Jeff Law wrote:
>
> On 11/20/20 11:12 AM, Martin Sebor via Gcc-patches wrote:
>> dump_function_to_file prints DECL_ATTRIBUTES but not TYPE_ATTRIBUTES
>> when both can be important and helpful for debugging, especially with
>> attributes that are added implicitly (such
On Mon, 23 Nov 2020, Thomas Koenig wrote:
> > Well it does not:
> >
> > In file included from .../libgfortran/generated/maxval_r4.c:26:
> > .../libgfortran/generated/maxval_r4.c: In function 'maxval_r4':
> > .../libgfortran/libgfortran.h:292:30: warning: target format does not
> > support
On Fri, Nov 13, 2020 at 09:41:28AM +0100, Richard Biener via Gcc-patches wrote:
> On Thu, Mar 12, 2020 at 1:41 AM J.W. Jagersma via Gcc-patches
> wrote:
> > The following patch extends the generation of exception handling
> > information, so that it is possible to catch exceptions thrown from
> >
On Tue, Nov 24, 2020 at 4:27 AM Jeff Law wrote:
>
>
>
> On 11/4/20 2:19 AM, Hongtao Liu via Gcc-patches wrote:
> > Hi:
> > When programmers explicitly use mask loaded intrinsics, don't
> > transform the instruction to vpblend{b,w,d,q} since If mem_addr points
> > to a memory region with less
Ping^3, thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555905.html
On 2020/11/13 10:05, Xionghu Luo via Gcc-patches wrote:
Ping^2, thanks.
On 2020/11/5 09:34, Xionghu Luo via Gcc-patches wrote:
Ping.
On 2020/10/10 16:08, Xionghu Luo wrote:
Originated from
On Mon, Nov 23, 2020 at 1:31 PM Jonathan Wakely wrote:
>
> On 22/11/20 13:37 +, Jonathan Wakely via Libstdc++ wrote:
> >On Sun, 22 Nov 2020, 12:29 Iain Sandoe, wrote:
> >
> >> thanks for looking at this over the weekend.
> >>
> >> Jonathan Wakely via Gcc-patches wrote:
> >>
> >> > On Sat,
On Fri, Nov 20, 2020 at 03:36:24AM +, Maciej W. Rozycki wrote:
> Use a double colon to introduce the comments like elsewhere throughout
> the VAX machine description.
It's a double semicolon, so kind of a single colon ;-)
Segher
On Wed, 18 Nov 2020 at 19:13, Richard Biener wrote:
>
> On Wed, 18 Nov 2020, Prathamesh Kulkarni wrote:
>
> > Hi,
> > For the following test-case (slightly reduced from PR)
> > int a, b, c;
> >
> > int g() {
> > char i = 0;
> > for (c = 0; c <= 8; c++)
> > --i;
> >
> > while (b) {
> >
On Fri, Nov 20, 2020 at 03:34:16AM +, Maciej W. Rozycki wrote:
> The `c' operand format specifier is handled directly by the middle end
> in `output_asm_insn':
>
>%cN means require operand N to be a constant
> and print the constant expression with no punctuation.
>
> however it
On 11/10/20 2:09 PM, Jeff Law wrote:
> On 11/10/20 1:14 PM, Jakub Jelinek via Gcc-patches wrote:
>> On Tue, Nov 10, 2020 at 08:44:32PM +0100, Stefan Kanthak wrote:
>>> Eric Botcazou wrote:
>>>
> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3()
> functions
> is
On 11/16/20 11:54 PM, Jason Merrill wrote:
On 11/16/20 9:41 PM, Martin Sebor wrote:
The result of DECL_SIZE_UNIT doesn't always reflect the size
of data members of virtual classes. This can lead to objects
of such types appearing smaller than they are to warnings like
-Warray-bounds or
Hi!
On Thu, Nov 19, 2020 at 06:54:29PM -0500, Michael Meissner wrote:
> 1) Only set gnu attribute #4 if long double was passed. Passing __float128
> when long double is IBM or __ibm128 when long double is IEEE no longer sets
> the
> attribute. This resulted in a lot of false positives, such as
On Fri, 20 Nov 2020, Martin Sebor via Gcc-patches wrote:
> The VLA bounds are evaluated in function definitions so there
> must be a point where that's done. I don't know where that
> happens but unless at that point the most significant bound
> is still associated with the param (AFAIK, it
As noted in bug 95630, C11 removed a restriction in C99 on comparing
pointers to compatible complete and incomplete types (this was one of
the changes in N1439, which was largely a terminological change to
make incomplete types a subset of object types rather than a different
kind of type).
Hi,
Does gcc provide an iterator to traverse all the local variables that are
declared in the current routine?
If not, what’s the best way to traverse the local variables?
Thanks.
Qing
Hi Jeff,
On Fri, Nov 20 2020, Jeff Law wrote:
> On 6/12/20 3:25 PM, Martin Jambor wrote:
>>
[...]
>>
>> 2020-06-12 Martin Jambor
>>
>> * ipa-prop.h (ipa_pass_through_data): Expand comment describing
>> operation.
>> * ipa-prop.c (analyze_agg_content_value): Detect new special
On 11/11/20 2:55 AM, Jakub Jelinek wrote:
> On Wed, Nov 11, 2020 at 09:33:00AM +0100, Stefan Kanthak wrote:
>> Ouch: that's but not the point here; what matters is the undefined behaviour
>> of
>> ((u) & 0x00ff) << 24
>>
>> 0x00ff is a signed int, so (u) & 0x00ff is signed
On 6/11/20 6:01 AM, Zhanghaijian (A) wrote:
> Hi,
>
> This is a experimental fix for pr94274.
> For if/else structure, when the expressions is binary operation and have a
> common subexpression, and the opcode is the same, we can
> fold the merging phi node in tree_ssa_phiopt_worker
Hi!
On Thu, Nov 19, 2020 at 06:43:02PM -0500, Michael Meissner wrote:
> One feature of the current GNU attribute implementation is if you have a
> shared
> library (such as libgcc_s.so), the GNU attributes for the shared library is an
> inclusive OR of all of the modules within the library.
Hi!
Sorry this took so long.
On Thu, Oct 15, 2020 at 04:46:01PM +0800, HAO CHEN GUI wrote:
> On 29/9/2020 上午 6:46, Segher Boessenkool wrote:
> >[ Please do not insert patches into discussions ]
So, please send new patches as a new thread. This makes it much easier
to handle. If you want to
On Mon, Nov 23, 2020 at 8:52 AM Iain Sandoe wrote:
> Jason Merrill wrote:
>
> > On 11/7/20 10:11 AM, Iain Sandoe wrote:
>
> >> + warning_at (token1->location, OPT_Wattributes, "attributes
> are"
> >> + " only permitted in this position for
> Objective-C++,"
> >> +
Hi Iain,
Is there some testcase that can be used to see a progression from
applying this patch?
I haven't been able to find anything. Previously, everything was
passed as ". r r r r r r" and so on; there were also too many
arguments for functions like findloc. Since "r " is the most
Am 23.11.20 um 22:51 schrieb Maciej W. Rozycki:
/* Define to 1 if you have the header file. */
#undef HAVE_IEEEFP_H
So perhaps it does do the "right thing" if you do not have this header file on
your VAX operating system.
Well it does not:
In file included from
On Sat, 21 Nov 2020, Toon Moene wrote:
> > 2. libgfortran -- oddly enough for Fortran a piece requires IEEE 754
> > floating-point arithmetic (possibly a porting problem too).
>
> gcc/libgfortran/config.h.in does have:
>
> /* Define to 1 if you have the header file. */
> #undef
Commit 229752afe315 ("VEC_COND_EXPR optimizations") has improved code
generation: we no longer need "vx x,x,-1", which turned out to be
superfluous. Instead, we simply swap 0 and -1 arguments of the
preceding "vsel".
gcc/testsuite/ChangeLog:
2020-11-23 Ilya Leoshkevich
*
On 11/21/20 6:26 AM, Andrew MacLeod wrote:
On 11/21/20 12:07 AM, Jeff Law wrote:
On 11/9/20 9:00 AM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554000.html
Jeff, I don't expect to have the cycles to reimplement this patch
using the Ranger APIs before
Hi Thomas.
Thomas Koenig via Fortran wrote:
this patch makes sure that we pass the correct fn decls for
some of our library functions. cshift and others still remain
to be implemented.
This is a step in our voyage to stop lying to the middle end :-)
Regression-tested. OK for trunk?
Ping?
On Sat, Nov 21, 2020 at 12:39:53AM -0500, Michael Meissner wrote:
> The test c-c++-common/dfp/convert-bfp-11.c explicit expects long double to use
> the IBM 128-bit extended double format. In particular, some of the tests
> expect an infinity to be created if decimal values that are converted
The patch below is based on a previous version by Steve.
The present version fixes an additional copy error.
Needless to say that it (still!) regtests cleanly on x86_64-pc-linux-gnu.
OK for master? As it appears safe, OK for backport to at least 10-branch?
Thanks,
Harald
PR fortran/85796 -
On 11/3/20 2:14 PM, Nathan Sidwell wrote:
>
> Header units can provide macros to an importer. For efficiency that
> is done lazily. When we import a header unit we mark the identifers
> it defines as significant. It's only when we need the macro
> definition (including in #ifdef &| defined
On 11/10/20 2:51 PM, David Malcolm via Gcc-patches wrote:
> I'd like to ping this patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556214.html
> Are the non-analyzer parts OK for master?
Just looking for an ACK on the analyzer_init notification bits in the
generic parts of the
On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:
> To determine the target of a pointer expression and the offset into
> it, the increasingly widely used compute_objsize function traverses
> the IL following the DEF statements of pointer variables, aggregating
> offsets from POINTER_PLUS
"Kewen.Lin" writes:
> Hi,
>
> I adjusted some vectorization test cases for vect_partial_vectors_usage_1
> before, but as exposed in the recent testings, some of them need to be
> adjusted again. The reason is that the commit r11-3393 improved the
> epilogue loop handling of partial vectors and
Hi!
On Sat, Nov 21, 2020 at 12:37:10AM -0500, Michael Meissner wrote:
> Since the test is explicitly checking for IBM extended double, do not try to
> run it when long double is IEEE 128-bit.
Before your change, it would explicitly use __ibm128 if that is not the
same as long double.
You need a
Dear Jeff,
On Mon, Nov 23, 2020 at 3:02 PM Jeff Law wrote:
>
> You use a getter function to retrieve the value of ret.to, which is
> fine. Is there a specific reason why you're not using a setter function
> to save the value?
I did this because I have access to ret.to in the libcpp
On Fri, 20 Nov 2020, Anders Magnusson wrote:
> > Then there is a fix for the PDP11 backend addressing an issue I found in
> > the handling of floating-point comparisons. Unlike all the other changes
> > this one has not been regression-tested, not even built as I have no idea
> > how to
Matthew Malcomson writes:
> new file mode 100644
> index
> ..a6a11866823ae8ba9c20b79ac068e84aa73e053d
> --- /dev/null
> +++ b/gcc/testsuite/lib/hwasan-dg.exp
> @@ -0,0 +1,121 @@
> +# Copyright (C) 2012-2019 Free Software Foundation, Inc.
2012-2020
> +
>
Hi!
On Sat, Nov 21, 2020 at 12:33:52AM -0500, Michael Meissner wrote:
> +# See if the target is a powerpc with the long double format that uses the
> IBM
> +# extended double format.
"Return 1 if the target is PowerPC, and long double is IBM extended double."
> @@ -7939,6 +7992,9 @@ proc
On 11/4/20 2:19 AM, Hongtao Liu via Gcc-patches wrote:
> Hi:
> When programmers explicitly use mask loaded intrinsics, don't
> transform the instruction to vpblend{b,w,d,q} since If mem_addr points
> to a memory region with less than whole vector size of accessible
> memory, the mask would
On Mon, 23 Nov 2020, Uecker, Martin wrote:
> Joseph,
>
> here is the patch to not drop qualifiers for _Atomic in
> typeof. I am not sure whether this is appropriate in
> stage3, but I wanted to leave it here for you to comment
> and so that it does not lost.
>
> First, I noticed that the change
Sorry for the earlier OK, was replying to the wrong message…
Matthew Malcomson writes:
> @@ -1216,6 +1255,24 @@ expand_stack_vars (bool (*pred) (size_t), class
> stack_vars_data *data)
> {
> offset = alloc_stack_frame_space (stack_vars[i].size, alignb);
>
On Mon, Nov 23, 2020 at 08:10:49PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote:
> > On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> > > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > > > Sure -- I am
Matthew Malcomson writes:
> Hi there,
>
> I was just doing some double-checks and noticed I'd placed the
> documentation in the wrong section of tm.texi. The `MEMTAG` hooks were
> documented in the `Register Classes` section, so I've now moved it to
> the `Misc` section.
>
> That's the only
So the primary purpose of this patch is to make it easier to write tests
for removal of useless test/compare insns on the H8.
In simplest terms the costing model in the H8 port tends to encourage
changing something like
x = y + 4;
if (x == 0)
into
x = y + 4;
if (y == -4)
This is a
Matthew Malcomson writes:
> Hi there,
>
> I was just doing some double-checks and noticed I'd placed the
> documentation in the wrong section of tm.texi. The `MEMTAG` hooks were
> documented in the `Register Classes` section, so I've now moved it to
> the `Misc` section.
>
> That's the only
Joseph,
here is the patch to not drop qualifiers for _Atomic in
typeof. I am not sure whether this is appropriate in
stage3, but I wanted to leave it here for you to comment
and so that it does not lost.
First, I noticed that the change to drop qualifiers
in lvalue conversion also implies that
On 10/9/20 6:39 AM, JeanHeyd Meneide via Gcc-patches wrote:
> Hello,
>
>> Typo: comple-time
>>
>>> 2020-10-08 JeanHeyd "ThePhD" Meneide
>>>
>>>* gcc/c-family/c-cppbuiltin.c: Add predefined macro
>>> definitions for charsets
>> I think you should put the macro names in braces after
Hi
This fixes a blocker for x86_64 darwin20 (a.k.a macOS 11)
It is needed on all open branches too.
(probably this comes under my Dariwn hat - but since it involves
regenerating all the configure scripts… I’d welcome another pair
of eyes)
tested on:
darwin8-darwin20, powerpc, i686, x86_64,
On Mon, Nov 23, 2020 at 12:59:29PM -0600, Segher Boessenkool wrote:
> On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> > On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > > Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> > > which
On Sat, Nov 21, 2020 at 12:27:30AM -0500, Michael Meissner wrote:
> On Thu, Nov 19, 2020 at 08:03:02AM -0600, Segher Boessenkool wrote:
> > Sure -- I am suggesting to always define __IBM128_MAX__ and the like,
> > which then can be used to define LDBL_MAX, but also can be used
> > directly.
>
> I
On 11/23/20 11:21 AM, Jakub Jelinek wrote:
On Mon, Nov 23, 2020 at 11:08:13AM -0700, Martin Sebor wrote:
I don't think it would be significant complication, on the other side you
avoid wasting compile time memory on that (GC one, which means it will be
wasted until GC collection if there is one
Here is the patch to adjust the include-stack pruning messages to also
strip out c++ modules. The ICE regexp was a little too strict such
that if someone overrides the bug-reporting URL it doesn't trigger.
May as well relax it too.
gcc/testsuite/
* lib/prune.exp
On 22/11/20 22:13 +0100, Stephan Bergmann wrote:
On 20/11/2020 23:44, Thomas Rodgers wrote:
Tested x86_64-pc-linux-gnu, committed.
Clang complains:
$ cat test.cc
#include
$ clang++ --gcc-toolchain=~/gcc/trunk/inst -std=c++20 -fsyntax-only test.cc
In file included from test.cc:1:
In file
On 22/11/20 22:41 +0100, Stephan Bergmann wrote:
On 20/11/2020 23:44, Thomas Rodgers wrote:
Tested x86_64-pc-linux-gnu, committed.
...and there are multiple definition complaints from the linker
because of two missing "include":
index 7b2682a577e..23ab2018ca8 100644
---
On 23/11/20 18:31 +, Jonathan Wakely wrote:
On 22/11/20 13:37 +, Jonathan Wakely via Libstdc++ wrote:
On Sun, 22 Nov 2020, 12:29 Iain Sandoe, wrote:
thanks for looking at this over the weekend.
Jonathan Wakely via Gcc-patches wrote:
On Sat, 21 Nov 2020 at 23:55, David Edelsohn
On 22/11/20 13:37 +, Jonathan Wakely via Libstdc++ wrote:
On Sun, 22 Nov 2020, 12:29 Iain Sandoe, wrote:
thanks for looking at this over the weekend.
Jonathan Wakely via Gcc-patches wrote:
> On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
> wrote:
>> I am seeing 93 new
On 22/11/20 01:27 +, Jonathan Wakely via Libstdc++ wrote:
On Sat, 21 Nov 2020 at 23:55, David Edelsohn via Libstdc++
wrote:
I am seeing 93 new libstdc++ failures on AIX, even after Jonathan's
fixes. And a few c++ failures with similar symptoms. I'm not certain
that it is due to this
On Mon, Nov 23, 2020 at 11:08:13AM -0700, Martin Sebor wrote:
> > I don't think it would be significant complication, on the other side you
> > avoid wasting compile time memory on that (GC one, which means it will be
> > wasted until GC collection if there is one ever). Plus all the issues from
Hello,
Update of the hwasan tests attached.
Ok for trunk?
(NOTE on the state of the entire patch series:
Currently re-testing everything from scratch to ensure I didn't get tripped up
from old state carried around.
Also looking into PR 97941 on hwasan. As yet don't understand what's
On 11/23/20 10:30 AM, Jakub Jelinek wrote:
On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote:
If the most significant bound is lost, why don't you save in the attribute
early only the most significant bound before it is lost
The other bounds are a part of the type so saving them in
On 11/23/20 9:35 AM, Iain Sandoe wrote:
> Hello,
>
> The current config.guess/sub version do not support the recently
> released Darwin platforms; current upstream does.
>
>
>
> This imports from:
>
> sha1 77632d92f25e26b95c64afd3700d51bd03587613
> Date:Â Â 2020-11-07 04:46:23 +
>
>
On Mon, Nov 23, 2020 at 10:03:44AM -0700, Martin Sebor wrote:
> > If the most significant bound is lost, why don't you save in the attribute
> > early only the most significant bound before it is lost
>
> The other bounds are a part of the type so saving them in the attribute
> isn't essential.
On 11/21/20 1:01 AM, Jakub Jelinek wrote:
On Fri, Nov 20, 2020 at 03:44:01PM -0700, Martin Sebor via Gcc-patches wrote:
So that likely means you are doing it too early.
The bounds are added to attribute "arg spec" for each param in
push_parm_decl. I think that's both as early and (except
On 2020-11-23 09:20, Richard Biener wrote:
> On Sun, Nov 22, 2020 at 5:38 PM J.W. Jagersma wrote:
>>
>> On 2020-11-21 12:27, J.W. Jagersma wrote:
>>> ...
>>> Another idea I had is to introduce a new operand modifier, eg. '-', which
>>> would signify that the output *must* be considered clobbered
Hello,
The current config.guess/sub version do not support the recently released
Darwin platforms; current upstream does.
This imports from:
sha1 77632d92f25e26b95c64afd3700d51bd03587613
Date: 2020-11-07 04:46:23 +
ChangeLog:
* config.guess: Import latest upstream.
On Mon, 23 Nov 2020, Martin Liška wrote:
> On 10/18/18 1:59 AM, Joseph Myers wrote:
> > - || strcmp (language_string, "GNU C17") == 0)
> > + || strcmp (language_string, "GNU C17") == 0
> > + || strcmp (language_string, "GNU C2X"))
>
> Hello Joseph.
>
> Shouldn't
On Sun, Nov 22, 2020 at 11:00 AM Rainer Orth
wrote:
>
> > This patch to the Go frontend and libgo changes the name mangling
> > convention. The previous convention (which was actually the second
> > one) turned out to be ambiguous when the path to a package contained a
> > dot; this is a common
On 21/11/20 17:39 +, Jonathan Wakely wrote:
On 21/11/20 17:04 +, Jonathan Wakely wrote:
On 21/11/20 16:16 +0100, Andreas Schwab wrote:
In file included from
/daten/aranym/gcc/gcc-20201121/Build/m68k-linux/libstdc++-v3/include/bits/shared_ptr_atomic.h:33,
from
This makes SLP discovery handle associatable (including mixed
plus/minus) chains better by swapping operands across the whole
chain.
While it works it still is a prototype only. I need to consider
the compile-time complexity by reworking how many "permutes" we
allow during SLP discovery (like a
Hi,
this patch adds missing gcc_free on agg.items and descriptors and makes
allocations precise. This saves about 316MB WPAing Firefox
Honza
Bootstrapped/regtested x86_64-linux, comitted.
* ipa-prop.c (build_agg_jump_func_from_list,
ipa_read_jump_function): Reserve agg.items
On Mon, 23 Nov 2020, Tamar Christina wrote:
> Hi All,
>
> This patch adds support for
>
> * Complex Addition with rotation of 90 and 270.
>
> Addition with rotation of the second argument around the Argand plane.
> Supported rotations are 90 and 180.
>
> c = a + (b * I) and c = a
> On Nov 19, 2020, at 10:38 PM, Maciej W. Rozycki wrote:
>
> Hi,
>
> [Paul, there's a PDP11 piece for you further down here and then 29/31.]
>
> ...
>
> Then there is a fix for the PDP11 backend addressing an issue I found in
> the handling of floating-point comparisons. Unlike all the
This tweaks the 'included from ...' printing to deal with imports in
the 'include' path. One new thing is that there can now be two
'include' names on a single line. For example 'in module X, included
at Y'. This reads better than placing them on different lines.
gcc/
*
This adds an empty module.cc file, along with make rules to build it.
gcc/cp/
* module.cc: New dummy file.
* Make-lang.in: Add rules to build module.o
pushing to trunk
--
Nathan Sidwell
diff --git c/gcc/cp/Make-lang.in w/gcc/cp/Make-lang.in
index
Am Montag, den 23.11.2020, 14:55 +0100 schrieb Christophe Lyon:
> Hi,
>
>
> On Thu, 19 Nov 2020 at 07:34, Uecker, Martin
> wrote:
> >
> >
> > Here is another version of the patch. The
> > only difference is the additional the check
> > using 'tree_ssa_useless_type_conversion'.
> >
> >
> >
On 11/23/20 3:50 PM, Sebastian Huber wrote:
On 23/11/2020 15:49, Martin Liška wrote:
On 11/23/20 3:35 PM, Sebastian Huber wrote:
If I have to wait for next stage 1, I can also try to refactor write_one_data()
after your patch which removes the buffering.
Yes, please build your patches on
On 11/23/20 2:02 PM, Martin Liška wrote:
May I apply the patch after it finishes regression tests and bootstrap?
It survives testing.
There's the second part which adds -frecord-gcc-switches-format.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Thanks,
Martin
>From
On 21/11/20 16:36 -0800, H.J. Lu wrote:
On Sat, Nov 21, 2020 at 9:40 AM Jonathan Wakely via Gcc-patches
wrote:
On 21/11/20 17:04 +, Jonathan Wakely wrote:
>On 21/11/20 16:16 +0100, Andreas Schwab wrote:
>>In file included from
On 23/11/2020 15:49, Martin Liška wrote:
On 11/23/20 3:35 PM, Sebastian Huber wrote:
If I have to wait for next stage 1, I can also try to refactor
write_one_data() after your patch which removes the buffering.
Yes, please build your patches on top of the file buffering removal.
Ok.
This
Given that (at least for C/C++) there is some initial support for
OpenMP 5.0's allocators, it is likely that users will try it.
Also the release notes state: "the allocator routines of OpenMP 5.0,
including initial|allocate| clause support in C/C++."
The latter does not include the omp allocate
On 11/23/20 3:35 PM, Sebastian Huber wrote:
If I have to wait for next stage 1, I can also try to refactor write_one_data()
after your patch which removes the buffering.
Yes, please build your patches on top of the file buffering removal.
This would avoid some duplicated code, however, it
The "persistent" attribute is now handled generically, and does not
need specific support in the MSP430 back end.
Successfully built and regtested C/C++ testsuites for msp430-elf.
Committed as obvious.
>From 77ee207e17d02e4aec502c6aedd9b0ba36a08de3 Mon Sep 17 00:00:00 2001
From: Jozef
On Fri, 2020-11-20 at 12:14 -0700, Jeff Law wrote:
>
> On 6/30/20 12:46 PM, Ilya Leoshkevich wrote:
> > v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
> >
> > This is the implementation of Jakub's suggestion: allow
> > __builtin_constant_p () after IPA, but fold it into 0.
Hello Martin,
On 23/11/2020 15:30, Martin Liška wrote:
+/* Convert the gcov info to a gcda data stream. This function does
not support
+ whole program statistics and top counters. It is intended for
free-standing
+ environments which do not support the C library file I/O. For the
data
On 11/17/20 10:57 AM, Sebastian Huber wrote:
This is a proposal to get the gcda data for a gcda info in a free-standing
environment. It is intended to be used with the -fprofile-info-section option.
A crude test program which doesn't use a linker script is:
#include
#include
extern
On 11/23/20 1:25 PM, Sebastian Huber wrote:
On 20/11/2020 17:14, Sebastian Huber wrote:
On 20/11/2020 16:25, Martin Liška wrote:
Apart from these 2 hooks, I bet you will also need gcov_position and gcov_seek
functions,
can be seen in my sent patch.
For what do I need them?
I prefer the
On Mon, 23 Nov 2020, Jakub Jelinek wrote:
> Hi!
>
> The PR38359 change made the -1 >> x to -1 optimization less useful by
> requiring that the x must be non-negative.
> Shifts by negative amount are UB, but we for historic reasons had in some
> (but not all) places some hack to treat shifts by
1 - 100 of 124 matches
Mail list logo
