http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
Bug #: 56875
Summary: vax target miscompiles short negative constants for
64bit values
Classification: Unclassified
Product: gcc
Version: unknown
Status: UN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54226
Bug #: 54226
Summary: Executables compiled with -pie do not work on
NetBSD/sparc or sparc
Classification: Unclassified
Product: gcc
Version: 4.5.3
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54226
Martin Husemann changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Created attachment 30729
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30729&action=edit
test for bug 26905
Compiling the test from #26905 wit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
--- Comment #2 from Martin Husemann ---
Compare with this on amd64:
> c++ -o plain.s -S conftest.cc
> c++ -o shared.s -fPIC -shared -S conftest.cc
> diff -u plain.s shared.s
--- plain.s 2013-08-30 21:46:18.0 +0200
+++ shared.s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
--- Comment #4 from Martin Husemann ---
(In reply to Eric Botcazou from comment #3)
> So what? What happens if conftest.cc doesn't fiddle with visibility at all?
Sorry, I am not quite sure I understand what you are up to.
Same thing happens, s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
--- Comment #6 from Martin Husemann ---
Ooops, my lack of x86 ABI knowledge strikes again.
Indeed, visibility is properly expressed in the prologue, all is fine.
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Trying to configure gcc fails with an endless loop in one of the configure
tests of libstc++. There are actually two errors in this:
(1) a fatal error when reading a PCH file "had to rel
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370
--- Comment #1 from Martin Husemann ---
The fatal error seems to happen because NetBSD uses the default HAVE_MMAP_FILE
implementation of gt_pch_get_address and gt_pch_use_address instead of specific
host hooks.
Looking at the existing host hook i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370
--- Comment #3 from Martin Husemann ---
(In reply to Richard Biener from comment #2)
> Probably because nobody submitted and tested a NetBSD implementation.
You mean an evil hack to try to avoid the relocation (like all existing host
hooks seem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370
--- Comment #4 from Martin Husemann ---
To avoid confusion, I'm splitting this into two separate reports - will dig
further into the crash myself, since it is probably not easy to reproduce on
other host platforms.
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
I may be misunderstanding the interface - but it looks to me like it lets the
kernel chose an arbitrary
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
In toplev_main variable line_table is initialized and becomes 0x417dc000,
however, when
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58379
--- Comment #2 from Martin Husemann ---
(In reply to Richard Biener from comment #1)
> If you have a system that randomizes then you have to re-define the hook.
Besides ASLR there are various things out of control of the compiler that do
result i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
--- Comment #2 from Martin Husemann ---
Created attachment 30790
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30790&action=edit
Restore line_table and input_location before calling fatal_error when failing a
pch load
With this patch, the f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
--- Comment #1 from Martin Husemann ---
The global pointer "line_table" is changed to the contents of the precompiled
header file in gt_pch_restore in this loop:
/* Read in all the global pointers, in 6 easy loops. */
for (rt = gt_ggc_rtab;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397
--- Comment #1 from Martin Husemann ---
Created attachment 30803
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30803&action=edit
host hooks for NetBSD
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Created attachment 30802
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30802&action=edit
build glue changes
As discussed in #58370 and
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Compilation stops with:
../../../gcc-4.8.1/libgcc/libgcov.c:827:1: internal compiler error:
output_operand: invalid expression as operand
(will dig into it and provide more info)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
--- Comment #1 from Martin Husemann ---
The error happens here:
#1 0x002d15ca in output_addr_const (file=0x7f5b79c8,
x=0x7f10a250, 2136701384, 2131796560) at ../../gcc-4.8.1/gcc/final.c:3877
#2 0x002d1466 in output_addr_const (file=0x7f5b7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
--- Comment #2 from Martin Husemann ---
The more interesting XEXP(x, 0) of that rtx is the one triggering the failure:
$15 = {code = REG, mode = SImode, jump = 0, call = 0, unchanging = 0,
volatil = 0, in_struct = 0, used = 0, frame_related =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
Martin Husemann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
--- Comment #3 from Martin Husemann ---
Of course I do not mind fixing gas, but the whole point of the "D" formatting
code is to work around this assembler bug, and while this might be mostly
irrelevant nowadays, isn't gcc supposed to work with ot
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
During stage1 build of libstc++ this call dies with a segfault:
Reading symbols from /usr/pkgobj/lang/gcc48/work/build/gcc/cc1plus...done.
(gdb) run -quiet -nostdinc++ -v -I
/usr/pkgobj/lang/gcc48/work/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #1 from Martin Husemann ---
(gdb) x/i 0x0092cdb0
=> 0x92cdb0 : movb 0x14(r0),r0
(gdb) info reg
r0 0x4 4
r1 0x8 8
r2 0x0 0
r3 0xf0c308 15778568
r4 0x0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #3 from Martin Husemann ---
0x92c9fc :movab 0xff60(sp),sp
0x92ca01 :
movab *0xef3cfc <_GLOBAL_OFFSET_TABLE_+1548>,0xffd8(fp)
0x92ca09 : movl 0x4(ap),r0
0x92ca0d : movl 0x4(r0),0xf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #4 from Martin Husemann ---
I stared at the assembly a bit more (but my vax fu is weak):
we are in the last line of
216 #line 781 "../../gcc-4.8.1/gcc/config/vax/vax.md"
217 ((INTVAL (operands[1]) == 8 || INTVAL (operands[1])
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
Martin Husemann changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #5 from Martin Husemann ---
Just as a sanity check: I verified that the natively generated insn-recog.c is
the same as one cross compiled on an amd64 host.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #6 from Martin Husemann ---
To verify, I instrumented get_mem_attrs:
static inline struct mem_attrs *
get_mem_attrs (const_rtx x)
{
struct mem_attrs *attrs;
attrs = MEM_ATTRS (x);
attrs = MEM_ATTRS (x);
if (!attrs) {
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
Bug #: 53219
Summary: inline function erroneously clobbers %i0 register on
64 bit sparc comiple of perls regcomp.c
Classification: Unclassified
Product: gcc
Version: unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #1 from Martin Husemann 2012-05-03
21:34:13 UTC ---
It occured to me that gcc would (rightfully) behave this way, if the (previous)
value in %i0 should be considered dead at this point - which might be the case,
hard to tell due to lo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #2 from Martin Husemann 2012-05-04
07:56:48 UTC ---
I double checked: the sigsetjmp/siglonjmp function prototypes are properly
marked as returns_twice and noreturn, so I claim this to be abug in gcc ;-)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #4 from Martin Husemann 2012-05-04
13:27:37 UTC ---
Created attachment 27307
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27307
intermediate file when compiling regcomp.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #5 from Martin Husemann 2012-05-04
13:29:45 UTC ---
Using built-in specs.
COLLECT_GCC=cc
Target: sparc64--netbsd
Configured with: /usr/src/tools/gcc/../../external/gpl3/gcc/dist/configure
--target=sparc64--netbsd --enable-long-long --
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #7 from Martin Husemann 2012-05-06
10:59:19 UTC ---
Created attachment 27324
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27324
gcc -S output for the miscompiled function
The original report showed the disassembler output from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
Martin Husemann changed:
What|Removed |Added
CC||martin at netbsd dot org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #7 from Martin Husemann ---
I can reproduce the same crash on a different input file with a amd64 -> vax
cross compiler (so we can drop the theory that a miscompiled recog_1 function
causes this).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #8 from Martin Husemann ---
And apparently same cause:
ooops, bogus rtx mem attrs: 0x4
(subreg:SI (reg/v:DI 70 [ xtime ]) 4)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #9 from Martin Husemann ---
Please correct me if I am wrong, but in the bitfield cotexts in vax.md there
are multiple places with similar constructs like:
219&& (REG_P (operands[0])
220|| ! mode_dependent_address_p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #10 from Martin Husemann ---
Matt Thomas suggested to go with the easy solution for now: protect the calls
with MEM_P, i.e.: change the ! mode_dependent_address_p() in the bitfield
patterns to
(MEM_P(..) && ! mode_dependent_address_p
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Trying a native bootstrap on VAX fails when compiling libdecnumber with a
failed assertion here:
#0 0x0085637c in fancy_abort (file=0x8dae4d "../../gcc-4.8.2/gcc/emit-rtl.c",
line=2019,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #1 from Martin Husemann ---
The real question is: why does memory_address_addr_space_p() return false for
this rtx. Stepping into it results in:
0x007618be in vax_legitimate_address_p (mode=HImode, x=0x7ea0fd2c,
strict=20, 5, 212
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #2 from Martin Husemann ---
indexable_address_p() returns false for
(symbol_ref:SI ("DECPOWERS") [flags 0x40] )
because flag_pic is true and symbolic_operand (xfoo0, SImode)) returns true:
/* Return true if xfoo0 and xfoo1 constitut
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #3 from Martin Husemann ---
Matt asked for the instruction involved - I think it is this:
(insn 245 244 246 51 (set (mem:HI (reg/v/f:SI 1 %r1 [orig:67 sup ] [67]) [2
*sup_104+0 S2 A16])
(plus:HI (subreg:HI (mem/u/c:SI (plus:SI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #4 from Martin Husemann ---
I got a quick lesson in addressing modes for vax ;-)
It seems the mode = HImode passed to the upper functions in the call stack is
the problem - with HImode we can only use index operands with a factor of 2,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #5 from Martin Husemann ---
Created attachment 31275
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31275&action=edit
.i file from the failing compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #6 from Martin Husemann ---
This is beyound my gcc capabilities: the rtx in question is wrong for vax, but
the bug seems to be at a higher level: an indexed memory access can not be
wrapped into a subreg with offset in the same stateme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #3 from Martin Husemann ---
Indeed. Digging a bit with gdb (but in our local 6.4 version) shows:
#0 0x009fa7be in allocno_copy_cost_saving (allocno=0x7f7ff679a178,
hard_regno=11)
at /usr/src/tools/gcc/../../external/gpl3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85401
--- Comment #4 from Martin Husemann ---
The costs are missing for various modes:
(gdb) p (default_target_ira_int->x_ira_register_move_cost)
$6 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x7f7ff7b8c8b0, 0x7f7ff7b8c8b0, 0x0 }
(that is: only HImode and SImode co
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Target Milestone: ---
Gcc 7 has a new warning:
partman.c:1908:12: error: ' (' directive output may be truncated writing 2
bytes into a region of size between 1 and 255 [-Werror=format-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89312
--- Comment #2 from Martin Husemann ---
Thanks for the explanation, but I see no way I could improve the code in
question reasonably and (sorry to be blunt) consider it quite stupid of gcc to
warn about it by default.
I do want the total string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89312
--- Comment #4 from Martin Husemann ---
This is scary.
So in the future there will be valid reasons for the truncation warning, but
you are not offering any way to suppress the totally useless false positives?
My problem with this warning is th
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Target Milestone: ---
Created attachment 38464
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38464&action=edit
striped down example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71051
--- Comment #1 from Martin Husemann ---
Created attachment 38465
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38465&action=edit
generated asm code
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Target Milestone: ---
Created attachment 40719
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40719&action=edit
Simple example triggering the warning
When compiled with g++ -std=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695
Martin Husemann changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749
--- Comment #4 from Martin Husemann ---
Yes - I'm still trying to reduce it to a reasonable test case, but in general
it works - so I am confused big time.
Also Julio (the ATF author) claims the same test works on FreeBSD with a very
similar compi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807
--- Comment #4 from Martin Husemann ---
Neither can I on NetBSD/amd64 - will check with Thomas for differences on his
system
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807
--- Comment #5 from Martin Husemann ---
Thomas and I compared environments and found the difference: it is gcc compiled
by clang that misbehaves. I could reproduce and verify it - but past
bootstrapping it is something that will never happen to na
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
System: NetBSD/sparc64; NetBSD in-tree version of gcc:
> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: sparc64--netbsd
Configured with: /usr/src6/tools/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
--- Comment #1 from Martin Husemann ---
Here is a small test program:
---8<---
#include
#include
int main(int argc, char **argv)
{
unsigned long v[2], *p;
int a, b;
for (int i = 0; i < 2 && i < argc; i++) {
: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Created attachment 31793
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31793&action=edit
original source file exhibiting the problem
I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749
--- Comment #1 from Martin Husemann ---
Created attachment 31794
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31794&action=edit
unused_test.i file from -save-temps
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
This test program correctly dies when compiled with gcc 4.5.4:
#include
int main(int argc, char **argv)
{
char b[10];
strcpy(b, &q
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749
--- Comment #2 from Martin Husemann ---
Unfortunately I can not reproduce the issue with the .i file generated with
-save-temps (but still with the original .c file).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674
Martin Husemann changed:
What|Removed |Added
CC||martin at netbsd dot org
--- Comment
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Created attachment 31962
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31962&action=edit
generated assembler code (cc -O2 -S test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59958
--- Comment #2 from Martin Husemann ---
Is the alignment expected from malloc() configurable in gcc and/or different
from the standard stack alignment?
A small test program along the lines of
if ((uintptr_t)malloc(1) & mask) printf("yes\n") el
: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
With a gcc configured like this:
> mipsel--netbsd-gcc -v
Using built-in specs.
COLLECT_GCC=mipsel--netbsd-gcc
COLLECT_LTO_WRAPPER=/usr/pkg/libexec/gcc/mipsel--netbsd/4.9.0/lto-wrapper
Target: mip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61651
--- Comment #1 from Martin Husemann ---
Passing AS_FOR_TARGET (and friends) in the configure environment does not help,
but explicitly adding --with-as=.. does fix the issue.
So this looks like a pure configure bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397
Martin Husemann changed:
What|Removed |Added
Attachment #30803|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397
Martin Husemann changed:
What|Removed |Added
Version|4.8.1 |5.2.0
--- Comment #3 from Martin Husem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
Martin Husemann changed:
What|Removed |Added
Version|4.8.1 |5.2.0
--- Comment #3 from Martin Husem
y: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at netbsd dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: sparc64--netbsd
GCC host triplet: sparc64--netbsd
GCC target triplet: hppa--netbsd
http://gcc.gn
--- Additional Comments From martin at netbsd dot org 2004-11-14 10:06
---
Created an attachment (id=7543)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7543&action=view)
nd6.i - preproccessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
--- Additional Comments From martin at netbsd dot org 2004-11-14 19:56
---
Forgot to mention (and did not try myself): I've been told this same stuff
compiles just fine for NetBSD/hppa on a i386 host.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18473
Assignee: unassigned at gcc dot gnu.org
Reporter: martin at netbsd dot org
Target Milestone: ---
Created attachment 38787
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38787&action=edit
source code demonstrating the bug
Calculating the nth power of ten in below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695
Martin Husemann changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695
Martin Husemann changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592
Martin Husemann changed:
What|Removed |Added
CC||martin at netbsd dot org
--- Comment
81 matches
Mail list logo
