https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93962
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93961
Eric Botcazou changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
||2020-03-11
Ever confirmed|0 |1
CC||ebotcazou at gcc dot gnu.org
--- Comment #1 from Eric Botcazou ---
Please post the output of 'gcc -v' for the affected compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119
--- Comment #3 from Eric Botcazou ---
> The addiu s0,s0,0 instruction must only be issued once but instead is in
> several places. This leads to an invalid call at 9c.
Duplicating the instruction is not a problem per se if it is executed only on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119
Eric Botcazou changed:
What|Removed |Added
Target|Mips|mips*-*-*
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119
Eric Botcazou changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu.org |
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
--- Comment #13 from Eric Botcazou ---
I'm leaning towards calling extract_bit_field instead of operand_subword_force
on the value from store_integral_bit_field in order to generate the unaligned
load.
However, this triggers bad memories (see PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
Eric Botcazou changed:
What|Removed |Added
Component|target |middle-end
--- Comment #14 from Eric Bot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92071
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Summary|[10 regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
Eric Botcazou changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #12 from Er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94119
--- Comment #12 from Eric Botcazou ---
> I noticed that you accidentially put the wrong year into the ChangeLog.
Thanks, fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94359
--- Comment #10 from Eric Botcazou ---
> No. I guess Eric (Cc'ed) is in a better position to answer that.
Same as for PowerPC: look at the function_ok_for_sibcall predicate.
||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-04-04
--- Comment #1 from Eric Botcazou ---
> Please, note Ada is not C, Ada is about safety. A program should be checked
> for corectness a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94419
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
Summary|accepting wrong p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94573
--- Comment #3 from Eric Botcazou ---
> In particular, fixed with r10-3575-g629387a6586a753166f5cf53d587026a34362523
> I thought that commit was about store merging with non-call-expceptions, but
> apparently it affects more.
Possibly the adjust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717
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=94717
--- Comment #3 from Eric Botcazou ---
> The compiler is apparently not prepared for new trapping loads. Fixing...
No, just a missing check on landing pads:
index a6687cd9c98..4ab8e0250ab 100644
--- a/gcc/gimple-ssa-store-merging.c
+++ b/gcc/gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717
--- Comment #5 from Eric Botcazou ---
> Shouldn't that be done in try_coalesce_bswap instead?
> Because checking lp_nr above will only make sure it is the same between
> merged_store and the first store after it, but we are trying to coalesce
> o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94717
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896
Eric Botcazou changed:
What|Removed |Added
CC||polacek at redhat dot com
--- Comment #2
bootstrap errors on |[8/9/10/11 regression] Ada
|Cygwin64|bootstrap errors on
||Cygwin64
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94918
--- Comment #7 from Eric Botcazou ---
The Ada bits have been installed, but approval from a global maintainer is
needed for the libgcc bits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #13 from Eric Botcazou ---
Since Richard kindly invited me to the party, I feel entitled to voice my
personal opinion :-) which is apparently aligned with Richard's. I think that
we should allow REG_EQUAL notes for insns with exactly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #15 from Eric Botcazou ---
> So, hrm, we could in principle attach a REG_EQ* note to any single_set
> instruction?
Yes, I think that's what is currently implemented modulo bugs, although of
course we do not create a REG_EQUAL note fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #17 from Eric Botcazou ---
> Ok, so what we do about this bug then if it ought to be combine.c that needs
> changing? For REG_EQUAL notes in combine_instructions check for the
> auto-incdec side-effects in the pattern (I'd hope we do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65696
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95035
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Ever
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #2 from Eric Botcazou ---
Fixing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95035
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95333
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |11.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95452
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95395
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2020-06-01
Ever confirmed|0
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #3 from Eric Botcazou ---
Fixing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95395
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95433
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #8 from Eric Botcazou ---
Well, the middle-end provides build_nonstandard_boolean_type to build boolean
types with arbitrary precision so it cannot assume they have precision 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95582
--- Comment #10 from Eric Botcazou ---
> Yeah, that was for vector components. Not that I like it much. Can
> the middle-end assume that the Ada boolean types only contain 0 or 1
> or are there other values that are supposed to be well-defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-06-28
--- Comment #5 from Eric Botcazou ---
> Regardless, I think run-time enforcement of the immutability of constant
> data is important for so
||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Summary|generic instantiation fails |link failure with abstract
|to detect abstract |equality operator
||ebotcazou at gcc dot gnu.org
Last reconfirmed||2020-06-29
Ever confirmed|0 |1
--- Comment #1 from Eric Botcazou ---
Contributions welcome.
|-Wmaybe-unintialized
||warnings
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Martin Sebor ---
The first -Wmaybe-unintialized warning is issued for the read in this
statement:
SR.1076_294 = D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96019
--- Comment #4 from Eric Botcazou ---
> So AFAIU
>
> int main(int argc, char *argv[]) {
> uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 };
> SS instance;
> memcpy (&instance, raw, sizeof (SS));
> printf("%x, %x\n", instanc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92002
Eric Botcazou changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment #14 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95940
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Eric Botcazou changed:
What|Removed |Added
Component|target |rtl-optimization
Status|WAIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #29 from Eric Botcazou ---
It's again __builtin_unreachable making a mess in the RTL stream:
(note 23 11 24 [bb 3] NOTE_INSN_BASIC_BLOCK)
(jump_insn:TI 24 23 15 (set (pc)
(if_then_else (leu (reg/v:SI 24 %r24 [orig:99 g ] [99]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #30 from Eric Botcazou ---
Not clear what the right fix is... The hot spot in relax_delay_slots:
/* If this is a jump insn, see if it now jumps to a jump, jumps to
the next insn, or jumps to a label that is not the la
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
Eric Botcazou changed:
What|Removed |Added
Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96015
--- Comment #34 from Eric Botcazou ---
> Eric, thoughts?
Another possibility would be to remove the problematic barriers during the
barriers pass that is run just before reorg:
/* Some old code expects exactly one BARRIER as the NEXT_INSN of a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96167
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96228
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95730
--- Comment #5 from Eric Botcazou ---
> Therefore int128_t does not exist, as far as users are concerned. I'm not
> sure how that translates to the GCC internals, but trying to use TImode for
> anything other than moves is not going to work on GC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #12 from Eric Botcazou ---
> So with the attached 'updated patch' I see
>
> === gnat tests ===
>
>
> Running target unix/
> FAIL: gnat.dg/debug11_pkg.adb scan-assembler-not foreign_imported_func
> FAIL: gnat.dg/debu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #16 from Eric Botcazou ---
> So, for Ada, would you like to preserve current behavior rather than what
> Richard's patch does?
> If so, can't we have a langhook that decides that?
> I don't know much about Ada, but would think that ha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96383
--- Comment #22 from Eric Botcazou ---
On the other hand, if all it takes to avoid the new DIEs is to set the
DECL_IGNORED_P flag, then it might be simpler to go ahead with the change and
set the flag in Ada more often.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344
Eric Botcazou changed:
What|Removed |Added
Summary|[11 regerssion] |3rdd case of
|gnat.dg/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Eric Botcazou changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu.org |
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96607
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97053
--- Comment #2 from Eric Botcazou ---
The statement generated by DSE
MEM [(struct Data *)&data + 8B] = {};
looks nonsensical and I guess store-merging is not prepared for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078
--- Comment #1 from Eric Botcazou ---
The following few lines are enough on SPARC at -O2:
extern void foo (long double);
void bar (long double d)
{
foo (d);
}
|ASSIGNED
Last reconfirmed||2020-09-17
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #2 from Eric Botcazou ---
Fixing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2020-09-18
CC||ebotcazou at gcc dot gnu.org
Status|UNCONFIRMED |WAITING
--- Comment #1 from Eric Botcazou ---
What does 'gcc -v' print exactly? It looks like you're trying to bootstrap a
64-bit com
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #18 from Eric Botcazou ---
Investigating.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170
--- Comment #6 from Eric Botcazou ---
> I wasn't sure what the purpose of splitting at "." was (in particular since
> I think of GCC as a C/C++ compiler and the "." would not normally appear in
> qualified names as a separator).
Yet there is a c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #19 from Eric Botcazou ---
Created attachment 47084
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47084&action=edit
Tentative fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #20 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Oct 23 11:34:48 2019
New Revision: 277314
URL: https://gcc.gnu.org/viewcvs?rev=277314&root=gcc&view=rev
Log:
PR tree-optimization/92131
* tree-vrp.c (extract_rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #21 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Oct 23 11:37:28 2019
New Revision: 277315
URL: https://gcc.gnu.org/viewcvs?rev=277315&root=gcc&view=rev
Log:
PR tree-optimization/92131
* tree-vrp.c (extract_rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #22 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Oct 23 11:38:41 2019
New Revision: 277316
URL: https://gcc.gnu.org/viewcvs?rev=277316&root=gcc&view=rev
Log:
PR tree-optimization/92131
* tree-vrp.c (extract_rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Version|9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92131
--- Comment #23 from Eric Botcazou ---
Author: ebotcazou
Date: Wed Oct 23 13:17:34 2019
New Revision: 277331
URL: https://gcc.gnu.org/viewcvs?rev=277331&root=gcc&view=rev
Log:
PR tree-optimization/92131
* tree-vrp.c (extract_rang
||ebotcazou at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Eric Botcazou ---
Right, there is no requirement on the implementation of
__builtin_sadd_overflow, it just needs to produce correct results.
||2019-10-27
CC||ebotcazou at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Eric Botcazou ---
I can reproduce.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095
Eric Botcazou changed:
What|Removed |Added
CC|ebotcazou at gcc dot gnu.org, |
|ebotcazou at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170
--- Comment #9 from Eric Botcazou ---
> Is there a reason why -fstack-usage doesn't output mangled name ?
Yes, the output was supposed to be human-readable, that's why the location of
the function is also output.
> Wouldn't it better if it was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92303
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |8.4
Summary|ICE on sparc-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302
Eric Botcazou changed:
What|Removed |Added
Component|target |testsuite
--- Comment #2 from Eric Botca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302
--- Comment #3 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Nov 4 18:30:23 2019
New Revision: 277787
URL: https://gcc.gnu.org/viewcvs?rev=277787&root=gcc&view=rev
Log:
PR testsuite/92302
* gcc.target/sparc/sparc-ret-3.c: A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92302
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2019-11-07
CC||ebotcazou at gcc dot gnu.org
Target Milestone|--- |9.3
Summary|Compiler generates 2|[9/10 regression] double
|function calls in a 'with |elaborati
at gcc dot gnu.org |
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #2 from Eric Botcazou ---
Fixing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #9 from Eric Botcazou ---
> I don't think the inliner should work around this - this hasn't been
> necessary for Ada which is a good sign here. Eric - how does GiGi handle
> this
> case?
VLAs are always passed by reference in Ada.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92088
--- Comment #10 from Eric Botcazou ---
> VLAs are always passed by reference in Ada.
And, more generally, any type with variable size is too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095
--- Comment #5 from Eric Botcazou ---
Author: ebotcazou
Date: Fri Nov 8 12:30:47 2019
New Revision: 277966
URL: https://gcc.gnu.org/viewcvs?rev=277966&root=gcc&view=rev
Log:
PR target/92095
* config/sparc/sparc-protos.h (output_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095
--- Comment #6 from Eric Botcazou ---
Author: ebotcazou
Date: Fri Nov 8 12:33:48 2019
New Revision: 277967
URL: https://gcc.gnu.org/viewcvs?rev=277967&root=gcc&view=rev
Log:
PR target/92095
* config/sparc/sparc-protos.h (output_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095
--- Comment #7 from Eric Botcazou ---
Author: ebotcazou
Date: Fri Nov 8 12:38:03 2019
New Revision: 277968
URL: https://gcc.gnu.org/viewcvs?rev=277968&root=gcc&view=rev
Log:
PR target/92095
* config/sparc/sparc-protos.h (output_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92095
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2019-11-18
CC||ebotcazou at gcc dot gnu.org
Known to work||10.0, 8.3.0
Target Milestone|--- |9.3
Summary|GNAT Bug for Invalid_Value |[9 regression] internal
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
--- Comment #3 from Eric Botcazou ---
Investigating.
||2019-11-21
CC||ebotcazou at gcc dot gnu.org
Summary|trunk/gcc/ada/expect.c: 2 * |couple of suspicious
|suspicious assignments ?|assignments in expect.c
Ever confirmed|0 |1
at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575
--- Comment #2 from Eric Botcazou ---
Author: ebotcazou
Date: Mon Nov 25 10:29:51 2019
New Revision: 278671
URL: https://gcc.gnu.org/viewcvs?rev=278671&root=gcc&view=rev
Log:
PR ada/92575
* expect.c (__gnat_expect_poll [VMS, HPUX
1 - 100 of 5427 matches
Mail list logo
