[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[aldot at gcc dot gnu dot org]

--- Comment #84 from aldot at gcc dot gnu dot org  2008-09-24 09:51 ---
The fix doesn't seem to work for me on arm:
$ cat pr-weak.c
/* tell the compiler that the count isn't in the small data section if the arch
 * has one (eg: FRV)
 */
extern const unsigned long kallsyms_num_syms
__attribute__((weak, section(".rodata")));

int main(void) {
  return !!kallsyms_num_syms;
}

$ /there.arm/usr/bin/arm-linux-uclibcgnueabi-gcc -Os -S -o - pr-weak.c -v
Using built-in specs.
Target: arm-linux-uclibcgnueabi
Configured with: /srcs/toolchain_build_arm_nofpu/gcc-4.4.0/configure
--prefix=/usr --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu
--target=arm-linux-uclibcgnueabi --enable-languages=c,fortran
--with-sysroot=/there.arm
--with-build-time-tools=/there.arm/usr/arm-linux-uclibcgnueabi/bin
--disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --enable-shared
--with-gmp=/srcs/toolchain_build_arm_nofpu/gmp
--with-mpfr=/srcs/toolchain_build_arm_nofpu/mpfr --disable-nls --enable-threads
--disable-multilib --with-float=soft --with-abi=aapcs-linux --disable-libssp
--disable-libssp --disable-libmudflap --disable-libgomp
--enable-decimal-float=no
Thread model: posix
gcc version 4.4.0 20080923 (experimental) [trunk revision 140602] (GCC) 
COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft'
'-mabi=aapcs-linux'
 /there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/cc1 -quiet -v
-iprefix /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/ pr-weak.c
-quiet -dumpbase pr-weak.c -mfloat-abi=soft -mabi=aapcs-linux -auxbase-strip -
-Os -version -o -
ignoring nonexistent directory
"/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include"
ignoring nonexistent directory "/there.arm/usr/local/include"
ignoring duplicate directory
"/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include"
ignoring duplicate directory
"/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed"
ignoring nonexistent directory
"/there.arm/usr/bin/../lib/gcc/../../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/include"
#include "..." search starts here:
#include <...> search starts here:
 /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include
 /there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/include-fixed
 /there.arm/usr/include
End of search list.
GNU C (GCC) version 4.4.0 20080923 (experimental) [trunk revision 140602]
(arm-linux-uclibcgnueabi)
compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 071bc0f306e6057c8a651fee23ec8dfa
.cpu arm10tdmi
.fpu softvfp
.eabi_attribute 20, 1
.eabi_attribute 21, 1
.eabi_attribute 23, 3
.eabi_attribute 24, 1
.eabi_attribute 25, 1
.eabi_attribute 26, 2
.eabi_attribute 30, 4
.eabi_attribute 18, 4
.file   "pr-weak.c"
.text
.align  2
.global main
.type   main, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L3
ldr r0, [r3, #0]
subsr0, r0, #0
movne   r0, #1
bx  lr
.L4:
.align  2
.L3:
.word   kallsyms_num_syms
.size   main, .-main
.ident  "GCC: (GNU) 4.4.0 20080923 (experimental) [trunk revision
140602]"
.section.note.GNU-stack,"",%progbits
COMPILER_PATH=/there.arm/usr/bin/../libexec/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../libexec/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/bin/
LIBRARY_PATH=/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/:/there.arm/usr/bin/../lib/gcc/:/there.arm/usr/bin/../lib/gcc/arm-linux-uclibcgnueabi/4.4.0/../../../../arm-linux-uclibcgnueabi/lib/:/there.arm/lib/:/there.arm/usr/lib/
COLLECT_GCC_OPTIONS='-Os' '-S' '-o' '-' '-v' '-mfloat-abi=soft'
'-mabi=aapcs-linux'

works with 4.3.2 configured in the same way.


-- 

aldot at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #83 from hp at gcc dot gnu dot org  2008-09-22 02:06 ---
committed


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #82 from hp at gcc dot gnu dot org  2008-09-22 01:56 ---
Subject: Bug 37170

Author: hp
Date: Mon Sep 22 01:54:41 2008
New Revision: 140540

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140540
Log:
PR middle-end/37170
PR middle-end/37280
* gcc.dg/weak/weak-15.c, gcc.dg/weak/weak-16.c,
g++.dg/ext/inline1.C: New tests.

Added:
trunk/gcc/testsuite/g++.dg/ext/inline1.C
trunk/gcc/testsuite/gcc.dg/weak/weak-15.c
trunk/gcc/testsuite/gcc.dg/weak/weak-16.c
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #81 from hp at gcc dot gnu dot org  2008-09-22 01:55 ---
Subject: Bug 37170

Author: hp
Date: Mon Sep 22 01:54:03 2008
New Revision: 140539

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140539
Log:
PR middle-end/37170
PR middle-end/37280
* final.c (mark_symbol_ref_as_used): New helper function.
(output_operand): Instead of just looking inside MEMs for
SYMBOL_REFs, use new helper function and for_each_rtx.
* varasm.c (assemble_external): Move #ifndef ASM_OUTPUT_EXTERNAL
to after weak-handling.  Don't mark decls with TREE_STATIC as weak.
Make head comment more general.
* config/darwin.c (machopic_output_indirection): Handle weak
references here, like in assemble_external.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/darwin.c
trunk/gcc/final.c
trunk/gcc/varasm.c


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[jsm28 at gcc dot gnu dot org]

-- 

jsm28 at gcc dot gnu dot org changed:

   What|Removed |Added

   Priority|P3  |P2


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #80 from dave at hiauly1 dot hia dot nrc dot ca  2008-09-02 
14:06 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> Any news on the hppa testing?

I didn't do anything further with the 32-bit port.  I did do a
hppa64-hpux11.11 build with your change.  I went through the C test
results yesterday.  Although there are lots of failures, I didn't
see any problem related to your proposed change.  So, if there are
no other problems, I would say submit the change for review.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #79 from hp at gcc dot gnu dot org  2008-09-02 10:18 ---
Any news on the hppa testing?


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #78 from hp at gcc dot gnu dot org  2008-09-01 01:42 ---
FWIW, the results in
 certainly look
clean enough to be usable as a baseline.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #77 from hp at gcc dot gnu dot org  2008-08-31 22:51 ---
(In reply to comment #76)
> Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c
> 
> > Is this really a regression?

I mean "regression, compared to unpatched".

> Yes, but it may not have anything to do with your change.

Then *please* leave them out of this PR.
I need results just compared to an unpatched revision no earlier than 139233.

I can't take on all weak-related or extern-related regressions, and this
PR is only supposed to fix the one in the description (without regressing for
any targets).

Thanks for testing!


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #76 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-31 
21:31 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> Is this really a regression?

Yes, but it may not have anything to do with your change.  Looking
through my test results, I see it started failing between 136817 and
136971.  At 136817, there were no test failures with undefined symbols,
wrong symbol type, etc.

static14.C and static20.C started betweea 137850 and 138833.

I just did a quick scan through the test logs for issues that looked
like they might be related to the current problem.

> What unpatched revision did you use as a baseline?

Your patch was applied to 139805.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #75 from hp at gcc dot gnu dot org  2008-08-31 20:33 ---
(In reply to comment #74)
> > Patch, take 6.
> 
> This one is a significant improvement.  In the C testsuite, I'm
> seeing a few failures like this one:
> 
> Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
> /te
> st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c-O3
> -fwhole-
> program -combine -fipa-type-escape -fprofile-generate  -lm   -o
> /test/gnu/gcc/ob
> jdir/gcc/testsuite/gcc/w_prof_global_array.x01(timeout = 300)
> /usr/ccs/bin/ld: Unsatisfied symbols:
>_GLOBAL__FI_w_prof_global_array_x01 (first referenced in +init option)
> (code)
>_GLOBAL__FD_w_prof_global_array_x01 (first referenced in +fini option)
> (code)
> collect2: ld returned 1 exit status

Is this really a regression?
What unpatched revision did you use as a baseline?

When I compile that testcase, edited because of the stdlib include as follows:
--- w_prof_global_array.c   2008-01-03 16:12:42.0 +0100
+++ /home/hp/wp.c   2008-08-31 21:09:44.0 +0200
@@ -1,4 +1,4 @@
-#include 
+extern void abort(void);
 typedef struct
 {
   int a;

I don't see a difference unpatched/patched at revision 139233 in the generated
assembly code, compiling with:
./xgcc -B./ -S ~/wp.c -o wp.s -O3 -fwhole-program -combine -fipa-type-escape
-fprofile-generate
(and no, adding "__attribute__ ((__noreturn__))" still makes no difference.)

> Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
> -B/test/gnu/
> gcc/objdir/gcc/testsuite/g++/../../
> /test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja
> /g++.other/static14.C  -nostdinc++
> -I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/
> libstdc++-v3/include/hppa2.0w-hp-hpux11.11
> -I/test/gnu/gcc/objdir/hppa2.0w-hp-hp
> ux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
> -I/test/
> gnu/gcc/gcc/libstdc++-v3/include/backward
> -I/test/gnu/gcc/gcc/libstdc++-v3/tests
> uite/util -fmessage-length=0   -ansi -pedantic-errors -Wno-long-long   
> -L/test/
> gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs 
> -L/test/gnu/gcc/o
> bjdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
> -L/test/gnu/gcc/objdir/hppa
> 2.0w-hp-hpux11.11/./libiberty  -lm   -o static14.exe(timeout = 300)
> /usr/ccs/bin/ld: Unsatisfied symbols:
>basic_string::~basic_string() (first referenced in /var/tmp//ccI3Feaf.o)
> (code)
>Side::name()::sname (first referenced in /var/tmp//ccI3Feaf.o) (data)
> collect2: ld returned 1 exit status
> compiler exited with status 1

No difference here either "-ansi -pedantic-errors -Wno-long-long".
Weirdness: I see references in the generated code to
basic_string::~basic_string() and Side::name()::sname, and that generated code
isn't there for cris-elf or native.  Ditto static20.C

Maybe I'd see a difference if I force weak support?
Let me check...


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #74 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-31 
03:19 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> --- Comment #71 from hp at gcc dot gnu dot org  2008-08-30 06:27 ---
> Created an attachment (id=16169)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169&action=view)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169&action=view)
> Patch, take 6.

This one is a significant improvement.  In the C testsuite, I'm
seeing a few failures like this one:

Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/
/te
st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/struct/w_prof_global_array.c-O3
-fwhole-
program -combine -fipa-type-escape -fprofile-generate  -lm   -o
/test/gnu/gcc/ob
jdir/gcc/testsuite/gcc/w_prof_global_array.x01(timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
   _GLOBAL__FI_w_prof_global_array_x01 (first referenced in +init option)
(code)
   _GLOBAL__FD_w_prof_global_array_x01 (first referenced in +fini option)
(code)
collect2: ld returned 1 exit status

and in the C++ suite,

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja
/g++.other/static14.C  -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/
libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hp
ux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/
gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/tests
uite/util -fmessage-length=0   -ansi -pedantic-errors -Wno-long-long   
-L/test/
gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs 
-L/test/gnu/gcc/o
bjdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/hppa
2.0w-hp-hpux11.11/./libiberty  -lm   -o static14.exe(timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
   basic_string::~basic_string() (first referenced in /var/tmp//ccI3Feaf.o)
(code)
   Side::name()::sname (first referenced in /var/tmp//ccI3Feaf.o) (data)
collect2: ld returned 1 exit status
compiler exited with status 1

and

Executing on host: /test/gnu/gcc/objdir/gcc/testsuite/g++/../../g++
-B/test/gnu/
gcc/objdir/gcc/testsuite/g++/../../
/test/gnu/gcc/gcc/gcc/testsuite/g++.old-deja
/g++.other/static20.C  -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/
libstdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hp
ux11.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/
gnu/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/tests
uite/util -fmessage-length=0   -ansi -pedantic-errors -Wno-long-long   
-L/test/
gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs 
-L/test/gnu/gcc/o
bjdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
-L/test/gnu/gcc/objdir/hppa
2.0w-hp-hpux11.11/./libiberty  -lm   -o static20.exe(timeout = 300)
/usr/ccs/bin/ld: Unsatisfied symbols:
   foo::func()::x (first referenced in /var/tmp//ccG3jpCC.o) (data)
collect2: ld returned 1 exit status

Sorry, this is so hard.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #73 from hp at gcc dot gnu dot org  2008-08-30 18:45 ---
(In reply to comment #72)
> SUPPORTS_WEAK is defined on hppa2.0w-hp-hpux11.11 depending on GAS
> support.  See som.h.

Good to know.  It can't be compiled cross out of the box though, and the
default is off:

/bin/sh ./libtool --tag=CC --mode=link gcc -W -Wall -Wstrict-prototypes
-Wmissing-prototypes -Werror -g -O2   -o size  \
size.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a 
-lz
libtool: link: gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Werror -g
-O2 -o size size.o bucomm.o version.o f\
ilemode.o  ../bfd/.libs/libbfd.a ../libiberty/libiberty.a -lz
../bfd/.libs/libbfd.a(targets.o):(.data+0x10): undefined reference to `som_vec'
../bfd/.libs/libbfd.a(targets.o):(.rodata+0x20): undefined reference to
`som_vec'
collect2: ld returned 1 exit status
make[5]: *** [size] Error 1
make[5]: Leaving directory `/home/hp/combq/hppa2-obj/binutils'


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #72 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-30 
18:19 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> It shouldn't matter for Darwin (which doesn't define ASM_OUTPUT_EXTERNAL,
> right?) but will fix the test-case for hppa2.0w-hp-hpux11.11, which BTW seems
> not to support weak.

SUPPORTS_WEAK is defined on hppa2.0w-hp-hpux11.11 depending on GAS
support.  See som.h.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #71 from hp at gcc dot gnu dot org  2008-08-30 06:27 ---
Created an attachment (id=16169)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16169&action=view)
Patch, take 6.

Sigh.  This just moves the TREE_STATIC check from the early-return to the
weak-test, since it's wrong for *some* external declarations.
It shouldn't matter for Darwin (which doesn't define ASM_OUTPUT_EXTERNAL,
right?) but will fix the test-case for hppa2.0w-hp-hpux11.11, which BTW seems
not to support weak.  Test in progress, native and cris-elf as before.

I'm thankful as always for any testing, this time particularly on hppa-hpux
targets.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16146|0   |1
is obsolete||


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #70 from hp at gcc dot gnu dot org  2008-08-30 03:37 ---
(In reply to comment #67)
> > -   .IMPORT _ZNSoD1Ev,CODE
> 
> If any of these functions is present in the .s, then there's a problem.
> The default for a 32-bit HP-UX symbol that isn't imported is DATA.

The problem here, is just that the .IMPORT lines are gone.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #69 from hp at gcc dot gnu dot org  2008-08-30 03:20 ---
(In reply to comment #64)
> Not sure what you meant by that comment; that's not what happens here AFAICT.
> I stated that output_operand does not see the same symbol_ref as was passed to
> the rtl insn expander, so target-specific code is needed just like for Darwin
> - or maybe it's just missing in generic code, for the constant pool.

No, that's not it.  The TREE_STATIC test is wrong.
I should merge extern and (extern) weak handling somehow.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #68 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-30 
02:48 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> > If the encoding for function names is getting stripped, then
> > ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.
> 
> Not sure what you meant by that comment; that's not what happens here AFAICT.
> I stated that output_operand does not see the same symbol_ref as was passed to
> the rtl insn expander, so target-specific code is needed just like for Darwin
> - or maybe it's just missing in generic code, for the constant pool.

I believe that the only special aspect of symbol_ref processing on the
32-bit hppa port is the symbol name encoding.  There's also some flag
bits.  Other than that, it's not clear why output_operand would see
something different from what was passed to the rtl insn expander.

There's nothing new in the hppa backend wrt symbol references.

Besides the .import issue, function pointers have to point to a
function descriptor (not the real code).  This is done using a plabel
which is a relocation which tells the linker to create a pointer to
a function descriptor.  This happens automatically if the output for
the function pointer output uses assembler_integer (assuming the name
encoding is correct).

Because the output of .import directives is a two stage process, there
might be an issue if a symbol_ref was garbage collected after the
assemble_external call.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #67 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-30 
01:19 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> If the extern references had been "sort -u":ed, they'd had looked like this,
> diff from unpatched to patched for the attachment in comment #61, compiled 
> with
> -O2:
> 
> --- ../../../comboo/hppa2/gcc/hppa2.s   2008-08-29 22:32:02.0 +0200
> +++ ./hppa2.s   2008-08-29 22:31:38.0 +0200
> @@ -6664,13 +6664,7 @@ L$ASFDE0143:
> .align 4
>  L$EFDE0143:
> .word   0x0
> -   .IMPORT _ZNSdD0Ev,CODE
> -   .IMPORT _ZNSdD1Ev,CODE
> .IMPORT _ZNSdD2Ev,CODE
> -   .IMPORT _ZNSiD0Ev,CODE
> -   .IMPORT _ZNSiD1Ev,CODE
> -   .IMPORT _ZNSoD0Ev,CODE
> -   .IMPORT _ZNSoD1Ev,CODE

If any of these functions is present in the .s, then there's a problem.
The default for a 32-bit HP-UX symbol that isn't imported is DATA.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #66 from hp at gcc dot gnu dot org  2008-08-30 01:08 ---
(In reply to comment #61)
> Created an attachment (id=16165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view) [edit]
> preprocessed source from hppa2.0w-hp-hpux11.11 

Could you please dig out the cc1plus options too, so I'm not missing the
original case?


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #65 from hp at gcc dot gnu dot org  2008-08-30 01:05 ---
If the extern references had been "sort -u":ed, they'd had looked like this,
diff from unpatched to patched for the attachment in comment #61, compiled with
-O2:

--- ../../../comboo/hppa2/gcc/hppa2.s   2008-08-29 22:32:02.0 +0200
+++ ./hppa2.s   2008-08-29 22:31:38.0 +0200
@@ -6664,13 +6664,7 @@ L$ASFDE0143:
.align 4
 L$EFDE0143:
.word   0x0
-   .IMPORT _ZNSdD0Ev,CODE
-   .IMPORT _ZNSdD1Ev,CODE
.IMPORT _ZNSdD2Ev,CODE
-   .IMPORT _ZNSiD0Ev,CODE
-   .IMPORT _ZNSiD1Ev,CODE
-   .IMPORT _ZNSoD0Ev,CODE
-   .IMPORT _ZNSoD1Ev,CODE
.IMPORT _ZNSt15basic_streambufIcSt11char_traitsIcEE4syncEv,CODE
.IMPORT
_ZNSt15basic_streambufIcSt11char_traitsIcEE5imbueERKSt6locale,CODE
.IMPORT _ZNSt15basic_streambufIcSt11char_traitsIcEE5uflowEv,CODE
@@ -6684,13 +6678,6 @@ L$EFDE0143:
.IMPORT _ZNSt8ios_baseD2Ev,CODE
.IMPORT
_ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E,CODE
.IMPORT _ZNSt9basic_iosIcSt11char_traitsIcEED2Ev,CODE
-   .IMPORT _ZTISd,DATA
-   .IMPORT _ZTISi,DATA
-   .IMPORT _ZTISo,DATA
-   .IMPORT _ZTISt15basic_streambufIcSt11char_traitsIcEE,DATA
-   .IMPORT _ZTVN10__cxxabiv120__si_class_type_infoE,DATA
-   .IMPORT _ZTVSt15basic_streambufIcSt11char_traitsIcEE,DATA
-   .IMPORT _ZTVSt9basic_iosIcSt11char_traitsIcEE,DATA
.IMPORT _ZThn8_NSdD0Ev,CODE
.IMPORT _ZThn8_NSdD1Ev,CODE
.IMPORT _ZTv0_n12_NSdD0Ev,CODE


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #64 from hp at gcc dot gnu dot org  2008-08-30 00:39 ---
(In reply to comment #63)
> If the encoding for function names is getting stripped, then
> ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.

Not sure what you meant by that comment; that's not what happens here AFAICT.
I stated that output_operand does not see the same symbol_ref as was passed to
the rtl insn expander, so target-specific code is needed just like for Darwin
- or maybe it's just missing in generic code, for the constant pool.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dave at hiauly1 dot hia dot nrc dot ca]

--- Comment #63 from dave at hiauly1 dot hia dot nrc dot ca  2008-08-29 
22:39 ---
Subject: Re:  [4.4 Regression]: gcc.dg/weak/weak-1.c

> Looks like the HPPA port, like Darwin, transforms the original symbol_refs 
> upon
> seeing them, such that output_operand doesn't see all required,

If the encoding for function names is getting stripped, then
ASM_OUTPUT_EXTERNAL_REAL will fail to type the symbol correctly.

Dave


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #62 from hp at gcc dot gnu dot org  2008-08-29 20:51 ---
Looks like the HPPA port, like Darwin, transforms the original symbol_refs upon
seeing them, such that output_operand doesn't see all required,


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[andreast at gcc dot gnu dot org]

--- Comment #61 from andreast at gcc dot gnu dot org  2008-08-29 17:16 
---
Created an attachment (id=16165)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16165&action=view)
preprocessed source from hppa2.0w-hp-hpux11.11 


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #60 from eric dot weddington at atmel dot com  2008-08-28 21:05 
---
(In reply to comment #59)
> Patch at .
> 

Patch still works on AVR.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #59 from hp at gcc dot gnu dot org  2008-08-27 16:33 ---
Patch at .


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #58 from hp at gcc dot gnu dot org  2008-08-27 15:40 ---
(In reply to comment #57)
> I meant: no news == good news == nothing to report, but success on both
> platforms!-)

Thanks for telling and for testing.  (Really, I try to avoid interpreting lack
of information as other than possibly communications failure, and I don't think
I'm wrong.  So many other things can and will happen.)

I'll post the patch, finally.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #57 from dominiq at lps dot ens dot fr  2008-08-27 15:23 ---
>> I'll report any problem.
>
> Thanks.  Any news on the ppc-darwin and i686-darwin test results?

I meant: no news == good news == nothing to report, but success on both
platforms!-)


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #56 from hp at gcc dot gnu dot org  2008-08-27 14:52 ---
(In reply to comment #55)
> Just in case, I am bootstraping gcc on ppc darwin9 with the patch. It should
> finish tonight (GMT+2) and regtesting results available tomorrow morning. I'll
> report any problem.

Thanks.  Any news on the ppc-darwin and i686-darwin test results?
(FWIW, my results were clean, but that was expected as they'd been for earlier
revisions too.)


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #55 from dominiq at lps dot ens dot fr  2008-08-26 11:57 ---
> FeaPR-creep is strictly frowned upon: open a new PR.

This now pr37241.

With the patch in comment #54 all the failures reported in comment #40 are gone
without regressions
(currently regtesting gfortran).

Thanks for the patch(es).  

Just in case, I am bootstraping gcc on ppc darwin9 with the patch. It should
finish tonight (GMT+2) and regtesting results available tomorrow morning. I'll
report any problem.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #54 from hp at gcc dot gnu dot org  2008-08-26 02:00 ---
Created an attachment (id=16146)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16146&action=view)
Patch, take 5.

Removing the "TREE_CODE (decl) == FUNCTION_DECL && ..." part helped to elide
the bogus weak declarations for vtables that had been taken care of locally. 
Doh. :)
On Darwin, there were also some spurious .weak_reference X emitted for
locally-defined X. Fixed by gating that output as in assemble_external.
Trivially tested with the test-cases that have appeared here.  Test runs
started for native x86_64-linux and cross to cris-elf.

I'd be thankful for your testing.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16141|0   |1
is obsolete||


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #53 from hp at gcc dot gnu dot org  2008-08-25 21:36 ---
(In reply to comment #52)
> While we are at the "weak" arcanes on Darwin, we have also the following since
> at least revision 136913 (revision 136903 seems the most likely candidate, the
> others being 136899, 136905, and 136912):

That's not nearly around the window for the revisions for the behavior in the
description of this PR.  FeaPR-creep is strictly frowned upon: open a new PR.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #52 from dominiq at lps dot ens dot fr  2008-08-25 20:23 ---
While we are at the "weak" arcanes on Darwin, we have also the following since
at least revision 136913 (revision 136903 seems the most likely candidate, the
others being 136899, 136905, and 136912):

FAIL: g++.dg/abi/key2.C scan-assembler .globl __ZTI1fn\\t.weak_definition
__ZTI1fn\\t.section __DATA,__const_coal,coalesced

The corresponding part of the assembly code reads:

   42 - .long   __ZN1f1hEv
   43 - .globl __ZTI1f
   44 : .weak_definition __ZTI1f
   45 + .align 2
   46 + __ZTI1f:

If one can shot two birds with one stone, this will be nice. Otherwise I'll
fill another PR.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #51 from hp at gcc dot gnu dot org  2008-08-25 19:16 ---
(In reply to comment #50)
> I think the C++ failures are related to PR 37167.

Depends on how you define "related".  Maybe the patch for this bug will include
the fix for it (see proposed varasm.c:assemble_external changes), but not the
other way round.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[pinskia at gcc dot gnu dot org]

--- Comment #50 from pinskia at gcc dot gnu dot org  2008-08-25 18:58 
---
I think the C++ failures are related to PR 37167.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #49 from hp at gcc dot gnu dot org  2008-08-25 18:35 ---
(In reply to comment #48)
> I get:
(many "X.s:unknown:Undefined symbol: Y can't be a weak_definition" elided)

Yes, those look sufficiently similar. (No C or C++ knowledge required. :)
Good to know that it's probably just "that" bug.
I have what I need.
Thanks.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #48 from dominiq at lps dot ens dot fr  2008-08-25 18:17 ---
I get:

[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/empty7.C
/var/tmp//ccCa6HmC.s:unknown:Undefined symbol: __ZTV2S3 can't be a
weak_definition
/var/tmp//ccCa6HmC.s:unknown:Undefined symbol: __ZTV2S4 can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/layout2.C
/var/tmp//cc6U13JE.s:unknown:Undefined symbol: __ZTV1D can't be a
weak_definition
/var/tmp//cc6U13JE.s:unknown:Undefined symbol: __ZTV1B can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/abi/vbase12.C
/var/tmp//ccTo47cP.s:unknown:Undefined symbol: __ZTV1C can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.dg/inherit/thunk7.C
/var/tmp//cckYOBdw.s:unknown:Undefined symbol: __ZTV1D can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.brendan/misc11.C
/var/tmp//cc6Kf47c.s:unknown:Undefined symbol: __ZTV1B can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/offset1.C
/var/tmp//cc98DFie.s:unknown:Undefined symbol: __ZTV4Barf can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/virt2.C
/var/tmp//ccZeI4BH.s:unknown:Undefined symbol: __ZTV2S1 can't be a
weak_definition
/var/tmp//ccZeI4BH.s:unknown:Undefined symbol: __ZTV2S2 can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rtti4.C
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rtti4.C:49: warning:
direct base 'B' inaccessible in 'E' due to ambiguity
/var/tmp//ccphb9BU.s:unknown:Undefined symbol: __ZTV1E can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rttid4.C
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/rttid4.C:50: warning:
direct base 'B' inaccessible in 'E' due to ambiguity
/var/tmp//ccWsGUAt.s:unknown:Undefined symbol: __ZTV1E can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.other/virtual9.C
/var/tmp//ccjNVoz2.s:unknown:Undefined symbol: __ZTV1C can't be a
weak_definition
/var/tmp//ccjNVoz2.s:unknown:Undefined symbol: __ZTV1B can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.robertl/eh990323-2.C
/var/tmp//cc6nnIz5.s:unknown:Undefined symbol: __ZTV1B can't be a
weak_definition
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.robertl/eh990323-4.C
/var/tmp//ccau8OGJ.s:unknown:Undefined symbol: __ZTV1B can't be a
weak_definition


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #47 from dominiq at lps dot ens dot fr  2008-08-25 18:12 ---
> To help shorten the number of iterations, can you please verify that the
> failures all look as above in the .log files?

You have to realize that I am C* illiterate. So I need more precise directives.
For instance, do

...
class Barf : virtual public Bar {
public:
  virtual void init(int argc, char **argv) { Bar::init(argc, argv); }
};
...
[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/offset1.C/var/tmp//ccIY8j6p.s:unknown:Undefined
symbol: __ZTV4Barf can't be a weak_definition

and

...
struct  B : virtual A
{
virtual int f() {   return 1;   }
virtual int g() = 0;
};
...
[ibook-dhum] f90/bug% g++44 -c
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.brendan/misc11.C
/var/tmp//cccB5iE4.s:unknown:Undefined symbol: __ZTV1B can't be a
weak_definition

look the same? My answer is "yes", but in the first case the symbol is a class
and in the second one a struct(ure?), so the "yes" may be a mistake.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #46 from hp at gcc dot gnu dot org  2008-08-25 17:58 ---
(In reply to comment #39)
> More good news, the weak gcc tests pass now for 32 and 64 bit modes.
> 
> Also bad news, I have extra failures in the g++ tests (32-bit mode so far),

> /var/tmp//ccLGtbMk.s:unknown:Undefined symbol: __ZTV4Barf can't be a

Hm, looks like the equivalent of the inlined-function test is needed, but for
data.

To help shorten the number of iterations, can you please verify that the
failures all look as above in the .log files?

For the record, the main reasons avr results are so different to darwin can be
seen in my earlier comments.  To wit:

1) very different symbol handling in the target (where avr is mainstream, I
think)
2) annotation for weak references are different to weak definitions on darwin,
with stricter checking in the assembler.

The reason avr was getting different failures is that it, unlike most ELF
targets, does not define ASM_OUTPUT_EXTERN, which most other ELF targets get by
including the "general" config/elfos.h.  This "missing include" is possibly by
itself a buglet.  On the other hand, elfos.h contains lots of arbitrary crud,
like the weird and target-specific reason for defining ASM_OUTPUT_EXTERN!
Really, elfos.h should be called svr4.h, but that name's already taken...

I'll get started on a new patch...


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #45 from dominiq at lps dot ens dot fr  2008-08-25 17:25 ---
> I have 2 less fails now on c++

On Darwin there is one test which now passes:

g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov

but several new failures (comment #40).


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #44 from eric dot weddington at atmel dot com  2008-08-25 17:20 
---
(In reply to comment #43)
> > Patch #4 still fixes all "weak" test regressions on avr.
> 
> Did you test g++?
> 

Yes. I build and test for c, c++, ada, and objc (yes, it actually builds for
AVR). I have 2 less fails now on c++ than I did on 2008-08-21 (revision
139385), but that could be due to almost anything. I don't pay attention much
to c++ test results for avr, mainly because there are 1064 failures and I don't
have very many users of c++ on avr.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #43 from dominiq at lps dot ens dot fr  2008-08-25 17:10 ---
> Patch #4 still fixes all "weak" test regressions on avr.

Did you test g++?


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #42 from eric dot weddington at atmel dot com  2008-08-25 16:51 
---
(In reply to comment #41)
> (In reply to comment #37)
> > Created an attachment (id=16141)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141&action=view) [edit]
> > Patch, take 4.
> 
> > Please, test on darwin and avr.
> 
> Testing started on avr.
> 

Patch #4 still fixes all "weak" test regressions on avr.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #41 from eric dot weddington at atmel dot com  2008-08-25 15:12 
---
(In reply to comment #37)
> Created an attachment (id=16141)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141&action=view) [edit]
> Patch, take 4.

> Please, test on darwin and avr.

Testing started on avr.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #40 from dominiq at lps dot ens dot fr  2008-08-25 13:35 ---
Here is the list of new g++ failures (32 and 64 bit modes, except
g++.dg/abi/empty7.C):

FAIL: g++.dg/abi/empty7.C (test for excess errors)<--- 32-bit mode only
FAIL: g++.dg/abi/layout2.C (test for excess errors)
FAIL: g++.dg/abi/vbase12.C (test for excess errors)
FAIL: g++.dg/inherit/thunk7.C (test for excess errors)
FAIL: g++.old-deja/g++.brendan/misc11.C (test for excess errors)
FAIL: g++.old-deja/g++.mike/offset1.C (test for excess errors)
FAIL: g++.old-deja/g++.mike/virt2.C (test for excess errors)
FAIL: g++.old-deja/g++.other/rtti4.C (test for excess errors)
FAIL: g++.old-deja/g++.other/rttid4.C (test for excess errors)
FAIL: g++.old-deja/g++.other/virtual9.C (test for excess errors)
FAIL: g++.old-deja/g++.robertl/eh990323-2.C (test for excess errors)
FAIL: g++.old-deja/g++.robertl/eh990323-4.C (test for excess errors)

It looks like a missing test for some "virtual".


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #39 from dominiq at lps dot ens dot fr  2008-08-25 11:44 ---
More good news, the weak gcc tests pass now for 32 and 64 bit modes.

Also bad news, I have extra failures in the g++ tests (32-bit mode so far),
e.g.:

[ibook-dhum] f90/bug% g++44
/opt/gcc/_gcc_clean/gcc/testsuite/g++.old-deja/g++.mike/offset1.C
/var/tmp//ccLGtbMk.s:unknown:Undefined symbol: __ZTV4Barf can't be a
weak_definition


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #38 from dominiq at lps dot ens dot fr  2008-08-25 09:56 ---
With the patch in comment #37 I bootstraped

Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.4.0 [revision 139556p5] 20080825 (experimental) (GCC) 

Regtesting started.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #37 from hp at gcc dot gnu dot org  2008-08-25 02:09 ---
Created an attachment (id=16141)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16141&action=view)
Patch, take 4.

Fourth time's a charm.

The difference is just strengthening the early-return in assemble_external so
inlined functions (or any actually defined functions) aren't handled as
externs.
Tests started on native x86_64-linux and cris-elf.

Please, test on darwin and avr.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #36 from hp at gcc dot gnu dot org  2008-08-25 01:48 ---
Created an attachment (id=16140)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16140&action=view)
Weak testing weak: testing weak stronger.

I was missing tests that referenced a weak address, but offset, and the address
of a weak variable, but from data, not code.  Also is something of an attempt
to verify that the prims.ii situation doesn't happen in C.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #35 from hp at gcc dot gnu dot org  2008-08-25 01:26 ---
Created an attachment (id=16139)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16139&action=view)
Testcase exposing the (on darwin) breaking aspect of prims.ii

See comments in the test-case.  The test-case breaks for all targets with
ASM_OUTPUT_EXTERNAL (e.g. x86_64-linux) with r139233, but e.g. not for
unpatched darwin.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #34 from dominiq at lps dot ens dot fr  2008-08-24 16:50 ---
[ibook-dhum] f90/bug% gfc -m64 -S -fno-common
/opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/weak/weak-2.c
[ibook-dhum] f90/bug% grep ffoo1a weak-2.s
movq[EMAIL PROTECTED](%rip), %rax


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #33 from dominiq at lps dot ens dot fr  2008-08-24 16:46 ---
> All the results for 32-bit mode only, but I am pretty confident that they will
> hold with -m64.

This is wrong: the tests pass in 32-bit mode, but fail with -m64.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #32 from hp at gcc dot gnu dot org  2008-08-23 18:38 ---
Thanks, I got everything I need.

The problem seen for the Darwin bootstrap is caused not by the output_operand
call to assemble_external, but by another call, in cp/decl2.c:mark_used.

Plainly treating that (as now) the same as the assemble_external call from
output_operand, causes lots of actually not used (perhaps inlined, but not
referenced) functions to be marked as weak.  You can see this diffing e.g.
prims.s for unpatched 139232 and 139233 for x86_64-linux but you don't see it
for unpatched darwin because of the assemble_external call being masked by the
#ifdef.  For GNU/Linux, having random .weak annotations for unreferenced and
undefined symbols apparently has no visible effect.  The reason that the Darwin
assembler complains when it sees some of these, is that they're coupled with
annotations specifically for weak *definitions* for one reason or another
(without a matching symbol definition), while with more common targets the weak
annotations for references and definitions look the same, the absence/presence
of the actual definition defines what weakness type it is.

I'm not sure why there are assemble_external calls all over and from language
front-ends; there should be only one in output_operand (for code) and one where
data is output.

Come to think of it, they shouldn't be there either, but in expand, so we don't
have to play target-specific tricks.  Not sure whether that change would fit in
this PR, or if I should go with just remove or gate the bogus and redundant
assemble_external calls.  Bah, I guess I should just have asked for revert of
139233; that and related earlier changes obviously weren't fit for trunk.  Ok,
one more try.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[andreast at gcc dot gnu dot org]

--- Comment #31 from andreast at gcc dot gnu dot org  2008-08-23 08:17 
---
 /Volumes/development/gcc/head/objdir-x86_64/./gcc/cc1plus -fpreprocessed
prims.ii -fPIC -feliminate-unused-debug-symbols -quiet -dumpbase prims.cc
-mmacosx-version-min=10.5.4 -mtune=generic -auxbase-strip .libs/prims.o -g -O2
-Wswitch-enum -Wextra -Wall -version -fno-rtti -fnon-call-exceptions
-fdollars-in-identifiers -fomit-frame-pointer -fno-common -o prims.s
GNU C++ (GCC) version 4.4.0 20080822 (experimental) [trunk revision 139497]
(x86_64-apple-darwin9)
compiled by GNU C version 4.4.0 20080822 (experimental) [trunk revision
139497], GMP version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: d33cfb8d3b429a09faa5a0175497a6bb
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.4' '-shared-libgcc'
'-B/Volumes/development/gcc/head/objdir-x86_64/./gcc' '-nostdinc++'
'-L/Volumes/development/gcc/head/objdir-x86_64/x86_64-apple-darwin9/libstdc++-v3/src'
'-L/Volumes/development/gcc/head/objdir-x86_64/x86_64-apple-darwin9/libstdc++-v3/src/.libs'
'-B/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/bin/'
'-B/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/lib/'
'-isystem'
'/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/include'
'-isystem'
'/Volumes/development/gcc/head/testbin-x86_64/x86_64-apple-darwin9/sys-include'
'-DHAVE_CONFIG_H' '-I.' '-I/Volumes/development/gcc/head/gcc/libjava'
'-I./include' '-I./gcj' '-I/Volumes/development/gcc/head/gcc/libjava'
'-Iinclude' '-I/Volumes/development/gcc/head/gcc/libjava/include'
'-I/Volumes/development/gcc/head/gcc/libjava/classpath/include'
'-Iclasspath/include'
'-I/Volumes/development/gcc/head/gcc/libjava/classpath/native/fdlibm'
'-I/Volumes/development/gcc/head/gcc/libjava/../boehm-gc/include'
'-I../boehm-gc/include' '-I/Volumes/development/gcc/head/gcc/libjava/libltdl'
'-I/Volumes/development/gcc/head/gcc/libjava/libltdl'
'-I/Volumes/development/gcc/head/gcc/libjava/.././libjava/../gcc'
'-I/Volumes/development/gcc/head/gcc/libjava/../zlib'
'-I/Volumes/development/gcc/head/gcc/libjava/../libffi/include'
'-I../libffi/include' '-fno-rtti' '-fnon-call-exceptions'
'-fdollars-in-identifiers' '-Wswitch-enum' '-D_FILE_OFFSET_BITS=64'
'-fomit-frame-pointer' '-Wextra' '-Wall' '-D_GNU_SOURCE'
'-DPREFIX="/Volumes/development/gcc/head/testbin-x86_64"'
'-DTOOLEXECLIBDIR="/Volumes/development/gcc/head/testbin-x86_64/lib"'
'-DJAVA_HOME="/Volumes/development/gcc/head/testbin-x86_64"'
'-DBOOT_CLASS_PATH="/Volumes/development/gcc/head/testbin-x86_64/share/java/libgcj-4.4.0.jar"'
'-DJAVA_EXT_DIRS="/Volumes/development/gcc/head/testbin-x86_64/share/java/ext"'
'-DGCJ_ENDORSED_DIRS="/Volumes/development/gcc/head/testbin-x86_64/share/java/gcj-endorsed"'
'-DGCJ_VERSIONED_LIBDIR="/Volumes/development/gcc/head/testbin-x86_64/lib/gcj-4.4.0-10"'
'-DPATH_SEPARATOR=":"'
'-DECJ_JAR_FILE="/Volumes/development/gcc/head/testbin-x86_64/share/java/ecj.jar"'
'-DLIBGCJ_DEFAULT_DATABASE="/Volumes/development/gcc/head/testbin-x86_64/lib/gcj-4.4.0-10/classmap.db"'
'-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="gcj-4.4.0-10/classmap.db"' '-g' '-O2'
'-MT' 'prims.lo' '-MD' '-MP' '-MF' '.deps/prims.Tpo' '-c' '-fno-common' '-DPIC'
'-v' '-save-temps' '-o' '.libs/prims.o' '-mtune=generic'
 /Volumes/development/gcc/head/objdir-x86_64/./gcc/as -arch x86_64
-force_cpusubtype_ALL -o .libs/prims.o prims.s
prims.s:unknown:Undefined symbol: __Z19_Jv_AllocPtrFreeObjiPN4java4lang5ClassE
can't be a weak_definition
prims.s:unknown:Undefined symbol: __Z12_Jv_AllocObjiPN4java4lang5ClassE can't
be a weak_definition


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[andreast at gcc dot gnu dot org]

--- Comment #30 from andreast at gcc dot gnu dot org  2008-08-22 18:42 
---
Created an attachment (id=16132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16132&action=view)
preprocessed source prims.ii


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #29 from hp at gcc dot gnu dot org  2008-08-22 18:18 ---
(In reply to comment #28)
> Well, a bit of good news: patch #3 fixes all test case regressions regarding
> "weak" for the AVR.

Thanks for testing!  Hopefully I can get that preprocessed code soon and with a
bit of luck the bug would be in the darwin-specific changes.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #28 from eric dot weddington at atmel dot com  2008-08-22 18:06 
---
Well, a bit of good news: patch #3 fixes all test case regressions regarding
"weak" for the AVR.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #27 from hp at gcc dot gnu dot org  2008-08-22 17:18 ---
(In reply to comment #26)
> Bootstrap fails at

Gosh darn.
Please attach preprocessed code and I'll try to figure out what's going on...


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #26 from dominiq at lps dot ens dot fr  2008-08-22 17:09 ---
Bootstrap fails at

[ibook-dhum] x86_64/libjava% /opt/gcc/i686-darwin/./gcc/xgcc -shared-libgcc
-B/opt/gcc/i686-darwin/./gcc -nostdinc++
-L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src
-L/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libstdc++-v3/src/.libs
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -m64 -DHAVE_CONFIG_H -I.
-I../../../../gcc-4.4-work/libjava -I./include -I./gcj
-I../../../../gcc-4.4-work/libjava -Iinclude
-I../../../../gcc-4.4-work/libjava/include
-I../../../../gcc-4.4-work/libjava/classpath/include -Iclasspath/include
-I../../../../gcc-4.4-work/libjava/classpath/native/fdlibm
-I../../../../gcc-4.4-work/libjava/../boehm-gc/include -I../boehm-gc/include
-I../../../../gcc-4.4-work/libjava/libltdl
-I../../../../gcc-4.4-work/libjava/libltdl
-I../../../../gcc-4.4-work/libjava/.././libjava/../gcc
-I../../../../gcc-4.4-work/libjava/../libffi/include -I../libffi/include
-fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum
-D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall
-D_GNU_SOURCE -DPREFIX=\"/opt/gcc/gcc4.4w\"
-DTOOLEXECLIBDIR=\"/opt/gcc/gcc4.4w/lib/x86_64\"
-DJAVA_HOME=\"/opt/gcc/gcc4.4w\"
-DBOOT_CLASS_PATH=\"/opt/gcc/gcc4.4w/share/java/libgcj-4.4.0.jar\"
-DJAVA_EXT_DIRS=\"/opt/gcc/gcc4.4w/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/opt/gcc/gcc4.4w/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/opt/gcc/gcc4.4w/lib/x86_64/gcj-4.4.0-10\"
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"/opt/gcc/gcc4.4w/share/java/ecj.jar\"
-DLIBGCJ_DEFAULT_DATABASE=\"/opt/gcc/gcc4.4w/lib/x86_64/gcj-4.4.0-10/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.4.0-10/classmap.db\" -g -O2 -m64
-MT prims.lo -MD -MP -MF .deps/prims.Tpo -c
../../../../gcc-4.4-work/libjava/prims.cc  -fno-common -DPIC

/var/tmp//cctr5h82.s:unknown:Undefined symbol:
__Z19_Jv_AllocPtrFreeObjiPN4java4lang5ClassE can't be a weak_definition
/var/tmp//cctr5h82.s:unknown:Undefined symbol:
__Z12_Jv_AllocObjiPN4java4lang5ClassE can't be a weak_definition


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #25 from hp at gcc dot gnu dot org  2008-08-22 15:25 ---
Created an attachment (id=16130)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16130&action=view)
Patch, take 3.

Thanks for your reports!

I stupidly forgot to move out the tree type checks from inside the #ifdef and
just couldn't see it!  Odd that the weak-test-cases didn't trig this.
Now fixed.  Lightly checked that it still fixes the C regressions covered by
weak.exp for avr and darwin-i686, new regression runs started for cris-elf and
native.

Please, test on your targets!


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

  Attachment #16125|0   |1
is obsolete||


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #24 from dominiq at lps dot ens dot fr  2008-08-22 14:54 ---
Created an attachment (id=16129)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16129&action=view)
libggc2.i for i686-apple-darwin9


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #23 from dominiq at lps dot ens dot fr  2008-08-22 14:53 ---
Here is the command line and its result from directory
/opt/gcc/i686-darwin/i686-apple-darwin9/x86_64/libgcc:

[ibook-dhum] x86_64/libgcc% /opt/gcc/i686-darwin/./gcc/xgcc -v -save-temps
-B/opt/gcc/i686-darwin/./gcc/ -B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/
-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -g -O2 -m64 -O2 -g -O2 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual
-Wold-style-definition -isystem ./include -fPIC -pipe -g -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc
-I../../../../gcc-4.4-work/libgcc -I../../../../gcc-4.4-work/libgcc/.
-I../../../../gcc-4.4-work/libgcc/../gcc
-I../../../../gcc-4.4-work/libgcc/../include -DHAVE_CC_TLS -o _mulxc3.o -MT
_mulxc3.o -MD -MP -MF _mulxc3.dep -DL_mulxc3 -c
../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS

xgcc: warning: -pipe ignored because -save-temps specified
Reading specs from /opt/gcc/i686-darwin/./gcc/specs
Target: i686-apple-darwin9
Configured with: ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
Thread model: posix
gcc version 4.4.0 [revision 139455p5] 20080822 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.5.4' '-v' '-save-temps'
'-B/opt/gcc/i686-darwin/./gcc/' '-B/opt/gcc/gcc4.4w/i686-apple-darwin9/bin/'
'-B/opt/gcc/gcc4.4w/i686-apple-darwin9/lib/' '-isystem'
'/opt/gcc/gcc4.4w/i686-apple-darwin9/include' '-isystem'
'/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include' '-g' '-O2' '-m64' '-O2' '-g'
'-O2' '-DIN_GCC' '-W' '-Wall' '-Wwrite-strings' '-Wstrict-prototypes'
'-Wmissing-prototypes' '-Wcast-qual' '-Wold-style-definition' '-isystem'
'./include' '-fPIC' '-pipe' '-g' '-DHAVE_GTHR_DEFAULT' '-DIN_LIBGCC2'
'-D__GCC_FLOAT_NOT_NEEDED' '-I.' '-I.' '-I../../.././gcc'
'-I../../../../gcc-4.4-work/libgcc' '-I../../../../gcc-4.4-work/libgcc/.'
'-I../../../../gcc-4.4-work/libgcc/../gcc'
'-I../../../../gcc-4.4-work/libgcc/../include' '-DHAVE_CC_TLS' '-o' '_mulxc3.o'
'-MT' '_mulxc3.o' '-MD' '-MP' '-MF' '_mulxc3.dep' '-DL_mulxc3' '-c'
'-fvisibility=hidden' '-DHIDE_EXPORTS' '-mtune=generic'
 /opt/gcc/i686-darwin/./gcc/cc1 -E -quiet -v -I. -I. -I../../.././gcc
-I../../../../gcc-4.4-work/libgcc -I../../../../gcc-4.4-work/libgcc/.
-I../../../../gcc-4.4-work/libgcc/../gcc
-I../../../../gcc-4.4-work/libgcc/../include -imultilib x86_64 -iprefix
/opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/ -isystem
/opt/gcc/i686-darwin/./gcc/include -isystem
/opt/gcc/i686-darwin/./gcc/include-fixed -MD _mulxc3.d -MF _mulxc3.dep -MP -MT
_mulxc3.o -D__DYNAMIC__ -DIN_GCC -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -DHAVE_CC_TLS -DL_mulxc3 -DHIDE_EXPORTS -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/include -isystem
/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include -isystem ./include
../../../../gcc-4.4-work/libgcc/../gcc/libgcc2.c -fPIC
-feliminate-unused-debug-symbols -mmacosx-version-min=10.5.4 -m64
-mtune=generic -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition -fPIC
-fvisibility=hidden -g -g -g -fworking-directory -O2 -O2 -O2 -fpch-preprocess
-o libgcc2.i
ignoring nonexistent directory "/opt/gcc/gcc4.4w/i686-apple-darwin9/include"
ignoring nonexistent directory
"/opt/gcc/gcc4.4w/i686-apple-darwin9/sys-include"
ignoring nonexistent directory "./include"
ignoring nonexistent directory
"/opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/include"
ignoring nonexistent directory
"/opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/include-fixed"
ignoring nonexistent directory
"/opt/gcc/i686-darwin/gcc/../lib/gcc/i686-apple-darwin9/4.4.0/../../../../i686-apple-darwin9/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/opt/gcc/i686-darwin/gcc/../lib/gcc/../../include"
ignoring nonexistent directory
"/opt/gcc/i686-darwin/gcc/../lib/gcc/../../lib/gcc/i686-apple-darwin9/4.4.0/include"
ignoring nonexistent directory
"/opt/gcc/i686-darwin/gcc/../lib/gcc/../../lib/gcc/i686-apple-darwin9/4.4.0/include-fixed"
ignoring nonexistent directory
"/opt/gcc/i686-darwin/gcc/../lib/gcc/../../lib/gcc/i686-apple-darwin9/4.4.0/../../../../i686-apple-darwin9/include"
ignoring duplicate directory "."
ignoring duplicate directory "../../../../gcc-4.4-work/libgcc/."
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../.././gcc
 ../../../../gcc-4.4-work/libgcc
 ../../../../gcc-4.4-work/libgcc/../gcc
 ../../../../gcc-4.4-work/libgcc/../include
 /opt/gcc/i686-darwin/./

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #22 from eric dot weddington at atmel dot com  2008-08-22 14:52 
---
ICE from building gcc target=avr with patch:

Reading specs from /usr/local/avrdev/gcc/build/./gcc/specs
Target: avr
Configured with: ../gcc/configure --prefix=/usr/local/avr-test --target=avr
--datadir=/usr/local/avr-test/doc/gcc --with-pkgversion='WinAVR test'
--with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse'
--with-dwarf2 --with-gmp=/usr/local --with-mpfr=/usr/local
--enable-win32-registry=WinAVR-test --enable-languages=c --enable-doc
--disable-nls --disable-shared --disable-libada --disable-libssp :
(reconfigured) ../gcc/configure --prefix=/usr/local/avr-test --target=avr
--datadir=/usr/local/avr-test/doc/gcc --with-pkgversion='WinAVR test'
--with-bugurl='URL:http://sourceforge.net/tracker/?atid=520074&group_id=68108&func=browse'
--with-dwarf2 --with-gmp=/usr/local --with-mpfr=/usr/local
--enable-win32-registry=WinAVR-test --enable-languages=c,c++,objc,ada
--enable-doc --disable-nls --disable-shared --disable-libada --disable-libssp
Thread model: single
gcc version 4.4.0 20080822 (experimental) [trunk revision 139423] (WinAVR test) 
COLLECT_GCC_OPTIONS='-B/usr/local/avrdev/gcc/build/./gcc/'
'-B/usr/local/avr-test/avr/bin/' '-B/usr/local/avr-test/avr/lib/' '-isystem'
'/usr/local/avr-test/avr/include' '-isystem'
'/usr/local/avr-test/avr/sys-include' '-g' '-D__USE_MINGW_ACCESS' '-mmcu=avr25'
'-O2' '-g' '-D__USE_MINGW_ACCESS' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W'
'-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes'
'-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-DDF=SF'
'-Dinhibit_libc' '-mcall-prologues' '-Os' '-g' '-DIN_LIBGCC2'
'-D__GCC_FLOAT_NOT_NEEDED' '-Dinhibit_libc' '-I.' '-I.' '-I../../.././gcc'
'-I../../../../gcc/libgcc' '-I../../../../gcc/libgcc/.'
'-I../../../../gcc/libgcc/../gcc' '-I../../../../gcc/libgcc/../include'
'-DHAVE_CC_TLS' '-o' '_mulsc3.o' '-MT' '_mulsc3.o' '-MD' '-MP' '-MF'
'_mulsc3.dep' '-DL_mulsc3' '-c' '-v' '-save-temps'
 /usr/local/avrdev/gcc/build/./gcc/cc1 -E -quiet -v -I. -I. -I../../.././gcc
-I../../../../gcc/libgcc -I../../../../gcc/libgcc/.
-I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -imultilib
avr25 -iprefix /usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/ -isystem
/usr/local/avrdev/gcc/build/./gcc/include -isystem
/usr/local/avrdev/gcc/build/./gcc/include-fixed -MD _mulsc3.d -MF _mulsc3.dep
-MP -MT _mulsc3.o -D__USE_MINGW_ACCESS -D__USE_MINGW_ACCESS -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -DDF=SF -Dinhibit_libc -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DHAVE_CC_TLS -DL_mulsc3 -isystem
/usr/local/avr-test/avr/include -isystem /usr/local/avr-test/avr/sys-include
-isystem ./include ../../../../gcc/libgcc/../gcc/libgcc2.c -mmcu=avr25
-mcall-prologues -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wcast-qual -Wold-style-definition -g -g -g
-fworking-directory -O2 -Os -fpch-preprocess -o libgcc2.i
ignoring nonexistent directory "/usr/local/avr-test/avr/sys-include"
ignoring nonexistent directory "./include"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/include"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/include-fixed"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/../../../../avr/sys-include"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/avr/4.4.0/../../../../avr/include"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/include"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/include-fixed"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/../../../../avr/sys-include"
ignoring nonexistent directory
"/usr/local/avrdev/gcc/build/gcc/../lib/gcc/../../lib/gcc/avr/4.4.0/../../../../avr/include"
ignoring duplicate directory "."
ignoring duplicate directory "../../../../gcc/libgcc/."
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../.././gcc
 ../../../../gcc/libgcc
 ../../../../gcc/libgcc/../gcc
 ../../../../gcc/libgcc/../include
 /usr/local/avrdev/gcc/build/./gcc/include
 /usr/local/avrdev/gcc/build/./gcc/include-fixed
 /usr/local/avr-test/avr/include
End of search list.
COLLECT_GCC_OPTIONS='-B/usr/local/avrdev/gcc/build/./gcc/'
'-B/usr/local/avr-test/avr/bin/' '-B/usr/local/avr-test/avr/lib/' '-isystem'
'/usr/local/avr-test/avr/include' '-isystem'
'/usr/local/avr-test/avr/sys-include' '-g' '-D__USE_MINGW_ACCESS' '-mmcu=avr25'
'-O2' '-g' '-D__USE_MINGW_ACCESS' '-DIN_GCC' '-DCROSS_DIRECTORY_STRUCTURE' '-W'
'-Wall' '-Wwrite-strings' '-Wstrict-prototypes' '-Wmissing-prototypes'
'-Wcast-qual' '-Wold-style-definition' '-isystem' './include' '-DDF=SF'
'-Dinhibit_libc' '-mcall-prologues' '-Os' '-g' '-DIN_LIBGCC2'
'-D__GCC_FLOAT_NOT_NEEDED' 

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #21 from eric dot weddington at atmel dot com  2008-08-22 14:51 
---
Created an attachment (id=16128)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16128&action=view)
Preprocessed source of ICE from building with patch.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #20 from hp at gcc dot gnu dot org  2008-08-22 14:18 ---
(In reply to comment #18)
> My command line is:
> 
> ../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
> --mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
> --build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
> --with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
> --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib

The *gcc* command line at the point of the ICE is the interesting one.
Add -v -save-temps to get the preprocessed code and show the "internal" command
line.

> Concerning the "preprocessed code", although I assume that I'll have to
> (re)break the bootstrap, I have no more idea about how I can get it.

Yes.  Then repeat manually the last gcc command, adding -v -save-temps.
Just like always for gcc bug reports involving an ICE.
Thanks.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |4.4.0


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #19 from eric dot weddington at atmel dot com  2008-08-22 13:44 
---
(In reply to comment #17)
> Could one (or both) please attach preprocessed code and command line so I can
> reproduce the ICE you see with the *whole* patch applied?  I don't see it for
> neither cris-elf nor native and I don't see where it comes from.
> Thanks in advance.
> 

Sure. I'll have it for you in a little while as it's still morning here...


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #18 from dominiq at lps dot ens dot fr  2008-08-22 13:20 ---
> Could one (or both) please attach preprocessed code and command line so I can
> reproduce the ICE you see with the *whole* patch applied?  I don't see it for
> neither cris-elf nor native and I don't see where it comes from.

My command line is:

../gcc-4.4-work/configure --prefix=/opt/gcc/gcc4.4w
--mandir=/opt/gcc/gcc4.4w/share/man --infodir=/opt/gcc/gcc4.4w/share/info
--build=i686-apple-darwin9 --enable-languages=c,c++,fortran,objc,obj-c++,java
--with-gmp=/sw --with-libiconv-prefix=/usr --with-system-zlib
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib

Concerning the "preprocessed code", although I assume that I'll have to
(re)break the bootstrap, I have no more idea about how I can get it.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #17 from hp at gcc dot gnu dot org  2008-08-22 13:14 ---
Could one (or both) please attach preprocessed code and command line so I can
reproduce the ICE you see with the *whole* patch applied?  I don't see it for
neither cris-elf nor native and I don't see where it comes from.
Thanks in advance.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #16 from dominiq at lps dot ens dot fr  2008-08-22 11:51 ---
Note the patch in comment #12 minus the varasm.c part fixes also

FAIL: g++.dg/ext/weak2.C scan-assembler weak[^ \\t]*[ \\t]_?_Z3foov

All the results for 32-bit mode only, but I am pretty confident that they will
hold with -m64.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #15 from dominiq at lps dot ens dot fr  2008-08-22 11:48 ---
> I don't think this has anything to do with your patch.

Unfortunately it has (at least on i686-apple-darwin9). Reverting the patch for
gcc/varasm.c I have bootstrapped without any problem and the good news it that
the remaining patch fixes:

FAIL: gcc.dg/darwin-weakimport-2.c scan-assembler weak_reference _foo

and

FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \\t]*[ \\t]_?j
FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \\t]*[ \\t]_?foo
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1a
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1b
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1c
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \\t]*[ \\t]_?ffoo1e
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \\t]*[ \\t]_?vfoo1a
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \\t]*[ \\t]_?vfoo1b
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \\t]*[ \\t]_?vfoo1c

but not

FAIL: gcc.dg/darwin-weakimport-1.c scan-assembler weak_reference _a


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #14 from eric dot weddington at atmel dot com  2008-08-22 03:37 
---
I tried testing with 139423, but I'm getting a separate error during build:

../../../../gcc/libgcc/../gcc/libgcc2.c: In function '__mulsc3':
../../../../gcc/libgcc/../gcc/libgcc2.c:1831: internal compiler error: tree
check: expected tree that contains 'decl with visibility' structure, have
'result_decl' in assemble_external, at varasm.c:2318

I don't think this has anything to do with your patch. I'll have to test it
later after this ICE gets fixed.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #13 from hp at gcc dot gnu dot org  2008-08-22 02:24 ---
Patch in comment #12 is as previously mentioned, except because of Darwin's
weird symbol handling, the symbol_ref's didn't pass through the same way as
other operands, so it has to mark weak references "manually".  (No, this is not
how -fPIC usually works; targets still pass around a symbol_ref, just wrapped
in unspec rtx's.) Tested manually on crosses to ia64-elf, cris-elf, avr-elf and
i686-darwin; AFAICT the failures still present with the previous version are
gone.

Currently testing this patch native x86_64-unknown-linux-gnu and cross to
cris-elf, plan to post a RFA to gcc-patches@ tomorrow (in about 12h, that is).
If you read this before reading the RFA, you're very welcome to test the patch.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #12 from hp at gcc dot gnu dot org  2008-08-22 02:16 ---
Created an attachment (id=16125)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16125&action=view)
Patch, take 2.

Against r139233.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #11 from hp at gcc dot gnu dot org  2008-08-21 20:05 ---
Ok, I see why it doesn't work for you guys now: there's another bug; the weak
handling is buggily put inside code gated by #ifdef ASM_OUTPUT_EXTERNAL.
Simply moving it after that hunk should work.  But I also see a wart with the
original fix; I should iterate over the operand using for_each_rtx, not just
peel off mem references and check for a const... (no, I can't imagine a target
affected by that, but anyway)

And I see where the code was copied from, same bug there (not really
weak-related, rather extern-related, so I'll save it for later).

Patch retracted, new patch coming up.


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords|patch   |


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #10 from dominiq at lps dot ens dot fr  2008-08-21 19:06 ---
I have had a closer look to the failures on i686-apple-darwin9 and they are due
to the replacement of '.weak_definition' with '.indirect_symbol' in the
assembly code (the regexp problem seems related to different engines in Tcl and
egrep). It could be worth looking to the origin of the failures on other
targets.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #9 from eric dot weddington at atmel dot com  2008-08-21 19:04 
---
(In reply to comment #7)
> Patch did not fix any those regressions for the AVR:
> 
> FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
> FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
> FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e
> FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a
> FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b
> FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c
> FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e
> FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a
> FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b
> FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c
> FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a
> FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b
> FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c
> FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1i
> FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1j
> 

Ok, patched correctly, and verified that the patch does NOT fix the above
regressions.


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #8 from eric dot weddington at atmel dot com  2008-08-21 17:13 
---
(In reply to comment #7)
> Patch did not fix any those regressions for the AVR:
> 

Stupid me: There were problems when it tried to patch that I didn't notice.
Fixing that and retesting... 


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #7 from eric dot weddington at atmel dot com  2008-08-21 17:07 
---
Patch did not fix any those regressions for the AVR:

FAIL: gcc.dg/attr-weakref-1.c (test for excess errors)
FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e
FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a
FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b
FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c
FAIL: gcc.dg/weak/weak-3.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c
FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a
FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b
FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c
FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1i
FAIL: gcc.dg/weak/weak-5.c scan-assembler weak[^ \t]*[ \t]_?vfoo1j


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #6 from dominiq at lps dot ens dot fr  2008-08-21 15:33 ---
> But was the failures you see too introduced with r139233?

It is not in r139096, but appeared in r139293. So it is the right window, but I
don't have anything in between.  From what I have seen it looks more like a
regexp problem.  If nobody comes with a better idea by tomorrow, I'll open a
nex PR.

> I can't tell myself because I see no test-results for
> i686-apple-darwin on gcc-testresults@ (hint hint).

\begin{rant}

Looking at the fate of darwin posts on gcc-testresults (the length of the ggc
failures for ppc-darwin is increasing at a steady state while producing 3
results a day), I have decided to concentrate on PR now and then (my main
interest is gfortran on Darwin, I just post C* results because I see them).

\end{rant}


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #5 from hp at gcc dot gnu dot org  2008-08-21 13:28 ---
(In reply to comment #4)
> Same thing here on i686-apple-darwin9.

But was the failures you see too introduced with r139233?
I can't tell myself because I see no test-results for
i686-apple-darwin on gcc-testresults@ (hint hint).

> FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
> FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c
> FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e
> FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a
> FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b
> FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c

If not, given the failures, I'd guess you're looking at a different bug.
(Please open a separate PR, this one will cover just the weak-related bug
matching the original description.)


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[dominiq at lps dot ens dot fr]

--- Comment #4 from dominiq at lps dot ens dot fr  2008-08-21 09:15 ---
Same thing here on i686-apple-darwin9.

> Does the patch work for you?

No! I still get:

FAIL: gcc.dg/weak/weak-1.c scan-assembler weak[^ \t]*[ \t]_?j
FAIL: gcc.dg/weak/weak-12.c scan-assembler weak[^ \t]*[ \t]_?foo
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1a
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1b
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1c
FAIL: gcc.dg/weak/weak-2.c scan-assembler weak[^ \t]*[ \t]_?ffoo1e
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1a
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1b
FAIL: gcc.dg/weak/weak-4.c scan-assembler weak[^ \t]*[ \t]_?vfoo1c

I also get the following answers for different regexps:

[ibook-dhum] f90/bug% egrep "weak[^ ]*[ \t]_?vfoo1k" weak-4.s
.weak_definition _vfoo1k
[ibook-dhum] f90/bug% egrep "weak[^ \t]*[ \t]_?vfoo1k" weak-4.s
[ibook-dhum] f90/bug% 


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #3 from hp at gcc dot gnu dot org  2008-08-21 00:33 ---
(In reply to comment #2)
> This test also fails recently for avr-unknown-elf.

Does the patch work for you?


-- 


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[eric dot weddington at atmel dot com]

--- Comment #2 from eric dot weddington at atmel dot com  2008-08-21 00:26 
---
This test also fails recently for avr-unknown-elf.
Also fails: weak-2.c, weak-3.c, weak-4.c, weak-5.c, weak-12.c.
May be related: also fails on gcc.dg/attr-weakref-1.c.
These tests are known fail revision 139269, known success 139231


-- 

eric dot weddington at atmel dot com changed:

   What|Removed |Added

 CC||eric dot weddington at atmel
   ||dot com


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

--- Comment #1 from hp at gcc dot gnu dot org  2008-08-20 15:30 ---
Patch at .


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

   Keywords||patch


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

[Bug middle-end/37170] [4.4 Regression]: gcc.dg/weak/weak-1.c

[hp at gcc dot gnu dot org]

-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |hp at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2008-08-20 00:46:02
   date||


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