Re: [PATCH] rs6000: Disable generation of lwa in 32-bit mode
some (20040709-2.c, etc.) fail with a linker error now, instead of Hmm, packed structs. If gcc is generating mis-aligned accesses using lwa or ld, that would be another TARGET_64BIT vs TARGET_POWERPC64 bug, wouldn't it? I have analysed it, patch on the way. The problem is LO_SUMs of misaligned symbols; we never get those in practice on 64-bit because things go via the TOC, but the problem is there in theory for 64-bit as well. Segher
Re: Build/Makefile question
On Sat, Oct 27, 2012 at 1:45 PM, Caroline Tice wrote: > Ian Tayler (in private communication) asked that I get the part of the > build log that shows the .so and .a files being built and send it to > the list. Here it is. I see the problem. libstdc++/libsupc++/Makefile.am overrides the default CXXLINK to invoke libtool with --tag disable-shared. Your new shared libraries have only C input files, so they are being linked with CXXLINK, they are being linked with LINK. You need to override the default value of LINK. Ian
Re: [PATCH] rs6000: Disable generation of lwa in 32-bit mode
On Sat, Oct 27, 2012 at 06:33:34AM +0200, Segher Boessenkool wrote: > some (20040709-2.c, etc.) fail with a linker error now, instead of Hmm, packed structs. If gcc is generating mis-aligned accesses using lwa or ld, that would be another TARGET_64BIT vs TARGET_POWERPC64 bug, wouldn't it? -- Alan Modra Australia Development Lab, IBM
Re: Regression/bug in 4.7 regarding typedef in templated class
On 10/27/2012 10:58 PM, Sebastian Huber wrote: On 27/10/12 15:16, Jonathan Wakely wrote: On 27 October 2012 13:55, Peter A. Felvegi wrote: I didn't find anything relevant in Bugzilla when searching for 'typedef template'. Should I file a bug report? If you've found what you think is a bug and you can't find an existing Bugzilla report then yes, you should file a bug report. This list is not for reporting bugs. Maybe this is related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058 I agree, it seems closely related: for both the behavior of the compiler changed with Rev 18400. Thanks! Paolo.
gcc-4.7-20121027 is now available
Snapshot gcc-4.7-20121027 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121027/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 192880 You'll find: gcc-4.7-20121027.tar.bz2 Complete GCC MD5=f6981560d64397eeb240ec70d4b76d4f SHA1=92cc57a09a28266055206d38c2de00fdac9cb26e Diffs from 4.7-20121020 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Regression/bug in 4.7 regarding typedef in templated class
On 27/10/12 15:16, Jonathan Wakely wrote: On 27 October 2012 13:55, Peter A. Felvegi wrote: I didn't find anything relevant in Bugzilla when searching for 'typedef template'. Should I file a bug report? If you've found what you think is a bug and you can't find an existing Bugzilla report then yes, you should file a bug report. This list is not for reporting bugs. Maybe this is related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55058 -- Sebastian Huber, embedded brains GmbH Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany Phone : +49 89 18 90 80 79-6 Fax : +49 89 18 90 80 79-9 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
Re: Build/Makefile question
Ian Tayler (in private communication) asked that I get the part of the build log that shows the .so and .a files being built and send it to the list. Here it is. -- Caroline Tice cmt...@google.com /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -shared-libgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc -nostdinc++\ -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/loca\ l/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m\ 32 -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-v3/../libgcc -I/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/usr/local\ /google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/include -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-v3/libsupc++ -prefer-pic -D_GLIBCXX_SHARED -Wall -Wextra -Wwrit\ e-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=vtv_init.lo -g -O0 -D_GNU_SOURCE -m32 -Wl,-L../libsupc++/.libs -Wl,--wh\ ole-archive,-lvtv_init,--no-whole-archive -fvtable-verify=std -Wno-error -c ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc libtool: compile: /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -shared-libgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc -nostdinc++ -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-\ unknown-linux-gnu/32/libstdc++-v3/src -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86\ _64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-\ v3/../libgcc -I/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-\ gnu/32/libstdc++-v3/include -I/usr/local/google2/cmtice/gcc-fsf/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -f\ function-sections -fdata-sections -frandom-seed=vtv_init.lo -g -O0 -D_GNU_SOURCE -m32 -Wl,-L../libsupc++/.libs -Wl,--whole-archive,-lvtv_init,--no-whole-archive -fvtable-verify=std -Wno-er\ ror -c ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o vtv_init.o ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc:49:54: warning: constructor priorities from 0 to 100 are reserved for the implementation [enabled by default] void __VLTunprotect() __attribute__((constructor(98))); ^ ../../../../../gcc-fsf/libstdc++-v3/libsupc++/vtv_init.cc:59:53: warning: constructor priorities from 0 to 100 are reserved for the implementation [enabled by default] void __VLTprotect() __attribute__((constructor(100))); ^ /bin/sh ../libtool --tag=CC --mode=link /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/\ local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -g -O0 -m32 -m32 -o libvtv_init.l\ a -rpath /usr/local/lib/../lib32 vtv_init.lo libtool: link: /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-\ gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -m32 -shared-m32 -m32 -m32 -Wl,-soname -Wl,libvtv_init.so.0 -o\ .libs/libvtv_init.so.0.0.0 libtool: link: (cd ".libs" && rm -f "libvtv_init.so.0" && ln -s "libvtv_init.so.0.0.0" "libvtv_init.so.0") libtool: link: (cd ".libs" && rm -f "libvtv_init.so" && ln -s "libvtv_init.so.0.0.0" "libvtv_init.so") libtool: link: ar rc .libs/libvtv_init.a vtv_init.o libtool: link: ranlib .libs/libvtv_init.a libtool: link: ( cd ".libs" && rm -f "libvtv_init.la" && ln -s "../libvtv_init.la" "libvtv_init.la" ) /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /usr/local/google2/cmtice/gcc-fsf.obj/./gcc/xgcc -shared-libgcc -B/usr/local/google2/cmtice/gcc-fsf.obj/./gcc -nostdinc++\ -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src -L/usr/local/google2/cmtice/gcc-fsf.obj/x86_64-unknown-linux-gnu/32/libstdc++-v3/src/.libs -B/usr/loca\ l/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86
website update
Hi, I just wanted to let you know, I've updated my website at: http://www.cyberfiber.org, hope you don't mind me notifying you. Hope you people can fine-tune both the compiler and the assembler during development, otherwise I will have to migrate to Microsoft Windows in the near future. Let me know, Regards, Mischa.
Re: Regression/bug in 4.7 regarding typedef in templated class
On 27 October 2012 13:55, Peter A. Felvegi wrote: > > I didn't find anything relevant in Bugzilla when searching for 'typedef > template'. Should I file a bug report? If you've found what you think is a bug and you can't find an existing Bugzilla report then yes, you should file a bug report. This list is not for reporting bugs.
Regression/bug in 4.7 regarding typedef in templated class
Hello,
after upgrading gcc one of my classes failed to compile. Stock
Debian/Wheezy 4.4, 4.5, 4.6 compiled the code, also compiled a version
of 4.7.0 that was built by me from sources some time ago. Clang 3.0-6
also compiled, but stock 4.7.1-7, the head of 4.7 (4.7.3 d51dc77f,
r192839) and the head of master (4.8.0 1a2798ac, r192875) didn't.
Reduced the code to a test case:
8<8<8<8<8<8<8<
class Id
{
public:
Id();
Id(char a, char b);
explicitId(int v);
Id(const char* id_);
};
template
class Foo
{
public:
// typedef ID IdType;
void Bar(const ID& id_);
typedef ID IdType;
};
template
void Foo::Bar(const IdType& id_)
//void Foo::Bar(const ID& id_)
{
}
void foo()
{
Foo f;
f.Bar("hello");
}
8<8<8<8<8<8<8<
$ g++ -c gcctypedef.cpp
gcctypedef.cpp: In function ‘void foo()’:
gcctypedef.cpp:29:15: error: no matching function for call to
‘Foo::Bar(const char [6])’
gcctypedef.cpp:29:15: note: candidate is:
gcctypedef.cpp:21:6: note: void Foo::Bar(const IdType&) [with ID =
Id; Foo::IdType = Id]
gcctypedef.cpp:21:6: note: no known conversion for argument 1 from
‘const char [6]’ to ‘Id&’
4.8 gives the same error, but in prettier, more verbose format.
If the typedef in class Foo is _before_ the Bar fn declaration, gcc
compiles the code.
If instead of the typedef (IdType) the original type (ID) is used in the
argument of the Bar fn at the definition, gcc compiles the code.
I git bisect'd the commit that introduced the regression/bug:
commit 44f861fca343148a1b0720105ec2b7f14bbcc849
Author: jason
Date: Wed Feb 8 09:52:11 2012 +
PR c++/52035
* pt.c (tsubst): Strip uninstantiated typedef.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@184000
138bc75d-0d04-0410-961f-82ee72b054a4
I didn't find anything relevant in Bugzilla when searching for 'typedef
template'. Should I file a bug report?
Kind regards, Peter
expansion of vector shifts...
On sparc a simple test like (from the PR tree-optimization/53410 testcase):
typedef int V __attribute__((vector_size (4 * sizeof (int;
typedef unsigned int W __attribute__((vector_size (4 * sizeof (int;
void
f10 (W *p, W *q)
{
*p = *p < (((const W) { 1U, 1U, 1U, 1U }) << *q);
}
aborts in convert_move() because we're trying to move a TImode value
into a V2SImode one. How does that happen?
On sparc the generic tree vector layer turns the above expression into
two V2SImode shifts. The *q parts of each shift are represented as:
(subreg:V2SI (reg:TI xxx) 0)
(subreg:V2SI (reg:TI xxx) 8)
When we get down into expand_shift_1(), that SUBREG is stripped out by
the SHIFT_COUNT_TRUNCATED code, and that's how we end up in the crash
by the time we reach convert_move() (via expand_binop() -->
expand_binop_directly() --> convert_modes() --> convert_move()).
Perhaps we should elide the SUBREG stripping if the subreg has a
vector mode?
Actually, what seems to confuse this code is that we're passing
TImode values around for this vector that the target doesn't have
direct support for. The SUBREG stripper explicitly checks for
INTEGRAL_MODE_P, and indeed TImode is integral.
