https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110592
Martin Husemann changed:
What|Removed |Added
CC||martin at netbsd dot org
--- Comment
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
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
: 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-truncation
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71695
Martin Husemann changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
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=edit
Simple example triggering the warning
When compiled with g++ -std=gnu+
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=71695
Martin Husemann changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=edit
source code demonstrating the bug
Calculating the nth power of ten in below simple prog
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=edit
generated asm code
: 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=edit
striped down example C code
Attac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
Version|4.8.1 |5.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
Attachment #30803|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
Version|4.8.1 |5.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61651
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
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.
: 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: mipsel
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/gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60941
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
Here is a small test program:
---8---
#include stdio.h
#include stdlib.h
int main(int argc, char **argv)
{
unsigned long v[2], *p;
int a, b;
for (int i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807
--- Comment #5 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60807
--- Comment #4 from Martin Husemann martin at netbsd dot org ---
Neither can I on NetBSD/amd64 - will check with Thomas for differences on his
system
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749
--- Comment #4 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59958
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
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
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=31962action=edit
generated assembler code (cc -O2 -S test.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59674
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
CC||martin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
Unfortunately I can not reproduce the issue with the .i file generated with
-save-temps (but still with the original .c file).
: 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=31793action=edit
original source file exhibiting the problem
I have a program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59749
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
Created attachment 31794
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31794action=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 string.h
int main(int argc, char **argv)
{
char b[10];
strcpy(b, 1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #5 from Martin Husemann martin at netbsd dot org ---
Created attachment 31275
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31275action=edit
.i file from the failing compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #6 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #3 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #4 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58901
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
indexable_address_p() returns false for
(symbol_ref:SI (DECPOWERS) [flags 0x40] var_decl 0x7f22fe60 DECPOWERS)
because flag_pic is true and symbolic_operand (xfoo0, SImode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #10 from Martin Husemann martin at netbsd dot org ---
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
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,
function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #9 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #7 from Martin Husemann martin at netbsd dot org ---
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 martin at netbsd dot org ---
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 #5 from Martin Husemann martin at netbsd dot org ---
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 martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #4 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442
--- Comment #3 from Martin Husemann martin at netbsd dot org ---
0x92c9fc recog_1(rtx, rtx, int*)+2:movab 0xff60(sp),sp
0x92ca01 recog_1(rtx, rtx, int*)+7:
movab *0xef3cfc _GLOBAL_OFFSET_TABLE_+1548,0xffd8(fp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875
--- Comment #3 from Martin Husemann martin at netbsd dot org ---
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
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 martin at netbsd dot org ---
(gdb) x/i 0x0092cdb0
= 0x92cdb0 recog_1(rtx, rtx, int*)+950: movb 0x14(r0),r0
(gdb) info reg
r0 0x4 4
r1 0x8 8
r2 0x0 0
r3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
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 martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58426
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58397
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
Created attachment 30803
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30803action=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=30802action=edit
build glue changes
As discussed in #58370 and #58379
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370
--- Comment #4 from Martin Husemann martin at netbsd dot org ---
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 martin at netbsd dot org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
Created attachment 30790
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30790action=edit
Restore line_table and input_location before calling fatal_error when failing a
pch load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58381
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
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
: 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 relocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370
--- Comment #1 from Martin Husemann martin at netbsd dot org ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58370
--- Comment #3 from Martin Husemann martin at netbsd dot org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
--- Comment #4 from Martin Husemann martin at netbsd dot org ---
(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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
--- Comment #6 from Martin Husemann martin at netbsd dot org ---
Ooops, my lack of x86 ABI knowledge strikes again.
Indeed, visibility is properly expressed in the prologue, all is fine.
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=30729action=edit
test for bug 26905
Compiling the test from #26905 with -fPIC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58278
--- Comment #2 from Martin Husemann martin at netbsd dot org ---
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
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:
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:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54226
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
Status|WAITING |RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830
Martin Husemann martin at netbsd dot org changed:
What|Removed |Added
CC||martin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #7 from Martin Husemann martin at netbsd dot org 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53219
--- Comment #2 from Martin Husemann martin at netbsd dot org 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 martin at netbsd dot org 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 martin at netbsd dot org 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
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 martin at netbsd dot org 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
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.gnu.org
--- 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=7543action=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
81 matches
Mail list logo
