[buildrobot] mips64-linux broken
Hi Maxim! One of your recent libc<->android clean-up patches broke the mips64-linux target as a side-effect, see eg. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=53806: g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -Ic-family -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/c-family -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o c-family/c-cppbuiltin.o -MT c-family/c-cppbuiltin.o -MMD -MP -MF c-family/.deps/c-cppbuiltin.TPo /home/jbglaw/repos/gcc/gcc/c-family/c-cppbuiltin.c /home/jbglaw/repos/gcc/gcc/c-family/c-cppbuiltin.c: In function ‘void c_cpp_builtins(cpp_reader*)’: /home/jbglaw/repos/gcc/gcc/c-family/c-cppbuiltin.c:1014:370: error: ‘ANDROID_TARGET_OS_CPP_BUILTINS’ was not declared in this scope make[1]: *** [c-family/c-cppbuiltin.o] Error 1 MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: 17:44 <@uschebit> Evangelist ist doch ein Vertriebler the second : für unverkäufliche Produkte, oder? (#korsett, 20120821) signature.asc Description: Digital signature
Re: 3 libstdc++ tests fail at random
I'll look into the async failure when I get home in a few hours.
Re: bisonc++ ??
On Dec 7, 2013 9:58 PM, "Bruce Korb" wrote: > > On 12/07/13 12:59, Bruce Korb wrote: >> >> Googling: >> >>> gcc undefined reference to `lexer_line' >> >> >> yields: >> >> http://stackoverflow.com/questions/4262531/trouble-building-gcc-4-6 >> >> Please check for it in configure and mention it in the dependency message. >> :) >> Thank you! > > > Oops -- I was too optimistic: > >> build/gengtype.o build/errors.o build/gengtype-lex.o >> build/gengtype-parse.o build/gengtype-state.o build/version.o >> ../../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a >> build/gengtype.o: In function `create_optional_field_': >> /u/gnu/proj/gcc-svn-bld/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/gengtype.c:1002: >> undefined reference to `lexer_line' > > > What is this message really telling me? It usually means you don't have bison and/or flex installed. They are documented as prerequisites for building from svn. I don't think bisonc++ is needed, that answer is wrong (or at best misleading, maybe for that person installing bisonc++ caused flex to be installed).
Re: Truncate optimisation question
> No, the second follow-up was about moving the simplification to combine.c
> and guarding it with !WORD_REGISTER_OPERATIONS, or whatever other check
> you prefer, so that no undoing is necessary.
In fact the mere distribution of the SUBREG seems to be questionable, whatever
the target. For the testcase of PR58295, the redundant masking is eliminated
because:
(insn 9 7 10 2 (set (reg:SI 120)
(plus:SI (reg:SI 119)
(const_int -48 [0xffd0]))) pr58295.c:8 5 {*arm_addsi3}
(expr_list:REG_DEAD (reg:SI 119)
(nil)))
(insn 10 9 11 2 (set (reg:SI 121)
(and:SI (reg:SI 120)
(const_int 255 [0xff]))) pr58295.c:8 80 {*arm_andsi3_insn}
(expr_list:REG_DEAD (reg:SI 120)
(nil)))
(insn 11 10 12 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 121)
(const_int 9 [0x9]))) pr58295.c:8 227 {*arm_cmpsi_insn}
(expr_list:REG_DEAD (reg:SI 121)
(nil)))
is combined into:
(set (reg:CC 100 cc)
(compare:CC (plus:SI (reg:SI 119)
(const_int -48 [0xffd0]))
(const_int 9 [0x9])))
and then split, thanks to:
case SUBREG:
/* Check for the case where we are comparing A - C1 with C2, that is
(subreg:MODE (plus (A) (-C1))) op (C2)
with C1 a constant, and try to lift the SUBREG, i.e. to do the
comparison in the wider mode. One of the following two conditions
must be true in order for this to be valid:
1. The mode extension results in the same bit pattern being added
on both sides and the comparison is equality or unsigned. As
C2 has been truncated to fit in MODE, the pattern can only be
all 0s or all 1s.
2. The mode extension results in the sign bit being copied on
each side.
The difficulty here is that we have predicates for A but not for
(A - C1) so we need to check that C1 is within proper bounds so
as to perturbate A as little as possible. */
in simplify_comparison (and the SUBREG is generated from the AND by another
case of simplify_comparison). Distributing the SUBREG disables the code.
Therefore, I think that the best thing to do is to go back to Uros' original
idea of distributing the SUBREG only within a PLUS or a MINUS:
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01682.html
The outer operation sort of guarantees that operating in this mode is OK for
the target, so the transformation can be done unconditionally. It could be
also done in simplify-rtx.c instead of combine.c.
--
Eric Botcazou
Re: Truncate optimisation question
Eric Botcazou writes: > Therefore, I think that the best thing to do is to go back to Uros' original > idea of distributing the SUBREG only within a PLUS or a MINUS: > http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01682.html > The outer operation sort of guarantees that operating in this mode is OK for > the target, so the transformation can be done unconditionally. It could be > also done in simplify-rtx.c instead of combine.c. Please do you whatever you think is best. Clearly I screwed this up, sorry. Richard
Re: [buildrobot] mips64-linux broken
On 9/12/2013, at 3:24 am, Jan-Benedict Glaw wrote: > Hi Maxim! > > One of your recent libc<->android clean-up patches broke the > mips64-linux target as a side-effect, see eg. > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=53806: > > g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC > -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings > -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. > -Ic-family -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/c-family > -I/home/jbglaw/repos/gcc/gcc/../include > -I/home/jbglaw/repos/gcc/gcc/../libcpp/include > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber > -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber > -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o c-family/c-cppbuiltin.o > -MT c-family/c-cppbuiltin.o -MMD -MP -MF c-family/.deps/c-cppbuiltin.TPo > /home/jbglaw/repos/gcc/gcc/c-family/c-cppbuiltin.c > /home/jbglaw/repos/gcc/gcc/c-family/c-cppbuiltin.c: In function ‘void > c_cpp_builtins(cpp_reader*)’: > /home/jbglaw/repos/gcc/gcc/c-family/c-cppbuiltin.c:1014:370: error: > ‘ANDROID_TARGET_OS_CPP_BUILTINS’ was not declared in this scope > make[1]: *** [c-family/c-cppbuiltin.o] Error 1 I'm looking into this. Thanks, -- Maxim Kuvyrkov www.kugelworks.com
Joseph Myers joins GCC Steering Committee
On behalf of the entire GCC Steering Committee, it gives me great pleasure to welcome Joseph Myers as the newest member of the GCC Steering Committee. We hope that everyone will join us to wish him all of the support and wisdom for this new challenge. We are grateful for the continued excellent guidance of Jakub Jelinek, Richard Biener and Joseph Myers as co-Release Managers. And we thank Mark Mitchell for his years of dedication, guidance, leadership and service, and wish him great success with his future endeavors. We wish everyone Happy Holidays and a prosperous new year! The GCC Steering Commitee David Edelsohn Kaveh Ghazi Jeffrey Law Marc Lehmann Jason Merrill David Miller Toon Moene Joseph Myers Gerald Pfeifer Joel Sherrill Jim Wilson
Re: bisonc++ ??
On 12/08/13 07:21, Jonathan Wakely wrote: It usually means you don't have bison and/or flex installed. Flex. They are documented as prerequisites for building from svn. Documented prerequisites may as well be documented: in the cellar...in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.” (Sorry, I like Doug Adams.) The problem being that when "upgrading" to a more current stable release, the development tools get stripped out, I don't remember which ones I need and running the configure/build doesn't tell me what I am missing anew. Therefore, prerequisites should be tested for and any missing should be directly announced. I'll supply a patch to gcc-patches, once my fixinc thing is in. Thank you! - Bruce
Re: 3 libstdc++ tests fail at random
On 7 December 2013 17:28, H.J. Lu wrote:
> On Sat, Dec 7, 2013 at 9:26 AM, H.J. Lu wrote:
>> On Sat, Dec 7, 2013 at 9:09 AM, Jakub Jelinek wrote:
>FAIL: 30_threads/async/async.cc execution test
>>>
>>> async.exe:
>>> /usr/src/gcc/libstdc++-v3/testsuite/30_threads/async/async.cc:66: void
>>> test02(): Assertion `status == std::future_status::ready' failed.
>>>
>>> This one fails pretty frequently for me, 6 times out of last 12 i686-linux
>>
>> Same here.
>>
>>> bootstraps/regtests, starting with ~ Nov 21th bootstrap (but before that
>>
>> It started for me around revision 205144.
>>
>
> http://gcc.gnu.org/ml/gcc-cvs/2013-11/msg00869.html
>
> changed 30_threads/async/async.cc.
My recent change to that test introduced a race, the main thread could
wake up and check for readiness before the shared state had been made
ready. Fixed by this patch.
Tested x86_64-linux and i686-linux, committed to trunk.
2013-12-08 Jonathan Wakely
* testsuite/30_threads/async/async.cc: Fix race condition in test.
commit 2141b30307e7802625e72eba3037c0528fcaa76d
Author: Jonathan Wakely
Date: Sun Dec 8 21:35:22 2013 +
* testsuite/30_threads/async/async.cc: Fix race condition in test.
diff --git a/libstdc++-v3/testsuite/30_threads/async/async.cc
b/libstdc++-v3/testsuite/30_threads/async/async.cc
index 1f94494..05fd23c 100644
--- a/libstdc++-v3/testsuite/30_threads/async/async.cc
+++ b/libstdc++-v3/testsuite/30_threads/async/async.cc
@@ -29,23 +29,18 @@
using namespace std;
-struct work {
- typedef void result_type;
- void operator()(mutex& m, condition_variable& cv)
- {
-unique_lock l(m);
-cv.notify_one();
- }
-};
+void work(mutex& m)
+{
+ unique_lock l(m);
+}
void test01()
{
mutex m;
- condition_variable cv;
unique_lock l(m);
- future f1 = async(launch::async, work(), ref(m), ref(cv));
- cv.wait(l);
- f1.get();
+ future f1 = async(launch::async, &work, ref(m));
+ l.unlock(); // allow async thread to proceed
+ f1.get();// wait for it to finish
}
void test02()
@@ -53,15 +48,15 @@ void test02()
bool test __attribute__((unused)) = true;
mutex m;
- condition_variable cv;
unique_lock l(m);
- future f1 = async(launch::async, work(), ref(m), ref(cv));
+ future f1 = async(launch::async, &work, ref(m));
std::future_status status;
status = f1.wait_for(std::chrono::milliseconds(1));
VERIFY( status == std::future_status::timeout );
status = f1.wait_until(std::chrono::system_clock::now());
VERIFY( status == std::future_status::timeout );
- cv.wait(l);
+ l.unlock(); // allow async thread to proceed
+ f1.wait(); // wait for it to finish
status = f1.wait_for(std::chrono::milliseconds(0));
VERIFY( status == std::future_status::ready );
status = f1.wait_until(std::chrono::system_clock::now());
gcc-4.9-20131208 is now available
Snapshot gcc-4.9-20131208 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20131208/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 205795 You'll find: gcc-4.9-20131208.tar.bz2 Complete GCC MD5=57d84499a918a772880c0446fdf98937 SHA1=37f171bc0d1f5314f4c2f504f07b0f67a405eff4 Diffs from 4.9-20131201 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
[buildrobot] s390x-linux broken
On Mon, 2013-12-09 08:21:43 +1300, Maxim Kuvyrkov wrote: > On 9/12/2013, at 3:24 am, Jan-Benedict Glaw wrote: > > One of your recent libc<->android clean-up patches broke the > > mips64-linux target as a side-effect, see eg. > > http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=53806: Would be nice if you'd have a look at s390x-linux, too: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/jbglaw/repos/gcc/gcc -I/home/jbglaw/repos/gcc/gcc/. -I/home/jbglaw/repos/gcc/gcc/../include -I/home/jbglaw/repos/gcc/gcc/../libcpp/include -I/home/jbglaw/repos/gcc/gcc/../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/jbglaw/repos/gcc/gcc/../libbacktrace-o s390.o -MT s390.o -MMD -MP -MF ./.deps/s390.TPo /home/jbglaw/repos/gcc/gcc/config/s390/s390.c /home/jbglaw/repos/gcc/gcc/config/s390/s390.c:11923: error: ‘linux_has_ifunc_p’ was not declared in this scope /home/jbglaw/repos/gcc/gcc/config/s390/s390.c:11923: error: too many initializers for ‘gcc_target’ make[1]: *** [s390.o] Error 1 (Cf. http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=53887) Thanks, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: http://perl.plover.com/Questions.html the second : signature.asc Description: Digital signature
RE: Joseph Myers joins GCC Steering Committee
Welcome Joseph. Wish everyone Happy Holidays and a wonderful 2014! Charlie -Original Message- From: gcc-announce-ow...@gcc.gnu.org [mailto:gcc-announce-ow...@gcc.gnu.org] On Behalf Of David Edelsohn Sent: Monday, December 09, 2013 3:28 AM To: gcc@gcc.gnu.org; gcc-annou...@gcc.gnu.org Subject: Joseph Myers joins GCC Steering Committee On behalf of the entire GCC Steering Committee, it gives me great pleasure to welcome Joseph Myers as the newest member of the GCC Steering Committee. We hope that everyone will join us to wish him all of the support and wisdom for this new challenge. We are grateful for the continued excellent guidance of Jakub Jelinek, Richard Biener and Joseph Myers as co-Release Managers. And we thank Mark Mitchell for his years of dedication, guidance, leadership and service, and wish him great success with his future endeavors. We wish everyone Happy Holidays and a prosperous new year! The GCC Steering Commitee David Edelsohn Kaveh Ghazi Jeffrey Law Marc Lehmann Jason Merrill David Miller Toon Moene Joseph Myers Gerald Pfeifer Joel Sherrill Jim Wilson
