https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #6 from Bernd Edlinger ---
const char a[2][3] = { "1234", "12" };
int main ()
{
{
volatile int i = 1;
int n = __builtin_strlen (a[i]);
n += __builtin_strlen (a[0]);
if (n != 3)
__builtin_abort ();
}
}
mayb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86542
Jakub Jelinek changed:
What|Removed |Added
Keywords||openmp
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86539
Jakub Jelinek changed:
What|Removed |Added
Keywords||openmp
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86542
Bug ID: 86542
Summary: wrong-code for collapsed taskloop which needs
omp_cpyfn
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543
Bug ID: 86543
Summary: [9 Regression] FAIL: gfortran.dg/dec_structure_23.f90
-O (test for errors, line 16)
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86539
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Tue Jul 17 08:06:25 2018
New Revision: 262776
URL: https://gcc.gnu.org/viewcvs?rev=262776&root=gcc&view=rev
Log:
PR middle-end/86539
* gimplify.c (gimplify_omp_for): Ensur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86456
--- Comment #6 from Richard Biener ---
Looks like binutils 2.30 readelf still isn't happy with dwarf5 produced for
LTO.
readelf: Error: Internal error: DWARF version is not 2, 3 or 4.
readelf: Warning: DIE at offset 0x12f refers to abbreviation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86539
--- Comment #2 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #7 from Bernd Edlinger ---
Maybe something like the following?
--- expr.c.kk 2018-07-17 10:14:43.668347058 +0200
+++ expr.c 2018-07-17 10:21:13.101779984 +0200
@@ -11282,6 +11282,7 @@ string_constant (tree arg, tree *ptr_off
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86520
--- Comment #7 from Richard Earnshaw ---
(In reply to Stephen Warren from comment #6)
> > Note that library code also assumes that misaligned accesses are safe:
> > that is the default for AArch64.
>
> I assume you're talking about gcc's default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86420
--- Comment #5 from nsz at gcc dot gnu.org ---
this fixed the glibc test failures for me.
(-ftrapping-math does not affect the const folding of arithmetics, i guess for
library functions it does, it would be less confusing if that was consistent)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86534
--- Comment #1 from Richard Biener ---
You can use --with-isl-lib=/usr/local/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86540
Richard Biener changed:
What|Removed |Added
Target||aarch64
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544
Bug ID: 86544
Summary: Popcount detection generates different code on C and
C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86517
--- Comment #7 from Jan Hubicka ---
Hi,
I am attaching patch I am testing and also table generated by a script that
walks through individual combinations of options. The combination rules are as
follows.
I tried to take into account that target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86534
--- Comment #2 from Дилян Палаузов ---
I can pass --with-isl-lib=/usr/local/lib, I can also compile ld.gold to have
implicit -L/usr/local/lib. But if gcc is supposed to be linkable with both
ld.bfd and ld.gold, then --with-isl-lib shall not be n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86541
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544
--- Comment #1 from kugan at gcc dot gnu.org ---
(In reply to ktkachov from comment #0)
> Great to see that GCC now detects the popcount loop in PR 82479!
> I am seeing some curious differences between gcc and g++ though.
> int
> pc (unsigned long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86545
Bug ID: 86545
Summary: [6/7/8/9 Regression] ICE in transfer_expr on invalid
WRITE statement
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86545
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86536
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86540
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86546
Bug ID: 86546
Summary: ICE on invalid: tree_class_check_failed()
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86315
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86545
--- Comment #1 from janus at gcc dot gnu.org ---
I guess the problem is the absence of the error message that one gets when
calling the specific function directly, without going through the generic
interface:
write(*,*) trim_string(s) ! cor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86542
--- Comment #1 from Jakub Jelinek ---
Author: jakub
Date: Tue Jul 17 10:54:52 2018
New Revision: 262815
URL: https://gcc.gnu.org/viewcvs?rev=262815&root=gcc&view=rev
Log:
PR middle-end/86542
* omp-low.c (create_task_copyfn): Copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86513
--- Comment #5 from Csaba Ráduly ---
BTW, I wasn't building in the source directory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #8 from Bernd Edlinger ---
$ cat part.c
const char a[2][3] = { "121", "1" };
int main ()
{
int n = __builtin_strlen (&a[0][0]);
n += __builtin_strlen (a[0]);
if (n != 8)
__builtin_abort ();
}
I think I find no way to st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #9 from Richard Biener ---
(In reply to Bernd Edlinger from comment #8)
> $ cat part.c
>
> const char a[2][3] = { "121", "1" };
>
> int main ()
> {
> int n = __builtin_strlen (&a[0][0]);
> n += __builtin_strlen (a[0]);
>
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #10 from Bernd Edlinger ---
(In reply to Richard Biener from comment #9)
>
> I bet Martin would argue it's invalid ...
>
> The standard specifies initializing char[3] with "121" is valid. 7.24.1/1
> specifies "if an array is access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #11 from Bernd Edlinger ---
But seriously:
/* Avoid returning a string that doesn't fit in the array
it is stored in, like
const char a[4] = "abcde";
but do handle those that fit even if they have excess
initial
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86523
--- Comment #5 from Dmitry G. Dyachenko ---
r262559 PASS
r262747 FAIL
$ cat x.ii
class a {
int b;
};
int const c = 0, d = 1, f = 2, g = 3;
struct B {
typedef a h;
h i;
};
template B j();
template struct k { static B const e; };
template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86162
--- Comment #2 from Jonathan Wakely ---
For the record, looks like it was fixed by r261621
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86513
--- Comment #6 from Jonathan Wakely ---
OK, I was just going by what you said:
(In reply to Csaba Ráduly from comment #3)
> [...] my usual "svn up && make bootstrap && make install" [...]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86523
Martin Liška changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86547
Bug ID: 86547
Summary: s390x: Maximum number of LRA assignment passes is
achieved (30) when compiling a small inline assembler
snippet
Product: gcc
Version: 9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84848
Uroš Bizjak changed:
What|Removed |Added
Target|hppa64-hp-hpux11.11 |hppa64-hp-hpux11.11,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
Bug ID: 86548
Summary: GCC could tmp file /tmp/ccDxn2Yd.ltrans0.ltrans.o
could be based on the compiled file name
Product: gcc
Version: 8.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86523
--- Comment #7 from Richard Biener ---
So there was no early debug info generated for the decl
in fact there's no early debug for anything besides the globals
c,d,f and g and artifical infrastructure.
Which is likely because everything is op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86456
--- Comment #7 from Richard Biener ---
Author: rguenth
Date: Tue Jul 17 12:26:21 2018
New Revision: 262819
URL: https://gcc.gnu.org/viewcvs?rev=262819&root=gcc&view=rev
Log:
2018-07-17 Richard Biener
PR lto/86456
* dwarf2out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84168
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Component|c |target
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84168
--- Comment #5 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Jul 17 12:43:43 2018
New Revision: 262821
URL: https://gcc.gnu.org/viewcvs?rev=262821&root=gcc&view=rev
Log:
Avoid assembler warnings from AArch64 constructor/destruct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86456
Richard Biener changed:
What|Removed |Added
Known to work||9.0
Summary|[8/9 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86523
--- Comment #8 from Richard Biener ---
Note while the patch fixes the reported issue it still ICEs the same way
when compiling with -g0 and linking with -g (as I would have expected).
That would be fixed by sth like the following but that then h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84168
--- Comment #6 from ktkachov at gcc dot gnu.org ---
Author: ktkachov
Date: Tue Jul 17 12:53:42 2018
New Revision: 262822
URL: https://gcc.gnu.org/viewcvs?rev=262822&root=gcc&view=rev
Log:
Avoid assembler warnings from AArch64 constructor/destruct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #3 from Ian Lance Taylor ---
Thanks for providing the gen-sysinfo.go file. I see that cmsghdr is defined in
that file. Several function declarations use it. It even has a size of 12
bytes. It's just missing a definition. So I'm c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86549
Bug ID: 86549
Summary: [8/9 Regression] -flto -g0 vs. -g issues
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, lto
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84168
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86549
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
tino.lange at factset dot com changed:
What|Removed |Added
CC||tino.lange at factset dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #22 from Jonathan Wakely ---
Author: redi
Date: Tue Jul 17 13:18:47 2018
New Revision: 262824
URL: https://gcc.gnu.org/viewcvs?rev=262824&root=gcc&view=rev
Log:
PR libstdc++/86450 use -Wabi=2 and simplify -Werror use
Use -Wabi=2 to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #23 from Jonathan Wakely ---
This should be fixed now, please confirm (I can't even get a build to complete
with --enable-maintainer-mode, I continue to be amazed you rely on something so
fragile).
--enable-maintainer-mode no longer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543
Fritz Reese changed:
What|Removed |Added
CC||foreese at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86549
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
Richard Biener changed:
What|Removed |Added
Keywords||lto
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
Martin Liška changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
--- Comment #3 from Richard Biener ---
(In reply to Jonny Grant from comment #0)
> It's pretty hard to work out which file this o file comes from. Could it
> include the first file name in the tmp path to make it clearer where it came
> from?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
--- Comment #4 from Jonny Grant ---
(In reply to Martin Liška from comment #2)
> I can implement that.
Great! Happy to pay bounty of $100 to you or GNU.
Could I ask for as short as possible tmp file name so output not too long. eg
could abrevi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> (In reply to Jonny Grant from comment #0)
> > It's pretty hard to work out which file this o file comes from. Could it
> > include the first file name in the tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86548
--- Comment #6 from Jonny Grant ---
(In reply to Richard Biener from comment #3)
> (In reply to Jonny Grant from comment #0)
> > It's pretty hard to work out which file this o file comes from. Could it
> > include the first file name in the tmp p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469
--- Comment #10 from Jonny Grant ---
[copy from other ticket]
(In reply to Richard Biener from comment #3)
> (In reply to Jonny Grant from comment #0)
> > It's pretty hard to work out which file this o file comes from. Could it
> > include the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86550
Bug ID: 86550
Summary: Lambda parsing allows arbitrary types in
decl-specifier-seq
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86550
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86550
--- Comment #1 from Jakub Jelinek ---
Created attachment 44403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44403&action=edit
gcc9-pr86550.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86541
--- Comment #2 from Richard Henderson ---
(In reply to Richard Biener from comment #1)
> Given that we have a target pass that makes use of SSE regs for scalar
> operations I wonder if it would make more sense to attack this at the
> target level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
Bug ID: 86551
Summary: [ICE] bare class and select type
Product: gcc
Version: 8.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82418
Dennis Lubert changed:
What|Removed |Added
CC||plasmahh at gmx dot net
--- Comment #5 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #12 from Martin Sebor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #4 from Curtis Hamilton ---
Here's the definition in sys/socket.h:
/*
* Header for ancillary data objects in msg_control buffer.
* Used for additional information with/about a datagram
* not expressible by flags. The format is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86480
--- Comment #5 from Jason Merrill ---
Author: jason
Date: Tue Jul 17 15:39:46 2018
New Revision: 262825
URL: https://gcc.gnu.org/viewcvs?rev=262825&root=gcc&view=rev
Log:
PR c++/86480 - nested variadic lambda and constexpr if.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #13 from Martin Sebor ---
(In reply to Richard Biener from comment #9)
>
> I bet Martin would argue it's invalid ...
That's right, the example in comment 8 is undefined because strlen() requires a
nul-terminated string argument and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
Thomas Koenig changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86520
--- Comment #8 from Stephen Warren ---
Great, thanks for all the explanations. Makes perfect sense.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469
--- Comment #11 from Jonny Grant ---
Hi Richard
I have a smaller test case which. It shows only part of the error.
"Dwarf Error: Invalid abstract instance DIE ref"
Richard, would this be useful?
g++-8 -std=c++11 -g -ggdb -pthread -O0 -Wnonnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #14 from Bernd Edlinger ---
(In reply to Martin Sebor from comment #13)
> (In reply to Richard Biener from comment #9)
> >
> > I bet Martin would argue it's invalid ...
>
> That's right, the example in comment 8 is undefined because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83184
--- Comment #8 from Fritz Reese ---
Author: foreese
Date: Tue Jul 17 16:02:03 2018
New Revision: 262828
URL: https://gcc.gnu.org/viewcvs?rev=262828&root=gcc&view=rev
Log:
2018-07-17 Fritz Reese
gcc/testsuite/ChangeLog:
PR fortra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86543
Fritz Reese changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469
--- Comment #12 from Jonny Grant ---
Created attachment 44404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44404&action=edit
Invalid DIE testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #5 from Ian Lance Taylor ---
Thanks. Unfortunately I don't know why this is failing.
Does it help if you edit the file libgo/sysinfo.c to move
#include
ahead of
#include
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
Franz Sirl changed:
What|Removed |Added
CC||sirl at gcc dot gnu.org
--- Comment #15 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86552
Bug ID: 86552
Summary: missing warning for reading past the end of non-string
arrays
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #16 from Martin Sebor ---
I would prefer to avoid discussing the array size rule and optimization in too
many places, and especially in bugs that aren't directly related to it. There
are other bugs where it is being discussed (mainly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #17 from Bernd Edlinger ---
Martin,
in expr.c at string_constant() there is an impossible check:
if (TREE_CODE (init) == CONSTRUCTOR)
{
if (TREE_CODE (arg) != ARRAY_REF
&& TREE_CODE (arg) == COMPONENT_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
Bug ID: 86553
Summary: libstdc++-v3 build failure on AIX 5.3
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #6 from Curtis Hamilton ---
Adding before solves the issue with "cmsghdr" but
not the other entries.
/usr/local/bin/gmkdir -p .; files=`echo
/usr/ports/lang/gcc7/work/gcc-7.3.0/libgo/go/runtime/alg.go
/usr/ports/lang/gcc7/work/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86551
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #25 from Steve Kargl ---
On Tue, Jul 17, 2018 at 01:24:00PM +, redi at gcc dot gnu.org wrote:
>
> --- Comment #23 from Jonathan Wakely ---
> This should be fixed now, please confirm (I can't even get a
> build to complete with -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554
Bug ID: 86554
Summary: Incorrect code generation with signed/unsigned
comparison
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86555
Bug ID: 86555
Summary: unaligned address for ldrd/strd on armv5e
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86554
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #18 from Bernd Edlinger ---
(In reply to Martin Sebor from comment #12)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00936.html
Sorry, Martin,
with your patch I have an ICE in the following test:
$ cat part.c
const char a[
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #19 from Bernd Edlinger ---
sorry wrong test case:
$ cat part.c
cat part.c
#define a "121\01"
int main ()
{
volatile int i=4;
int n = __builtin_strlen (&a[0]);
n += __builtin_strlen (&a[i]);
if (n != 4)
__builtin_abor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #20 from Bernd Edlinger ---
part.c.004t.original looks funny:
;; Function main (null)
;; enabled by -tree-original
{
volatile int i = 4;
int n = 4;
volatile int i = 4;
int n = 4;
SAVE_EXPR <= 4 ? 4 - (ssizetype) SAV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334
H.J. Lu changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81652
Bug 81652 depends on bug 85334, which changed state.
Bug 85334 Summary: Shadow stack isn't unwound properly through signal handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85334
What|Removed |Added
-
1 - 100 of 127 matches
Mail list logo