https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061
--- Comment #3 from Mutex ---
Repeated with
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
The latest I have access to.
Same thing.
$ gcc -maes -Os *.c *.s
$ ./a.out
Segmentation fault (core dumped)
$ gcc -maes *.c *.s
$ ./a.out
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061
--- Comment #2 from Mutex ---
Created attachment 47545
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47545=edit
Updated example
Made a mistake in the first update which might've introduced a non-relevant
segfault. This fixes it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83411
Yury Gribov changed:
What|Removed |Added
CC||ygribov at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93062
Bug ID: 93062
Summary: Failed to generate indirect branch for long branches
on risc-v
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061
Andrew Pinski changed:
What|Removed |Added
Target||x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93061
Bug ID: 93061
Summary: Optimising for size -Os causes segfault with AES-NI
reference
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060
--- Comment #4 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49595#c11 :
The implementation-defined extended integer types are documented alongside
the other implementation-defined behavior in implement-c.texi: "GCC does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060
--- Comment #2 from fdlbxtqi ---
(In reply to Andrew Pinski from comment #1)
> >extended integer types
>
> Because it is not an extended integer type.
Ok. Thank you for your answer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060
fdlbxtqi changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060
--- Comment #1 from Andrew Pinski ---
>extended integer types
Because it is not an extended integer type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93060
Bug ID: 93060
Summary: __uint128_t is not an
std::integral/std::unsigned_integral
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020
--- Comment #3 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Dec 24 05:05:32 2019
New Revision: 279724
URL: https://gcc.gnu.org/viewcvs?rev=279724=gcc=rev
Log:
PR go/93020
libgo: Hurd portability patches
By Svante
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #4 from fdlbxtqi ---
A demo fix would be like this i think:
template
inline constexpr output_iter my_copy_n(input_iter first,std::size_t
count,output_iter result)
{
using input_value_type = typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #3 from fdlbxtqi ---
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/stl_algobase.h
I have found out the problem.
1. libstdc++ does not use memmove for different trivially copyable objects. It
only uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #2 from fdlbxtqi ---
Also find a bug of __memmove
/*
* A constexpr wrapper for __builtin_memmove.
* @param __num The number of elements of type _Tp (not bytes).
*/
template
_GLIBCXX14_CONSTEXPR
inline void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047
--- Comment #2 from Jiu Fu Guo ---
Sorry for missing -fpic
gcc builtin-return-1.c -O3 -fpic -frename-registers -o ./builtin-return-1.exe
and this issue can be reproduced on gcc7.4, gcc6.4 is ok.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93023
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
--- Comment #1 from fdlbxtqi ---
I am going to rewrite these functions by C++20 concepts + if constexpr for
C++20 for you, Jwakely. I do not believe these enable-if/ overloading functions
would not be a problem.
ported LTO compression algorithms: zlib
gcc version 10.0.0 20191223 (experimental) (somegcc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058
--- Comment #1 from Sergei Trofimovich ---
Th important bits seems to be:
gcc/testsuite/g++.dg/asan/asan_test.cc:129:22: error: writing 1 byte into a
region of size 0 [-Werror=stringop-overflow=]
I think it happens because glibc marks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93059
Bug ID: 93059
Summary: char and char8_t does not talk with each other with
memcpy. std::copy std::copy_n, std::fill, std::fill_n,
std::uninitialized_copy std::uninitialized_copy_n,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058
Bug ID: 93058
Summary: FAIL: g++.dg/asan/asan_test.C -O2 (test for excess
errors)
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93057
Bug ID: 93057
Summary: -flto=64 -o "t#o" leads to an error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86238
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #4 from TC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93056
Bug ID: 93056
Summary: Poor codegen for heapsort in stephanov_vector
benchmark
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93055
Bug ID: 93055
Summary: accumulation loops in stepanov_vector benchmark use
more instruction level parpallelism
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054
--- Comment #2 from Andrew Pinski ---
(In reply to prathamesh3492 from comment #1)
> I wonder if we should emit an error in the front-end if a noreturn function
> has non-void return type ? For above test-case, the function cb() is marked
> with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
--- Comment #3 from Andrew Pinski ---
I think https://gcc.gnu.org/install/specific.html#aarch64-x-x should be updated
rather than anything else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
--- Comment #2 from Andrew Pinski ---
Yes for aarch64, a 6 old binutils is too old. A 5 year old one is not though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #4 from Alexander Cherepanov ---
Could you please provide a bit more specific reference? If you mean various
discussions about C provenance semantics then they are not about these cases.
All examples in pr93051 and in this pr fully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
CC||prathamesh3492 at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70786
--- Comment #9 from Richard Earnshaw ---
comment 8 should be for pr70876.
On Mon, 2019-12-23 at 10:09 +, sch...@linux-m68k.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049
>
> --- Comment #1 from Andreas Schwab ---
> Make sure you have sysroot properly set up so that the gcc Makefile finds the
> system limits.h.
Do you mean this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
--- Comment #1 from Roman Zhuykov ---
Now I can confirm it started with r275967.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37377
--- Comment #17 from Richard Earnshaw ---
last patch was for pr37577.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93054
Bug ID: 93054
Summary: ICE in gimple_set_lhs, at gimple.c:1820
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
Bug ID: 93053
Summary: libgcc build failure with old binutils on aarch64
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93052
--- Comment #3 from Andrew Pinski ---
There is a C defect report about these cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65752
--- Comment #60 from Alexander Cherepanov ---
It seems to me that problems with the optimization `p == q ? p : q` -> `q`
(comment 15, comment 38, comment 56 etc.) are not specific to past-the-end
pointers. So I filed a separated bug for it with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #34 from Alexander Cherepanov ---
It seems to me that problems with the optimization `if (p == q) use p` -> `if
(p == q) use q` (comment 4 etc.) are not specific to past-the-end pointers. So
I filed a separated bug for it with
mp;& ./a.out
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
ounds of ‘int[1]’
[-Warray-bounds]
33 | *r = 2;
| ^~
test.c:22:9: note: while referencing ‘y’
22 | int y[1];
| ^
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
test.c && ./a.out
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
[-Wrestrict]
22 | f(, );
| ^~ ~~
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
Strictly speaking this example is
;
| ^
result: 1
--
gcc x86-64 version: gcc (GCC) 10.0.0 20191223 (experimental)
--
The warning nicely illustrates the problem:-)
Based on the example from Harald van Dijk in pr61502#c4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92961
Thomas Koenig changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93050
Bug ID: 93050
Summary: throw within constructor initialisation list causes
invalid free in destructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
--- Comment #4 from Pilar Latiesa ---
Minimal testcase ;-)
#include
struct TTensor {};
struct TCoefs
{
double aP;
std::valarray aF;
TTensor b;
};
TCoefs CalcCoefs()
{
double aP = 0.0;
return {aP, {}, {}};
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92644
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049
--- Comment #1 from Andreas Schwab ---
Make sure you have sysroot properly set up so that the gcc Makefile finds the
system limits.h.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
Arseny Solokha changed:
What|Removed |Added
CC||asolokha at gmx dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
--- Comment #2 from Pilar Latiesa ---
Even more reduced:
#include
template
struct TTensor {};
template
struct TCoefs
{
double aP;
std::valarray aF;
TTensor b;
};
template
class TExprDiv
{
public:
TCoefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
--- Comment #1 from Pilar Latiesa ---
Reduced:
#include
template
class valarray {};
template
struct TTensor
{};
template
struct TCoefs
{
double aP;
std::valarray aF;
TTensor b;
};
template
class TCampo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93049
Bug ID: 93049
Summary: limits.h generated by fixincludes breaks
cross-compilation
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
--- Comment #1 from rsandifo at gcc dot gnu.org
---
Author: rsandifo
Date: Mon Dec 23 09:43:46 2019
New Revision: 279717
URL: https://gcc.gnu.org/viewcvs?rev=279717=gcc=rev
Log:
[C++] Make same_type_p return false for gnu_vector_type_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93048
Bug ID: 93048
Summary: ICE in verify_gimple
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677
Eric Botcazou changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93047
Bug ID: 93047
Summary: frename-registers does not work well with
__builtin_return
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93041
fxue at gcc dot gnu.org changed:
What|Removed |Added
CC||fxue at gcc dot gnu.org
---
62 matches
Mail list logo
