OK, Steve
Thanks
Paul
On Wed, 12 Jun 2019 at 02:04, Steve Kargl
wrote:
>
> The attached patch fixes an ICE when freeing an array-spec
> that involves an assumed-shaped coarray (see testcase). The
> patch regression tests cleanly. I don't use coarrays, so
> cannot say whether the testcase is
AArch64 comment for ADDSUB iterator is a typo or copy-and-paste error.
Attached patch fixes this. I believe this falls under obvious
category. I will commit it after 48hrs unless comments should be
better worded.
Thanks,
Kugan
gcc/ChangeLog:
2019-06-12 Kugan Vivekanandarajah
*
On 6/3/19 9:01 PM, Marek Polacek wrote:
I sort of ended up going down a rathole, but then I realized we don't need to
delay parsing of noexcept-specifiers of member friend function declarations,
because they aren't members of the class.
Where are you getting this from? I'm definitely
On неделя, 9 юни 2019 г. 17:38:58 EEST Segher Boessenkool wrote:
> Hi Dimitar,
>
> Just some comments, do with it what you want :-)
>
> On Sun, Jun 09, 2019 at 11:01:38PM +0300, Dimitar Dimitrov wrote:
> > +; An unfortunate side effect is that quite a few invalid RTL patterns are
> > +;
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-05/msg01513.html
On 5/22/19 10:42 AM, Martin Sebor wrote:
Attached is a revised implementation of the -Wformat-diag checker
incorporating the feedback I got on the first revision.
Martin
The attached patch fixes an ICE when freeing an array-spec
that involves an assumed-shaped coarray (see testcase). The
patch regression tests cleanly. I don't use coarrays, so
cannot say whether the testcase is valid Fortran. I simply
fixed the ICE. OK to commit?
2019-06-11 Steven G. Kargl
On 6/11/19 3:02 PM, Aldy Hernandez wrote:
On 6/11/19 12:52 PM, Martin Sebor wrote:
On 6/11/19 10:26 AM, Aldy Hernandez wrote:
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM
The sprintf and strlen passes both work with strings but
run independently of one another and don't share state. As
a result, lengths of strings dynamically created by functions
that are available to the strlen pass are not available to
sprintf. Conversely, lengths of strings formatted by
the
* Claudiu Zissulescu [2019-06-06 10:37:09 +0300]:
> Hi Sandra, Andrew
>
> Please find a small patch on the documentation which adds info about naked,
> ilink and firq function attributes.
>
> Ok to apply?
> Claudiu
>
> gcc/
> -xx-xx Claudiu Zissulescu
>
> * doc/extend.texi (ARC
On 6/11/19 12:52 PM, Martin Sebor wrote:
On 6/11/19 10:26 AM, Aldy Hernandez wrote:
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez
wrote:
This patch cleans
On 5/31/19 12:15 PM, Jonathan Wakely wrote:
>> Alright, thanks for the hint. I was just following the instructions in
>> gcc-9.1.0/fixincludes/README:
>>
>> """
>> Please also send relevant information to gcc-b...@gcc.gnu.org,
>> gcc-patches@gcc.gnu.org and,
>> please, to me: bk...@gnu.org.
>> """
On 5/31/19 6:35 AM, Jonas Jelten wrote:
> This code snippet of mingw's stdio.h:
>
>
> #ifdef _WIN64
> _CRTIMP FILE *__cdecl __iob_func(void);
> #define _iob __iob_func()
> #else
> [.]
> #if (!defined(NO_OLDNAMES) || defined(__GNUC__))
> __MINGW_EXTENSION typedef __int64 fpos_t;
>
Oops! Sorry about that, should be fixed now!
On Tue, Jun 11, 2019 at 3:32 PM Rainer Orth
wrote:
>
> Matthew Beliveau writes:
>
> > ChangeLog:
> >
> > 2019-06-11 Matthew Beliveau
>
>
> I don't believe this ;-)
>
> > * MAINTAINERS: Add
On 6/7/19 1:12 PM, Martin Sebor wrote:
> On 6/6/19 3:53 PM, Jeff Law wrote:
>> On 6/5/19 4:51 PM, Martin Sebor wrote:
>>> One of my new tests for the strlen/sprintf integration tripped
>>> over an incomplete handling of VLAs by the strlen pass. Where
>>> it can determine the length of a substring
On 6/8/19 3:21 PM, Faraz Shahbazker wrote:
> The __pool and __pend symbols are used to mark the beginning and end
> of inline constant pools in MIPS16 code regions. However if the pool
> occurs at the boundary of a code region and is not followed by further
> code, presence of the __pend symbol
On 6/9/19 2:01 PM, Dimitar Dimitrov wrote:
> This is the latest patch set for adding TI PRU I/O processor backend to GCC.
> Comments from all previous series have been addressed [1], [2], [3], [4], [5].
>
> Test results can be downloaded from here:
>
Hello
On 04/06/2019 11:05 pm, Julian Brown wrote:
Hi,
I've pushed a new branch "openacc-gcc-9-branch" to the Git
mirror (i.e. as a Git-only branch), for development of OpenACC and
related functionality on top of the GCC 9 branch. It's currently based
off the gcc-9_1_0-release tag, and contains
On Tue, Jun 11, 2019 at 03:05:26PM -0400, Jason Merrill wrote:
> On 6/11/19 2:28 PM, Marek Polacek wrote:
> > On Tue, Jun 11, 2019 at 08:37:27AM -0400, Jason Merrill wrote:
> > > On 6/11/19 7:47 AM, Jakub Jelinek wrote:
> > > > On Mon, Jun 10, 2019 at 09:59:46PM -0400, Marek Polacek wrote:
> > > >
On 6/11/19 1:23 AM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase, we handle the case where both attributes
> are on the same decl (as varpool_node::alias isn't set yet), by setting the
> section even on the alias and then diagnosing if it is different from the
> target's section
Matthew Beliveau writes:
> ChangeLog:
>
> 2019-06-11 Matthew Beliveau
I don't believe this ;-)
> * MAINTAINERS: Add myself.
>
> --- MAINTAINERS (revision 272167)
> +++ MAINTAINERS (working copy)
> @@ -316,6 +316,7 @@
> Gergö Barany
ChangeLog:
2019-06-11 Matthew Beliveau
* MAINTAINERS: Add myself.
--- MAINTAINERS (revision 272167)
+++ MAINTAINERS (working copy)
@@ -316,6 +316,7 @@
Gergö Barany
Charles Baylis
Tejas Belagod
+Matthew Beliveau
Jon Beniston
Andrew Bennett
Andrew Benson
On 6/11/19 2:28 PM, Marek Polacek wrote:
On Tue, Jun 11, 2019 at 08:37:27AM -0400, Jason Merrill wrote:
On 6/11/19 7:47 AM, Jakub Jelinek wrote:
On Mon, Jun 10, 2019 at 09:59:46PM -0400, Marek Polacek wrote:
This test segvs since r269078, this hunk in particular:
@@ -4581,8 +4713,9 @@
On 6/11/19 9:16 AM, Martin Liška wrote:
On 6/11/19 2:27 PM, Jason Merrill wrote:
On 6/11/19 3:41 AM, Martin Liška wrote:
On 6/10/19 8:21 PM, Jason Merrill wrote:
On Mon, Jun 10, 2019 at 3:08 AM Martin Liška wrote:
On 6/7/19 11:43 PM, Jason Merrill wrote:
On Fri, Jun 7, 2019 at 8:14 AM
On Tue, Jun 11, 2019 at 08:37:27AM -0400, Jason Merrill wrote:
> On 6/11/19 7:47 AM, Jakub Jelinek wrote:
> > On Mon, Jun 10, 2019 at 09:59:46PM -0400, Marek Polacek wrote:
> > > This test segvs since r269078, this hunk in particular:
> > >
> > > @@ -4581,8 +4713,9 @@ cxx_eval_constant_expression
This test currently fails on Darwin, because the port inlines fn2 for
both PIC (and non-pic for m32). Fixed by adjusting the target condition.
tested on x86_64-darwin6, x86_64-linux-gnu
applied to mainline
thanks
Iain
2019-06-11 Iain Sandoe
PR testsuite/65364
*
Tested x86_64-linux, committed to trunk.
Jonathan Wakely writes:
> On 29/05/19 23:53 +0100, Jonathan Wakely wrote:
>>On 29/05/19 15:32 -0700, Thomas Rodgers wrote:
>>> * include/pstl/algorithm_fwd.h: Synchronize with
>>> upstream PSTL project.
>>> * include/pstl/algorithm_impl.h:
Tested x86_64-linux, committed to trunk.
Jonathan Wakely writes:
> On 29/05/19 15:30 -0700, Thomas Rodgers wrote:
>>
>> * include/pstl/glue_memory_impl.h: Rename all macros of the form
>> _PSTL_(.*)_H to _PSTL_\U\1_H.
>> * include/pstl/numeric_impl.h: Likewise.
>> *
Tested x86_64-linux, committed to trunk.
Thomas Rodgers writes:
> Jonathan Wakely writes:
>
>> On 31/05/19 17:15 -0700, Thomas Rodgers wrote:
>>>
>>>Revising previous version of this patch to pick another missed
>>>uglification.
>>
>> OK for trunk, thanks.
>>
>> I also see this one:
>>
>>
Tested x86_64-linux, committed to trunk.
Thomas Rodgers writes:
> * include/bits/c++config: Adjust TBB detection logic to select serial
> PSTL backend if no TBB present.
> * testsuite/utils/pstl/test_utils.h: Remove check for
> __PSTL_USE_PAR_POLICIES
> ---
>
On 6/11/19 10:26 AM, Aldy Hernandez wrote:
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez
wrote:
This patch cleans up the various contains, may_contain, and
On 10-06-19 23:46, Jakub Jelinek wrote:
> Hi!
>
> In PTX, and accepts only .pred, .b16, .b32 and .b64 types, not .u64 etc.
> Fixed thusly, bootstrapped/regtested on x86_64-linux with nvptx-none
> offloading, ok for trunk and 9.2/8.4?
>
LGTM [and to Alexander as mentioned in PR90811 comment 3].
On 6/11/19 12:17 PM, Martin Sebor wrote:
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez
wrote:
This patch cleans up the various contains, may_contain, and
value_inside_range variants we have
On 6/11/19 9:05 AM, Aldy Hernandez wrote:
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez wrote:
This patch cleans up the various contains, may_contain, and
value_inside_range variants we have throughout, in favor of one--
contains_p. There should
On 6/11/19 7:59 AM, Matthew Beliveau wrote:
Hello,
Correct me if I'm wrong, but before the function checks for virtual
bases, an if-statement checks for extra_warnings on line 6049(when my
patch is applied). The check was there before I made my changes, and
my test fails
without -Wextra.
For op_by_pieces operations between two areas of memory, this patch adds
-fminimize-op-by-pieces-run to minimize number of operations. When
operating on LENGTH bytes of memory, it starts with the widest usable
integer size, MAX_SIZE, for LENGTH bytes and finishes with the smallest
usable integer
On 6/11/19 9:45 AM, Richard Biener wrote:
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez wrote:
This patch cleans up the various contains, may_contain, and
value_inside_range variants we have throughout, in favor of one--
contains_p. There should be no changes in functionality.
I have
On Tue, Jun 11, 2019 at 10:33:07AM -0400, Jason Merrill wrote:
> On 6/11/19 9:59 AM, Matthew Beliveau wrote:
> > Correct me if I'm wrong, but before the function checks for virtual
> > bases, an if-statement checks for extra_warnings on line 6049(when my
> > patch is applied). The check was there
On 6/11/19 9:59 AM, Matthew Beliveau wrote:
Correct me if I'm wrong, but before the function checks for virtual
bases, an if-statement checks for extra_warnings on line 6049(when my
patch is applied). The check was there before I made my changes, and
my test fails without -Wextra. Below is the
Hello,
Correct me if I'm wrong, but before the function checks for virtual
bases, an if-statement checks for extra_warnings on line 6049(when my
patch is applied). The check was there before I made my changes, and
my test fails
without -Wextra. Below is the code above the warning call:
if
On Tue, Jun 11, 2019, 6:45 AM Richard Biener wrote:
>
> The following fixes the documented(!) quadraticness in
> split_nonconstant_init_1 by simply marking to be removed
> constructor elements and doing that in a second run over
> the constructor.
>
> More micro-optimizing would be possible by
> On Tue, 11 Jun 2019, Jan Hubicka wrote:
>
> > > So the important thing is that during matching the paths
> > > aptr->a and *bptr we return false for
> > > same_type_for_tbaa (int *, struct a *), correct? But if
> > > we can do that then the alias sets should not conflict in
> > > the first
> Hmm, so looking at
>
> +DEFPARAM_Ofast (PARAM_ALLOW_STORE_DATA_RACES,
> "allow-store-data-races",
> "Allow new data races on stores to be introduced.",
> - 0, 0, 1)
> + 0, 1, 0, 1)
>
> once we want to have different defaults for -Os, -O2 and -Ofast
> we need
On Tue, Jun 11, 2019 at 12:40 PM Aldy Hernandez wrote:
>
> This patch cleans up the various contains, may_contain, and
> value_inside_range variants we have throughout, in favor of one--
> contains_p. There should be no changes in functionality.
>
> I have added a note to range_includes_zero_p,
On Tue, Jun 11, 2019 at 12:27 PM Aldy Hernandez wrote:
>
> We already have value_range::singleton_p. No need for a separate
> external function with the same functionality.
>
> OK?
OK.
Shame that there isn't some nicer syntax for
- return value_range_constant_singleton (get_value_range
> Hi.
>
> The assert in stream_out_histogram_value is wrong about single value
> counters where we can have a negative number as a target of an indirect
> call. And likewise we use special value -1 for counters that overflow.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression
On Tue, 11 Jun 2019, Jan Hubicka wrote:
> Hi,
> we plan to work on optimizing -O2 better for C++ code. This should
> involve enabling some limited auto-inlining and possibly other opts. To
> not ruin code size we plan to tune down the newly introduced
> optimizations as well as some of existing
Hi.
The assert in stream_out_histogram_value is wrong about single value
counters where we can have a negative number as a target of an indirect
call. And likewise we use special value -1 for counters that overflow.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to
Greetings,
This patch addresses a bug in ldr GOT for mcmodel=tiny in
which this instruction is not generated for ilp32 modes.
Defined 2 new patterns for ldr_got_tiny. Added additional
checks to use the appropriate rtl pattern for any of the modes.
Examples of previously unrecognized
On 6/11/19 2:27 PM, Jason Merrill wrote:
> On 6/11/19 3:41 AM, Martin Liška wrote:
>> On 6/10/19 8:21 PM, Jason Merrill wrote:
>>> On Mon, Jun 10, 2019 at 3:08 AM Martin Liška wrote:
On 6/7/19 11:43 PM, Jason Merrill wrote:
> On Fri, Jun 7, 2019 at 8:14 AM Martin Liška wrote:
>> On
On Tue, 11 Jun 2019, Jan Hubicka wrote:
> > So the important thing is that during matching the paths
> > aptr->a and *bptr we return false for
> > same_type_for_tbaa (int *, struct a *), correct? But if
> > we can do that then the alias sets should not conflict in
> > the first place and we
On 6/10/19 5:52 PM, Jakub Jelinek wrote:
Hi!
My PR85077
+ if (VECTOR_TYPE_P (TREE_TYPE (x)))
+ x = fold (x);
cp_fold change apparently broke the following and similar testcases, if
split_nonconstant_init splits the initialization into a runtime part and
some CONSTRUCTOR, it clears
On Sat, Jun 8, 2019 at 10:44 PM Marc Glisse wrote:
>
> Hello,
>
> this small tweak of fold_real_zero_addition_p lets it handle vectors as
> well.
>
> Bootstrap and regtest on x86_64-pc-linux-gnu.
OK.
Thanks,
Richard.
> 2019-06-10 Marc Glisse
>
> PR tree-optimization/62041
>
On 6/11/19 7:47 AM, Jakub Jelinek wrote:
On Mon, Jun 10, 2019 at 09:59:46PM -0400, Marek Polacek wrote:
This test segvs since r269078, this hunk in particular:
@@ -4581,8 +4713,9 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
tree t,
break;
case SIZEOF_EXPR:
-
On Fri, Jun 7, 2019 at 11:11 PM Jason Merrill wrote:
>
> A tree node that has been poisoned by ggc_free is easily recognizable by the
> TREE_CODE 0xa5a5; let's look for that rather than access some random memory
> off
> the end of the array.
>
> OK for trunk?
OK.
Richard.
> *
On 6/11/19 3:41 AM, Martin Liška wrote:
On 6/10/19 8:21 PM, Jason Merrill wrote:
On Mon, Jun 10, 2019 at 3:08 AM Martin Liška wrote:
On 6/7/19 11:43 PM, Jason Merrill wrote:
On Fri, Jun 7, 2019 at 8:14 AM Martin Liška wrote:
On 6/7/19 2:09 PM, Richard Biener wrote:
On Fri, Jun 7, 2019 at
Hi,
here is testcase for that.
I think we need to get rid of most -1 return values to make access path
matching work. Here we work out that stroing to *bptr
is not going to affect a since *bptr is a struct, but alias set
conflicts does not help.
This fails w/o patch sine struct b and int *
On Tue, 11 Jun 2019, Kewen.Lin wrote:
> >> If my understanding on this question is correct, IMHO we should try to make
> >> IVOPTs conservative than optimistic, since once the predict is wrong from
> >> too optimistic decision, the costing on the doloop use is wrong, it's very
> >> possible to
> So the important thing is that during matching the paths
> aptr->a and *bptr we return false for
> same_type_for_tbaa (int *, struct a *), correct? But if
> we can do that then the alias sets should not conflict in
> the first place and we shouldn't need any path-based disambiguation
> here.
>
On Mon, 10 Jun 2019, Jan Hubicka wrote:
> Hi,
> this is kind of minimal patch to handle pointers in access paths.
> I do not include logic for arrays nor attempt to deal better with incomparable
> pointers (such as pointers to two different incomplete record types).
>
> A lazy way would be to
On Mon, Jun 10, 2019 at 09:59:46PM -0400, Marek Polacek wrote:
> This test segvs since r269078, this hunk in particular:
>
> @@ -4581,8 +4713,9 @@ cxx_eval_constant_expression (const constexpr_ctx *ctx,
> tree t,
>break;
>
> case SIZEOF_EXPR:
> - r = fold_sizeof_expr (t);
> -
On Tue, Jun 11, 2019 at 11:50:40AM +0200, Jakub Jelinek wrote:
> The rest is just a general comment on the preexisting code.
> Using a bunch of const char *whatever = _("...");
> at the start of function is undesirable, it means any time this function is
> called, even in the likely case there is
The following fixes the documented(!) quadraticness in
split_nonconstant_init_1 by simply marking to be removed
constructor elements and doing that in a second run over
the constructor.
More micro-optimizing would be possible by recording the
first removed element index and special-casing
On Mon, Jun 10, 2019 at 10:37 PM Martin Sebor wrote:
>
> On 6/10/19 1:29 PM, Jakub Jelinek wrote:
> > On Mon, Jun 10, 2019 at 01:23:28PM -0600, Martin Sebor wrote:
> >> + else if (integer_zerop (TREE_OPERAND (node, 1))
> >> + /* Dump the types of INTEGER_CSTs explicitly, for we can't
> >>
This patch cleans up the various contains, may_contain, and
value_inside_range variants we have throughout, in favor of one--
contains_p. There should be no changes in functionality.
I have added a note to range_includes_zero_p, perhaps as a personal
question than anything else. This
On Mon, Jun 10, 2019 at 1:20 PM Marc Glisse wrote:
>
> Hello,
>
> if we compare for instance size() and capacity() for a std::vector, we get
> this kind of pattern. I started with just nop conversions and got a bit
> carried away handling all those cases.
>
> Bootstrap+regtest on
On Mon, Jun 10, 2019 at 11:47 AM Nick Clifton wrote:
>
> Hi Richard,
>
> OK, here is a resubmission of my patch with just the addition of the
> libctf patches this time. (Sorry about the previous bad patch).
> Tested with a bootstrap and a normal build. OK to apply ?
Sure.
Thanks,
We already have value_range::singleton_p. No need for a separate
external function with the same functionality.
OK?
commit 42981b54247461fcaa43d14315efa6fd3abbf949
Author: Aldy Hernandez
Date: Tue Jun 4 18:42:33 2019 +0200
Remove value_range_constant_singleton in favor of
Hi,
we plan to work on optimizing -O2 better for C++ code. This should
involve enabling some limited auto-inlining and possibly other opts. To
not ruin code size we plan to tune down the newly introduced
optimizations as well as some of existing ones (shuch as complete loop
unrolling) to make
On Tue, Jun 11, 2019 at 10:30:59AM +0100, Mark Eggleston wrote:
> Jim MacArthur
> Mark Eggleston
Two spaces before < instead of one.
This is not a patch review, just comments:
> This has to be written in a slightly verbose manner because GCC 7
> defaults to building with
On 10/06/2019 15:10, Mark Eggleston wrote:
On 10/06/2019 15:07, Thomas Koenig wrote:
Am 10.06.19 um 15:33 schrieb Mark Eggleston:
This patch is for a customer that has a huge codebase and that is
the only reason for its existence.
I didn't know gfortran as a whole has customers as such :-)
On 10/06/19 18:46 -0400, Ed Smith-Rowland via libstdc++ wrote:
On 6/10/19 2:43 AM, Ville Voutilainen wrote:
On Mon, 10 Jun 2019 at 02:53, Ed Smith-Rowland <3dw...@verizon.net> wrote:
Darn it, I had those constexpr lib patches in tree.
Attached are what I just committed to gcc-9 and passes
On Tue, 11 Jun 2019, Jakub Jelinek wrote:
> On Fri, Jun 07, 2019 at 09:07:39AM +0200, Martin Liška wrote:
> > 2019-06-07 Martin Liska
> >
> > * ansidecl.h:
> > (ATTRIBUTE_RESULT_SIZE_1): Define new macro.
> > (ATTRIBUTE_RESULT_SIZE_2): Likewise.
> >
On Mon, 10 Jun 2019, Marc Glisse wrote:
> On Wed, 5 Jun 2019, Richard Biener wrote:
>
> > The following was inspired by Marins work on escapes of locals
> > and the discussion there. It teaches points-to analysis that
> > the point of function return is special and thus escapes through
> > that
On 6/10/19 2:55 PM, Martin Liška wrote:
> Ready to be installed?
Jakub approved me this on IRC. Installed as r272144.
Martin
On 6/10/19 8:21 PM, Jason Merrill wrote:
> On Mon, Jun 10, 2019 at 3:08 AM Martin Liška wrote:
>> On 6/7/19 11:43 PM, Jason Merrill wrote:
>>> On Fri, Jun 7, 2019 at 8:14 AM Martin Liška wrote:
On 6/7/19 2:09 PM, Richard Biener wrote:
> On Fri, Jun 7, 2019 at 2:03 PM Martin Liška
On 6/10/19 11:53 PM, Jakub Jelinek wrote:
> On Mon, Jun 10, 2019 at 08:02:26PM +0200, Jakub Jelinek wrote:
>> This change broke build without target libc.
>>
>> ../../../../libgcc/libgcov-merge.c:37:6: error: conflicting types for
>> ‘__gcov_merge_single’
>>37 | void __gcov_merge_single
Hi!
On the following testcase, we handle the case where both attributes
are on the same decl (as varpool_node::alias isn't set yet), by setting the
section even on the alias and then diagnosing if it is different from the
target's section (would succeed with bar having baz section attribute).
If
Hi Expert,
I encounter a build error for llvm on ppc after upgrade gcc to 9.1.0
| collect2: fatal error: ld terminated with signal 11 [Segmentation fault]
The linker used here is powerpc-poky-linux-g++.
# powerpc-poky-linux-g++ -v
Using built-in specs.
COLLECT_GCC=powerpc-poky-linux-g++
www.fortran.org made a number of changes to their site which now
defaults to https, does not carry the FORTRAN 77 Standard any more
(that I could find it), and removed some other material.
This updates readings.html accordingly, and also streamlines the
Fortran section there a bit to reduce
79 matches
Mail list logo
