https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #7 from Eric Botcazou ---
> This nop behaviour could be a bit inconsistent across architectures. For
> example, arm and powerpc don't generate a nop here.
Well, it's low-level trickery so architecture-dependent by definition.
> I st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |10.3
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99358
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
--- Comment #2 from Eric Botcazou ---
Created attachment 50297
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50297&action=edit
Stopgap fix
To be applied on the 11 branch only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376
Eric Botcazou changed:
What|Removed |Added
Summary|Sanitizer detects undefined |Sanitizer detects undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376
--- Comment #2 from Eric Botcazou ---
> Clearly a pair of tests against HOST_BITS_PER_WIDE_INT is missing in:
>
> if (result_width < mode_width)
> nonzero &= (HOST_WIDE_INT_1U << result_width) - 1;
>
> if (result_low > 0)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70094
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|ebotcazou at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
--- Comment #4 from Eric Botcazou ---
> Worked a treat! on both x86_64 (for the code in the reproducer, which of
> course then went on to fail because of partial RTS) and for the original
> arm-eabi problem, which then executed its test code perf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2021-03-05
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
--- Comment #3 from Eric Botcazou ---
> gcc -v
No, what's needed is the output for the *base* compiler, i.e. the compiler you
start from, not the compiler you're building.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 99376, which changed state.
Bug 99376 Summary: sanitizer detects undefined behaviour in rtlanal.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99376
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99264
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99401
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
Summary|GCC11 MinGW-w64 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96983
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
Target|powerpc64*-linux-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99486
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #19 from Eric Botcazou ---
> a-ztflau.adb: In function 'Ada.Float_Wide_Wide_Text_Io.Aux_Float.Puts':
> a-ztflau.adb:132:8: error: insn does not satisfy its constraints:
> (insn 174 39 180 2 (set (mem/c:DF (plus:SI (reg/f:SI 30 %fp)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #24 from Eric Botcazou ---
> Technically, you have ;-) There's gcc211 in the cfarm, but
> unfortunately the installation is highly nonstandard, doesn't follow
> cfarm conventions, and lacks GNAT. While I do have a local gcc
> instal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99422
--- Comment #27 from Eric Botcazou ---
> Before the patches function process_address_1 used CONSTRAINT__UNKNOWN
> (taken from '=' of constraint "=T,..." and this is wrong) to check validity
> address. It was invalid and LRA added reloads for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99607
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Eric Botcazou changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Eric Botcazou changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Eric Botcazou changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #1 from Eric Botcazo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |SUSPENDED
--- Comment #3 from Eric Botca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #5 from Eric Botcazou ---
> I am very very rusty on Ada, what should I do to check that Id is good?
Probably put back the original assert on line 155.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
--- Comment #10 from Eric Botcazou ---
> 2021-03-17 Jakub Jelinek
>
> PR middle-end/98099
> * gcc.dg/pr98099.c: Don't compile the test on pdp endian.
> For big endian use -fsso-struct=little-endian dg-options.
>
> --- gcc/t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99624
--- Comment #7 from Eric Botcazou ---
> If I compile the build with -gnata, thereby arming the pragma assert,
> the build fails.
Then this proves that the sanitizer does not work since the assertion does not
trigger in a regular build, so there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641
--- Comment #1 from Eric Botcazou ---
I can reproduce, it's the expansion of __builtin_memcmp.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641
Eric Botcazou changed:
What|Removed |Added
Component|ada |middle-end
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99641
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99719
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802
Eric Botcazou changed:
What|Removed |Added
Summary|[11 regression] Assignment |[11 regression] assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
Eric Botcazou changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
--- Comment #9 from Eric Botcazou ---
> Richard, did you mean to CC me for another PR by any chance?
Never mind, I was confused by your commit.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966
Eric Botcazou changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
Eric Botcazou changed:
What|Removed |Added
Status|NEW |WAITING
--- Comment #11 from Eric Botcaz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97966
--- Comment #13 from Eric Botcazou ---
Yes, thanks for the quick turnaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99360
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|ebotcazou at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2020-10-22
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #12 from Eric Botcazou ---
> It still fails for me with g:2118438f49f0c193abe3fa3def350a8129045746
> Commit Date: Mon Oct 26 19:05:53 2020 +0100
The PowerPC64 issue is different, let me have a quick look at it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #13 from Eric Botcazou ---
This builds for me on powerpc64-linux, so I gather it's on powerpc64le-linux?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #16 from Eric Botcazou ---
> It's actually a partial cross compiler (-m32), please take a look at the
> build log.
What's this beast exactly? I'm afraid the build log is useless here, it would
be better to post the configure line an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #23 from Eric Botcazou ---
> It's a build log from OpenSUSE OBS, so it contains all that you requested.
AFAICS this log is for a native compiler:
[ 131s] checking build system type... powerpc64-suse-linux-gnu
[ 131s] checking host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #26 from Eric Botcazou ---
Created attachment 49471
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49471&action=edit
Tentative fix for the SuSE PowerPC compiler
Martin, can you give it a try when you get a chance?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Eric Botcazou changed:
What|Removed |Added
Attachment #49471|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Eric Botcazou changed:
What|Removed |Added
Attachment #49472|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #31 from Eric Botcazou ---
> Unfortunately, it still fails.
OK, can you try the new one?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97557
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
--- Comment #5 from Eric Botcazou ---
> as the comments says the check isn't correct but it might work for simple
> non-LTO cases. Anybody willing to try?
But isn't LTO towards being the default these days? If so, what's the point of
punishing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64711
--- Comment #7 from Eric Botcazou ---
> The issue with clearing nothrow is that those pesky builtins have
> that "sticky" while the per-stmt flag (gimple_call_nothrow ())
> just amends it. Guess we might want to fix that (in gimple_call_flags)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805
--- Comment #2 from Eric Botcazou ---
Created attachment 49555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49555&action=edit
Tentative fix
Please give it a try when you get a chance.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805
--- Comment #5 from Eric Botcazou ---
> We need:
>
> #include
We cannot do that unconditionally because it's also compiled as a C file.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805
Eric Botcazou changed:
What|Removed |Added
Attachment #49555|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97859
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97859
--- Comment #6 from Eric Botcazou ---
> target_cpu is powerpc64le
>
> Makefile.rtl:
>
> ifeq ($(strip $(filter-out powerpc64,$(target_cpu))),)
> ifneq ($(strip $(MULTISUBDIR)),/ppc)
> LIBGNAT_TARGET_PAIRS += $(GNATRTL_128BIT_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805
--- Comment #8 from Eric Botcazou ---
> Fix #2 works for me.
OK, thanks.
> Probably, should be new PR.
Nope, it's PR ada/97504, please follow up there.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97805
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97911
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2020-11-23
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
--- Comment #8 from Eric Botcazou ---
Sorry for dropping the ball, I'll get back to it momentarily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
--- Comment #6 from Eric Botcazou ---
> Not sure how useful this is but all of the following toss the same ICE :
>
> long f(long arg){return arg + 4096;}
>
> long f(long arg){return arg - 4096;}
>
> long f(long arg){return 4096 +
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #36 from Eric Botcazou ---
> The s390x build failure is still preset. Can you please take a look?
This one looks unrelated to r11-4029 or other Ada changes. Do you know which
revision has introduced it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97939
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |9.4
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082
--- Comment #1 from Eric Botcazou ---
What's the point of using -fipa-icf at -O0 exactly? P1 for this...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082
--- Comment #3 from Eric Botcazou ---
> It's an option fuzzing.
OK, but let's please do that in a smarter way and avoid nonsense like this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98127
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Eric Botcazou changed:
What|Removed |Added
CC||sch...@linux-m68k.org
--- Comment #39 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344
--- Comment #5 from Eric Botcazou ---
> A fresh build of trunk on x86_64 shows the following Ada failures:
>
> ! FAIL: gnat.dg/opt86a.adb (1: +1)
> ! FAIL: gnat.dg/opt86b.adb (1: +1)
> ! FAIL: gnat.dg/opt86c.adb (1: +1)
>
> The logs show thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98134
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Eric Botcazou changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment #40 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96470
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98199
--- Comment #3 from Eric Botcazou ---
> struct b {
> long a;
> short d;
> int c;
> int f;
> int e;
> int g;
> };
> struct h {
> int a;
> int i;
> short j;
> struct b k;
> signed : 20;
> int e;
> int g;
> } __attribute__(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458
--- Comment #4 from Eric Botcazou ---
> In general on x86 the compiler handles stack allocation (and probing when
> stack clash protection is enabled). However, on Windows targets that stuff
> is actually handled by calls to __chkstk_ms.
>
> On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #20 from Eric Botcazou ---
> So I'm going to look at this again. Some random thoughts on the Ada bools
> though. It would be nice if the Ada FE could leave boolean_type_node
> untouched so that when the middle-end produces a compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98230
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
---
1 - 100 of 1387 matches
Mail list logo
