https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61583
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61583
--- Comment #4 from Alan Modra ---
Author: amodra
Date: Mon Jun 23 15:10:32 2014
New Revision: 211898
URL: https://gcc.gnu.org/viewcvs?rev=211898&root=gcc&view=rev
Log:
gcc/
PR bootstrap/61583
* tree-vrp.c (remove_range_asserti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61583
--- Comment #3 from Alan Modra ---
Author: amodra
Date: Mon Jun 23 15:08:30 2014
New Revision: 211897
URL: https://gcc.gnu.org/viewcvs?rev=211897&root=gcc&view=rev
Log:
gcc/
PR bootstrap/61583
* tree-vrp.c (remove_range_asserti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61583
--- Comment #1 from Alan Modra ---
A bit more poking and I see that VR info is being added during the vrp1 pass by
tree-vrp.c:remove_range_assertions, but not when -g.
Hmm, at a guess the root cause of the problem is that is_unreachable is being
||2014-06-23
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Seen first on ibm-4.9 branch with powerpc64, but also occurs on 4.9 branch with
both powerpc64 and x86_64. x86_64 configured with --enable-threads=posix
--disable
|--- |FIXED
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Target Milestone|4.8.4 |4.8.1
--- Comment #13 from Alan Modra ---
Fixed in 4.8.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #10 from Alan Modra ---
Author: amodra
Date: Wed Jun 11 23:50:16 2014
New Revision: 211483
URL: http://gcc.gnu.org/viewcvs?rev=211483&root=gcc&view=rev
Log:
PR target/61300
* doc/tm.texi.in (INCOMING_REG_PARM_STA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #9 from Alan Modra ---
Author: amodra
Date: Wed Jun 11 23:49:49 2014
New Revision: 211482
URL: http://gcc.gnu.org/viewcvs?rev=211482&root=gcc&view=rev
Log:
PR target/61300
* doc/tm.texi.in (INCOMING_REG_PARM_STA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #8 from Alan Modra ---
Author: amodra
Date: Fri Jun 6 01:04:22 2014
New Revision: 211296
URL: http://gcc.gnu.org/viewcvs?rev=211296&root=gcc&view=rev
Log:
PR target/61300
* doc/tm.texi.in (INCOMING_REG_PARM_STA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #7 from Alan Modra ---
No, I don't believe there is a convenient way we can look at the
REG_PARM_STACK_SPACE argument to determine whether it was used for a call or
for a function body. (I did think it might be possible, hence my com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61098
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|http://gcc.gnu.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #5 from Alan Modra ---
Actually, to work the patch in comment #3 would need to be
- if (!prototype_p (fun) || stdarg_p (fun))
+ if (1)
return true;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #4 from Alan Modra ---
You could do that, but smaller stack frames is one of the nice features of the
ELFv2 ABI! What I called the "quick and dirty" fix seems to be the way to go,
as the scheme I had in mind to avoid a new INCOMING_R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61098
--- Comment #2 from Alan Modra ---
Author: amodra
Date: Mon May 26 13:09:48 2014
New Revision: 210932
URL: http://gcc.gnu.org/viewcvs?rev=210932&root=gcc&view=rev
Log:
PR target/61098
* config/rs6000/rs6000.c (rs6000_emit_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61300
--- Comment #2 from Alan Modra ---
Created attachment 32854
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32854&action=edit
quick and dirty fix
This fixes the problem in a fairly obvious way, but I think we can use a more
refined approach
||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment #1 from Alan Modra ---
So, the "writes way past this" is writing into the parameter save area.
compare_kr is assuming that it was called with a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
--- Comment #15 from Alan Modra ---
Author: amodra
Date: Fri May 23 01:28:23 2014
New Revision: 210837
URL: http://gcc.gnu.org/viewcvs?rev=210837&root=gcc&view=rev
Log:
PR target/61231
* config/rs6000/rs6000.c (mem_operand_gpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
--- Comment #14 from Alan Modra ---
Author: amodra
Date: Fri May 23 01:24:08 2014
New Revision: 210836
URL: http://gcc.gnu.org/viewcvs?rev=210836&root=gcc&view=rev
Log:
PR target/61231
* config/rs6000/rs6000.c (mem_operand_gpr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231
--- Comment #13 from Alan Modra ---
Author: amodra
Date: Fri May 23 01:17:41 2014
New Revision: 210835
URL: http://gcc.gnu.org/viewcvs?rev=210835&root=gcc&view=rev
Log:
PR target/61231
* config/rs6000/rs6000.c (mem_operand_gpr)
||2014-05-21
CC||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #9 from Alan Modra ---
So, what's happening here o
||2014-05-08
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60737
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60737
--- Comment #4 from Alan Modra ---
Author: amodra
Date: Thu May 8 02:05:19 2014
New Revision: 210201
URL: http://gcc.gnu.org/viewcvs?rev=210201&root=gcc&view=rev
Log:
PR target/60737
* config/rs6000/rs6000.c (expand_block_move
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61098
--- Comment #1 from Alan Modra ---
Created attachment 32754
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32754&action=edit
testcase
,
||powerpc64le-linux
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2014-05-07
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Seen on a for (i = 0; i < 1; i++) loop
13bc: 3d 20 05 f5 lis r9,1525
13c0: 7d 29 03 a6 mtctr r9
13c4: 7d 3e 1a 14 add r9,r30
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61032
--- Comment #1 from Alan Modra ---
This is a code quality regression from gcc-4.7.2
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
-mcmodel=medium introduced a code model where addresses typically need two
instructions. As illustrated in the following, the fact that rs6000 lacks an
address_cost function to say that
|4.10.0
Last reconfirmed||2014-05-01
Component|middle-end |target
CC||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
|--- |FIXED
--- Comment #7 from Alan Modra ---
Blah, committed the patch with the wrong pr number, 57935 vs 57936.
Author: amodra
Date: Wed Feb 26 21:57:40 2014
New Revision: 208186
URL: http://gcc.gnu.org/viewcvs?rev=208186&root=gcc&view=rev
Log:
PR target/57936
* r
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57935
--- Comment #4 from Alan Modra ---
Author: amodra
Date: Wed Feb 26 21:57:40 2014
New Revision: 208186
URL: http://gcc.gnu.org/viewcvs?rev=208186&root=gcc&view=rev
Log:
PR target/57935
* reload1.c (emit_input_reload_insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57935
--- Comment #3 from Alan Modra ---
Author: amodra
Date: Wed Feb 26 04:41:53 2014
New Revision: 208166
URL: http://gcc.gnu.org/viewcvs?rev=208166&root=gcc&view=rev
Log:
Apply mainline r207798
PR target/58675
PR targ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
--- Comment #8 from Alan Modra ---
Author: amodra
Date: Wed Feb 26 04:41:53 2014
New Revision: 208166
URL: http://gcc.gnu.org/viewcvs?rev=208166&root=gcc&view=rev
Log:
Apply mainline r207798
PR target/58675
PR targ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
--- Comment #6 from Alan Modra ---
Bill, the ppc64-abi-dfp-1.c ICE is cured by the patch committed for pr58675 on
the trunk. Now committed to ibm-4.8.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
Alan Modra changed:
What|Removed |Added
Target Milestone|--- |4.9.0
gcc dot gnu.org |amodra at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59844
Alan Modra changed:
What|Removed |Added
CC||anton at samba dot org
--- Comment #5 from A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
Alan Modra changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57935
--- Comment #2 from Alan Modra ---
Author: amodra
Date: Sat Feb 15 10:49:55 2014
New Revision: 207798
URL: http://gcc.gnu.org/viewcvs?rev=207798&root=gcc&view=rev
Log:
PR target/58675
PR target/57935
* config/rs6000/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
--- Comment #6 from Alan Modra ---
Author: amodra
Date: Sat Feb 15 10:49:55 2014
New Revision: 207798
URL: http://gcc.gnu.org/viewcvs?rev=207798&root=gcc&view=rev
Log:
PR target/58675
PR target/57935
* config/rs6000/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
--- Comment #3 from Alan Modra ---
The testcase doesn't ICE since 206639. That wasn't an rs6000 patch so we
probably still have the underlying issue in the rs6000 backend.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936
--- Comment #2 from Alan Modra ---
No, cancel comment #1, I was fooled by version skew between the unpatched and
the patched compiler. The testcase doesn't ICE on recent versions of gcc.
||2014-02-10
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
This one also seems to be fixed by the patch in pr58675.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
Alan Modra changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58675
--- Comment #4 from Alan Modra ---
*** Bug 57935 has been marked as a duplicate of this bug. ***
||amodra at gmail dot com
Resolution|--- |DUPLICATE
--- Comment #1 from Alan Modra ---
This is exactly the same issue as pr58675.
*** This bug has been marked as a duplicate of bug 58675 ***
||2014-02-10
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #3 from Alan Modra ---
I reckon this is overly restrictive checking in rs6000_secondary_reload_inner.
rtl during reload is a little messy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
--- Comment #8 from Alan Modra ---
*** Bug 60029 has been marked as a duplicate of this bug. ***
||amodra at gmail dot com
Resolution|--- |DUPLICATE
--- Comment #1 from Alan Modra ---
Fixed by r207553. I'm not sure why this one didn't show up in the list of
tests I reported fixed in
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00273.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
--- Comment #4 from Alan Modra ---
Author: amodra
Date: Thu Feb 6 13:25:38 2014
New Revision: 207553
URL: http://gcc.gnu.org/viewcvs?rev=207553&root=gcc&view=rev
Log:
PR target/60032
gcc/
* config/rs6000/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073
--- Comment #7 from Alan Modra ---
The variadic support in libfii is fairly recent. And yes, it might have been
there earlier if the testcases actually tested what they were suppose to test!
Note that powerpc64-gcc passes fp arguments correspond
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60073
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
--- Comment #3 from Alan Modra ---
No, not quite. SECONDARY_MEMORY_NEEDED_MODE looks to be required by lra, so
make rs6000_secondary_memory_needed_mode depend on lra_in_progress.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60032
Alan Modra changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|amodra at gcc
||2014-02-04
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #1 from Alan Modra ---
Reduced testcase
void foo (void)
{
register float __attribute__ ((mode(SD))) r31 __asm__ ("r31");
regi
||2014-01-16
CC||amodra at gmail dot com
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59814
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #1 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #24 from Alan Modra ---
Nick's latest patch passes bootstrap and regression testing powerpc64-linux.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #19 from Alan Modra ---
Jakub, you're correct. I should have read the standard on flexible array
members before poking at this bug last year. Nick's patch is looking good to
me.
ISO/IEC 9899:1999 is quite clear that the answer to co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #17 from Alan Modra ---
I believe Eric's comment
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00179.html points at the correct
fix, but it's a bit messy. You need to recursively descend both "decl" and
"init" in code like c-decl.c:fin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #16 from Alan Modra ---
Hi Nick, that patch looks exactly like my first attempt to fix this bug. I
forget the details now but I'm fairly certain it wasn't a complete fix, which
is why I didn't submit my patch..
Note that the underlyi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
--- Comment #9 from Alan Modra ---
Once upon a time I understood this code quite well, but it's been a while since
I looked at it in detail, and I'd forgotten that inout gets split to separate
input and output operands if a register is allowed.
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57586
--- Comment #6 from Alan Modra ---
Author: amodra
Date: Tue Sep 24 11:32:28 2013
New Revision: 202866
URL: http://gcc.gnu.org/viewcvs?rev=202866&root=gcc&view=rev
Log:
PR middle-end/57134
PR middle-end/57586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134
--- Comment #6 from Alan Modra ---
Author: amodra
Date: Tue Sep 24 11:32:28 2013
New Revision: 202866
URL: http://gcc.gnu.org/viewcvs?rev=202866&root=gcc&view=rev
Log:
PR middle-end/57134
PR middle-end/57586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
Alan Modra changed:
What|Removed |Added
Target Milestone|--- |4.8.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
Alan Modra changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
--- Comment #6 from Alan Modra ---
Author: amodra
Date: Mon Sep 23 14:27:56 2013
New Revision: 202830
URL: http://gcc.gnu.org/viewcvs?rev=202830&root=gcc&view=rev
Log:
PR target/58330
* gcc.target/powerpc/pr58330.c: New.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
--- Comment #5 from Alan Modra ---
Author: amodra
Date: Mon Sep 23 14:27:06 2013
New Revision: 202829
URL: http://gcc.gnu.org/viewcvs?rev=202829&root=gcc&view=rev
Log:
PR target/58330
* config/rs6000/rs6000.md (bswapdi2_64bit):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57589
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
Resolution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57589
--- Comment #5 from Alan Modra ---
Author: amodra
Date: Tue Sep 17 02:04:49 2013
New Revision: 202642
URL: http://gcc.gnu.org/viewcvs?rev=202642&root=gcc&view=rev
Log:
PR target/57589
* config/rs6000/driver-rs6000.c (elf_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57134
--- Comment #5 from Alan Modra ---
r200086 fixed Anton's first testcase but then he found another one. See
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00983.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
--- Comment #4 from Alan Modra ---
Author: amodra
Date: Tue Sep 10 08:38:57 2013
New Revision: 202428
URL: http://gcc.gnu.org/viewcvs?rev=202428&root=gcc&view=rev
Log:
PR target/58330
oops, missed from commit
Added:
trunk/gcc/t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
--- Comment #3 from Alan Modra ---
Author: amodra
Date: Mon Sep 9 23:48:10 2013
New Revision: 202418
URL: http://gcc.gnu.org/viewcvs?rev=202418&root=gcc&view=rev
Log:
PR target/58330
gcc/
* config/rs6000/rs6000.md (bswapd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58330
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
Alan Modra changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58034
Alan Modra changed:
What|Removed |Added
Known to work||4.7.2
Known to fail|
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
Created attachment 30575
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30575&action=edit
preprocessed test case
nprl/tst-cleanup2 fails when compiled with -O2 -mcpu=power6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57865
--- Comment #4 from Alan Modra ---
Created attachment 30489
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30489&action=edit
Fix ool_adjust
Please verify that this fixes the problem
||2013-07-10
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #2 from Alan Modra ---
My guess is that it's this change
-#define FIRST_SAVED_GP_REGNO 13
+#define FIRST_SAVED_GP_
Assignee: unassigned at gcc dot gnu.org
Reporter: amodra at gmail dot com
On powerpc64 with -mcmodel=small -O1, this
int x;
void f1 (long long hx)
{
if (hx < 0x3ff0LL)
x++;
}
results in
.L.f1:
lis 9,0x3fef
ori 9,9,65535
sldi 9,9,32
oris 9,9,0xf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57717
Alan Modra changed:
What|Removed |Added
CC||amodra at gmail dot com
--- Comment #3 from
||amodra at gmail dot com
Component|target |middle-end
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
Severity|major |normal
||http://gcc.gnu.org/ml/gcc-p
||atches/2013-06/msg00642.htm
||l
Assignee|unassigned at gcc dot gnu.org |amodra at gmail dot com
||2013-05-10
CC||amodra at gmail dot com
Ever confirmed|0 |1
--- Comment #7 from Alan Modra ---
Fix mainline and 4.8
http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00282.html
http://gcc.gnu.org/ml/gcc-cvs/2013-05/msg00283
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180
Alan Modra changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180
Bug #: 57180
Summary: Structures with a flexible arrray member have wrong
size
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #10 from Alan Modra 2013-05-04 14:39:34
UTC ---
Incidentall, I expect the patch referred to in comment #6 will ICE with
tree-checking on due to CONSTRUCTOR nodes not having the required fields for
DECL_SIZE_UNIT.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28865
--- Comment #9 from Alan Modra 2013-05-04 14:34:39
UTC ---
>From what I see on current mainline for a testcase based on
glibc/nss/nss_files/files-init.c the var_decl size and the type size agree and
are correct. What causes a problem with
_this >
constant addressable asm_written static ignored BLK file
/home/amodra/src/gcc-current/libjava/classpath/gnu/java/awt/dnd/peer/gtk/GtkDragSourceContextPeer.java
line 0 col 0
size
constant 384>
unit size
constant 48>
align 64 initial
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #12 from Alan Modra 2013-05-03 10:47:22
UTC ---
Created attachment 30017
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30017
Use .org instead of padding in section anchor block
This one ensures that offsets of emitted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #11 from Alan Modra 2013-05-03 10:42:12
UTC ---
No, of course that doesn't work. We make references into the section anchor
block as .LANCHORn+offset, so the items in the block must be exactly where
place_block_symbol() expect
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
Alan Modra changed:
What|Removed |Added
Target Milestone|4.8.1 |---
--- Comment #10 from Alan Modr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #5 from Alan Modra 2013-05-02 14:01:59
UTC ---
So the section anchor code places vars (and constants) in blocks according to
their alignment and sizes (varasm.c:place_block_symbol). The calculations are
all good, offsets are p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57074
--- Comment #4 from Alan Modra 2013-05-02 11:35:20
UTC ---
I believe this is triggered by powerpc turning on -fsection-anchors by default,
and a section anchor bug loses the alignment. The classes are all nicely
aligned if I compile with
701 - 800 of 1596 matches
Mail list logo
