bootstrap-ubsan shows:
gcc/hash-map.h:277:19: runtime error: member access within null pointer of
type 'struct hash_map'
Fix the issue by returning early.
bootstrap-ubsan on X86_64 and ppc64le. Tested on ppc64le.
OK for trunk?
gcc/
* hash-map.h (gt_cleare_cache): Avoid UB.
diff --git
bootstrap-ubsan shows:
gcc/expr.c:4103:17: runtime error: signed integer overflow: 0 -
-9223372036854775808 cannot be represented in type 'long int'
Fix by handling the saw_unknown case earlier.
bootstrap-ubsan on X86_64 and ppc64le. Tested on ppc64le.
OK for trunk?
PR rtl-optimizatio
Looking for something Jonathan pointed out, I noticed (again) that
our language is a bit verbose around our bug reporting / management
instructions.
Applied
Gerald
Add a link to our bug reporting instructions. Trim some language.
Index: management.html
=
On 24 November 2017 at 20:38, Christophe Lyon
wrote:
> On 24 November 2017 at 19:05, Tamar Christina wrote:
>> Hi Christophe,
>>
>>>
>>> After your commit, I have these reports:
>>> http://people.linaro.org/~christophe.lyon/cross-
>>> validation/gcc/trunk/255064/report-build-info.html
>>>
>>> Aft
On 11/23/2017 11:34 AM, JonY wrote:
> On 11/22/2017 11:14 AM, Boris Kolpackov wrote:
>> JonY <10wa...@gmail.com> writes:
>>
>>> Is there a problem with using .so for internal libraries instead of
>>> "dll"...
>>
>> I think not but I haven't tested it. The problem with using .so instead
>> of .dll i
Dear All,
This regression was caused by the patch for PR81447. The chunk that
has been modified came about because use association of derived types
in block data, in the presence of a vtable, was trying to add vtable
procedures, which is not allowed. The original patch did not
explicitly target bl
On 26 November 2017 at 13:56, Christophe Lyon
wrote:
> On 24 November 2017 at 20:38, Christophe Lyon
> wrote:
>> On 24 November 2017 at 19:05, Tamar Christina
>> wrote:
>>> Hi Christophe,
>>>
After your commit, I have these reports:
http://people.linaro.org/~christophe.lyon/cross
According to the description of inssp instruction from Intel CET it adusts the
shadow stack pointer (ssp) only by value in the range of [0..255]. As a number
of adjustment could be greater than 255 there should be a loop generated to
adjust ssp.
gcc/
* config/i386/i386.md: Add
On 11/24/2017 02:53 PM, Jakub Jelinek wrote:
> Hi!
>
> On most targets, N_SLINE has addresses relative to the start of
> the function, which means -gstabs{,+} is completely broken with
> hot/cold partitioning (fails to assemble almost anything that
> has both partitions). This used to be bearable
On 11/24/2017 11:18 AM, Olivier Hainque wrote:
> Hello,
>
> Bootstrap for mingw target configurations is failing today, with complaints
> about an inexistant /dev/null.
>
> The failing commands are issued by the selftest recipes in gcc/Makefile,
> using:
>
> SELFTEST_FLAGS = -nostdinc /dev/
On 11/26/2017 02:12 AM, Markus Trippelsdorf wrote:
> bootstrap-ubsan shows:
> gcc/expr.c:4103:17: runtime error: signed integer overflow: 0 -
> -9223372036854775808 cannot be represented in type 'long int'
>
> Fix by handling the saw_unknown case earlier.
>
> bootstrap-ubsan on X86_64 and ppc64
11 matches
Mail list logo