http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51857
Alan Modra changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51926
Bug #: 51926
Summary: libstdc++ iterator store bigendian bitfield related
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
|UNCONFIRMED |ASSIGNED
Keywords||missed-optimization,
||wrong-code
Last reconfirmed||2012-01-21
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #39
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51926
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88311
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #6
dot gnu.org, |
|amodra at gmail dot com|
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88311
--- Comment #7 from Alan Modra ---
Hmm, it looks like combine is removing the long call.
hello2.c.262r.ud_dce:
(insn 10 9 11 2 (set (reg/f:SI 127)
(high:SI (symbol_ref:SI ("printf") [flags 0x41] ))) "hello2.c":5:3 651 {elf_high}
(n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88311
--- Comment #9 from Alan Modra ---
Created attachment 45235
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45235&action=edit
fix
r266604, git 0a4b5c66df9, "[RS6000] Use standard call patterns for
__tls_get_addr calls" is the patch that reg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88311
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88346
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
||2018-12-27
CC|amodra at gcc dot gnu.org |
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
dot gnu.org |
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment #3 from Alan Modra ---
The generated insn-attrtab.c insn_min_length differs after r267666, with a
bunch of insns returning INT_MAX. Prior to my patch,
genattrtab.c:min_attr_value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88777
--- Comment #4 from Alan Modra ---
Created attachment 45395
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45395&action=edit
fix
This patch results in exactly the same gcc/insn-*.[ch] on hppa-linux as
reverting r267666, and identical test-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #12 from Alan Modra ---
I suspect that the patch in comment #1 will break libcalls in other situations,
eg.
void f1 (int y)
{
extern double d;
d = y;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88614
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
--- Comment #17 from Alan Modra ---
> Is anything broken though?
Yes, as demonstrated by the testcase.
> If the libcall routines know they are called this way, all is fine.
They don't. libgcc functions are mostly C code that can make use of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #26 from Alan Modra ---
> I don't see that; I get
You need -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #27 from Alan Modra ---
And possibly -msecure-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 63197, which changed state.
Bug 63197 Summary: tc-m68k.c: Wrong warning "array subscript is below array
bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197
Alan Modra changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2018-04-27
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Created attachment 44063
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44063&action=edit
testcase
The attached testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135
Alan Modra changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2019-08-04
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
Huh, it looks like I missed adding the following to freebsd64.h:
#undef CPLUSPLUS_CPP_SPEC
#undef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91349
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91349
--- Comment #6 from Alan Modra ---
> Wouldn't it have been cleaner to split gnu_user.h
I agree. Please do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91349
--- Comment #9 from Alan Modra ---
> I have no idea which parts are GNU-specific, and which parts power actually
> needs.
Yeah, I was being cheeky in suggesting you provide the effort needed.
> I can just see that your change to include gnu-use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #8 from Alan Modra ---
Ah, no addsi3_carry won't work. You'll need a special version of elf_low that
trashes CA.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91289
--- Comment #13 from Alan Modra ---
(In reply to Segher Boessenkool from comment #9)
> My patch do not clobber r11, that's the point of it :-)
Eh, I shouldn't look at patches late at night. Even simple ones.
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
x86_64-linux, gcc r275988.
/home/alan/src/binutils-gdb/bfd/mach-o.c: In function
‘bfd_mach_o_init_segment’:
/home/alan/src/binutils-gdb/bfd/mach-o.c:3137:3: error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830
--- Comment #3 from Alan Modra ---
Created attachment 46904
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46904&action=edit
reduced testcase
-O2 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91830
Alan Modra changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Alan Modra ---
Con
gcc dot gnu.org |amodra at gmail dot com
--- Comment #2 from Alan Modra ---
Created attachment 46970
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46970&action=edit
fix currently under test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91676
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91938
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Created attachment 43235
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43235&action=edit
testcase
The attached testcase fails on ppc64le with -O2 -mcpu
||2018-01-25
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
Created attachment 43236
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43236&action=edit
p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84300
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
gcc dot gnu.org |amodra at gmail dot com
--- Comment #2 from Alan Modra ---
Testing what should be an obvious fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88343
--- Comment #33 from Alan Modra ---
It looks to me like that hunk is just removing some dead code, so it doesn't
matter whether it stays or goes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #10 from Alan Modra ---
Replying to comment #4, yes, the function decl is wrong. It should have the
full parameter list, or have none (ie. tree.c:prototype_p return false). The
powerpc ELFv2 ABI works fine with non-prototyped funct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
Alan Modra changed:
What|Removed |Added
Summary|Memory corruption on Power |PowerPC64 ELFv2 function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #12 from Alan Modra ---
A little more sophisticated.
* fortran/trans-types.c (gfc_get_function_type): Use a varargs decl
unless we have args other than hidden ones.
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/t
||amodra at gmail dot com
Resolution|--- |INVALID
--- Comment #1 from Alan Modra ---
No, the r2 load can't be moved. The ppc64 ABIs say the restore of r2 must
occur immediately after the call. This is necessary for exception unwinding.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #15 from Alan Modra ---
I've regression tested the patch on powerpc64le-linux, and of course verified
that it fixes the testcase. I'm also fairly certain the patch intent is
correct in the narrow sense of it correcting gfc_get_functi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #17 from Alan Modra ---
> On platforms where varargs have a different calling
> signature from normal functions, this would be an ABI change.
True, but in C terms, gfortran is currently doing this:
void f (char *res, int reslen);
..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89295
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #3 from Alan Modra ---
I believe this is a bug in rs6000_register_move_cost. Testing a fix.
||2019-02-14
CC||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87689
--- Comment #20 from Alan Modra ---
That is what I thought too at first, and why I though that making calls with
hidden args to be varargs was not going to be a problem. However, calling
build_varargs_function_type_vec with an empty typelist doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #5 from Alan Modra ---
Created attachment 45760
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45760&action=edit
Current set of patches
It turns out there is a lot more than just wrong register_move_cost. This
patchset does fi
||amodra at gmail dot com
Resolution|--- |INVALID
--- Comment #1 from Alan Modra ---
Not a gcc problem
||amodra at gmail dot com
Resolution|--- |INVALID
--- Comment #1 from Alan Modra ---
Not a gcc problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
--- Comment #10 from Alan Modra ---
> NON_SPECIAL_REGS removal
The gcc docs say of register classes: "You should define a class for the union
of two classes whenever some instruction allows both classes."
So this would seem to be going in the w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
Alan Modra changed:
What|Removed |Added
Attachment #45760|0 |1
is obsolete|
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Target Milestone: ---
Created attachment 45813
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45813&action=edit
preprocessed source
gold flagged this from a svn r26917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #1 from Alan Modra ---
Reduced C testcase, compile at -O1.
static const unsigned char utf8_bom[3] = { 0xEF, 0xBB, 0xBF };
void
plonk (unsigned char *p)
{
__builtin_memcpy (p, utf8_bom, 3);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Alan Modra changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Alan Modra changed:
What|Removed |Added
Priority|P1 |P3
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Alan Modra changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #17 from Alan Modra ---
The correct place for comment #15 patch is get_block_for_decl, I think. I'm
bootstrapping such a patch along with an assert in output_object_block that we
don't have a merge section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #18 from Alan Modra ---
The assertion triggered in multiple places when compiling various libgcc2.c
pieces, and dfp-bit.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #19 from Alan Modra ---
Created attachment 45829
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45829&action=edit
Prevent use of merge sections when -fsection-anchors
This isn't particularly elegant, but survives bootstrap and
-
||patches/2019-03/msg01299.ht
||ml
CC|amodra at gmail dot com|
--- Comment #16 from Alan Modra ---
Patch posted.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
Alan Modra changed:
What|Removed |Added
Priority|P1 |P3
--- Comment #21 from Alan Modra ---
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89271
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #8 from Alan Modra ---
Oh, and .LTHUNK0 is a function symbol with a local entry offset..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513
--- Comment #10 from Alan Modra ---
Yes, just like the function _ZN12Intermediate1vEv.
From here:
.set.LTHUNK0,_ZN12Intermediate1vEv
||2019-05-21
CC|amodra at gcc dot gnu.org |
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90545
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90689
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
Assignee
dot gnu.org, |
|amodra at gmail dot com|
Resolution|--- |FIXED
--- Comment #7 from Alan Modra ---
Fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #7 from Alan Modra ---
Huh, I'd forgotten that gas only reloads the opcode table when the cpu changes.
Be aware that .machine isn't a complete solution as it doesn't fix a wrong gas
command line for "gcc -c asm.S". You can't insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #8 from Alan Modra ---
Created attachment 46555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46555&action=edit
assembler command line fixes
I'll happily handle the assembler command line problems. Here's a lightly
tested pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91050
--- Comment #9 from Alan Modra ---
Created attachment 46556
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46556&action=edit
more assembler command line fixes
Another one for targets that default to altivec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91135
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72802
--- Comment #12 from Alan Modra ---
gcc.c-torture/compile/pr72802.c failed for me (likely with -mcpu=power9) with
the version of gcc I happened to have at the time I developed the patch in #c5.
I'm not sure now whether it was to demonstrate the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84300
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82368
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81682
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85075
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84033
--- Comment #8 from Alan Modra ---
Hi Breno, the first gcc-8 has not yet been released (current aim is for a
release mid April), nor has there been a release from the gcc-7 or gcc-6
branches containing this bug fix. I missed out on gcc-7.3 by a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83707
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84762
Alan Modra changed:
What|Removed |Added
CC||tamar.christina at arm dot com
--- Comment
||2018-12-04
CC|amodra at gcc dot gnu.org |
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88346
--- Comment #1 from Alan Modra ---
OK, good, the %e is doing its job in showing up missing cases.. And thanks for
pointing out the silly typo.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073
Bug #: 56073
Summary: SPEComp2012 376.kdtree fails to complete
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
||2013-01-22
AssignedTo|unassigned at gcc dot |amodra at gmail dot com
|gnu.org |
Ever Confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56073
Alan Modra changed:
What|Removed |Added
Target||powerpc64-linux
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56159
Bug #: 56159
Summary: config/linux/ptrlock.c lacks acquire barrier
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56159
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
201 - 300 of 872 matches
Mail list logo
