[Bug debug/99457] gcc/gdb -gstabs+ is buggy.

[jay.krell at cornell dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99457

--- Comment #4 from Jay  ---
I thought I stepped far enough, as I showed.
I didn't try current, granted.
And yeah, I don't need -gstabs+ and have now switched to -g.

[Bug debug/99457] New: gcc/gdb -gstabs+ is buggy.

[jay.krell at cornell dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99457

Bug ID: 99457
   Summary: gcc/gdb -gstabs+ is buggy.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

gcc/gdb -gstabs+ is buggy.
Could be either, I didn't investigate.
The codegen is correct.
That's ok, I didn't really need it, I'll use regular -g.

$ cat 1.c
#include 
int main()
{
char a[100] = {0};
printf("%d\n", a[0]);
}

$ gcc --version
gcc (Ubuntu 9.3.0-10ubuntu2) 9.3.0

$ gcc -gstabs+ 1.c

 # correct output
$ ./a.out
0

$ gdb --version
GNU gdb (Ubuntu 9.1-0ubuntu1) 9.1

$ gdb ./a.out
(gdb) break main
(gdb) r

Breakpoint 1, main () at 1.c:3
3   {
(gdb) n
4   char a[100] = {0};
(gdb)
5   printf("%d\n", a[0]);
(gdb) p a
$1 =
"@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003",
'\000' , "\001", '\000' 
(gdb) p a[0]
$2 = 64 '@'
(gdb) disas
Dump of assembler code for function main:
   0x5169 <+0>: endbr64
   0x516d <+4>: push   %rbp
   0x516e <+5>: mov%rsp,%rbp
   0x5171 <+8>: sub$0x70,%rsp
   0x5175 <+12>:mov%fs:0x28,%rax
   0x517e <+21>:mov%rax,-0x8(%rbp)
   0x5182 <+25>:xor%eax,%eax
   0x5184 <+27>:movq   $0x0,-0x70(%rbp)
   0x518c <+35>:movq   $0x0,-0x68(%rbp)
   0x5194 <+43>:movq   $0x0,-0x60(%rbp)
   0x519c <+51>:movq   $0x0,-0x58(%rbp)
   0x51a4 <+59>:movq   $0x0,-0x50(%rbp)
   0x51ac <+67>:movq   $0x0,-0x48(%rbp)
   0x51b4 <+75>:movq   $0x0,-0x40(%rbp)
   0x51bc <+83>:movq   $0x0,-0x38(%rbp)
   0x51c4 <+91>:movq   $0x0,-0x30(%rbp)
   0x51cc <+99>:movq   $0x0,-0x28(%rbp)
   0x51d4 <+107>:   movq   $0x0,-0x20(%rbp)
   0x51dc <+115>:   movq   $0x0,-0x18(%rbp)
   0x51e4 <+123>:   movl   $0x0,-0x10(%rbp)
=> 0x51eb <+130>:   movzbl -0x70(%rbp),%eax
   0x51ef <+134>:   movsbl %al,%eax
   0x51f2 <+137>:   mov%eax,%esi
   0x51f4 <+139>:   lea0xe09(%rip),%rdi# 0x6004
   0x51fb <+146>:   mov$0x0,%eax
   0x5200 <+151>:   callq  0x5070 
   0x5205 <+156>:   mov$0x0,%eax
   0x520a <+161>:   mov-0x8(%rbp),%rdx
(gdb) q

$ gcc -g 1.c
$ gdb ./a.out
(gdb) r

Breakpoint 1, main () at 1.c:3
3   {
(gdb) n
4   char a[100] = {0};
(gdb)
5   printf("%d\n", a[0]);
(gdb) p a
$1 = '\000' 

[Bug target/88352] x86 mingw returning struct with just double in ST0 instead of edx:eax

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88352

--- Comment #2 from Jay  ---
The linked bug was amd64. This is x86.
I'm not sure they are the same. Maybe.

[Bug target/64384] mingw-w64: stdcall function returning an aggregate is incompatible with MS ABI

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384

Jay  changed:

   What|Removed |Added

 CC||jay.krell at cornell dot edu

--- Comment #6 from Jay  ---
This is probably a bug in Visual C++ when compiling as C.
Or rather, whatever is/was correct, C and C++ should have matched.
At this point, one must be considered correct, the other incorrect, and neither
changable.

Since most "COM" programming is done with C++, given no good choice here, the
C++ behavior should be considered "correct", and either g++ but not gcc, or 
g++ and gcc should follow it. Certainly, at least, g++ should follow Visual C++
C++ behavior.

Consider warning.

Really there is no perfect fix here.

The relatively few C programmers using COM, will have to write a little bit of
C++ to interface correctly with such rare functions.

[Bug c/88352] New: x86 mingw returning struct with just double in ST0 instead of edx:eax

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88352

Bug ID: 88352
   Summary: x86 mingw returning struct  with just double in ST0
instead of edx:eax
   Product: gcc
   Version: 7.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

typedef struct { double d; } Struct;
typedef union { double d; } Union;

Struct f1 ()
{ 
const Struct res = {3.0};
return res;
}

Union f2 ()
{
const Union res = {3.0};
return res;
}

Result "should" be in edx:eax to match Visual C++ but first is in ST0.

Shown here with an older version but also seen in 7.3.

$ cat 1.c
typedef struct { double d; } Struct;
typedef union { double d; } Union;

Struct f1 ()
{ 
const Struct res = {3.0};
return res;
}

Union f2 ()
{
const Union res = {3.0};
return res;
}

$ /usr/local/bin/i686-w64-mingw32-gcc -c -S -v 1.c -O2
Using built-in specs.
COLLECT_GCC=/usr/local/bin/i686-w64-mingw32-gcc
Target: i686-w64-mingw32
Configured with: ../configure --target=i686-w64-mingw32
--prefix=/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--enable-languages=c,c++,fortran
--with-ld=/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/bin/i686-w64-mingw32-ld
--with-as=/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/bin/i686-w64-mingw32-as
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--disable-multilib --enable-threads=posix
Thread model: posix
gcc version 8.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-c' '-S' '-v' '-O2' '-mtune=generic' '-march=pentiumpro'

/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/libexec/gcc/i686-w64-mingw32/8.2.0/cc1
-quiet -v -D_REENTRANT 1.c -quiet -dumpbase 1.c -mtune=generic
-march=pentiumpro -auxbase 1 -O2 -version -o 1.s
GNU C17 (GCC) version 8.2.0 (i686-w64-mingw32)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 9.1.0
(clang-902.0.39.2), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0,
isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/sys-include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/include

/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/include-fixed

/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/include
End of search list.
GNU C17 (GCC) version 8.2.0 (i686-w64-mingw32)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 9.1.0
(clang-902.0.39.2), GMP version 6.1.2, MPFR version 4.0.1, MPC version 1.1.0,
isl version isl-0.20-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3686321321bbed62b5f333879ede45a4
COMPILER_PATH=/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/libexec/gcc/i686-w64-mingw32/8.2.0/:/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/libexec/gcc/i686-w64-mingw32/8.2.0/:/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/libexec/gcc/i686-w64-mingw32/:/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/:/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/:/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/bin/
LIBRARY_PATH=/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/:/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/lib/../lib/:/usr/local/Cellar/mingw-w64/5.0.4_1/toolchain-i686/lib/gcc/i686-w64-mingw32/8.2.0/../../../../i686-w64-mingw32/lib/
COLLECT_GCC_OPTIONS='-c' '-S' '-v' '-O2' '-mtune=generic' '-march=pentiumpro'
HB30-VM-Eklavya:mono4 jay$ cat 1.s
.file   "1.c"
.text
.p2align 4,,15
.globl  _f1
.def_f1;.scl2;  .type   32; .endef
_f1:
fldsLC0
ret
.p2align 4,,15
.globl  _f2
.def_f2;.scl2;  .type   32; .endef
_f2:
xorl%eax, %eax
movl$1074266112, %edx
ret
.section .rdata,"dr"
.align 4
LC0:
.long   1077936128
.ident  "GCC: (GNU) 8.2.0"

[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631

--- Comment #5 from Jay  ---
I confirmed.

Here is what you can.


Build out of tree, of course.
cd fixincludes
make check
while it is printing "fixed...", press control-c
ls tests/inc
You will see a directory named "*".
Creating this works on Mac and presumably Linux, but not WSL.

Because like I said * doesn't match anything, so goes through
on its own.

This stuff does a good job of hiding what it is doing
and deleting its tracks btw.

It helps to remove the >/dev/null in check.tpl/check.sh.
And set -ex in the parenthesized chunk near the top.

WSL should try to support this, I guess, but it is a little wonky.
Seems maybe an accident here.
Maybe it is for in-tree builds?
I also see a directory named "sun*" that might cause grief.

[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631

Jay  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|WONTFIX |---

--- Comment #4 from Jay  ---
Changing back to unconfirmed. Something is off here, I just didn't report it
correctly.

[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631

--- Comment #3 from Jay  ---
The star isn't matching anything, so it tries to create star.

I did set -ex to debug but I don't that is causing the problem.

Perhaps on other systems it does actually create star, but nobody noticed?
I'll have to check.

[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631

--- Comment #2 from Jay  ---
Err oops let me look again. Failure must be something else then.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628

--- Comment #8 from Jay  ---
Aha, kinda the same thing, but before or after analysis.
And this “deprecated” somewhat matches msvc - I was wondering about that but
didn’t see it.

It’d be nice to be able to customize the deprecated message but hopefully we’ll
keep the baby despite the bathwater. (Msvc added that option later.)

Thank you.

[Bug c/84631] New: make check in fixincludes fails seemingly due to star in directory names, on WSL

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631

Bug ID: 84631
   Summary: make check in fixincludes fails seemingly due to star
in directory names, on WSL
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

make check in fixincludes fails, seemingly due to "*" in directory names.
This is on WSL (Windows Subsystem for Linux).

I think Posix says stuff, like, / and \0 are the only special characters, but
for portability use a reduced set.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628

--- Comment #6 from Jay  ---
Misplaced comment:
But, the thing is, because optimization can remove the use of such functions,
people are now advocating that we noinline along with the attribute, which
hypothetically is unwarranted damage. Noinline being a partial disabling of
optimization, not complete.

See here:
https://github.com/mono/mono/pull/7353

But it isn't clear as I said, if it is worth warning/error for what the source
states, vs. what the optimizer divines from the code.

[Bug sanitizer/84629] sanitizer warnings and errors on Linux

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629

--- Comment #4 from Jay  ---
-disable-multilib fixed the errors. 
I didn't watch for the warnings.

[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002

--- Comment #4 from Jay  ---
Incorrect bug.

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628

--- Comment #5 from Jay  ---
I know. We just noticed and were surprised. It isn't clear if this is what
users would expect or not. Warn because they wrote code that "merely looks
bad", or only if the compiler decides after analysis that it really is bad?
Anyway, there are two points here I think. One is far more arguable than the
other. I don't think the small case shown should error.

[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002

--- Comment #3 from Jay  ---
But, the thing is, because optimization can remove the use of such functions,
people are now advocating that we noinline along with the attribute, which
hypothetically is unwarranted damage. Noinline being a partial disabling of
optimization, not complete.

See here:
https://github.com/mono/mono/pull/7353

[Bug ipa/84628] attribute(warning/error) functions should not be merged together

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628

--- Comment #3 from Jay  ---
The original case said something about "localalias" in the error, so aliases
don't seem to address it. I can dig that up probably.

Shouldn't it warn for:
 if (0)
   banned_function()
?

I believe we want it to.
You know, strive for equal warnings/errors w/ or w/o optimization, but I know
that is impossible in general, because optimization==analysis.


I believe attribute(error) should be like pragma poison except:
 - easier to implement the deprecated function
 - can provide custom error
 - works with C++ overloads -- attach attribute to full declaration, not just
identifier


But yeah, another option is to optimize a little less, on a case by case basis.
Or actually remove the attribute, or don't warn, if the compiler essentially
introduced the use.

[Bug sanitizer/84629] sanitizer warnings and errors on Linux

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629

--- Comment #3 from Jay  ---
This is ubuntu xenial I think, on WSL.
Which doesn't have multi-arch.
So I'll try configure -disable-multilib.

[Bug sanitizer/84629] New: sanitizer warnings and errors on Linux

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629

Bug ID: 84629
   Summary: sanitizer warnings and errors on Linux
   Product: gcc
   Version: 8.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:230:44: note: in
expansion of macro 'SYSCALL'
   HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd,
^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: 'SYS_ftruncat
'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:377:14: note:
in definition of macro 'HANDLE_EINTR'
   res = (f);   \
  ^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:230:44: note: in
expansion of macro 'SYSCALL'
   HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd,
^~~
In file included from
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:152:
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_stat(const char*, void*)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_stat64' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:322:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(stat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: '__lxstat64'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:322:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(stat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_lstat(const char*, void*)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_lstat64' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:349:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(lstat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: '__lxstat64'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:349:30: note: in
expansion of macro 'SYSCALL'
   int res = internal_syscall(SYSCALL(lstat64), path, );
  ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_dup2(int, int)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_dup2' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:385:27: note: in
expansion of macro 'SYSCALL'
   return internal_syscall(SYSCALL(dup2), oldfd, newfd);
   ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: 'SYS_dup2'
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:385:27: note: in
expansion of macro 'SYSCALL'
   return internal_syscall(SYSCALL(dup2), oldfd, newfd);
   ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function
'__sanitizer::uptr __sanitizer::internal_readlink(const char*, char*,
__sanitizer::uptr)':
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
error: '__NR_readlink' was not declared in this scope
 # define SYSCALL(name) __NR_ ## name
^
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:396:27: note: in
expansion of macro 'SYSCALL'
   return internal_syscall(SYSCALL(readlink), (uptr)path, (uptr)buf, bufsize);
   ^~~
/s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24:
note: suggested alternative: 'SYS_readlink'
 # define SYSCALL

[Bug c/84628] attribute(warning/error) should be evaluated before optimization

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628

--- Comment #1 from Jay  ---
Also occurs with git trunk ef8d0c5bff3c11a5d67617df2f43775f7a26fad2 8.0.1
20180228.

[Bug c/84628] New: attribute(warning/error) should be evaluated before optimization

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628

Bug ID: 84628
   Summary: attribute(warning/error) should be evaluated before
optimization
   Product: gcc
   Version: 7.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

This code should not error.
It is derived from real world code.

$ cat object.c
#define ERROR __attribute__ ((__error__ ("do not call this")))

int (*f1)();
int f2 () { return f1 (); }
ERROR int error1 () { return f2(); }
ERROR int error2 () { return f2(); }

$ $HOME/gcc720/bin/gcc -v

Using built-in specs.
COLLECT_GCC=/home/jay/gcc720/bin/gcc
COLLECT_LTO_WRAPPER=/home/jay/gcc720/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /src/gcc-7.2.0/configure -prefix=/home/jay/gcc720
-enable-languages=objc,obj-c++,go,fortran -disable-multilib
Thread model: posix

gcc version 7.2.0 (GCC)

$ $HOME/gcc720/bin/gcc -c -O2 object.c
object.c: In function ‘error2’:
cc1: error: call to ‘error1’ declared with attribute error: do not call this


I will try trunk.

[Bug bootstrap/45928] genattrtab is too slow.

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45928

--- Comment #4 from Jay  ---
Sorry wrong thread.

On Fri, Jul 21, 2017 at 4:09 PM Jay  wrote:

> The ifndef pid_t makes it a little unconvincing. I'll see if I can find my
> "sysroot".
>
> On Fri, Jul 21, 2017 at 9:42 AM egallager at gcc dot gnu.org <
> gcc-bugzi...@gcc.gnu.org> wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45928
>>
>> Eric Gallager  changed:
>>
>>What|Removed |Added
>>
>> 
>>  Status|UNCONFIRMED |NEW
>>Last reconfirmed||2017-07-21
>>  CC||egallager at gcc dot
>> gnu.org
>>  Ever confirmed|0   |1
>>
>> --- Comment #2 from Eric Gallager  ---
>> (In reply to Andrew Pinski from comment #1)
>> > Yes it is slow in 4.5.x.  It has been speed up on the trunk already.
>>
>> I remember it being slow in more recent builds I've done from trunk, too,
>> so
>> I'm confirming this bug.
>>
>> --
>> You are receiving this mail because:
>> You reported the bug.
>
>

[Bug bootstrap/45928] genattrtab is too slow.

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45928

--- Comment #3 from Jay  ---
The ifndef pid_t makes it a little unconvincing. I'll see if I can find my
"sysroot".

On Fri, Jul 21, 2017 at 9:42 AM egallager at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45928
>
> Eric Gallager  changed:
>
>What|Removed |Added
>
> 
>  Status|UNCONFIRMED |NEW
>Last reconfirmed||2017-07-21
>  CC||egallager at gcc dot
> gnu.org
>  Ever confirmed|0   |1
>
> --- Comment #2 from Eric Gallager  ---
> (In reply to Andrew Pinski from comment #1)
> > Yes it is slow in 4.5.x.  It has been speed up on the trunk already.
>
> I remember it being slow in more recent builds I've done from trunk, too,
> so
> I'm confirming this bug.
>
> --
> You are receiving this mail because:
> You reported the bug.

[Bug bootstrap/71409] New: darwin Comparing stages 2 and 3 slight failure

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71409

Bug ID: 71409
   Summary: darwin Comparing stages 2 and 3 slight failure
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

MacOSX Yosemite 10.10.4  


  jair:~ jay$ uname -a  
  Darwin jair.local 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04
PDT 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64  


  /src/gcc-6.1.0/configure -prefix=/Users/jay/gcc610  

  make  

  Comparing stages 2 and 3  
  warning: gcc/cc1-checksum.o differs  
  warning: gcc/cc1obj-checksum.o differs  
  warning: gcc/cc1plus-checksum.o differs  
  Bootstrap comparison failure!  
  gcc/tree-ssa-structalias.o differs  
  libcpp/expr.o differs

[Bug c++/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183

--- Comment #2 from Jay jay.krell at cornell dot edu ---
er, three traversals.

Also, ideally, nothing is ever output in hash order.
At least not to assembly source and objects. It might be unavoidable for final
executables.

i.e. adding one randomly named function should not cause the output to be
ordered, but that one function merely inserted in its predictable place.

[Bug c++/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183

--- Comment #3 from Jay jay.krell at cornell dot edu ---
https://github.com/modula3/cm3/commit/14d5e667e19abaab679b52bc8fd35a4e38073330

is a simple patch against 4.7 that establishes a partial ordering,
separating the indirect functions from the indirect data,
and appears to workaround the llvm-as bug.

It still outputs in hash order mostly.

Something similar/trivial against trunk should do.

[Bug c++/67183] Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183

--- Comment #1 from Jay jay.krell at cornell dot edu ---
It turns out, this looks easy to fix on the gcc side.

See machopic_finish.

Have it run two traversla instead of one. The first editing stubs, the second
non-lazy pointers.

[Bug c++/67183] New: Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67183

Bug ID: 67183
   Summary: Darwin stub vs. non_lazy pointer ordering incompatible
with clang assembler.
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jay.krell at cornell dot edu
  Target Milestone: ---

Darwin stub vs. non_lazy pointer ordering incompatible with clang assembler.
Incorrect code results when targeting 32bit older than 10.5.
Request to output in the same order as clang for compatibility -- all stubs
before all non-lazy pointers.


This is really obscure.


It did hit me and I spent a long while debugging it, though still not fully.


There appears to be a bug in the LLVM assembler.


gcc by default does not run it.
 i.e.:
   gcc -S foo.c
   clang foo.s
  usually works, but hits a problem here. 


It probably only occurs when targeting less than 10.5.
 i.e. gcc -mmacosx-version-min=10.4
 That switch works with both gcc and clang. 


 gcc outputs a presumably valid mix of stubs and non-lazy pointers.
  You only get the stubs for earlier than 10.5.


clang front end outputs all stubs before all the non-lazy pointers.
gcc outputs them in a jumbled order. Presumably that is ok.
The clang assembler gets confused matching things up when there are non-lazy
pointers before stubs. 


The bug is also 32bit specific as 64bit never has stubs.


Here is the bug in action:  

  jair:~ jay$ cat 1.c  
  void F1(int);  
  void F2(int);  
  extern int i;  

  void F3() { F1(i); }  
  void F4() { F2(i); }  
  jair:~ jay$ $HOME/gcc-5.2.0/bin/gcc -mmacosx-version-min=10.4 -m32 1.c -fPIC 
-c -S  
  jair:~ jay$ clang -c 1.s -m32  
  jair:~ jay$ otool -tVv 1.o  
  1.o:  
  (__TEXT,__text) section  
  _F3:
    pushl   %ebp
  0001  movl%esp, %ebp
  0003  subl$0x8, %esp
  0006  calll   ___x86.get_pc_thunk.ax
  000b  leal86-11(%eax), %eax
  0011  movl_F3(%eax), %eax
  0013  movl_F3(%eax), %eax  
  0015  subl$0xc, %esp  
  0018  pushl   %eax  
  0019  calll   0x4c## symbol stub for: _F1  
  001e  addl$0x10, %esp  
  0021  nop  
  0022  leave  
  0023  retl  
  _F4:  
  0024  pushl   %ebp  
  0025  movl%esp, %ebp  
  0027  subl$0x8, %esp  
  002a  calll   ___x86.get_pc_thunk.ax  
  002f  leal86-47(%eax), %eax  
  0035  movl_F3(%eax), %eax  
  0037  movl_F3(%eax), %eax  
  0039  subl$0xc, %esp  
  003c  pushl   %eax  
  003d  calll   0x51## symbol stub for: _i  
  0042  addl$0x10, %esp  
  0045  nop  
  0046  leave  
  0047  retl  


  Where is says symbol stub for: _i, it should for _F2.  


  Having gcc output the stubs/non-lazy pointers in the same order as clang  
  in order to be compatible with the clang assembler might be nice.  


  For my part, I will either run non-LLVM assembler, or target 10.5 or newer,  
  at least until I develop or get a patch for gcc to reorder.  


  Thank you,
 - Jay

[Bug middle-end/66984] ICE: fold_binary changes type of operand, causing failure in verify_gimple_assign_binary

[jay.krell at cornell dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984

--- Comment #2 from Jay jay.krell at cornell dot edu ---
1 please be sure that dividing the most negative number by -1 works. 
Perhaps just don't optimize anything with negstive numbers.


2 I suggest that gcc's C/C++ frontends expose these other forms of division,
for the sake of testability.


Thank you,
 - Jay

On Jul 24, 2015, at 2:09 AM, rguenth at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:

 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66984
 
 Richard Biener rguenth at gcc dot gnu.org changed:
 
   What|Removed |Added
 
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-24
 Ever confirmed|0   |1
 
 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
 The usual fix in fold-const.c is to make sure to convert operands to the
 required type when building the final expression.  Thus instead of
 
 10828   return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, 
 arg1);
 
 do
 
   return fold_build2_loc (loc, EXACT_DIV_EXPR, type,
   fold_convert (type, arg0), fold_convert (type,
 arg1));
 
 you can see this pattern in many places.
 
 Care to post a patch?  It's pre-approved.
 
 -- 
 You are receiving this mail because:
 You are on the CC list for the bug.

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #27 from Jay jay.krell at cornell dot edu ---
The patch looks very very reasonable
imho. I had a few reasonable patches.

 - Jay

On Jan 29, 2014, at 9:25 AM, glisse at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333
 
 --- Comment #26 from Marc Glisse glisse at gcc dot gnu.org ---
 (In reply to Sergey from comment #23)
 cc -V:
 cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12
 
 That thing belongs in a museum.
 
 -- 
 You are receiving this mail because:
 You reported the bug.

[Bug bootstrap/56703] New: problems with strsignal and maybe strstr due to varying const on return type

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703



 Bug #: 56703

   Summary: problems with strsignal and maybe strstr due to

varying const on return type

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jay.kr...@cornell.edu





The autoconf checks for strsignal and maybe strstr are overly strict or wrong

and fail due to varying const on the return.





gcc 4.8.0



 uname -a

SunOS unstable10s 5.10 Generic_147440-27 sun4v sparc

SUNW,SPARC-Enterprise-T5220





make[3]: Entering directory `/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/gcc'

/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/./prev-gcc/xg++

-B/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/./prev-gcc/

-B/home/jkrell/gcc480-sparc-sun-solaris2.10/sparc-sun-solaris2.10/bin/

-nostdinc++

-B/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs

-B/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs

-I/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10

-I/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/include

-I/home/jkrell/src/gcc-4.8.0/libstdc++-v3/libsupc++

-L/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs

-L/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs

-c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables

-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute

-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  

-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/jkrell/src/gcc-4.8.0/gcc

-I/home/jkrell/src/gcc-4.8.0/gcc/build

-I/home/jkrell/src/gcc-4.8.0/gcc/../include -I./../intl

-I/home/jkrell/src/gcc-4.8.0/gcc/../libcpp/include 

-I/home/jkrell/src/gcc-4.8.0/gcc/../libdecnumber

-I/home/jkrell/src/gcc-4.8.0/gcc/../libdecnumber/dpd -I../libdecnumber

-I/home/jkrell/src/gcc-4.8.0/gcc/../libbacktrace\

-o build/genconstants.o /home/jkrell/src/gcc-4.8.0/gcc/genconstants.c

In file included from ./bconfig.h:3:0,

 from /home/jkrell/src/gcc-4.8.0/gcc/genconstants.c:27:

./auto-host.h:1994:16: error: declaration does not declare anything

[-fpermissive]

 #define rlim_t long

^

In file included from /home/jkrell/src/gcc-4.8.0/gcc/genconstants.c:28:0:

/home/jkrell/src/gcc-4.8.0/gcc/system.h:448:48: error: 'char* strstr(const

char*, const char*)' conflicts with previous using declaration 'const char*

std::strstr(const char*, const char*)'

 extern char *strstr (const char *, const char *);

^

In file included from /home/jkrell/src/gcc-4.8.0/gcc/genconstants.c:28:0:

/home/jkrell/src/gcc-4.8.0/gcc/system.h:500:34: error: declaration of C

function 'const char* strsignal(int)' conflicts with

 extern const char *strsignal (int);

  ^

In file included from

/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/include/cstring:42:0,

 from /home/jkrell/src/gcc-4.8.0/gcc/system.h:205,

 from /home/jkrell/src/gcc-4.8.0/gcc/genconstants.c:28:

/usr/include/string.h:79:14: error: previous declaration 'char* strsignal(int)'

here

 extern char *strsignal(int);

  ^

gmake[3]: *** [build/genconstants.o] Error 1

gmake[3]: Leaving directory `/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/gcc'

gmake[2]: *** [all-stage2-gcc] Error 2

gmake[2]: Leaving directory `/home/jkrell/obj/gcc480-sparc-sun-solaris2.10'

gmake[1]: *** [stage2-bubble] Error 2

gmake[1]: Leaving directory `/home/jkrell/obj/gcc480-sparc-sun-solaris2.10'

gmake: *** [all] Error 2

jkrell@unstable10s [unstable10s]:~/obj/gcc480-sparc-sun-solaris2.10  





Both the strstr and strsignal declarations in system.h have autoconf #if's

around them.

One wonders why they evaluate to true.





krell@unstable10s [unstable10s]:~/obj/gcc480-sparc-sun-solaris2.10  grep STRS

*/*h

gcc/auto-host.h:#define HAVE_DECL_STRSIGNAL 0

gcc/auto-host.h:#define HAVE_DECL_STRSTR 0

gcc/auto-host.h:#define HAVE_STRSIGNAL 1

libiberty/config.h:#define HAVE_STRSIGNAL 1

libiberty/config.h:#define HAVE_STRSTR 1

prev-gcc/auto-host.h:#define HAVE_DECL_STRSIGNAL 1

prev-gcc/auto-host.h:#define HAVE_DECL_STRSTR 1

prev-gcc/auto-host.h:#define HAVE_STRSIGNAL 1





The mystery deepens...

cd gcc

vi config.log

...



| #undef HAVE_DECL_STRSIGNAL

| #define HAVE_DECL_STRSIGNAL 1

|

| #include ansidecl.h

| #include system.h

|

| int

| main ()

| {

| #ifndef strsignal

| char *(*pfn) = (char 

[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703



--- Comment #1 from Jay jay.krell at cornell dot edu 2013-03-23 23:12:03 UTC 
---

I see that the check for any function involves a cast of its type -- i.e. it

isn't customized per-function, so a change isn't trivial.



For now I have removed strstr and strsignal from system.h -- assume they are

declared.

[Bug bootstrap/56704] New: rlim_t problem gcc 4.8.0 on Solaris 2.10/sparc?

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56704



 Bug #: 56704

   Summary: rlim_t problem gcc 4.8.0 on Solaris 2.10/sparc?

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jay.kr...@cornell.edu





jkrell@unstable10s [unstable10s]:~/obj/gcc480-sparc-sun-solaris2.10/gcc  gmake

/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/./prev-gcc/xg++

-B/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/./prev-gcc/

-B/home/jkrell/gcc480-sparc-sun-solaris2.10/sparc-sun-solaris2.10/bin/

-nostdinc++

-B/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs

-B/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs

-I/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/include/sparc-sun-solaris2.10

-I/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/include

-I/home/jkrell/src/gcc-4.8.0/libstdc++-v3/libsupc++

-L/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/src/.libs

-L/home/jkrell/obj/gcc480-sparc-sun-solaris2.10/prev-sparc-sun-solaris2.10/libstdc++-v3/libsupc++/.libs

-c   -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables

-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute

-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  

-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/jkrell/src/gcc-4.8.0/gcc

-I/home/jkrell/src/gcc-4.8.0/gcc/build

-I/home/jkrell/src/gcc-4.8.0/gcc/../include -I./../intl

-I/home/jkrell/src/gcc-4.8.0/gcc/../libcpp/include 

-I/home/jkrell/src/gcc-4.8.0/gcc/../libdecnumber

-I/home/jkrell/src/gcc-4.8.0/gcc/../libdecnumber/dpd -I../libdecnumber

-I/home/jkrell/src/gcc-4.8.0/gcc/../libbacktrace\

-o build/genconstants.o /home/jkrell/src/gcc-4.8.0/gcc/genconstants.c

In file included from ./bconfig.h:3:0,

 from /home/jkrell/src/gcc-4.8.0/gcc/genconstants.c:27:

./auto-host.h:1994:16: error: declaration does not declare anything

[-fpermissive]

 #define rlim_t long

^

gmake: *** [build/genconstants.o] Error 1





I'm going to try just removing the lines from configure/configure.ac.

I don't see how it ends up deciding to do the #define.

rlim_t is typedefed in /usr/include/sys/resources.h

[Bug bootstrap/56703] problems with strsignal and maybe strstr due to varying const on return type

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56703



--- Comment #3 from Jay jay.krell at cornell dot edu 2013-03-23 23:24:55 UTC 
---

gmp/mpfr/mpc are in-tree

Notice that it has gotten past the first stage..so I didn't bother double

checking what my bootstrap compiler was..though gcc/g++ 3.x is in $PATH.



Very simple configure line -- just setting -prefix.



jkrell@unstable10s [unstable10s]:~/obj/gcc480-sparc-sun-solaris2.10/gcc  head

../config.log

This file contains any messages produced by compilers while

running configure, to aid debugging if configure makes a mistake.



It was created by configure, which was

generated by GNU Autoconf 2.64.  Invocation command line was



  $ /home/jkrell/src/gcc-4.8.0/configure

-prefix=/home/jkrell/gcc480-sparc-sun-solaris2.10

[Bug middle-end/56362] bitfield refs over-optimized?

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56362



--- Comment #2 from Jay jay.krell at cornell dot edu 2013-02-21 08:07:15 UTC 
---

Looking back at other data I have..this has something to do with configure

-enable-checking..but I don't know exactly what.



I am *guessing* that the signedness of the bitfield ref and the signedess of

the element could vary. Stripping of the bitfield ref would therefore change

the type of the expression, and that could then be sign extended.



I doubt I can construct a repro in C, but I can poke around to see if C or Java

or Ada can produce such bitfield refs..

[Bug middle-end/56363] over aggressive division folding ignores sign conversion

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56363

--- Comment #7 from Jay jay.krell at cornell dot edu 2013-02-20 08:51:49 UTC 
---
Here is the successful experiment, where I changed the code to operate on all
the div variants. Of course I am NOT suggesting this change be made. Nor is it
100% conclusive. But it is very much indicative of a problem.


 mkdir /obj
/gcc.4
 cd /obj/gcc.4  

 /src/gcc-4.7.2/configure -prefix=$HOME/gcc.4 -enable-checking=fold
-enable-languages=c
make

...

/obj/gcc.4/./prev-gcc/g++ -B/obj/gcc.4/./prev-gcc/ ...
/src/gcc-4.7.2/gcc/fold-const.c -o fold-const.o
/src/gcc-4.7.2/gcc/fold-const.c: In function ‘tree_node*
fold_comparison(location_t, tree_code, tree, tree, tree)’:
/src/gcc-4.7.2/gcc/fold-const.c:8765:1: error: type mismatch in binary
expression
long long int

long long unsigned int

long long int

D.64567 = D.64566 /[ex] 8;

/src/gcc-4.7.2/gcc/fold-const.c:8765:1: error: type mismatch in binary
expression
long long int

long long unsigned int

long long int

D.64594 = D.64593 /[ex] 8;

/src/gcc-4.7.2/gcc/fold-const.c:8765: confused by earlier errors, bailing out
make[3]: *** [fold-const.o] Error 1
make[3]: Leaving directory `/Users/jay/obj/gcc.4/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/Users/jay/obj/gcc.4'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/Users/jay/obj/gcc.4'
make: *** [all] Error 2


jbook2:gcc-4.7.2 jay$ diff -ur /src/orig/gcc-4.7.2 /src/gcc-4.7.2
diff -ur /src/orig/gcc-4.7.2/gcc/fold-const.c /src/gcc-4.7.2/gcc/fold-const.c
--- /src/orig/gcc-4.7.2/gcc/fold-const.c2012-06-01 10:03:19.0 -0700
+++ /src/gcc-4.7.2/gcc/fold-const.c2013-02-19 08:19:31.0 -0800
@@ -12048,7 +12048,7 @@
  Note that only CEIL_DIV_EXPR and FLOOR_DIV_EXPR are rewritten now.
  At one time others generated faster code, it's not clear if they do
  after the last round to changes to the DIV code in expmed.c.  */
-  if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)
+  if ((code == TRUNC_DIV_EXPR || code == ROUND_DIV_EXPR || code ==
FLOOR_DIV_EXPR || code == CEIL_DIV_EXPR)
multiple_of_p (type, arg0, arg1))
 return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);



Again, this is NOT a proposed patch. I am not that dumb. It helps SUGGEST that
there is a problem.


Perhaps I'll try with trunk.


 - Jay

[Bug middle-end/56363] over aggressive division folding ignores sign conversion

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56363



--- Comment #4 from Jay jay.krell at cornell dot edu 2013-02-19 16:18:02 UTC 
---

ah, here is more info; I reported the bug better years ago but it was never

looked at:





http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46679





There I don't claim bad code, but a failure with -enable-checking.





Something, like, you are supposed to have

type = type / type  



we start with

int64 = int64 / int64



but end up with

int64 = uint64 / uint64



which enable-checking doesn't like.

It is possible enable-checking has been relaxed in the years since I checked. I

can try again.





 - Jay

[Bug middle-end/56363] over aggressive division folding ignores sign conversion

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56363



--- Comment #6 from Jay jay.krell at cornell dot edu 2013-02-19 21:52:31 UTC 
---

  should pass op0 and op1 to the fold_build2_loc call, instead of arg0/arg1





I don't disagree, but I really I don't know.

Clearly that means almost but not exactly the same thing.





I am running a build now (i.e. when I left home this morning) with the bogus

change from the other bug, where I change all div forms here, with

-enable-checking, to see if it still triggers. I can also try our frontend

against 4.7.2 with -enable-checking, i.e. w/o the bogosity of changing all div

forms, and confirm there is still a problem.

[Bug middle-end/56363] over aggressive division folding ignores sign conversion

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56363



--- Comment #3 from Jay jay.krell at cornell dot edu 2013-02-18 20:50:44 UTC 
---

(In reply to comment #2)

 call?  Anyway, it would be better to see a testcase.





I'm not sure I can construct one in C.

It might be too painful for you to take what I have -- a general frontend that

accepts binary files.

I can try debugging it again.

I had/have a large test vector, including most positive/negativen numbers.



 - Jay

[Bug target/56361] New: assertion failure passing structs w/o fields by value on sparc64

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56361



 Bug #: 56361

   Summary: assertion failure passing structs w/o fields by value

on sparc64

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jay.kr...@cornell.edu





We have a strange front end.

It declares structs with size but no fields.

It actually works..except sometimes for SPARC64.





We have a function that passes a few structs by value.

They are 12 bytes each.







4.7.2/config/sparc/sparc.c:

static rtx

function_arg_record_value (const_tree type, enum machine_mode mode,

   int slotno, int named, int regbase)

.

.

.



  else

{

  /* ??? C++ has structures with no fields, and yet a size.  Give up

 for now and pass everything back in integer registers.  */

  nregs = (typesize + UNITS_PER_WORD - 1) / UNITS_PER_WORD;

}

  if (nregs + slotno  SPARC_INT_ARG_MAX)

nregs = SPARC_INT_ARG_MAX - slotno;

}

  gcc_assert (nregs != 0);







SPARC_INT_ARG_MAX == 6

nregs = 2

slotno = 6

so then nregs = 0

and the assert fails





I think it should say:

  gcc_assert (nregs != 0 || parms.stack);

[Bug middle-end/56362] New: bitfield refs over-optimized?

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56362



 Bug #: 56362

   Summary: bitfield refs over-optimized?

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jay.kr...@cornell.edu





Our front end is a bit wierd.

We don't declare the fields of our structs.

We use bitfield refs to pick out the fields we know are there.





Something like this:





If in C you had the reasonable:





struct { int a,b,c,d } e;

 e.b = component_ref 





We have:

 struct /* size 16 bytes */ e;

 bitfield_ref(e, offset 4 bytes, size 4 bytes, type int)





 I have changed it so sometimes, instead: 

   *(int*)(e + 4) 



e.g. when reading floating point fields,

but that defeats optimizations more.





so, then, while this mostly works, and generates better

code than the pointer offset + deref form, it does seem to

very occasionally not work.





I have not fully debugged this, at least not in years.





4.7.2/gcc/fold-const.c has this code:





  /* A bit-field-ref that referenced the full argument can be stripped.  */

  if (INTEGRAL_TYPE_P (TREE_TYPE (arg0))

   TYPE_PRECISION (TREE_TYPE (arg0)) == tree_low_cst (arg1, 1)

   integer_zerop (op2))

return fold_convert_loc (loc, type, arg0);





I believe this is a bit too aggressive.

Such as when there is a sign extension implied.





I added these two conditions to make to make it less aggressive:

   INTEGRAL_TYPE_P (type)

   TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))

[Bug middle-end/56363] New: over aggressive division folding ignores sign conversion

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56363



 Bug #: 56363

   Summary: over aggressive division folding ignores sign

conversion

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jay.kr...@cornell.edu





Our frontend is slightly unusual in that it uses FLOOR_DIV_EXPR instead of C's

more common TRUNC_DIV_EXPR. (For years it generated calls to helper functions

for div and mod, but then I noticed this builtin support.)

So it hits perhaps not well covered code?





Based on debugging this years ago (in an older version of gcc), I think gcc is

a bit overaggressive at folding constants in division.





4.7.2/gcc/fold-const.c has this code:





tree

fold_binary_loc (location_t loc,

 enum tree_code code, tree type, tree op0, tree op1)

.

.

.

  arg0 = op0;

  arg1 = op1;

.

.

.

  STRIP_NOPS (arg0);

  STRIP_NOPS (arg1);

.

.

.

  /* If arg0 is a multiple of arg1, then rewrite to the fastest div

 operation, EXACT_DIV_EXPR.



 Note that only CEIL_DIV_EXPR and FLOOR_DIV_EXPR are rewritten now.

 At one time others generated faster code, it's not clear if they do

 after the last round to changes to the DIV code in expmed.c.  */

  if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)

   multiple_of_p (type, arg0, arg1))

return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);





I think this is wrong if strip_nops stripped some signedness or other

conversions.





I added this condition:

   arg0 == op0  arg1 == op1 





Given the comment, that the code is not applied to C's TRUNC_DIV_EXPR, maybe

this can/should just be removed?

[Bug bootstrap/56364] New: autoconf compiler switches are also used to link and they can fail (-fno-rtti -fno-exceptions Solaris cc/ld)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56364



 Bug #: 56364

   Summary: autoconf compiler switches are also used to link and

they can fail (-fno-rtti -fno-exceptions Solaris

cc/ld)

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: bootstrap

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: jay.kr...@cornell.edu





Solaris cc and CC accept with warning -fno-rtti and -fno-exceptions.

But they are passed on to the Solaris linker, and it rejects them with an

error.





In 4.7.2/gcc/configure, -fno-rtti -fno-exceptions are tested

only for compilation, but if that works, they are also used for linking (in

gcc/Makefile).





Suggested fixes, one of:





1) just never use -fno-rtti -fno-exceptions

   Not a bad idea I think. Is there really noticable overhead these days?

   Less autoconf, more portability, is good.





2) only use -fno-rtti -fno-exceptions if using gcc 

   pretty easy and safe and no-change for most folks 





3) only compile with -fno-rtti -fno-exceptions, but don't link with them





4) test -fno-rtti -fno-exceptions with compiling and linking use

  them where they work and not where they don't; i.e. w/ and w/o -c 





 - Jay

[Bug libgomp/45351] many unaligned accesses in libgomp tests

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45351

--- Comment #8 from Jay jay.krell at cornell dot edu 2011-07-19 15:15:46 UTC 
---
Is there no annotation in /usr/include/whatever.h to get the required
alignment? Maybe that gcc doesn't-but-maybe-should understand?

 - Jay (phone)

On Jul 19, 2011, at 7:33 AM, ro at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45351
 
 Rainer Orth ro at gcc dot gnu.org changed:
 
   What|Removed |Added
 
 Status|NEW |ASSIGNED
 AssignedTo|unassigned at gcc dot   |ro at gcc dot gnu.org
   |gnu.org |
 
 --- Comment #7 from Rainer Orth ro at gcc dot gnu.org 2011-07-19 14:32:25 
 UTC ---
 Mine.
 
 -- 
 Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
 --- You are receiving this mail because: ---
 You reported the bug.

[Bug libgomp/45351] many unaligned accesses in libgomp tests

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45351

--- Comment #10 from Jay jay.krell at cornell dot edu 2011-07-19 15:58:04 UTC 
---
 Is there no annotation in /usr/include/whatever.h to get the required
 alignment? Maybe that gcc doesn't-but-maybe-should understand?

 No, the section I cited is all there is.  No idea why this error doesn't
 show up otherwise.


Do struct alignment rules on Tru64 have an effect? Not that I
looked-up/read the ABI details..
I'm not sure I have Tru64 access any longer (and my
time/work/money-to-burn has dramatically declined, sorry, it was fun!)
But I'd be curious what this does:

#include something
#include stddef.h


int main()
{
typedef struct { char a; sem_t b; } t1;
 printf(%u %u\n, sizeof(t1), offsetof(t1, b));
 return 0;
}

  5 or 6 or 8 or other?
  and 1 or 2 or 4 or other?
  If the alignment is really only 2, then I'd expect 6 and 2.
  If the alignment is somehow bumped up, then 8 and 4.


The code cited does seem poor.
Personally I'm a big fan of memset(p, 0, n) (or #define ZeroMemory(p, n)).


 - Jay

[Bug target/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45345

--- Comment #4 from Jay jay.krell at cornell dot edu 2011-05-28 19:20:51 UTC 
---
No -- this is mips64. OpenBSD uses it -- loongson.

[Bug target/45345] In function `mips16_build_function_stub' undefined reference to `ASM_OUTPUT_DEF'

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45345

--- Comment #6 from Jay jay.krell at cornell dot edu 2011-05-28 19:47:42 UTC 
---
No -- as in this, this isn't unused, ought not be deprecated.
You mentioned 32bit mips/a.out -- sure, maybe that is unused.
  I assume a.out is almost unused across the board.
But 64bit mips/elf is used.

Now, granted, OpenBSD I believe is sticking back with gcc 4.2?3/GPL2 so
probably doesn't care what you do with 4.5.

But surely Linux is using mips64/elf and probably also mips32/elf?
(and Irix, if it is still supported)
There is pretty recent hardware development here, you know, Loongson.

I must have been referring to the email thread or the duplicate mail.

[Bug other/48747] New: Darwin/MacOSX 10.5 fixincludes make check = complex.h missing

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48747

   Summary: Darwin/MacOSX 10.5 fixincludes make check = complex.h
missing
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


Darwin/MacOSX 10.5 fixincludes make check = complex.h missing

MacoOSX 10.5.8 intel.
bootstrap gcc is Apple 4.0.1.

uname -a
Darwin jbook2 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386

gcc-core-4.6.0.tar.bz2
no local edits, I'm pretty sure.
/src/gcc-4.6.0/configure -prefix $HOME/gcc-4.6.0-1  make  make install 
make check

Missing header fix:  complex.h

There were fixinclude test FAILURES

[Bug middle-end/46597] configure -enable-checking=... -enable-build-with-cxx and bootstrap is g++ 3.3 hit minor problem

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46597

--- Comment #1 from Jay jay.krell at cornell dot edu 2010-12-28 13:50:06 UTC 
---
I put #define ENABLE_CHECKING_GCC_VERSION ((GCC_VERSION  3003) ||
(!defined(__cplusplus)  (GCC_VERSION  2007)))
 in include/ansidecl.h after #define GCC_VERSION and I  this with the #if
FOO_CHECKING in rtl.h, tree.h, ira-int.h.


Alternatively, reject g++  3.4 entirely, or if enable-checking.
Or, well, I'm using -disable-bootstrap, and probably checking is never enabled
in the first phase anyway, so this all would just work if I didn't use that.
The patch is ok, but it might never make a difference if I didn't
-disable-bootstrap.


But I really really really like -disable-bootstrap, given how little I build,
which is still a very useful amount, it saves a ton (just libbackend.a and a
small frontend, no libraries, and I patched out gmp/mpfr/mpc dependencies, so
overall build is short even on slower machines (we run a range of machines..)).

[Bug target/46861] alpha gcc 4.2 -fPIC visibility hidden = gp-relative relocation against dynamic symbol

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861

--- Comment #4 from Jay jay.krell at cornell dot edu 2010-12-11 08:47:22 UTC 
---
It appears to also be ok in 4.3.5.


j...@alphalinux:~$ $HOME/gcc-4.3.5/bin/gcc -v
Using built-in specs.
Target: alphaev5-unknown-linux-gnu
Configured with: /home/jay/src/gcc-4.3.5/configure -prefix=/home/jay/gcc-4.3.5
Thread model: posix
gcc version 4.3.5 (GCC) 


j...@alphalinux:~$ $HOME/gcc-4.3.5/bin/gcc 1.c 2.c -fPIC -shared
 = success


4.4.5 I think has a bootstrap problem in libstdc++, I will confirm and open a
separate bug.

[Bug target/46861] alpha gcc 4.2 -fPIC visibility hidden = gp-relative relocation against dynamic symbol

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861

--- Comment #5 from Jay jay.krell at cornell dot edu 2010-12-11 09:40:39 UTC 
---
No problem with 4.4.5 either.

j...@alphalinux:~$ $HOME/gcc-4.4.5/bin/gcc -v
Using built-in specs.
Target: alphaev5-unknown-linux-gnu
Configured with: /home/jay/src/gcc-4.4.5/configure -prefix=/home/jay/gcc-4.4.5
Thread model: posix
gcc version 4.4.5 (GCC) 


j...@alphalinux:~$ $HOME/gcc-4.4.5/bin/gcc 1.c 2.c -fPIC -shared
 = success

[Bug target/46861] alpha gcc 4.2 -fPIC visibility hidden = gp-relative relocation against dynamic symbol

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861

--- Comment #2 from Jay jay.krell at cornell dot edu 2010-12-09 11:21:35 UTC 
---
Right, I already reported: no problem with 4.5.1.
4.2.4 is what Debian 5.0 has though.
I'll stick with my workaround.
I can try 4.3.x, 4.4.x if there is interest (i.e. in fixing them if they are
broken; heck for that matter I should probably try stock 4.2.x, instead of
Debian's)

[Bug target/46861] New: alpha gcc 4.2 -fPIC visibility hidden = gp-relative relocation against dynamic symbol

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46861

   Summary: alpha gcc 4.2 -fPIC visibility hidden = gp-relative
relocation against dynamic symbol
   Product: gcc
   Version: 4.2.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


I assume this is a known bug in gcc 4.2?
  No repro with 4.5.1.
I worked around it by using a local static signal handler that
calls the real one.


j...@alphalinux:~$ $HOME/gcc-4.5.1/bin/gcc -v -fPIC 1.c 2.c -shared
Target: alphaev5-unknown-linux-gnu
Configured with: /home/jay/src/gcc-4.5.1/configure -prefix=/home/jay/gcc-4.5.1

= success

j...@alphalinux:~$ gcc -v -fPIC 1.c 2.c -shared
Target: alpha-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --with-long-double-128
--enable-checking=release --build=alpha-linux-gnu --host=alpha-linux-gnu
--target=alpha-linux-gnu
Thread model: posix
gcc version 4.2.4 (Debian 4.2.4-6)


/usr/bin/ld: /tmp/ccNIE2XD.o: gp-relative relocation against dynamic symbol
SignalHandler
/usr/bin/ld: /tmp/ccNIE2XD.o: gp-relative relocation against dynamic symbol
SignalHandler
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

j...@alphalinux:~$ cat 1.c 2.c

#include signal.h
void SignalHandler(int signo, siginfo_t *info, void *context)
{
}

#include string.h
#include signal.h

#pragma GCC visibility push(hidden)

void SignalHandler(int signo, siginfo_t *info, void *context);

void F2(void)
{
  struct sigaction act;
  int r;

  memset(act, 0, sizeof(act));
  act.sa_sigaction = SignalHandler;
  sigaction(0, act, NULL);
}

[Bug middle-end/46679] fold_binary changes types in divisionm breaking configure -enable-checking

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46679

Jay jay.krell at cornell dot edu changed:

   What|Removed |Added

Version|4.5.1   |4.6.0

--- Comment #1 from Jay jay.krell at cornell dot edu 2010-12-02 09:08:49 UTC 
---
You can prove, almost, the existance of the bug by
making this change to slightly increase it:

jbook2:gcc jay$ svn diff  fold-const.c 
Index: fold-const.c
===
--- fold-const.c(revision 167194)
+++ fold-const.c(working copy)
@@ -11648,7 +11648,7 @@
  Note that only CEIL_DIV_EXPR and FLOOR_DIV_EXPR are rewritten now.
  At one time others generated faster code, it's not clear if they do
  after the last round to changes to the DIV code in expmed.c.  */
-  if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)
+  if ((code == CEIL_DIV_EXPR || code == TRUNC_DIV_EXPR || code ==
FLOOR_DIV_EXPR)
multiple_of_p (type, arg0, arg1))
 return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);


it: I don't think C ever produces ceil_div/floor_div, so
it's hard to demonstrate.

With this, bootstrap fails:


/src/gcc-trunk/configure -prefix=/usr/local/gcc-trunk
-enable-checking=assert,df,fold,misc,rtl,rtlflag,runtime,tree,types  make -j4

/src/gcc-trunk/gcc/tree-ssa-loop-prefetch.c:1503:1: error: type mismatch in
binary expression
unsigned int
int
unsigned int
D.55547 = D.55546 /[ex] 16;

other than just removing this chunk of code completely,
I might suggest checking that arg0 == op0  arg1 == op1.
Though that is probably a bit more conservative than necessary.

[Bug middle-end/46679] New: fold_binary changes types in divisionm breaking configure -enable-checking

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46679

   Summary: fold_binary changes types in divisionm breaking
configure -enable-checking
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


fold_binary seemingly changes the types of division inputs (but not the
output),
leading to configure -enable-checking to fail.


My code is something like this (using a different frontend
and slightly patched 4.5.1 but I don't think relevantly):


long a;

long F(void)
{
 return a / a;
}

configure -enable-checking=fold,...:

gcc-4.5
fold-const.c

fold_binary_loc(code = FLOOR_DIV_EXPR,
op0, op1, type all int_64


arg0, arg1 become word_64
(not op0, op1, but arg0, arg1)


and then we end up here:

  if ((code == CEIL_DIV_EXPR || code == FLOOR_DIV_EXPR)
   multiple_of_p (type, arg0, arg1))
return fold_build2_loc (loc, EXACT_DIV_EXPR, type, arg0, arg1);


and then:


error: type mismatch in binary expression
int_64
word_64
word_64


D.1003 = D.1001 /[ex] D.1002;


multiple_of_p is true because the operands are the same.
 (This would optimize to 1, unless the operands might be 0.)


I'll see if I can reproduce with unpatched C 4.5.1 and trunk.


 - Jay

[Bug middle-end/46681] New: insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46681

   Summary: insn-recog.c is too taxing on bootstrap compiler
(Apple gcc 4.0.1)
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


gcc -c   -g -O2 -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual \
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute \
-Wold-style-definition -fno-common  -DHAVE_CONFIG_H -I. -I. \
-I/src/gcc-trunk/gcc -I/src/gcc-trunk/gcc/. \
-I/src/gcc-trunk/gcc/../include -I/src/gcc-trunk/gcc/../libcpp/include
\
-I/src/gcc-trunk/gcc/../libdecnumber \
-I/src/gcc-trunk/gcc/../libdecnumber/dpd -I../libdecnumber   \
insn-recog.c -o insn-recog.o
cc1(5564) malloc: *** mmap(size=453095424) failed (error code=12)


This is on trunk with -disable-bootstrap.
I got something similar with 4.5.1, also -disable-bootstrap.


jbook2:~ jay$ gcc -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-arch=apple --with-tune=generic
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)


jbook2:~ jay$ uname -a
Darwin jbook2 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_I386 i386


jbook2:~ jay$ head /obj/gcc-trunk/config.log 
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /src/gcc-trunk/configure -prefix=/usr/local/gcc-trunk
-enable-checking=assert,df,fold,misc,rtl,rtlflag,runtime,tree
-disable-bootstrap -disable-intl -disable-nls -disable-libmudflap
-disable-libssp -disable-libgomp


jbook2:~ jay$ head /obj/gcc-4.5.1/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.64.  Invocation command line was

  $ /src/gcc-4.5.1/configure -prefix=/usr/local/gcc-4.5.1
-enable-checking=assert,df,fold,misc,rtl,rtlflag,runtime,tree
-disable-bootstrap -disable-intl -disable-nls -disable-libmudflap
-disable-libssp -disable-libgomp


Running make a second time seems to work.
Machine has 4GB but isn't necessarily single tasking.

[Bug middle-end/46681] insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46681

--- Comment #1 from Jay jay.krell at cornell dot edu 2010-11-27 01:09:47 UTC 
---
Actually running make again doesn't fix it.
And machine is nearly single-tasking at the moment.
I'll try without -disable-bootstrap.

[Bug middle-end/46681] insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46681

--- Comment #2 from Jay jay.krell at cornell dot edu 2010-11-27 01:14:57 UTC 
---
Trying again with ulimit -d unlimited.
I wonder if something like can/should be automated, like with some wrapper
executable.
Notice I'm using -enable-checking.

[Bug middle-end/46681] insn-recog.c is too taxing on bootstrap compiler (Apple gcc 4.0.1)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46681

--- Comment #3 from Jay jay.krell at cornell dot edu 2010-11-27 01:39:30 UTC 
---
no luck with ulimit -- I should have known since it is mmap
trying w/o -disable-bootstra

[Bug debug/46618] New: UNKNOWN_LOCATION = bus error

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46618

   Summary: UNKNOWN_LOCATION = bus error
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


I frequently see like this:
I don't know about this one, but generally it is because our frontend had used
UNKNOWN_LOCATION. I replace it with BUILTINS_LOCATION to fix it.


Can't UNKNOWN_LOCATION be acceptable?


(gdb) run
Starting program: /Users/jay/dev2/cm3/m3-sys/m3cc/AMD64_DARWIN-PA64_HPUX/cm3cg
-quiet -fPIC PA64_HPUX/TextCat.mc -g
Reading symbols for shared libraries +++. done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x
htab_hash_string (p=0x0) at ../../gcc-4.5/libiberty/hashtab.c:816
816  while ((c = *str++) != 0)
(gdb) bt
#0  htab_hash_string (p=0x0) at ../../gcc-4.5/libiberty/hashtab.c:816
#1  0x00268e9f in lookup_filename (file_name=0x0) at
../../gcc-4.5/gcc/dwarf2out.c:20124
#2  0x0028439d in add_dwarf_attr [inlined] () at
../../gcc-4.5/gcc/dwarf2out.c:16758
#3  0x0028439d in add_AT_file [inlined] () at
../../gcc-4.5/gcc/dwarf2out.c:7265
#4  0x0028439d in add_src_coords_attributes (die=0x0, decl=0x4132e050) at
../../gcc-4.5/gcc/dwarf2out.c:16758
#

[Bug middle-end/46597] New: configure -enable-checking=... -enable-build-with-cxx and bootstrap is g++ 3.3 hit minor problem

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46597

   Summary: configure -enable-checking=... -enable-build-with-cxx
and bootstrap is g++ 3.3 hit minor problem
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


I hit an error using g++ 3.3 to bootstrap on Darwin/ppc and configure
-enable-build-with-cxx -enable-checking=...

../../gcc-4.5/gcc/alias.c: In function `rtx_def* find_base_value(rtx_def*)':
../../gcc-4.5/gcc/alias.c:1008: error: cannot convert `rtx_def*' to `const 

case PLUS:
case MINUS:
  {
rtx temp, src_0 = XEXP (src, 0), src_1 = XEXP (src, 1); == this line 


I suggest therefore rtl.h:


 #if defined ENABLE_RTL_FLAG_CHECKING  GCC_VERSION  2007
 #if defined ENABLE_RTL_FLAG_CHECKING  ((!defined(__cplusplus)  
 GCC_VERSION  2007) || GCC_VERSION  3003)
#define RTL_FLAG_CHECK1(NAME, RTX, C1) __extension__\


or even just:
 #if defined ENABLE_RTL_FLAG_CHECKING  GCC_VERSION  3003


or like, not necessarily in rtl.h:

 #if GCC_VERSION = 3003
 #undef ENABLE_RTL_FLAG_CHECKING


or

 #if GCC_VERSION = 3003  defined(__cplusplus)
 #undef ENABLE_RTL_FLAG_CHECKING

Some allowance might be made for other compilers that implement the extensions
though?
Or, in C++, maybe use extensions less? e.g. inline functions might suit?


Thanks,
 - Jay

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #19 from Jay jay.krell at cornell dot edu 2010-11-08 11:50:35 UTC 
---
Hey, g++ 4.0 doesn't even like all of the code.
 You have to try all targets to uncover some of it.

target=alpha-dec-vms: 


g++ -c  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings
-W
missing-format-attribute   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc
-I../../g
cc-4.5/gcc/. -I../../gcc-4.5/gcc/../include
-I../../gcc-4.5/gcc/../libcpp/includ
e -I/Users/jay/dev2/cm3/m3-sys/m3cc/AMD64_DARWIN-ALPHA32_VMS/./gmp
-I/Users/jay/
dev2/cm3/m3-sys/m3cc/gcc-4.5/gmp  ../../gcc-4.5/gcc/vmsdbgout.c -o
vmsdbgout
.o
../../gcc-4.5/gcc/vmsdbgout.c:1944: error: integer constant is too large for
'lo
ng' type
../../gcc-4.5/gcc/vmsdbgout.c: In function 'int write_modbeg(int)':
../../gcc-4.5/gcc/vmsdbgout.c:746: error: invalid conversion from 'unsigned
int'
 to 'DST_LANGUAGE'
../../gcc-4.5/gcc/vmsdbgout.c: In function 'int write_rtnbeg(int, int)':
../../gcc-4.5/gcc/vmsdbgout.c:825: error: invalid conversion from 'int' to
'_DST
_TYPE'
make: *** [vmsdbgout.o] Error 1



jbook2:python jay$ g++ -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5493~1/src/configure --disable-checking
-enabl
e-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
 --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/includ
e/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9
--with-arch=apple
 --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5493)

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

Jay jay.krell at cornell dot edu changed:

   What|Removed |Added

Version|4.5.1   |4.6.0

--- Comment #17 from Jay jay.krell at cornell dot edu 2010-11-07 23:01:14 UTC 
---
unpatched trunk, same as 4.5.1:


 /home/jkrell/src/gcc-trunk/configure -prefix=$HOME/test1
-enable-build-with-cxx  gmake 


gmake[3]: Entering directory `/home/jkrell/obj/a/libcpp'
source='/home/jkrell/src/gcc-trunk/libcpp/charset.c' object='charset.o'
libtool=no DEPDIR=.deps depmode=dashXmstdout /bin/bash
/home/jkrell/src/gcc-trunk/libcpp/../depcomp CC 
-I/home/jkrell/src/gcc-trunk/libcpp -I.
-I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl
-I/home/jkrell/src/gcc-trunk/libcpp/include  -g 
-I/home/jkrell/src/gcc-trunk/libcpp -I.
-I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl
-I/home/jkrell/src/gcc-trunk/libcpp/include  -c
/home/jkrell/src/gcc-trunk/libcpp/charset.c
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 619: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 620: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 621: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 622: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 623: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 624: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 625: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 626: Warning (Anachronism):
Using bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
initialize extern C bool(*const)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 643: Warning (Anachronism):
Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 666: Warning (Anachronism):
Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 679: Warning (Anachronism):
Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 687: Warning (Anachronism):
Assigning bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*) to
extern C bool(*)(_iconv_info*,const unsigned char*,unsigned,_cpp_strbuf*).
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 744: Warning (Anachronism):
The operation extern C bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) is illegal.
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 746: Warning (Anachronism):
The operation extern C bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) is illegal.
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 748: Warning (Anachronism):
The operation extern C bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) is illegal.
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 750: Warning (Anachronism):
The operation extern C bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) == bool(*)(_iconv_info*,const unsigned
char*,unsigned,_cpp_strbuf*) is illegal.
/home/jkrell/src/gcc-trunk/libcpp/charset.c, line 752: Warning (Anachronism

[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334

--- Comment #1 from Jay jay.krell at cornell dot edu 2010-11-07 23:08:17 UTC 
---
Created attachment 22315
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22315
toplevel config.log

[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334

--- Comment #2 from Jay jay.krell at cornell dot edu 2010-11-07 23:08:57 UTC 
---
Created attachment 22316
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22316
libcpp config.log

[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334

--- Comment #3 from Jay jay.krell at cornell dot edu 2010-11-07 23:10:50 UTC 
---
jkr...@login [login]:~/src  ssh current10s
Last login: Sun Nov  7 23:09:51 2010 from login.bo.opencs
Sun Microsystems Inc.   SunOS 5.10  Generic January 2005
-bash-4.1$ cd obj
-bash-4.1$ mkdir b
-bash-4.1$ cd b
-bash-4.1$ which gcc
no gcc in /home/jkrell/sparc/bin /opt/csw/bin /usr/bin /usr/ccs/bin
/opt/csw/bin
-bash-4.1$ export CC=/opt/csw/gcc4/bin/gcc
-bash-4.1$ $CC -v
Using built-in specs.
Target: sparc-sun-solaris2.8
Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4
--exec-prefix=/opt/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas
--without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext
--with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw
--with-gmp=/opt/csw --enable-java-awt=xlib --enable-libada --enable-libssp
--enable-objc-gc --enable-threads=posix --enable-stage1-languages=c
--enable-languages=ada,c,c++,fortran,java,objc
Thread model: posix
gcc version 4.3.3 (GCC) 
-bash-4.1$ export CXX=CC
-bash-4.1$ $CXX -V
CC: Sun C++ 5.9 SunOS_sparc 2007/05/03
-bash-4.1$ which ar
/usr/ccs/bin/ar
-bash-4.1$ which gmake
/opt/csw/bin/gmake
-bash-4.1$ which make
/usr/ccs/bin/make
-bash-4.1$ export MAKE=gmake
-bash-4.1$ uname -a
SunOS current10s 5.10 Generic_142909-17 sun4v sparc SUNW,SPARC-Enterprise-T5220


/home/jkrell/src/gcc-trunk/configure -prefix=$HOME/test2 -enable-build-with-cxx
 $MAKE

.


gmake[3]: Entering directory `/home/jkrell/obj/b/libcpp'
source='/home/jkrell/src/gcc-trunk/libcpp/charset.c' object='charset.o'
libtool=no DEPDIR=.deps depmode=dashXmstdout /bin/bash
/home/jkrell/src/gcc-trunk/libcpp/../depcomp CC 
-I/home/jkrell/src/gcc-trunk/libcpp -I.
-I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl
-I/home/jkrell/src/gcc-trunk/libcpp/include  -g -W -Wall -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long 
-I/home/jkrell/src/gcc-trunk/libcpp -I.
-I/home/jkrell/src/gcc-trunk/libcpp/../include -I./../intl
-I/home/jkrell/src/gcc-trunk/libcpp/include  -c
/home/jkrell/src/gcc-trunk/libcpp/charset.c
CC: Warning: Option -W passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wwrite-strings passed to ld, if ld is invoked, ignored
otherwise
CC: Warning: Option -Wmissing-format-attribute passed to ld, if ld is invoked,
ignored otherwise
CC: Warning: Option -pedantic passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored
otherwise


attached toplevel config.log and libcpp/config.log
excerpt:

configure:4440: checking whether /opt/csw/gcc4/bin/gcc supports -pedantic
-Wno-long-long
WARN_PEDANTIC='-pedantic -Wno-long-long'


so you can see, CC and CXX are configured the same by autoconf, even though
they
might not be related.

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #18 from Jay jay.krell at cornell dot edu 2010-11-08 00:57:29 UTC 
---
more gcc_unreachable and then functions not returning, slightly 4.5.1 with Sun
CC (C++):


see
http://hudson.modula3.com:8080/job/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/105/console



/usr/bin/CC -c -g -DIN_GCC -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc
-I../../gcc-4.5/gcc/. -I../../gcc-4.5/gcc/../include
-I../../gcc-4.5/gcc/../libcpp/include
-I/home/m3hudson/current10x/workspace/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/cm3/m3-sys/m3cc/I386_SOLARIS/./gmp
-I/home/m3hudson/current10x/workspace/cm3-current-m3cc-I386_SOLARIS-opencsw-current10x/cm3/m3-sys/m3cc/gcc-4.5/gmp
-I/usr/include/libelf insn-output.c -o insn-output.o




../../gcc-4.5/gcc/config/i386/i386.md, line 2987: Error:
output_100(rtx_def**, rtx_def*) is expected to return a value.
../../gcc-4.5/gcc/config/i386/i386.md, line 2999: Error:
output_101(rtx_def**, rtx_def*) is expected to return a value.



../../gcc-4.5/gcc/config/i386/i386.md, line 3490: Error:
output_106(rtx_def**, rtx_def*) is expected to return a value. 



../../gcc-4.5/gcc/config/i386/i386.md, line 3502: Error:
output_107(rtx_def**, rtx_def*) is expected to return a value.
../../gcc-4.5/gcc/config/i386/i386.md, line 3643: Error:
output_111(rtx_def**, rtx_def*) is expected to return a value. 



I put return 0; after the gcc_unreachable.

[Bug other/46334] C++ compiler gets g++ switch even if it isn't g++

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334

--- Comment #4 from Jay jay.krell at cornell dot edu 2010-11-08 01:10:25 UTC 
---
another, this is an older Darwin/powerpc machine, using some version of g++


http://hudson.modula3.com:8080/job/cm3-current-m3cc-PPC_DARWIN/93/consoleFull


g++  -g  -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute-DHAVE_CONFIG_H  -o m3cgc1
m3cg/parse.o m3cg/m3-convert.o attribs.o main.o  libbackend.a
../libcpp/libcpp.a ../libcpp/libcpp.a ../libiberty/libiberty.a 
-L/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/.libs
-lgmp  
-L/Volumes/luthien/home/hudson2/workspace/cm3-m3cc-PPC_DARWIN/cm3/m3-sys/m3cc/PPC_DARWIN/./gmp/.libs
-lgmp   


ld: Undefined symbols:
__Z29legitimate_indirect_address_pP7rtx_defi


Presumed fix: remove inline on
config/rs6000/rs6000.c/legitimate_indirect_address.

[Bug other/46333] New: problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

   Summary: problems with configure -enable-build-with-cxx
-disable-bootstrap
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


Hi..so, I'm using configure -enable-build-with-cxx, with 4.5.1.


One person's machine has g++ 3.3.
Another's g++ produces executables that don't run, can't find libstdc++.
  So autoconf decides sizeof(int) == 0.
  On that machine, I'm instead trying /usr/bin/CC which is SunStudio 12.


Here are some of the problem.
I'm going to try to patch them all, but I don't have FSF papers.



g++ 3.3 doesn't like ATTRIBUTE_UNUSED after parameters,
as ansidecl.h says. But ARG_UNUSED isn't used much.
So:


/* Before GCC 3.4, the C++ frontend couldn't parse attributes placed after the
   identifier name. ATTRIBUTE_UNUSED is frequently used instead of
   ARG_UNUSED. */

#ifndef ATTRIBUTE_UNUSED
#if ! defined(__cplusplus) || (GCC_VERSION = 3004)
#define ATTRIBUTE_UNUSED __attribute__ ((__unused__))
#else
#define ATTRIBUTE_UNUSED /* nothing */
#endif
#endif
#define ARG_UNUSED(NAME) NAME ATTRIBUTE_UNUSED



ENUM_BITFIELD mixes integers and enums.
Fix:
#if (GCC_VERSION  2000)
#define ENUM_BITFIELD(TYPE, NAME, SIZE) __extension__ enum TYPE NAME : SIZE
#elif defined(__cplusplus)
#define ENUM_BITFIELD(TYPE, NAME, SIZE) enum TYPE NAME
#else
#define ENUM_BITFIELD(TYPE, NAME, SIZE) unsigned int
#endif


(in two copies of system.h)


but that breaks gengtype!
So I put in:
ENUM_BITFIELD{WS}?({WS}?{ID}{WS}?,{WS}?{ID}{WS}?,{WS}?[_0-9A-Z]+{WS}?); {
  /* do nothing */
}

not sure that is right!


some problem with obstack_free, I didn't investigate.
Maybe substraction involving void* NULL or 0?
Fix, obstack.h before:
Before:
# define obstack_free(h,obj)\
( (h)-temp = (char *) (obj) - (char *) (h)-chunk,\

After, add cast to char*:
# define obstack_free(h,obj)\
( (h)-temp = (char *) ((char*)(obj)) - (char *) (h)-chunk,\


ambiguity passing WIDE_INT to abs.
fix:
  in hwint.h define wide_abs to labs, llabs, or _abs64
  and use wide_abs


 There are also problems then compiling gmp in tree.
 I had to remove its #include iosfwd on Solaris because
 that pulled in locale and there was some problem.
Maybe due to local hacks? I removed all the locale stuff from my gcc/gmp.


 gmp also had using std::FILE which failed, I removed it.



oh, and I'm using a bit of C++.
gengtype doesn't like typedef vectorint foo_t or destructors.
I worked around like so:


#include vector
using namespace std;
#define typedef_vector typedef vector /* hack for gengtype */


and then typedef_vectorint foo_t;



and


#define DESTRUCTOR ~ /* hack for gengtype */

struct bar_t
{
  bar_t() { }
  virtual DESTRUCTOR bar_t() { }

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #1 from Jay jay.krell at cornell dot edu 2010-11-06 16:25:26 UTC 
---
also a bunch of gcc options are being passed to CC, odd
I set CXX=/usr/bin/CC to get here.


CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored
otherwise
source='../../gcc-4.5/libcpp/expr.c' object='expr.o' libtool=no DEPDIR=.deps
depmode=dashXmstdout /bin/bash ../../gcc-4.5/libcpp/../depcomp /usr/bin/CC 
-I../../gcc-4.5/libcpp -I. -I../../gcc-4.5/libcpp/../include
-I../../gcc-4.5/libcpp/include  -g -W -Wall -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long  -I../../gcc-4.5/libcpp -I.
-I../../gcc-4.5/libcpp/../include -I../../gcc-4.5/libcpp/include  -c
../../gcc-4.5/libcpp/expr.c
CC: Warning: Option -W passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wwrite-strings passed to ld, if ld is invoked, ignored
otherwise
CC: Warning: Option -Wmissing-format-attribute passed to ld, if ld is invoked,
ignored otherwise
CC: Warning: Option -pedantic passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored
otherwise
CC: Warning: Option -W passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wwrite-strings passed to ld, if ld is invoked, ignored
otherwise
CC: Warning: Option -Wmissing-format-attribute passed to ld, if ld is invoked,
ignored otherwise
CC: Warning: Option -pedantic passed to ld, if ld is invoked, ignored otherwise



also lots of warnings about mixing extern C and not:

../../gcc-4.5/libcpp/files.c, line 1173: Warning (Anachronism): Formal
argument 2 of type extern C unsigned(*)(const void*) in call to
htab_create_alloc(unsigned, extern C unsigned(*)(const void*), extern C
int(*)(const void*,const void*), extern C void(*)(void*), extern C
void*(*)(unsigned,unsigned), extern C void(*)(void*)) is being passed
unsigned(*)(const void*).
../../gcc-4.5/libcpp/files.c, line 1173: Warning (Anachronism): Formal
argument 3 of type extern C int(*)(const void*,const



and other errors related, mixing said in ternary, like:


foo = foo2 ? foo2 : foo3;
 (as in reallocator = set-reallocator ? set-reallocator : xrealloc)


where foo2 and foo3 vary in extern C-ness.
workaround is
foo = foo2
if (!foo)
  foo = foo3

even though that doesn't seem different enough -- I understand there is the
problem of figuring out a type for the ternary operator, but there is also the
matter of being able to assign the function pointers



here's an example of the obtack_free problem, either I didn't get all the
obstack.h files fixed or the cast needs to be void* or something:


../../gcc-4.5/libcpp/files.c, line 1193: Error: Cannot assign char* to int.

[Bug other/46334] New: C++ compiler gets g++ switch even if it isn't g++

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46334

   Summary: C++ compiler gets g++ switch even if it isn't g++
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


if C compiler is gcc and C++ compiler is not g++, C++ compiler gets g++ flags
(maybe redirect to autoconf?)

export CXX=/usr/bin/CC
gcc-4.5.1/configure -enable-build-with-cxx


 /usr/bin/CC -c  -g -DIN_GCC   -W -Wall -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc
-I../../gcc-4.5/gcc/. -I../../gcc-4.5/gcc/../include
-I../../gcc-4.5/gcc/../libcpp/include
-I/home/jkrell/dev2/cm3/m3-sys/m3cc/SOLsun/./gmp
-I/home/jkrell/dev2/cm3/m3-sys/m3cc/gcc-4.5/gmp 
-I../../gcc-4.5/gcc/../libdecnumber -I../../gcc-4.5/gcc/../libdecnumber/dpd
-I../libdecnumber   -I/usr/include/libelf  ../../gcc-4.5/gcc/df-core.c -o
df-core.o
CC: Warning: Option -W passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wall passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wwrite-strings passed to ld, if ld is invoked, ignored
otherwise
CC: Warning: Option -Wmissing-format-attribute passed to ld, if ld is invoked,
ignored otherwise
CC: Warning: Option -pedantic passed to ld, if ld is invoked, ignored otherwise
CC: Warning: Option -Wno-long-long passed to ld, if ld is invoked, ignored
otherwise
CC: Warning: Option -Wno-variadic-macros passed to ld, if ld is invoked,
ignored otherwise
CC: Warning: Option -Wno-overlength-strings passed to ld, if ld is invoked,
ignored otherwise
/usr/bin/CC -c  -g -DIN_GCC   -W -Wall -Wwrite-strings
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros


seems a bit off.

I'm trying now with CXX=CC, CC=cc.
The autoconf log is looking better.


 - Jay

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #4 from Jay jay.krell at cornell dot edu 2010-11-06 23:53:47 UTC 
---
../../gcc-4.5/gcc/opts.c, line 1233: Error: The function __flsbuf must have
a prototype.
../../gcc-4.5/gcc/opts.c, line 1350: Error: The function __flsbuf must have
a prototype.

#if (__cplusplus = 199711L  (defined(_LP64) || defined(_REENTRANT))) || \
__cplusplus  199711L
...
#ifndef _LP64
extern int  __filbuf(FILE *);
extern int  __flsbuf(int, FILE *);
#endif  /*  _LP64   */

#else   /* !defined __STDC__ */


either need to #if __GNUC__ around #define foo foo_unlocked
or need to define __REENTRANT.

This is all on Solaris 2.9, which may be out of support soon.
I can move to Solaris 2.10.

I need gcc 4.5.1. I can look into trunk *later*.

Some of my own patches run afoul of SunStudio 12 C++, that maybe
unique to me, e.g.:

bool unused_gcc_feature (...) { gcc_unreachable (); }

 = unused_gcc_feature must return a value
  so I put in return 0; unpatched gcc doesn't necessarily have this.


I'm not 100% which older g++ is on the other machine, just that it had problem
with attribute(unused).  However, I bet it is easier to use than non-g++! :)

Also my ENUM_BITFIELD has an obvious typo in the last case, it need to
reference NAME.


Later,
 - Jay

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #5 from Jay jay.krell at cornell dot edu 2010-11-07 00:07:31 UTC 
---
Huh, I misread and I don't see why _flsbuf/__flsbuf/_filbuf/__filbuf aren't
declared.
Anyway, I'll try:

# if defined(HAVE_PUTC_UNLOCKED)  (!defined(__cplusplus) || defined(__GNUC__)
|| !defined(__sun))

on
#  define putc(C, Stream) putc_unlocked (C, Stream)

and analogous on
#  define getc(Stream) getc_unlocked (Stream)

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #6 from Jay jay.krell at cornell dot edu 2010-11-07 00:15:05 UTC 
---
trying..
#if defined(__cplusplus)  !defined(__GNUC__)  defined(__sun)
#undef HAVE_PUTC_UNLOCKED
#undef HAVE_PUTCHAR_UNLOCKED
#undef HAVE_GETC_UNLOCKED
#undef HAVE_GETCHAR_UNLOCKED
#endif

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #7 from Jay jay.krell at cornell dot edu 2010-11-07 00:28:39 UTC 
---
rtl.c:
../../gcc-4.5/gcc/rtl.def, line 82: Error: Badly formed constant expression.
../../gcc-4.5/gcc/rtl.def, line 89: Error: } expected instead of sizeof.


rtl.c, change:

#define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS)   sizeof FORMAT - 1 ,

to:

#define DEF_RTL_EXPR(ENUM, NAME, FORMAT, CLASS)   sizeof (FORMAT) - 1 ,

seems to work. Seems preferable too.

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #8 from Jay jay.krell at cornell dot edu 2010-11-07 00:30:29 UTC 
---
an example of the gcc_unreachable problem that I don't think I caused:

../../gcc-4.5/gcc/targhooks.c, line 85: Error:
default_legitimate_address_p(machine_mode, rtx_def*, bool) is expected to
return a value.
../../gcc-4.5/gcc/targhooks.c, line 938: Error:
default_addr_space_convert(rtx_def*, tree_node*, tree_node*) is expected to
return a value.

I suggest putting in return 0; at end.

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #9 from Jay jay.krell at cornell dot edu 2010-11-07 00:50:02 UTC 
---
Here is an example that occurs many times, warning only:

extern C { void F1(void); }

void (*F2)(void) = F1;

-bash-4.1$ /usr/bin/CC -c $HOME/1.cpp
/home/jkrell/1.cpp, line 5: Warning (Anachronism): Using extern C void(*)()
to initialize void(*)().
1 Warning(s) detected.

-bash-4.1$ uname -a
SunOS current10s 5.10 Generic_142909-17 sun4v sparc SUNW,SPARC-Enterprise-T5220

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #10 from Jay jay.krell at cornell dot edu 2010-11-07 01:10:56 UTC 
---
Undefined   first referenced
 symbol in file
__gmpn_add 
/home/jkrell/dev2/cm3/m3-sys/m3cc/SOLsun/./gmp/.libs/libgmp.a(add.o)
__gmpn_cmp 
/home/jkrell/dev2/cm3/m3-sys/m3cc/SOLsun/./gmp/.libs/libgmp.a(add.o)
__gmpn_sub 
/home/jkrell/dev2/cm3/m3-sys/m3cc/SOLsun/./gmp/.libs/libgmp.a(add.o)
__gmpn_add_1   
/home/jkrell/dev2/cm3/m3-sys/m3cc/SOLsun/./gmp/.libs/libgmp.a(add_ui.o)
__gmpn_sub_1   
/home/jkrell/dev2/cm3/m3-sys/m3cc/SOLsun/./gmp/.libs/libgmp.a(add_ui.o)


trying extern C in gmp-in.h

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #11 from Jay jay.krell at cornell dot edu 2010-11-07 01:19:03 UTC 
---
fyi, even with modern g++ 4.0, there are many warnings, e.g.:

./../gcc-4.5/gcc/postreload.c: In function ‘void reload_cse_regs_1(rtx_def*)’:
../../gcc-4.5/gcc/postreload.c:199: warning: passing negative value
‘-0x

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #12 from Jay jay.krell at cornell dot edu 2010-11-07 01:37:15 UTC 
---
Huh, maybe enum bitfields are legal C++?

#if defined(__cplusplus)
#define ENUM_BITFIELD(TYPE, NAME, SIZE) enum TYPE NAME : SIZE


seems to work, so can go back to the 1 parameter version, and not change
gengtype.
I will try it.

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #13 from Jay jay.krell at cornell dot edu 2010-11-07 02:04:14 UTC 
---
gmpn_add/sub/cmp were because I have drastically slashed mpc/mpfr/gmp
dependency, and optimizations off here. That is fixed.
Now I can compile/link our cc1 analog!
That's all we use.
I can maybe continue this adventure with unpatched gmp/mpfr/mpc, trunk gcc, I'd
limit myself to C and C++ frontends if I do. It could well be that without
-disable-bootstrap, it doesn't use C++ until later stages and then works.

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #14 from Jay jay.krell at cornell dot edu 2010-11-07 04:03:13 UTC 
---
../../gcc-4.5/gcc/combine.c, line 6561: Error: Unexpected type name
rtl_hooks encountered.
../../gcc-4.5/gcc/combine.c, line 6561: Error: Unexpected type name
rtl_hooks encountered.

so change the type to rtl_hooks_t

(This is on Solaris 2.10 now, as I hit other problems on 2.9.)

a new warning:
../../gcc-4.5/gcc/bitmap.c, line 315: Warning (Anachronism): Attempt to
redefine __alignof__ without using #undef.

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #15 from Jay jay.krell at cornell dot edu 2010-11-07 04:13:30 UTC 
---
hm..or maybe the Sun CC recurses here?
rtl.h:#define gen_lowpart rtl_hooks.gen_lowpart

maybe #undef gen_lowpower and use rtl_hooks.gen_lowpart?
or rename the member to gen_lowpower_hook?

[Bug other/46333] problems with configure -enable-build-with-cxx -disable-bootstrap

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46333

--- Comment #16 from Jay jay.krell at cornell dot edu 2010-11-07 04:20:47 UTC 
---
I went with renaming the member to gen_lowerpart_, with underscore at the end.
There are no references to it except for the macro, it appears.
-bash-4.1$ CC -V
CC: Sun C++ 5.9 SunOS_sparc 2007/05/03
-bash-4.1$ uname -a
SunOS current10s 5.10 Generic_142909-17 sun4v sparc SUNW,SPARC-Enterprise-T5220

[Bug target/46091] New: missed optimization: x86 bt/btc/bts instructions

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091

   Summary: missed optimization: x86 bt/btc/bts instructions
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


The following code, at least when optimizing for space, should use x86
bt/btc/bts instructions.

#include limits.h
#include stddef.h

void set_bit(size_t* a, size_t b)
{
  const unsigned c = sizeof(size_t) * CHAR_BIT;
  a[b / c] |= (((size_t)1)  (b % c));
}

void clear_bit(size_t* a, size_t b)
{
  const unsigned c = sizeof(size_t) * CHAR_BIT;
  a[b / c] =  ~(((size_t)1)  (b % c));
}

int get_bit(size_t* a, size_t b)
{
  const unsigned c = sizeof(size_t) * CHAR_BIT;
  return !!(a[b / c]  (((size_t)1)  (b % c)));
}

[Bug target/45927] New: autoconf regression wrt .quad availability targeting amd64 from biarch cross compiler

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45927

   Summary: autoconf regression wrt .quad availability targeting
amd64 from biarch cross compiler
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


Regression in 4.5.1 vs. 4.3.5 (sorry, we skipped 4.4)

gcc_GAS_CHECK_FEATURE([.quad directive],
  gcc_cv_as_ix86_quad,,,
  [.quad 0],,
  [AC_DEFINE(HAVE_AS_IX86_QUAD, 1,
[Define if your assembler supports the .quad directive.])])


This breaks cross builds to Solaris/amd64.
  You can then easily trigger this path:


const char *
integer_asm_op (int size, int aligned_p)
{
  struct asm_int_op *ops;

  if (aligned_p)
ops = targetm.asm_out.aligned_op;
  else
ops = targetm.asm_out.unaligned_op;


  switch (size)
{
case 1:
  return targetm.asm_out.byte_op;
case 2:
  return ops-hi;
case 4:
  return ops-si;
case 8:
  return ops-di;  = NULL, but wasn't NULL in 4.3.5

...
bool
default_assemble_integer (rtx x ATTRIBUTE_UNUSED,
  unsigned int size ATTRIBUTE_UNUSED,
  int aligned_p ATTRIBUTE_UNUSED)
{
  const char *op = integer_asm_op (size, aligned_p);
  /* Avoid GAS bugs for large values.  Specifically negative values whose
 absolute value fits in a bfd_vma, but not in a bfd_signed_vma.  */
  if (size  UNITS_PER_WORD  size  POINTER_SIZE / BITS_PER_UNIT)
return false;
  return op  (assemble_integer_with_op (op, x), true);  == NULL = false,
but was presumably true in 4.3.5
}


bool
assemble_integer (rtx x, unsigned int size, unsigned int align, int force)
{
  int aligned_p;

  aligned_p = (align = MIN (size * BITS_PER_UNIT, BIGGEST_ALIGNMENT));

  /* See if the target hook can handle this kind of object.  */
  if (targetm.asm_out.integer (x, size, aligned_p))
return true;  = no longer hit this

...
  if (! assemble_integer (expand_expr (exp, NULL_RTX, VOIDmode,
   EXPAND_INITIALIZER),
  MIN (size, thissize), align, 0))
 ==error (initializer for integer/fixed-point value is too complicated);
  break;



They worked fine in gcc 4.3 when this autoconfigury was absent.
gcc 4.3 assumed .quad was available in biarch x86.
Probably the autoconfigury is close to correct.
It should be used perhaps, but only for guiding 32bit compilation.


I verified the problem is related to:

/* The 32-bit Solaris assembler does not support .quad.  Do not use it.  */
#ifndef HAVE_AS_IX86_QUAD
#undef ASM_QUAD
#endif



gcc-4.5/gcc/config/i386/sol2.h


which wasn't in 4.3.5.

4.3.5 instead had:


/* The 32-bit Solaris assembler does not support .quad.  Do not use it.  */
#ifndef TARGET_BI_ARCH
#undef ASM_QUAD
#endif

[Bug spam/45928] New: genattrtab is too slow.

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45928

   Summary: genattrtab is too slow.
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: spam
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


genattrtab is too slow.

This step:
build/genattrtab ../../gcc-4.5/gcc/config/i386/i386.md \
  insn-conditions.md  tmp-attrtab.c

takes a long time. I should look at what it is doing..

[Bug spam/45929] New: insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929

   Summary: insn-attrtab.c is too big, can't compile within a few
hundred MB (4.3.5 oops)
   Product: gcc
   Version: 4.3.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: spam
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


insn-attrtab.c is too big, can't compile within a few hundred MB

oops, this is 4.3.5, I meant to be building 4.5.1!

bootstrap compiler is I believe:
-bash-4.1$ /usr/sfw/bin/gcc -v
Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs
Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure
--prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++
--enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)


gcc -c   -g  -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute   
-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/.
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include
-I/home/jkrell/dev2/cm3/m3-sys/m3cc/AMD64_SOLARIS/./gmp
-I/home/jkrell/dev2/cm3/m3-sys/m3cc/gcc/gmp  -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumberinsn-attrtab.c -o
insn-attrtab.o


cc1: out of memory allocating 235720640 bytes after a total of 185008128 bytes
gmake: *** [insn-attrtab.o] Error 1

-bash-4.1$ ulimit
unlimited
-bash-4.1$ ulimit -a
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) unlimited
file size   (blocks, -f) unlimited
open files  (-n) 256
pipe size(512 bytes, -p) 10
stack size  (kbytes, -s) 10240
cpu time   (seconds, -t) unlimited
max user processes  (-u) 16357
virtual memory  (kbytes, -v) unlimited
-bash-4.1$  uname -a 
SunOS current10x 5.10 Generic_142910-17 i86pc i386 i86pc

[Bug spam/45929] insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929

Jay jay.krell at cornell dot edu changed:

   What|Removed |Added

Version|4.3.5   |4.5.1

--- Comment #1 from Jay jay.krell at cornell dot edu 2010-10-07 09:03:21 UTC 
---
same problem compiling 4.5.1

gcc -c  -g  -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-format-attribute -Wold-style-definition  
-DHAVE_CONFIG_H -I. -I. -I../../gcc-4.5/gcc -I../../gcc-4.5/gcc/.
-I../../gcc-4.5/gcc/../include -I../../gcc-4.5/gcc/../libcpp/include
-I/home/jkrell/dev2/cm3/m3-sys/m3cc/AMD64_SOLARIS/./gmp
-I/home/jkrell/dev2/cm3/m3-sys/m3cc/gcc-4.5/gmp 
-I../../gcc-4.5/gcc/../libdecnumber -I../../gcc-4.5/gcc/../libdecnumber/dpd
-I../libdecnumber   -I/usr/include/libelf  insn-attrtab.c -o insn-attrtab.o

cc1: out of memory allocating 277312464 bytes after a total of 14352384 bytes

[Bug spam/45929] insn-attrtab.c is too big, can't compile within a few hundred MB (4.3.5 oops)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45929

--- Comment #3 from Jay jay.krell at cornell dot edu 2010-10-07 10:31:04 UTC 
---
I'll switch to gcc 4.x. It would be nice to keep the files/functions smaller
for portability.

[Bug other/45864] New: system.h is crufty maybe? Raise the level fo ANSI C89?

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45864

   Summary: system.h is crufty maybe? Raise the level fo ANSI C89?
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jay.kr...@cornell.edu


I recently found a compiler that didn't like spaces
after the # in preprocessor directives.


In system.h:
 Do any systems lack stddef.h? (it is in ANSI C89)
 Do any systems lack #define NULL? (ditto)
 Do any systems lack limits.h? (ditto)
 Ditto:
   string.h? time.h? (ditto)
   errno declared in errno.h? (ditto)
   SEEK_SET, SEEK_CUR, SEEK_END (ditto)
   F_OK, X_OK, W_OK, R_OK
   O_RDONLY, O_WRONLY
   atof, atol, free, getenv, strstr, abort, offsetof? (ditto)
   malloc, calloc, realloc? (ditto)
   Posixy systems that gcc can be hosted on: getcwd, getwd, sbrk?


I wonder if all the compability stuff needs to stay.
  Along with suggesting a new one -- no spaces after #.


I wonder if the _unlocked stuff is worthwhile.
  One should be sure to have reasonably large inputs/outputs, not
  just getchar one at a time, for example.


Maybe some of this is for header-less environments?
I grant, getting headers for cross build scenarios can be a pain.
But I do need the libraries anyway.


 - Jay

[Bug middle-end/44984] gcc passes unsigned instead of int for printf width/precision (warnings generated)

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44984

--- Comment #3 from Jay jay.krell at cornell dot edu 2010-10-02 10:27:53 UTC 
---
 which compiler produces this


I'm afraid I'm not sure and can't quickly/easily make it happen again. Sorry.

[Bug java/45322] libjava error: libtool: compile: libobj name `ltdl.lo' may not contain shell special

[jay.krell at cornell dot edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45322

--- Comment #7 from Jay jay.krell at cornell dot edu 2010-10-02 10:29:06 UTC 
---
It looks like the machine I was using might not be available any longer. Sorry.