The subprocess return string is raw bytes in python3, it must decode
before used as string, verifed with python2 and python3.
gcc/ChangeLog:
* config/riscv/multilib-generator (arch_canonicalize): Call
decode for the subprocess return value.
---
gcc/config/riscv/multilib-generator
This patch to the Go frontend avoids the ambiguity between "chan <-
(chan int)" and "chan (<- chan int)". This parenthesizes the same way
as the gc compiler. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
a40029e3b185a4b4e16a2a83933f742ff48c9743
diff --git
In upstream libtool, 47a889a4ca20 ("Improve GNU/Hurd support.") fixed
detection of shlibpath_overrides_runpath, thus avoiding unnecessary relink.
This backports it.
ChangeLog:
* libtool.m4: Match gnu* along other GNU systems.
* libffi/configure: Re-generate.
* libgomp/conf
The previous fix for PR 98160 was incomplete and while it fixed
the more interesting aspect of the problem (a false positive) it
didn't remedy the ICE that showed up only with LTO. I have
reduced (again) the problem to a non-LTO test case and committed
the attached trivial fix in r11-6329 after r
get_offset_range() expects integer and pointer arguments but can't
deal with others such as C++ OFFSET_TYPE. The attached fix has
the function fail for arguments of such types. I have committed
the trivial change in r11-6328 after regression-testing in on
x86_64-linux.
Martin
commit fdd8560cce9
Setting the EOF token location to be the start of a line just after
the ending newline is not most helpful. While that location is
probably the right place to report preprocessing and lexing issues,
when parsing, the location just after the last token is better. That
way we get to point at some
unsafe_return_slot_p wasn't recognizing an empty base as
potentially-overlapping, which it definitely is.
The change to build_base_path is to make the virtual conversion also
recognized by is_empty_base_ref; unsafe_return_slot_p doesn't to handle
virtual conversions, but hypothetical future caller
The Go frontend was treating indirections through pointers that had
been explicitly checked against nil and slice and string index
expressions as non-trapping memory references. That is true for
ordinary Go programs, but it isn't true if the programs construct
their own memory addresses. In parti
On 12/23/20 4:43 PM, Jakub Jelinek wrote:
On Wed, Dec 23, 2020 at 04:40:29PM -0500, Jason Merrill via Gcc-patches wrote:
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow3.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow3.C
new file mode 100644
index 000..22d4c59f4f8
--- /dev/
On Wed, Dec 23, 2020 at 04:40:29PM -0500, Jason Merrill via Gcc-patches wrote:
> diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow3.C
> b/gcc/testsuite/g++.dg/cpp0x/constexpr-overflow3.C
> new file mode 100644
> index 000..22d4c59f4f8
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/c
On 12/23/20 1:59 AM, Jakub Jelinek wrote:
On Tue, Dec 22, 2020 at 09:56:03AM -0500, Jason Merrill via Gcc-patches wrote:
Not exactly sure why we just don't call build_zero_cst (type); for the > scalar
types
I don't know either. Want to test that?
The following passed bootstrap/regtested on
The element initializer was non-constant, so its CONSTRUCTOR element ended
up NULL, so unshare_constructor crashed trying to look at it. This patch
fixes this in two places: First, by returning when we see a non-constant
initializer; second, by not crashing on NULL.
Tested x86_64-pc-linux-gnu, ap
On 12/23/20 10:07 AM, Martin Liška wrote:
Hello.
I'm not fully familiar with code in warn_dealloc_offset, but I guess
the following can work.
Martin, what do you think?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks for looking into it!
Hello.
I'm not fully familiar with code in warn_dealloc_offset, but I guess
the following can work.
Martin, what do you think?
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
PR tree-optimization/98160
In the Go frontend, all calls to the runtime functions slicecopy and
slicestringcopy were removed in https://golang.org/cl/170005. Remove
the remaining mentions. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
b26699c53b257d3354a4cfd3fc9174104f116154
diff --
Hi,
This patch forces the TYPE_MODE of non-POD types as BLKmode. Without
this being forced, the optimizer could still make decisions that require
objects of the non-POD types to need a temporary, which would result in
an ICE during the expand to RTL passes.
Bootstrapped and regression tested on
libcody's testsuite is not very portable, and is testing a host
library, so will do weird things on cross compiling, I think. Let's
just drop it.
libcody/
* Makefile.in (LDFLAGS): Drop -L..
* tests/01-serialize/connect.cc: Delete.
* tests/01-seri
[The same cure is needed for __builtin_trunc on 32bit SSE targets.]
x86_expand_truncdf_32 expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +. When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x
On Sun, 13 Dec 2020 at 20:14, abebeos
wrote:
>
>
> On Fri, 11 Dec 2020 at 20:32, Jeff Law wrote:
>
>>
>>
>> On 12/9/20 6:12 AM, abebeos via Gcc-patches wrote:
>> > Essence:
>> >
>> > I need a confirmation that the testsuite setup as presented in:
>> >
>> > https://github.com/abebeos/avr-gnu
>> >
On 12/22/20 6:49 PM, David Malcolm wrote:
On Tue, 2020-12-22 at 12:39 +0100, Martin Liška wrote:
Hello.
The patch adds a new test for an existing GCOV test-case. Newly
added run-gcov-pytest parses JSON format produced by GCOV and
runs pytest on it.
Patch can bootstrap on x86_64-linux-gnu and s
Matthias has confirmed this fixes the problem. pushing to trunk
This adds --enable-default-pie support to c++tools, so that the sample
server is build -fPIE if requested.
PR bootstrap/98324
c++tools/
* Makefile.in: Add FLAGPIE.
* configure.ac: A
On 12/22/20 4:23 PM, Jonathan Wakely wrote:
can be transformed into a switch statement can be transformed into a
switch statement
Good point! I'm going to install the patch with the fix of this.
Thanks,
Martin
Hi Jakub,
this patch is to fix some of the problems with target mapping when inside
C++ member functions:
1. Allow deref '->' in map clauses.
2. Allow this[X] in map clauses.
3. Create map(this->member) from map(member), when encountering member's
FIELD_DECL.
This actually may not be the last r
On Tue, 22 Dec 2020, 21:39 Alexandre Oliva, wrote:
>
> Undefine various macros unexpectedly defined by VxWorks headers.
>
> Regstrapped on x86_64-linux-gnu, and tested with -x-arm-wrs-vxworks7r2.
> Ok to install?
>
OK, thanks.
>
> from Olivier Hainque
> for libstdc++-v3/ChangeLog
>
>
With the fix to PR98047 "C: Drop qualifiers of assignment expressions."
also the new incorrect warning for assignment of certain volatile expressions
introduced by dropping qualifiers in lvalue conversion (PR97702)
disappeared [P98029]. This patch only adds a test case.
-- Martin
C: Add test
25 matches
Mail list logo
