Marc Glisse wrote:
On Fri, 10 Apr 2020, Martin Liška wrote:
On 4/9/20 10:13 AM, Jonathan Wakely wrote:
On Thu, 9 Apr 2020 at 09:05, Marc Glisse wrote:
Note that the matching is not 1-to-1. Array vs non-array and
aligned vs non-aligned seem important, but sized and unsized delete can
both
Gerald Pfeifer wrote:
On Tue, 7 Apr 2020, Gustavo Romero via Gcc-patches wrote:
gcc/Changelog:
2020-04-06 Gustavo Romero
* dumpfile.c:
(selftest::temp_dump_context::temp_dump_context): Fix ctor.
If you approve (David, Jakub, or someone else) I can take care of
committing
Hi Nathan,
Iain Sandoe wrote:
> Nathan Sidwell wrote:
>
>> My fix for 94147 was confusing no-linkage with internal linkage, at the
>> language level. That's wrong. (the std is confusing here, because it
>> describes linkage of names (which is wrong), and lambdas have no names)
>>
>>
LAST_UPDATED: Sat Apr 4 08:01:44 UTC 2020 (revision r10-7550-gaae5d08a8d4d)
Native configuration is x86_64-apple-darwin19
=== g++ tests ===
Running target unix
FAIL: c-c++-common/asan/alloca_big_alignment.c -Os output pattern test
FAIL:
Iain Sandoe via Gcc-patches wrote:
LAST_UPDATED: Sat Apr 4 08:01:44 UTC 2020 (revision
r10-7550-gaae5d08a8d4d)
damn .. beaten by autocompletion again..
sorry
Iain
Hi Nathan,
Nathan Sidwell wrote:
> My fix for 94147 was confusing no-linkage with internal linkage, at the
> language level. That's wrong. (the std is confusing here, because it
> describes linkage of names (which is wrong), and lambdas have no names)
>
> Lambdas with extra-scope, have
Hi,
This is the final (non-bug-fixing) patch to bring our implementation
into line with n4849.
===
Although the note in the text [expr.await] / 5.1.1 is not normative,
it is asserted by users that an implementation that is unable to
perform unlimited symmetric transfers is not terribly
Hi
Recent changes in debug output have resulted in a change
in the length of the pub types info. This updates the tests to
reflect the new length.
tested on i686-darwin, x86_64-darwin,
applied to master
thanks
Iain
gcc/testsuite/ChangeLog:
* gcc.dg/pubtypes-2.c: Amend Pub Info Length.
H.J. Lu via Gcc-patches wrote:
On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
wrote:
On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
wrote:
On Linux/x86_64,
c34db4b6f8a5d80367c709309f9b00cb32630054 is the first bad commit
commit
Richard Sandiford wrote:
Alex Coplan writes:
Note that an obvious omission here is that this patch does not touch the
mult patterns such as *add__mult_. I found
that I couldn't hit these patterns with C code since multiplications by
powers of two always get turned into shifts by earlier RTL
Richard Sandiford wrote:
"Qian, Jianhua" writes:
Hi Richard
I found that some instructions are using '#' before immediate value，
and others are not. For example
(define_insn "insv_imm"
[(set (zero_extract:GPI (match_operand:GPI 0 "register_operand" "+r")
Jakub Jelinek via Gcc-patches wrote:
On Mon, May 25, 2020 at 06:37:57PM +0200, Richard Biener wrote:
I thought of using std::tuple but it requires c++11 support.
I am not sure we always build gcc with c++11?
https://gcc.gnu.org/install/prerequisites.html
We do for GCC 11 :-) Since we pay
David Edelsohn via Gcc-patches wrote:
FAIL: gcc.target/powerpc/swaps-p8-22.c (test for excess errors)
Excess errors:
cc1: error: '-mcmodel' not supported in this configuration
* gcc.target/powerpc/swaps-p8-22.c: Disable for -m32.
diff --git a/gcc/testsuite/gcc.target/powerpc/swaps-p8-22.c
Jakub Jelinek via Gcc-patches wrote:
On Thu, Aug 13, 2020 at 02:06:21PM +0200, Tobias Burnus wrote:
Build server is x86_64-gnu-linux, "i686-pc-linux-gnu-g++" is a native
binary of GCC 5.2.0
[Don't ask why i686 and not x86_64 is used.]
Ah, ok, so this boils down to:
int i = alignof (long
Hi Jason
Jason Merrill via Gcc-patches wrote:
We were crashing trying to find the CALL_EXPR in the result of a call to a
consteval operator.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* call.c (build_new_op_1): Don't look for a CALL_EXPR when
I suspect that
Hi.
this corrects some pastos in the user error messages for the
testcases, in PR95519. NFC.
tested on x86_64-darwin, applied to master.
thanks
Iain
This does not affect the test functionality, but only user-
facing debug messages when the tests are run outside the
test-suite.
Hi Alexandre,
Alexandre Oliva wrote:
On Jun 9, 2020, Iain Sandoe wrote:
I have an ugly patch that makes this work for Darwin (essentially, by
having two versions of the LTO tests
We could deal with that in a similar way to how .dwo files are handled,
namely, with explicit handling in
Hi David,
thanks for working on this!
David Edelsohn wrote:
[I'll start by repeating what I wrote about a similar libgcc change to
provide background and context.]
When AIX added 64 bit support, it implemented what Apple MacOS Darwin
calls "FAT" libraries for its equivalent functionality --
David Edelsohn wrote:
On Wed, Jun 3, 2020 at 3:14 PM Iain Sandoe wrote:
libstdc++-v3/
* Makefile.am (tmake_file): Build and install AIX-style FAT libraries.
* Makefile.in: Regenerate.
* configure.ac (tmake_file): Substitute.
* configure: Regenerate.
*
Hi Alexandre
Alexandre Oliva wrote:
When the linker plugin is not available, dump outputs in lto runs are
different from those outputs.exp tests expect, so skip them for now.
Targets (like Darwin too) that don’t have the linker plugin (presumably)
use fat LTO objects and drive the LTO
Hi Folks.
Iain Sandoe via Gcc-patches wrote:
Rainer Orth wrote:
maybe this is enough to cover all bases without having to do any
version or
target checks. (untested)
objdump is not available on quite a few Darwin versions with perfectly
functional
uleb128 - so I don’t want to punt
H.J. Lu via Gcc-patches wrote:
On Tue, Nov 24, 2020 at 5:13 PM Martin Sebor via Gcc-patches
wrote:
The attached patch cleans up most remaining -Wformat-diag instances
in an x86_64-build. I tried to minimize using #pragma diagnostic
so I tweaked the code instead. A preferable solution might
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?
Rainer Orth wrote:
maybe this is enough to cover all bases without having to do any version
or
target checks. (untested)
objdump is not available on quite a few Darwin versions with perfectly
functional
uleb128 - so I don’t want to punt on those for absence of it. We already
check for
Hi folks,
Rainer Orth wrote:
On Thu, Nov 26, 2020 at 02:26:58PM +0100, Rainer Orth wrote:
which shows that the problem is detected in the depths of
libbacktrace's DWARF reader. There's something completely off in
places, like line numbers well beyond the end of dwarf.c.
TBH, I don't
Thomas Koenig via Fortran wrote:
Hello world,
I have struggled with debugging the GENERIC generated by the
Fortran front end because it is only possible to look at the
code via -fdump-tree-original, but it is not possible to
inspect the values; additionally, the D.3456 form makes it
hard to
Hi Thomas,
Thomas Koenig wrote:
If it’s part of a symbol used by the rest of the toolchain (assembler,
linker
debugger) then it’s also important to note that some OS/tool pairs might
be more constrained than the one you’ve tested. In particular, some
assemblers will not accept all
Thomas Koenig via Fortran wrote:
yes a configure option is a possible way around a conflict.
I was thinking more along making it a run-time option.
This is an option which will only be used by a developer,
who should know what the source code contains and what
the tool chain supports (and
Martin Liška wrote:
The build suffers from the static initialization order fiasco:
==30085== Invalid read of size 4
==30085==at 0x1D451CD: hash_table_mod1 (hash-table.h:344)
==30085==by 0x1D451CD:
hash_table::mem_location_hash,
vec_usage*,
Hi Thomas,
Thomas Koenig via Fortran wrote:
I guess the hard thing is for the developer to know that (s)he wants
the option and what to do when a conflict occurs.
Actually, I just hit on a much simpler solution.
:) .. I’m all in favour of simplicity.
We translate all symbols to lower
Jonathan Wakely wrote:
On 13/11/20 11:07 +, Jonathan Wakely wrote:
Currently this is shown when building libstdc++ on Solaris:
-lrt: open: No such file or directory
The error comes from the make_sunver.pl script which tries to open each
of its arguments. The arguments are passed by this
Uros Bizjak via Gcc-patches wrote:
On Mon, Nov 9, 2020 at 11:50 AM Hongyu Wang wrote:
Hi
According to the discussion in
https://gcc.gnu.org/pipermail/gcc/2020-November/234096.html,
The testcase for keylocker-* is too strict for darwin target. This
patch adjusted the regex, and add a missing
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 libstdc++ failures on AIX, even after Jonathan's
fixes. And a few c++ failures with similar symptoms. I'm not certain
Martin Sebor via Gcc-patches wrote:
On 11/3/20 4:13 AM, Richard Biener wrote:
This fixes the bad assumption that sizeof (bool) == 1
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
2020-11-03 Richard Biener
PR bootstrap/97666
* tree-vect-slp.c
Hi Marek,
Marek Polacek via Gcc-patches wrote:
> On Wed, Oct 28, 2020 at 02:46:36PM -0400, Jason Merrill wrote:
>> On 10/28/20 2:00 PM, Marek Polacek wrote:
>>> On Tue, Oct 27, 2020 at 01:36:30PM -0400, Jason Merrill wrote:
On 10/24/20 6:52 PM, Marek Polacek wrote:
> Here, in r11-155,
Hi Folks,
This patch breaks bootstrap on Darwin platforms.
Pierre-Marie de Rodat wrote:
> The modification file time precision now defined by OS.
>
> Tested on x86_64-pc-linux-gnu, committed on trunk
>
> gcc/ada/
>
> * adaint.c (__gnat_file_time): New routine.
>
Rainer Orth wrote:
Hi Pierre-Marie,
This fixes an issue when setting the baud rate. The baud rate is set
using the cfsetospeed and cfsetispeed system calls. The code is using
speed_t for clarity. The non-blocking status is only reset when Block is
True. And serial blocking mode is now
Rainer Orth wrote:
Rainer Orth wrote:
Hi Pierre-Marie,
This fixes an issue when setting the baud rate. The baud rate is set
using the cfsetospeed and cfsetispeed system calls. The code is using
speed_t for clarity. The non-blocking status is only reset when Block is
True. And serial
Jeff et. al.
> On 9 Jun 2021, at 17:23, Jeff Law via Gcc-patches
> wrote:
> On 5/25/2021 2:23 PM, Paul Eggert wrote:
>> The GCC manual's documentation of -fno-trampolines was apparently
>> written from an Ada point of view. However, when I read it I
>> understandably mistook it to say that
Hi Martin
Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end.
I’ve been gradually trying to improve/add locations in the ObjC stuff.
To that end, I wonder if it might be worth considering always supplying
the intended
Andrew MacLeod via Gcc-patches wrote:
On 5/25/21 11:03 PM, sunil.k.pandey wrote:
On Linux/x86_64,
a6e94287d31525b3ad0963ad22a92e9f3dbcd3cf is the first bad commit
commit a6e94287d31525b3ad0963ad22a92e9f3dbcd3cf
Author: Andrew MacLeod
Date: Tue May 25 14:59:54 2021 -0400
Remove the
Martin Sebor wrote:
On 5/25/21 8:01 AM, Iain Sandoe via Gcc-patches wrote:
Hi Martin
Martin Sebor via Gcc-patches wrote:
The attached patch replaces the uses of TREE_NO_WARNING in
the Objective-C front end.
I’ve been gradually trying to improve/add locations in the ObjC stuff.
To that end
Bill Schmidt via Gcc-patches wrote:
2021-03-04 Bill Schmidt
gcc/
* config/rs6000/darwin.h (SUBTARGET_INIT_BUILTINS): Use the new
decl when new_builtins_are_live.
* config/rs6000/rs6000-builtin-new.def (__builtin_cfstring): New
built-in.
This is fine from
Alan Modra via Gcc-patches wrote:
On 2021-05-04 8:42 a.m., Nick Clifton wrote:
Hi Guys,
On 4/30/21 7:36 PM, Simon Marchi wrote:
I think this fix is obvious enough, I encourage you to push it,
OK - I have pushed the patch to the mainline branches of both
the gcc and binutils-gdb
Alan Modra wrote:
On Wed, May 05, 2021 at 08:05:29AM +0100, Iain Sandoe wrote:
Alan Modra via Gcc-patches wrote:
On 2021-05-04 8:42 a.m., Nick Clifton wrote:
Hi Guys,
On 4/30/21 7:36 PM, Simon Marchi wrote:
I think this fix is obvious enough, I encourage you to push it,
OK - I have
David Edelsohn via Gcc-patches wrote:
On Wed, Mar 24, 2021 at 3:51 AM Richard Biener
wrote:
On Wed, Mar 24, 2021 at 3:03 AM David Edelsohn wrote:
On Mon, Mar 22, 2021 at 4:10 AM Richard Biener
wrote:
Oh, and for a type like
struct { struct { struct { ... { double x; } } } } } };
the
Segher Boessenkool wrote:
On Wed, Mar 10, 2021 at 02:41:50AM -0300, Alexandre Oliva wrote:
ppc configurations that have -mstrict-align enabled by default fail
gcc.dg/strlenopt-80.c, because some memcpy calls don't get turned into
MEM_REFs, which defeats the tested-for strlen optimization.
Alexandre Oliva wrote:
On Mar 11, 2021, Iain Sandoe wrote:
Alexandre Oliva wrote:
On Mar 10, 2021, Alexandre Oliva wrote:
* gcc.target/powerpc/prefix-ds-dq.c: Enable __float128.
I've been reminded that this is not enough for the scan-assembler tests
to pass, at least in our
Alexandre Oliva wrote:
On Mar 10, 2021, Alexandre Oliva wrote:
* gcc.target/powerpc/prefix-ds-dq.c: Enable __float128.
I've been reminded that this is not enough for the scan-assembler tests
to pass, at least in our configurations. Nearly all of the asm
expectations are unmet. I'm yet
David Edelsohn via Gcc-patches wrote:
I am requesting a freeze on non-bug fix patches to trunk.
In the GCC 12 announcement, Jakub stated:
"The trunk has branched for the GCC 11 release and is now open
again for general development, stage 1. Please consider not
disrupting it too much during
Hi Matt,
> On 14 Aug 2021, at 09:14, Matt Jacobson via Gcc-patches
> wrote:
>
> When -fobjc-nilcheck is enabled, messages that result in a struct type should
> yield a zero-initialized struct when sent to nil. Currently, the frontend
> crashes when it encounters this situation. This patch
Hi,
> On 20 Aug 2021, at 11:29, Richard Sandiford wrote:
>
>>> Maybe it would be easier to have the makefile fragments determine
>>> something like CODE_MODEL_CFLAGS, which can be "-fPIC", "-mdynamic-no-pic",
>>> etc., and use:
>>>
>>> COMPILER += $(NO_PIE_CFLAGS) $(CODE_MODEL_CFLAGS)
>>
>>
> On 25 Aug 2021, at 18:56, H.J. Lu via Gcc-patches
> wrote:
>
> On Wed, Aug 25, 2021 at 10:51 AM H.J. Lu wrote:
>>
>> On Wed, Aug 25, 2021 at 10:42 AM Iain Sandoe wrote:
>>>
>>> Hi,
>>>
On 20 Aug 2021, at 11:29, Richard Sandiford
wrote:
>> Maybe it would be easier
> On 25 Aug 2021, at 19:22, H.J. Lu wrote:
>
> On Wed, Aug 25, 2021 at 11:10 AM Iain Sandoe wrote:
>>
>>
>>
>>> On 25 Aug 2021, at 18:56, H.J. Lu via Gcc-patches
>>> wrote:
>>>
>>> On Wed, Aug 25, 2021 at 10:51 AM H.J. Lu wrote:
On Wed, Aug 25, 2021 at 10:42 AM Iain Sandoe
> On 3 Sep 2021, at 13:33, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Fri, Sep 03, 2021 at 01:32:14PM +0100, Iain Sandoe via Gcc-patches wrote:
>> diff --git a/libgcc/libgcc-std.ver.in b/libgcc/libgcc-std.ver.in
>> index cea33267e53..f5c1bc1aa6c 100644
>>
> On 3 Sep 2021, at 10:00, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Fri, Sep 03, 2021 at 03:41:13PM +0800, liuhongt via Gcc-patches wrote:
>> --- a/libgcc/config/i386/64/t-softfp
>> +++ b/libgcc/config/i386/64/t-softfp
>> @@ -1 +1,6 @@
>> softfp_extras := fixhfti fixunshfti floattihf
Hi Paul,
> On 1 Sep 2021, at 20:28, Koning, Paul via Gcc-patches
> wrote:
>
>> On Sep 1, 2021, at 3:08 PM, Jeff Law via Gcc-patches
>> wrote:
>> On 9/1/2021 12:57 PM, Koning, Paul wrote:
>>>
On Sep 1, 2021, at 1:35 PM, Jeff Law via Gcc-patches
wrote:
Generally OK.
Hi Hongtao.
> On 2 Sep 2021, at 07:06, Hongtao Liu via Gcc-patches
> wrote:
>
> I'm going to check in the first 3 patches which are already approved.
>
> Update hf soft-fp from glibc.
> [i386] Enable _Float16 type for TARGET_SSE2 and above.
> [i386] libgcc: Enable hfmode soft-sf/df/xf/tf
Patch below fixes bootstrap,
OK if it passes testing on x86_64 darwin/linux?
(if !OK .. then suggestions welcome)
thanks
Iain
> On 2 Sep 2021, at 16:18, Hongtao Liu wrote:
>
>
>
> On Thursday, September 2, 2021, Iain Sandoe wrote:
> Hi Hongtao.
>
> > On 2 Sep 2021, at 07:06, Hongtao Liu
> On 6 Sep 2021, at 08:08, Jakub Jelinek via Gcc-patches
> wrote:
>
> On Mon, Sep 06, 2021 at 09:42:32AM +0800, Hongtao Liu wrote:
>>> Also, shouldn't the *hf* and *hc* APIs be exported from libgcc_s.so.1?
>>>
>>> 254: 00011960 968 FUNCLOCAL DEFAULT 13 __floattihf
>>>
> On 16 Sep 2021, at 18:11, Qing Zhao via Gcc-patches
> wrote:
>
>
>
>> On Sep 16, 2021, at 10:47 AM, Jakub Jelinek wrote:
>>
>> On Thu, Sep 16, 2021 at 03:39:46PM +, Qing Zhao wrote:
Even -mtune= is needed if you want to stay safe, otherwise people testing
with
Hi Joseph,
> On 2 Sep 2021, at 21:03, Joseph Myers wrote:
>
> On Thu, 2 Sep 2021, Iain Sandoe via Gcc-patches wrote:
>
>> diff --git a/libgcc/soft-fp/eqdf2.c b/libgcc/soft-fp/eqdf2.c
>> index 2a44ee377ce..a3bb664f5f1 100644
>> --- a/libgcc/soft-fp/eqdf2.c
&
> On 15 Jul 2021, at 06:09, guojiufu via Gcc-patches
> wrote:
>
> On 2021-07-15 02:04, Segher Boessenkool wrote:
>
>>> +@deftypefn {Target Hook} machine_mode TARGET_PREFERRED_DOLOOP_MODE
>>> (machine_mode @var{mode})
>>> +This hook takes a @var{mode} which is the original mode of doloop
> On 2 Aug 2021, at 22:37, Matt Jacobson via Gcc-patches
> wrote:
>
>> On Aug 2, 2021, at 5:09 PM, Eric Gallager wrote:
>>
>> On Wed, Jul 28, 2021 at 11:36 PM Matt Jacobson via Gcc-patches
>> wrote:
>>>
>>> As is, an invocation of GCC with -fnext-runtime -fobjc-abi-version=2
>>>
Hi Folks
> On 11 Aug 2021, at 11:55, Segher Boessenkool
> wrote:
> On Tue, Aug 10, 2021 at 04:46:11PM -0600, Sandra Loosemore wrote:
>> OK. I used your wording verbatim for the first one. For the second
>> one, I'm still pretty confused as I think it is at least theoretically
>> possible
The code that checks to see if objects have LTO content via
simple-object was not releasing resources, fixed thus.
tested on x86_64, powerpc64le linux, powerpc-aix, i686,x86_64-darwin,
OK for master and backports?
thanks
Iain
Signed-off-by: Iain Sandoe
gcc/ChangeLog:
* collect2.c
This adds some missing quotes around options and option argument
terms in warning messages. Avoid contractions in warning
messages.
tested on x86_64 darwin, pushed to master, thanks
Iain
Signed-off-by: Iain Sandoe
gcc/ChangeLog:
* config/darwin-driver.c
After r12-4432-g7bfe7d634f60b0a9 Darwin fails to bootstrap with D
enabled since there is no definition of either DWARF2_DEBUG_INFO or
PREFERRED_DEBUGGING_TYPE.
Fixed here by adding the tm-dwarf2.h file to tm_d_file for Darwin.
tested on x86_64-darwin, pushed to master, thanks,
Iain
P.S. it is
We were not wrapping all the default libraries in checks for whether
they should be used. We were also wasting a process launch calling
dsymutil for 'r' link lines (a NOP in practice). Order the checks
that exclude linking from most likely to occur, downwards.
tested on powerpc, i686, x86_64,
Darwin has a user convenience feature where some linker options are exposed
at the driver level (so one can type '-all_load' instead of '-Wl,-all_load'
or '-Xlinker -all_load'). We retain this feature, but now these options are
all marked as 'Driver' and we process them as early as possible so
> On 16 Oct 2021, at 10:27, Andrew Pinski via Gcc-patches
> wrote:
>
> On Fri, Oct 15, 2021 at 6:53 AM Andrew MacLeod via Gcc-patches
> wrote:
>>
>> I've been looking at the pathological time issue ranger has with the
>> testcase from, uh.. PR 97623 I think. I've lost the details,
Hi,
Recognise .d for D source files on the command line. This will
trigger an invocation of dsymutil when a D source is present.
tested along with D patches on i686, powerpc and x86_64 darwin,
pushed to master, thanks,
Iain
gcc/ChangeLog:
* config/darwin.h (DSYMUTIL_SPEC): Recognize D
Hi,
We have a somewhat unusual situation in that for PPC64, R13 is
both reserved for future use by the ABI document and callee-saved.
In fact, it is already used internally by the pthreads
implementation to contain pthread_self.
So add R13 to the fixed regs, but also keep it in the callee-
Hi,
These two symbols have been emitted since 4.8, but were not added
to the Darwin exports, so we have been using the ones from libgcc.a.
Added to libgcc_s now.
tested on i686 and x86_64-darwin, pushed to master,
thanks
Iain
Signed-off-by: Iain Sandoe
libgcc/ChangeLog:
*
A recent improvement in Waddress causes a bootstrap failure on
targets that define TARGET_FORMAT_TYPES since it cannot be NULL
if defined to an address.
There is no default for this target macro, and it would seem no
purpose to defining it to NULL, so the warning appears reasonable.
Fixed by
From: John Eivind Helset
Hi,
The reported ICE occurs when an invalid (non-template) type is found
as the return for an await_suspend.
Fixed by amending build_co_await to ensure that await_suspend return-
type is a template-instantiation before checking to see if it is a
valid coroutine handle
Hi,
C++20 [expr.await] / 2
An await-expression shall appear only in a potentially-evaluated expression
within the compound-statement of a function-body outside of a handler.
tested on x86_64, powerpc64le-linux, x86_64-darwin, cppcoro and folly,
pushed to master as obvious, thanks
Iain
We do not support this yet.
fail with a sorry instead of ICEing.
tested on x86_64,powerpc64le-linux, x86_64-darwin, cppcoro, folly.
pushed to master as obvious, thanks
Iain
Signed-off-by: Iain Sandoe
PR c++/101765
gcc/cp/ChangeLog:
* coroutines.cc (register_local_var_uses):
Hi,
There was a missing STRIP_NOPS which meant that, in some cases,
an awaiter variable could be hidden by a view-convert-expr.
tested on x86_64, powerpc64le linux and x86_86 darwin.
pushed to master as trivial/obvious.
thanks,
Iain
Signed-off-by: Iain Sandoe
PR c++/99575
Hi,
Although it is not immediately evident from the symptoms, the PR is
caused by a variable having a DECL_INITIAL() containing a co_await.
This is not correct, since such expressions have side-effects.
We were marking the overall co_await expression correctly, but if a
consumer of that
This fixes a bootstrap fail because saw_static_libcxx was unused for
targets without support for -Bstatic/dynamic.
The fix applied pushes the -static-libstdc++ back onto the command
line, which allows a target to substitute a static version of the
c++ standard library using specs.
tested on
For coroutines, we make copies of the original function arguments into
the coroutine frame. Normally, these are destroyed on the proper exit
from the coroutine when the frame is destroyed.
However, if an exception is thrown before the first suspend point is
reached, the cleanup has to happen in
Hi H.J.
> On 19 Oct 2021, at 19:01, H.J. Lu via Gcc-patches
> wrote:
>
> On Tue, Oct 19, 2021 at 8:03 AM David Edelsohn wrote:
>>
>> My colleague built GCC, including GCC Go, with your patch:
>>
>> "I was able to build libgo and test it partially. The results are
>> similar to the current
> On 24 Oct 2021, at 21:40, H.J. Lu via Gcc-patches
> wrote:
>
> On Sun, Oct 24, 2021 at 1:36 PM Iain Sandoe wrote:
>>
>> Hi H.J.
>>
>>> On 19 Oct 2021, at 19:01, H.J. Lu via Gcc-patches
>>> wrote:
>>>
>>> On Tue, Oct 19, 2021 at 8:03 AM David Edelsohn wrote:
>>
My
We were pushing a spec value for weak_reference_mismatches unconditionally
which is not needed (the value was the default) and the side-effect of
this was that we appeared to need to drive a link command; leading to
unexpected diagnostics for cases where gcc was invoked with an empty
command line.
This adds a missed change from r12-5974-g926d64906af.
The builin_decls array has been renamed to drop the trailing
_x that was used during the main changes to the builtins.
This fixes bootstrap for powerpc-darwin9, tested there, pushed
to master, thanks,
Iain
Signed-off-by: Iain Sandoe
There was a race condition where the link for the new shared EH library
(only used on earlier Darwin) could fail because the new crts had not been
copied to the gcc directory. This can cause a build failure (although
currently only seen on powerpc-darwin).
Fixed by adding specific dependency on
Although we build the library with GCC which is known to support
_Static_assert this might be done on a system without the macro
mapping static_assert to the compiler keyword.
The use of static_assert introduced with r12-6126-g3430132f3e82
causes bootstrap to fail on such targets, fixed by using
There are places that we need to make different codegen depending
on the object format rather than on the arch. We already have
definitions for ELF, COFF etc. this adds one for MACHO.
Tested on i686, powerpc, x86_64 and aarch64 Darwin.
pushed to master, thanks
Iain
Signed-off-by: Iain Sandoe
We were checking whether the flag had been set by the user, but not if
it was set to true. Which means that the check fails in its intent when
the user puts -fno-reorder-and-partition.
Tested on i686, powerpc and x86_64-darwin. Pushed to master, thanks
Iain
Signed-off-by: Iain Sandoe
Hi Andrew,
> On 24 Dec 2021, at 10:51, Andrew Pinski wrote:
>
> On Fri, Dec 24, 2021 at 2:47 AM Iain Sandoe via Gcc-patches
> wrote:
>>
>>
>> @@ -3336,6 +3336,7 @@ darwin_override_options (void)
>> (s)he knows why... */
>
> I see you already
The current rule was too strict and has not been required since Darwin11.
This relaxes the constraint to allow up to 2^28 alignment for non-common
entities. Common is still restricted to a maximum aligment of 2^15.
When the host is an older version of Darwin ( earlier that 11 ) then the
Hi Iain
> On 19 Nov 2021, at 08:32, Iain Buclaw wrote:
> This patch fixes a stage2 bootstrap failure in the D front-end on
> darwin due to libgphobos being dynamically linked despite
> -static-libphobos being on the command line.
>
> In the gdc driver, this takes the previous fix for the
We want to produce a situation where a default rpath can be added
to each executable (or dylib), but that can be overridden by any
specific rpath provided by the user.
gcc/ChangeLog:
* config.gcc: Include rpath.opt
* config/darwin-driver.c (darwin_driver_init): Detect cases
This provides a spec to insert "-rpath DDD" for each DDD corresponding
to a compiler startfile directory. This allows a target to use @rpath
as the install path for libraries, and have the compiler provide the
necessary rpath to handle this.
gcc/ChangeLog:
* gcc.c (RUNPATH_OPTION): New.
Allow the Ada runtimes to find GCC runtimes relative to their non-
standard install positions.
gcc/ada/
* gcc-interface/Makefile.in: Add @loader_path runpaths to the
libgnat and libgnarl shared library builds.
---
gcc/ada/gcc-interface/Makefile.in | 2 ++
1 file changed,
This is a fairly long explanation of the problems being addressed by
the patch set. Most of the changes are Darwin-specific - a change to
the libtool component allowing for this @rpath and some minor additions
to makefiles where libtool is not in use. At present, this seems pretty
specific to
Recent Darwin versions place contraints on the use of run paths
specified in environment variables. This breaks some assumptions
in the GCC build.
This change allows the user to configure a Darwin build to use
'@rpath/libraryname.dylib' in library names and then to add an
embedded runpath to
At present, for several reasons, it is not possible to switch
Darwin to use .cfi instructions for frame output.
When GCC uses .cfi_ instructions, the behaviour w.r.t frame
sections (for a target with unwind frames by defaults):
(no options ) .eh_frame
(-g ) .eh_frame
(-g -fno-unwind-tables
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 tools themselves. This is already pruned
in the main testsuite, this adds
1 - 100 of 260 matches
Mail list logo
