Re: Re: Adding a new thread model to GCC
Currently, --enable-threads=win32 map to gthr-win32.{h|c}, could we map
--enable-threads=win32-vista
--enable-threads=win32-win7 // Windows 7 and Windows Server 2008 R2
--enable-threads=win32-win8 // Windows 8 and Windows Server 2012
--enable-threads=win32-win8.1 // Windows 8.1 and Windows Server 2012 R2
--enable-threads=win32-win10 // Windows 10 and Windows Server 2016
to gthr-windows.{h|c} with the corresponding _WIN32_WINNT macros ?
Regards,
Dongsheng
On Thu, Apr 14, 2016 at 10:24 AM, lh_mouse wrote:
> Yes I learnt those *ByAddress* functions a few months ago and was shocked
> that Microsoft had plagiarized futex from Linux.
> As you have pointed out already, those APIs are only available on Windows 8
> and later.
>
> If we need fuex semantics on Windows 7 and earlier, we must simulate it.
> However, since futexes and keyed events work differently, simulation of
> futexes using keyed events would:
> 0) require a lot of work, and
> 1) suffer from performance penalty just like if we simulate keyed events on
> Windows 2000.
>
> The major difference is that, the FUTEX_WAIT syscall is an atomic
> compare-and-sleep operation, while the NtWaitForKeyedEvent syscall provides
> no comparison.
> Instead, the NtReleasedKeyedEvent syscall blocks the current thread until one
> thread is woken up, while FUTEX_WAKE does nothing and returns immediately.
>
> So here is my condition: in no event shall portability harm either efficiency
> or maintainability.
> Linux and Windows work differently. I consider it 'harmful' to make one look
> like the other.
>
>
> --
> Best regards,
> lh_mouse
> 2016-04-14
>
> -
> 发件人：Torvald Riegel
> 发送日期：2016-04-14 01:40
> 收件人：lh_mouse
> 抄送：gcc,mingw-w64-public
> 主题：Re: Adding a new thread model to GCC
>
> On Wed, 2016-04-13 at 17:17 +0800, lh_mouse wrote:
>> Hi all,
>>
>> The 'win32' thread model of gcc has been there since long long ago, being
>> compatible with very old Windows versions, also having a number of drawbacks:
>> 0) its implementation is very inefficient, and
>> 1) its mutexes and condition variables require dynamic initialization and
>> are unusable in C++11 as std::mutex requires a `constexpr` constructor, and
>> 2) allocating a number of rarely used mutexes or condition variables would
>> eventually make the system run out of kernel objects.
>>
>> As a solution for 1) and 2), Microsoft introduced keyed events, details of
>> which can be found here:
>> http://joeduffyblog.com/2006/11/28/windows-keyed-events-critical-sections-and-new-vista-synchronization-features/
>
> Have you looked at WaitOnAddress and WakeByAddressSingle /
> WakeByAddressAll too? AFAIK this is new in Windows 8, and seems similar
> to futexes.
>
> I think it might be better to get a std::synchronic (or similar)
> implementation into GCC, and then use these to implement at least the
> mutexes:
> https://github.com/ogiroux/synchronic/blob/master/include/synchronic
>
> One benefit would be that we then have one place where we have optimized
> spinning/blocking in libstdc++ on Windows, and less platform-specific
> code.
>
>
>
Re: GCC 4.3.5 Status Report (2010-05-22)
It's very simple (only for trunk, although it maybe more useful for branches):
Index: update_version_svn
===
--- update_version_svn (revision 169428)
+++ update_version_svn (working copy)
@@ -42,6 +42,12 @@
SVNROOT2=${SVNROOT}/branches/${BRANCH}
fi
+ LAST_COMMITER=`${SVN} log -q -l 1 ${SVNROOT2} | awk '{if (NR==2)
{print $3; exit}}'`
+ if test "${LAST_COMMITER}" = "gccadmin"; then
+echo "The last commiter is gccadmin, bump DATASTAMP skipped."
+continue
+ fi
+
for i in $datestamp_FILES; do
${SVN} -q co -N ${SVNROOT2}/`dirname $i` `basename $i`
done
On Mon, Jan 31, 2011 at 06:23, Gerald Pfeifer wrote:
>
> On Sat, 29 Jan 2011, Dongsheng Song wrote:
> > Just for curiousness, why we bump the DATESTAMP when the last commit
> > is DATESTAMP changes on the branch ?
>
> As far as I am concerned, that's a bug (or a missing feature). The
> script in question is maintainer-scripts/update_version_svn in the GCC
> source repository. I already made some simplifications today and am
> planning to do a bit more tonight. Are you interested in improving
> the script to address this issue?
>
> Gerald
Re: GCC 4.3.5 Status Report (2010-05-22)
Oh, update_version_svn can be apply to
trunk/gcc-4.5-branch/gcc-4.4-branch/gcc-4.3-branch, not only trunk.
On Mon, Jan 31, 2011 at 10:45, Dongsheng Song wrote:
> It's very simple (only for trunk, although it maybe more useful for branches):
>
> Index: update_version_svn
> ===
> --- update_version_svn (revision 169428)
> +++ update_version_svn (working copy)
> @@ -42,6 +42,12 @@
> SVNROOT2=${SVNROOT}/branches/${BRANCH}
> fi
>
> + LAST_COMMITER=`${SVN} log -q -l 1 ${SVNROOT2} | awk '{if (NR==2)
> {print $3; exit}}'`
> + if test "${LAST_COMMITER}" = "gccadmin"; then
> + echo "The last commiter is gccadmin, bump DATASTAMP skipped."
> + continue
> + fi
> +
> for i in $datestamp_FILES; do
> ${SVN} -q co -N ${SVNROOT2}/`dirname $i` `basename $i`
> done
>
> On Mon, Jan 31, 2011 at 06:23, Gerald Pfeifer wrote:
>>
>> On Sat, 29 Jan 2011, Dongsheng Song wrote:
>> > Just for curiousness, why we bump the DATESTAMP when the last commit
>> > is DATESTAMP changes on the branch ?
>>
>> As far as I am concerned, that's a bug (or a missing feature). The
>> script in question is maintainer-scripts/update_version_svn in the GCC
>> source repository. I already made some simplifications today and am
>> planning to do a bit more tonight. Are you interested in improving
>> the script to address this issue?
>>
>> Gerald
>
Re: GCC 4.3.5 Status Report (2010-05-22)
On Tue, Feb 1, 2011 at 18:31, Richard Guenther wrote: > > The DATESTAMP change could also be in a post-commit hook (doing > nothing if the date didn't change, of course). No idea whether this > is technically possible of course. > > Richard. > Yes, the post-commit hook can do this task. If we really want to do that, I can update the current post-commit hook script [1]. *) Get DATESTAMP for the current branch in the repository, e.g. $ svn cat svn://gcc.gnu.org/svn/gcc/trunk/gcc/DATESTAMP 20110201 $ svn cat svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch/gcc/DATESTAMP 20110201 ... *) Get the current DATESTAMP $ /bin/date +"%Y%m%d" 20110201 *) If the two DATESTAMP is equal, do nothing; otherwise update the DATESTAMP in the repository. [1] svn://gcc.gnu.org/svn/gcc/hooks/post-commit -- Dongsheng
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Tue, Feb 1, 2011 at 23:32, Gerald Pfeifer wrote: > On Tue, 1 Feb 2011, Dongsheng Song wrote: >>> The DATESTAMP change could also be in a post-commit hook (doing >>> nothing if the date didn't change, of course). No idea whether >>> this is technically possible of course. >> Yes, the post-commit hook can do this task. >> If we really want to do that, I can update the current post-commit >> hook script [1]. > > I'd love to see that and will be happy to work on this with you, > apply a patch, etc. > > Let's give others the chance to chime in, and if there are no > objections within the next two days, let's proceed. Fair? > > Gerald OK, let's waiting for comments now. Dongsheng
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
On Wed, Feb 2, 2011 at 22:00, Paul Koning wrote:
> No. Subversion specifically documents the fact that a pre-commit hook can't
> change the transaction; it can only inspect it.
>
> paul
>
Yes, here is a pilot post commit hook for bumping DATESTAMP:
post-commit |2 ++
update_datestamp | 51 +++
2 files changed, 53 insertions(+)
Index: hooks/update_datestamp
===
--- hooks/update_datestamp (revision 0)
+++ hooks/update_datestamp (revision 0)
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+REPOS="$1"
+REV="$2"
+
+PATH=/usr/local/bin:/usr/pkg/bin:/usr/bin:/bin
+IGNORE_BRANCHES='gcc-(2_95|3_0|3_1|3_2|3_3|3_4|4_0|4_1|4_2)-branch'
+
+# Run this from /tmp
+/bin/rm -rf /tmp/$$
+/bin/mkdir /tmp/$$
+cd /tmp/$$
+
+# Compute the branches which we should check for update.
+BRANCHES=`svnlook -r ${REV} dirs-changed "${REPOS}" \
+| grep -E "^trunk/|^branches/gcc-[0-9]+_[0-9]+-branch/" \
+| grep -E -v ${IGNORE_BRANCHES} \
+| awk -F '/' '{if ($1 == "trunk") { print $1} else { print $2}}' \
+| sort -u`
+
+# Assume all will go well.
+RESULT=0
+for BRANCH in ${BRANCHES}; do
+
+ # Compute the svn root URL we should check for update.
+ if test "${BRANCH}" = "trunk"; then
+DATESTAMP_URL="file://${REPOS}/trunk/gcc"
+ else
+DATESTAMP_URL="file://${REPOS}/branches/${BRANCH}/gcc"
+ fi
+
+ CURR_DATE=`/bin/date -u +"%Y%m%d"`
+ PREV_DATE=`svn cat "${DATESTAMP_URL}/DATESTAMP"`
+ if test "${CURR_DATE}" = "${PREV_DATE}"; then
+continue
+ fi
+
+ svn -q co -N "${DATESTAMP_URL}/" gcc
+ echo -n ${CURR_DATE} > gcc/DATESTAMP
+ if ! svn commit -m "Daily bump." gcc/DATESTAMP; then
+# If we could not commit the files, indicate failure.
+RESULT=1
+ fi
+
+ # Remove the files.
+ rm -rf /tmp/$$/gcc
+done
+
+/bin/rm -rf /tmp/$$
+
+exit $RESULT
Property changes on: hooks/update_datestamp
___
Added: svn:executable
+ *
Index: hooks/post-commit
===
--- hooks/post-commit (revision 169520)
+++ hooks/post-commit (working copy)
@@ -17,3 +17,5 @@
--repository "${REPOS}" --revision "${REV}" --background
${REPOS}/hooks/synchooks.sh "${REPOS}" "${REV}"
+
+${REPOS}/hooks/update_version_svn ${REPOS} ${REV} &
--
Dongsheng Song
Re: Bumping DATESTAMP (was: GCC 4.3.5 Status Report (2010-05-22))
Hi all,
Here is the update patch.
*) Remove IGNORE_BRANCHES
*) Add BRANCH_REGEXP
*) Remove '-n' from echo command line, use the original DATESTAMP format
*) Update PATH as Gerald recommend
*) Fix a typo in patch of hooks/post-commit
*) Write svn commit error messages to svn client as Gerald recommend
post-commit |6 ++
update_datestamp | 52
2 files changed, 58 insertions(+)
Index: hooks/update_datestamp
===
--- hooks/update_datestamp (revision 0)
+++ hooks/update_datestamp (revision 0)
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+REPOS="$1"
+REV="$2"
+
+PATH=/usr/bin:/bin
+BRANCH_REGEXP="^trunk/|^branches/gcc-[0-9]+_[0-9]+-branch/"
+
+# Run this from /tmp
+/bin/rm -rf /tmp/$$
+/bin/mkdir /tmp/$$
+cd /tmp/$$
+
+# Compute the branches which we should check for update.
+BRANCHES=`svnlook -r ${REV} dirs-changed "${REPOS}" \
+| grep -E "${BRANCH_REGEXP}" \
+| awk -F '/' '{if ($1 == "trunk") { print $1} else { print $2}}' \
+| sort -u`
+
+# Assume all will go well.
+RESULT=0
+for BRANCH in ${BRANCHES}; do
+
+ # Compute the DATESTAMP URL we should check for update. Since svn
+ # does not support checkout files, so we use the parent directory.
+ if test "${BRANCH}" = "trunk"; then
+DATESTAMP_URL="file://${REPOS}/trunk/gcc"
+ else
+DATESTAMP_URL="file://${REPOS}/branches/${BRANCH}/gcc"
+ fi
+
+ CURR_DATE=`/bin/date -u +"%Y%m%d"`
+ PREV_DATE=`svn cat "${DATESTAMP_URL}/DATESTAMP"`
+ if test "${CURR_DATE}" = "${PREV_DATE}"; then
+continue
+ fi
+
+ svn -q co -N "${DATESTAMP_URL}/" gcc
+ echo ${CURR_DATE} > gcc/DATESTAMP
+ if ! svn commit -m "Daily bump." gcc/DATESTAMP; then
+# If we could not commit the files, indicate failure.
+# The commiter will see the failure message from the svn client.
+RESULT=1
+ fi
+
+ # Remove the files.
+ rm -rf /tmp/$$/gcc
+done
+
+/bin/rm -rf /tmp/$$
+
+exit $RESULT
Property changes on: hooks/update_datestamp
___
Added: svn:executable
+ *
Index: hooks/post-commit
===
--- hooks/post-commit (revision 169782)
+++ hooks/post-commit (working copy)
@@ -17,3 +17,9 @@
--repository "${REPOS}" --revision "${REV}" --background
${REPOS}/hooks/synchooks.sh "${REPOS}" "${REV}"
+
+ERROR_MESSAGES=`${REPOS}/hooks/update_datestamp ${REPOS} ${REV} 2>&1
>/dev/null`
+ERROR_CODE="$?"
+echo ${ERROR_MESSAGES} >&2
+
+exit ${ERROR_CODE}
--
Dongsheng Song
Re: Parma Polyhedra Library 0.11.1
On Mon, Feb 21, 2011 at 01:32, Prof. Roberto Bagnara
wrote:
>
> We announce the availability of PPL 0.11.1, a new release of the Parma
> Polyhedra Library. This release includes several important bug fixes
> and performance improvements.
>
> The precise list of user-visible changes is available at
>
> http://www.cs.unipr.it/ppl/Download/ftp/releases/0.11.1/NEWS
>
> For more information, please come and visit the PPL web site at
>
> http://www.cs.unipr.it/ppl/
>
> On behalf of all the past and present developers listed at
> http://www.cs.unipr.it/ppl/Credits/ and in the file CREDITS,
>
> Abramo Bagnara Roberto Bagnara Patricia M. Hill Enea Zaffanella
>
> --
> Prof. Roberto Bagnara CEO & CTO
> Applied Formal Methods Laboratory BUGSENG srl
> Department of Mathematics Parco Area delle Scienze 53/A
> University of Parma, Italy I-43124 Parma, Italy
> http://www.cs.unipr.it/~bagnara/ http://bugseng.com/
> mailto:bagn...@cs.unipr.it mailto:roberto.bagn...@bugseng.com
>
When I build on i686-w64-mingw32 target:
libtool: compile: i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
-I/home/oracle/src/ppl-0.11.1/src -I.. -I..
-I/home/oracle/src/ppl-0.11.1/src
-I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
-frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc -DDLL_EXPORT -DPIC -o
.libs/fpu-ia32.o
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
Parma_Polyhedra_Library::detect_sse_unit()':
/home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
not declared in this scope
make[3]: *** [fpu-ia32.lo] Error 1
make[3]: Leaving directory `/tmp/x/src'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/x/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/x'
make: *** [all] Error 2
Here is my patch:
$ git diff src/fpu-ia32.cc
diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
index d361411..8a2a6a2 100644
--- a/src/fpu-ia32.cc
+++ b/src/fpu-ia32.cc
@@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
#include "fpu.defs.hh"
#include
#include
+#include
namespace {
And I'm doubt the assumption GMP does not support exception when cross
compiling:
$ git diff m4/ac_check_gmp.m4
diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
index c5dd1c9..8c2af74 100644
--- a/m4/ac_check_gmp.m4
+++ b/m4/ac_check_gmp.m4
@@ -181,8 +181,8 @@ int main() {
ac_cv_gmp_supports_exceptions=yes,
AC_MSG_RESULT(no)
ac_cv_gmp_supports_exceptions=no,
- AC_MSG_RESULT([assuming not])
- ac_cv_gmp_supports_exceptions=no)
+ AC_MSG_RESULT([assuming yes])
+ ac_cv_gmp_supports_exceptions=yes)
gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
if test x"$gmp_supports_exceptions" = xyes
--
Dongsheng
Re: Parma Polyhedra Library 0.11.1
On Tue, Feb 22, 2011 at 17:05, Roberto Bagnara wrote:
>> And I'm doubt the assumption GMP does not support exception when cross
>> compiling:
>>
>> $ git diff m4/ac_check_gmp.m4
>> diff --git a/m4/ac_check_gmp.m4 b/m4/ac_check_gmp.m4
>> index c5dd1c9..8c2af74 100644
>> --- a/m4/ac_check_gmp.m4
>> +++ b/m4/ac_check_gmp.m4
>> @@ -181,8 +181,8 @@ int main() {
>> ac_cv_gmp_supports_exceptions=yes,
>> AC_MSG_RESULT(no)
>> ac_cv_gmp_supports_exceptions=no,
>> - AC_MSG_RESULT([assuming not])
>> - ac_cv_gmp_supports_exceptions=no)
>> + AC_MSG_RESULT([assuming yes])
>> + ac_cv_gmp_supports_exceptions=yes)
>>
>> gmp_supports_exceptions=${ac_cv_gmp_supports_exceptions}
>> if test x"$gmp_supports_exceptions" = xyes
>
> How does this affect you? I mean, that setting only affects
> the PPL testsuite and if you are cross-compiling you are
> not using it.
But after the configure script done, I got the following warning:
...
config.status: executing libtool commands
configure: WARNING: CANNOT PROPAGATE EXCEPTIONS BACK FROM GMP:
*** MEMORY EXHAUSTION MAY RESULT IN ABRUPT TERMINATION.
*** This is OK, if you do not plan to use the bounded memory capabilities
*** offered by the PPL. Otherwise, if you are using GCC or the Intel C/C++
*** compiler, please make sure you use a version of GMP compiled with the
*** `-fexceptions' compiler option.
*** To build such a version, you can configure GMP as follows:
*** CPPFLAGS=-fexceptions ./configure --enable-cxx --prefix=/usr/local
Since the most gcc distro already support exceptions at default, so I think
we had better assume gmp support exceptions at default.
--
Dongsheng
Re: Parma Polyhedra Library 0.11.1
On Tue, Feb 22, 2011 at 17:05, Roberto Bagnara wrote:
> On 02/22/2011 06:04 AM, Dongsheng Song wrote:
>>
>> When I build on i686-w64-mingw32 target:
>>
>> libtool: compile: i686-w64-mingw32-g++ -DHAVE_CONFIG_H -I.
>> -I/home/oracle/src/ppl-0.11.1/src -I.. -I..
>> -I/home/oracle/src/ppl-0.11.1/src
>> -I/home/oracle/tmp/gcc-4.5-windows-obj/misc//include -g -O2
>> -frounding-math -march=x86-64 -O2 -flto -pipe -D_WIN32 -W -Wall -MT
>> fpu-ia32.lo -MD -MP -MF .deps/fpu-ia32.Tpo -c
>> /home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc -DDLL_EXPORT -DPIC -o
>> .libs/fpu-ia32.o
>> /home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc: In function 'void
>> Parma_Polyhedra_Library::detect_sse_unit()':
>> /home/oracle/src/ppl-0.11.1/src/fpu-ia32.cc:52:7: error: 'NULL' was
>> not declared in this scope
>> make[3]: *** [fpu-ia32.lo] Error 1
>> make[3]: Leaving directory `/tmp/x/src'
>> make[2]: *** [all] Error 2
>> make[2]: Leaving directory `/tmp/x/src'
>> make[1]: *** [all-recursive] Error 1
>> make[1]: Leaving directory `/tmp/x'
>> make: *** [all] Error 2
>>
>> Here is my patch:
>>
>> $ git diff src/fpu-ia32.cc
>> diff --git a/src/fpu-ia32.cc b/src/fpu-ia32.cc
>> index d361411..8a2a6a2 100644
>> --- a/src/fpu-ia32.cc
>> +++ b/src/fpu-ia32.cc
>> @@ -30,6 +30,7 @@ site: http://www.cs.unipr.it/ppl/ . */
>> #include "fpu.defs.hh"
>> #include
>> #include
>> +#include
>>
>> namespace {
>>
>
> Hi Dongsheng,
>
> I don't see any occurrences of NULL in fpu-ia32.cc.
> Perhaps this is a bug in the or related header file
> in your system?
>
When I use gcc 4.5 (version 4.5.3 20110221) with mingw-w64 trunk,
after preprocessing, setjmp(env) extend to _setjmp3((env), NULL) .
When I use gcc 4.6 (version 4.6.0 20110221) with mingw-w64 trunk,
after preprocessing, setjmp(env) extend to _setjmp3((env), __null) .
So gcc 4.5 run into trouble, but gcc 4.6 OK.
I don't know why and how to fix in GCC or mingw-w64, but just add
one line '#include' in the source is the simplest way.
--
Dongsheng
Include files search order of cross build gcc
Hi, When I cross build gcc on linux-amd64 box, I got a include files search order error: ... /root/obj/gcc-4.2/./gcc/xgcc -B/root/obj/gcc-4.2/./gcc/ -L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/mingw -L/root/obj/gcc-4.2/i686-pc-mingw32/winsup/w32api/lib -isystem /root/src/gcc-4.2.4/winsup/mingw/include -isystem /root/src/gcc-4.2.4/winsup/w32api/include -B/root/mingw32/i686-pc-mingw32/bin/ -B/root/mingw32/i686-pc-mingw32/lib/ -isystem /root/mingw32/i686-pc-mingw32/include -isystem /root/mingw32/i686-pc-mingw32/sys-include -O2 -I/root/src/gcc-4.2.4/gcc/../winsup/w32api/include -O2 -O2 -pipe -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/root/src/gcc-4.2.4/gcc -I/root/src/gcc-4.2.4/gcc/. -I/root/src/gcc-4.2.4/gcc/../include -I/root/src/gcc-4.2.4/gcc/../libcpp/include -I/usr/include -I/usr/include -I/root/src/gcc-4.2.4/gcc/../libdecnumber -I../libdecnumber -c /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c -o libgcc/./gthr-win32.o In file included from /usr/include/sys/select.h:46, from /usr/include/sys/types.h:220, from /usr/include/stdlib.h:320, from /root/mingw32/i686-pc-mingw32/include/objbase.h:12, from /root/mingw32/i686-pc-mingw32/include/ole2.h:9, from /root/mingw32/i686-pc-mingw32/include/windows.h:114, from /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c:34: /usr/include/bits/time.h:70: error: redefinition of ‘struct timeval’ In file included from /usr/include/sys/types.h:220, from /usr/include/stdlib.h:320, from /root/mingw32/i686-pc-mingw32/include/objbase.h:12, from /root/mingw32/i686-pc-mingw32/include/ole2.h:9, from /root/mingw32/i686-pc-mingw32/include/windows.h:114, from /root/src/gcc-4.2.4/gcc/config/i386/gthr-win32.c:34: Why gcc use stdlib.h in the path '/usr/include', not the path '/root/mingw32/i686-pc-mingw32/include' ? Regards, Dongsheng
Fwd: r168382 - in /trunk/libstdc++-v3: ChangeLog Mak...
I think gcc-cvs mail list should set reply address to gcc@gcc.gnu.org
instead of gcc-...@gcc.gnu.org.
-- Forwarded message --
From: Dongsheng Song
Date: Sat, Jan 1, 2011 at 11:29
Subject: Re: r168382 - in /trunk/libstdc++-v3: ChangeLog Mak...
To: b...@gcc.gnu.org
Cc: gcc-...@gcc.gnu.org
Hi Benjamin,
Your commit have 2 drawbacks:
1. insufficient docbook xsl path checker (trunk/libstdc++-v3/configure.ac)
# Check for docbook
AC_CHECK_PROG([XSLTPROC], xsltproc, yes, no)
AC_CHECK_PROG([XMLLINT], xmllint, yes, no)
AC_CHECK_FILE([/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION],
[glibcxx_stylesheets=yes], [glibcxx_stylesheets=no])
For Debian, here is the correct path:
-rw-r--r-- 1 root root 4510 Jul 22 2009
/usr/share/xml/docbook/stylesheet/docbook-xsl-ns/VERSION
-rw-r--r-- 1 root root 4504 Jul 21 2009
/usr/share/xml/docbook/stylesheet/docbook-xsl/VERSION
2. break cross compiling (trunk/libstdc++-v3/configure)
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for
/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION" >&5
$as_echo_n "checking for
/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION... " >&6; }
if test "${ac_cv_file__usr_share_sgml_docbook_xsl_ns_stylesheets_VERSION+set}"
= set; then :
$as_echo_n "(cached) " >&6
else
test "$cross_compiling" = yes &&
as_fn_error "cannot check for file existence when cross compiling" "$LINENO" 5
if test -r "/usr/share/sgml/docbook/xsl-ns-stylesheets/VERSION"; then
ac_cv_file__usr_share_sgml_docbook_xsl_ns_stylesheets_VERSION=yes
else
ac_cv_file__usr_share_sgml_docbook_xsl_ns_stylesheets_VERSION=no
fi
fi
After as_fn_error, my cross compiling failed without use hard code path.
--
Dongsheng
On Sat, Jan 1, 2011 at 06:20, wrote:
> Author: bkoz
> Date: Fri Dec 31 22:20:22 2010
> New Revision: 168382
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168382
> Log:
> 2010-12-31 Benjamin Kosnik
>
> * scripts/run_doxygen: Allow doxygen 1.7.1 again.
>
> * doc/xml/manual/build_hacking.xml: Update.
> * doc/xml/images/confdeps.dot: Same.
> * doc/xml/images/confdeps.png: Same.
>
> * configure.ac: Define BUILD_INFO, BUILD_XML, BUILD_HTML,
> BUILD_MAN, BUILD_PDF, BUILD_EPUB conditionally.
> * Makefile.am (xml, html, pdf, man, info, pd, dvi, epub): Define,
> and install rules.
> * doc/Makefile.am: Same. Add stamp rules.
> (doc-epub-docbook): Add.
> (stamp-xml-single-docbook): Make set too.
> * configure: Regenerate.
> * Makefile.in: Same.
> * doc/Makefile.in: Same.
> * include/Makefile.in: Same.
> * libsupc++/Makefile.in: Same.
> * po/Makefile.in: Same.
> * python/Makefile.in: Same.
> * src/Makefile.in: Same.
> * testsuite/Makefile.in: Same.
> * aclocal.m4: Same.
>
> 2010-12-31 Benjamin Kosnik
>
> * doc/doxygen/user.cfg.in: Disable PDF_HYPERLINKS.
>
>
> Modified:
> trunk/libstdc++-v3/ChangeLog
> trunk/libstdc++-v3/Makefile.am
> trunk/libstdc++-v3/Makefile.in
> trunk/libstdc++-v3/aclocal.m4
> trunk/libstdc++-v3/configure
> trunk/libstdc++-v3/configure.ac
> trunk/libstdc++-v3/doc/Makefile.am
> trunk/libstdc++-v3/doc/Makefile.in
> trunk/libstdc++-v3/doc/doxygen/user.cfg.in
> trunk/libstdc++-v3/doc/xml/images/confdeps.dot
> trunk/libstdc++-v3/doc/xml/manual/build_hacking.xml
> trunk/libstdc++-v3/include/Makefile.in
> trunk/libstdc++-v3/libsupc++/Makefile.in
> trunk/libstdc++-v3/po/Makefile.in
> trunk/libstdc++-v3/python/Makefile.in
> trunk/libstdc++-v3/scripts/run_doxygen
> trunk/libstdc++-v3/src/Makefile.in
> trunk/libstdc++-v3/testsuite/Makefile.in
>
>
Re: GNU MPFR 3.1.2 Release Candidate
Test on i686-w64-mingw32, only tfprintf.exe, tprintf.exe and
tsprintf.exe FAILED, the other tests passed.
=
3 of 160 tests failed
(1 test was not run)
=
[tversion] GMP: header 5.1.1, library 5.1.1
[tversion] MPFR tuning parameters from src/x86/mparam.h
PASS: tversion.exe
PASS: tinternals.exe
PASS: tinits.exe
PASS: tisqrt.exe
PASS: tsgn.exe
PASS: tcheck.exe
PASS: tisnan.exe
PASS: texceptions.exe
PASS: tset_exp.exe
PASS: tset.exe
PASS: mpf_compat.exe
PASS: mpfr_compat.exe
PASS: reuse.exe
PASS: tabs.exe
PASS: tacos.exe
PASS: tacosh.exe
PASS: tadd.exe
PASS: tadd1sp.exe
PASS: tadd_d.exe
PASS: tadd_ui.exe
PASS: tagm.exe
PASS: tai.exe
PASS: tasin.exe
PASS: tasinh.exe
PASS: tatan.exe
PASS: tatanh.exe
PASS: taway.exe
PASS: tbuildopt.exe
PASS: tcan_round.exe
PASS: tcbrt.exe
PASS: tcmp.exe
PASS: tcmp2.exe
PASS: tcmp_d.exe
PASS: tcmp_ld.exe
PASS: tcmp_ui.exe
PASS: tcmpabs.exe
PASS: tcomparisons.exe
PASS: tconst_catalan.exe
PASS: tconst_euler.exe
PASS: tconst_log2.exe
PASS: tconst_pi.exe
PASS: tcopysign.exe
PASS: tcos.exe
PASS: tcosh.exe
PASS: tcot.exe
PASS: tcoth.exe
PASS: tcsc.exe
PASS: tcsch.exe
PASS: td_div.exe
PASS: td_sub.exe
PASS: tdigamma.exe
PASS: tdim.exe
PASS: tdiv.exe
PASS: tdiv_d.exe
PASS: tdiv_ui.exe
PASS: teint.exe
PASS: teq.exe
PASS: terf.exe
PASS: texp.exe
PASS: texp10.exe
PASS: texp2.exe
PASS: texpm1.exe
PASS: tfactorial.exe
PASS: tfits.exe
PASS: tfma.exe
PASS: tfmod.exe
PASS: tfms.exe
Error in test 8, got '% a. 15, b. -1, c. td'
Error in test #8: mpfr_vfprintf printed 21 characters instead of 20
FAIL: tfprintf.exe
PASS: tfrac.exe
PASS: tfrexp.exe
PASS: tgamma.exe
PASS: tget_flt.exe
PASS: tget_d.exe
PASS: tget_d_2exp.exe
PASS: tget_f.exe
PASS: tget_ld_2exp.exe
SKIP: tget_set_d64.exe
PASS: tget_sj.exe
PASS: tget_str.exe
PASS: tget_z.exe
PASS: tgmpop.exe
PASS: tgrandom.exe
PASS: thyperbolic.exe
PASS: thypot.exe
PASS: tinp_str.exe
PASS: tj0.exe
PASS: tj1.exe
PASS: tjn.exe
PASS: tl2b.exe
PASS: tlgamma.exe
PASS: tli2.exe
PASS: tlngamma.exe
PASS: tlog.exe
PASS: tlog10.exe
PASS: tlog1p.exe
PASS: tlog2.exe
PASS: tmin_prec.exe
PASS: tminmax.exe
PASS: tmodf.exe
PASS: tmul.exe
PASS: tmul_2exp.exe
PASS: tmul_d.exe
PASS: tmul_ui.exe
PASS: tnext.exe
PASS: tout_str.exe
PASS: toutimpl.exe
PASS: tpow.exe
PASS: tpow3.exe
PASS: tpow_all.exe
PASS: tpow_z.exe
Error in test 8, got '% a. 15, b. -1, c. td'
Error in test #8: mpfr_printf printed 21 characters instead of 20
FAIL: tprintf.exe
PASS: trandom.exe
PASS: trec_sqrt.exe
PASS: tremquo.exe
PASS: trint.exe
PASS: troot.exe
PASS: tround_prec.exe
PASS: tsec.exe
PASS: tsech.exe
PASS: tset_d.exe
PASS: tset_f.exe
PASS: tset_ld.exe
PASS: tset_q.exe
PASS: tset_si.exe
PASS: tset_sj.exe
PASS: tset_str.exe
PASS: tset_z.exe
PASS: tset_z_exp.exe
PASS: tsi_op.exe
PASS: tsin.exe
PASS: tsin_cos.exe
PASS: tsinh.exe
PASS: tsinh_cosh.exe
Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...);
expected: "0010610209857723, -1.2345678875e+07, 0.032258"
got: "0010610209857723, -1.2345678875e+07, -0.00"
FAIL: tsprintf.exe
PASS: tsqr.exe
PASS: tsqrt.exe
PASS: tsqrt_ui.exe
PASS: tstckintc.exe
PASS: tstdint.exe
PASS: tstrtofr.exe
PASS: tsub.exe
PASS: tsub1sp.exe
PASS: tsub_d.exe
PASS: tsub_ui.exe
PASS: tsubnormal.exe
PASS: tsum.exe
PASS: tswap.exe
PASS: ttan.exe
PASS: ttanh.exe
PASS: ttrunc.exe
PASS: tui_div.exe
PASS: tui_pow.exe
PASS: tui_sub.exe
PASS: turandom.exe
PASS: tvalist.exe
PASS: ty0.exe
PASS: ty1.exe
PASS: tyn.exe
PASS: tzeta.exe
PASS: tzeta_ui.exe
[tversion] GMP: header 5.1.1, library 5.1.1
[tversion] MPFR tuning parameters from src/x86/mparam.h
PASS: tversion.exe
=
3 of 160 tests failed
(1 test was not run)
=
On Sat, Mar 9, 2013 at 12:09 AM, Vincent Lefevre wrote:
> The release of GNU MPFR 3.1.2 ("canard à l'orange" patch level 2)
> is imminent. Please help to make this release as good as possible
> by downloading and testing this release candidate:
>
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.gz
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.zip
>
> The MD5's:
> 3a95e02c8dc2897638eb998da837e63a mpfr-3.1.2-rc1.tar.bz2
> a273dd7752039b8753e09afdd9f0506b mpfr-3.1.2-rc1.tar.gz
> d8019782b2d3007c60fd292856a59104 mpfr-3.1.2-rc1.tar.xz
> abb2a2fde5109219ab1bef2d55cb5742 mpfr-3.1.2-rc1.zip
>
> The SHA1's:
> 38b1cd6f6ab0190d4b991d4bcdb24d112c9f mpfr-3.1.2-rc1.tar.bz2
> 9a64b70a3d55c7f8a7faf81cf8f1ad74453dab3b mpfr-3.1.2-rc1.tar.gz
> 36d0de647a00527f88c762363e449fcfc6be1375 mpfr-3.1.2-rc1.tar.xz
> fc1b9df7a3779c115d1b4eb1aff5cc0f42b5307a mpfr-3.1.2-rc1.zip
>
> The signatures:
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz.asc
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2.asc
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.gz.asc
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.zip.asc
>
> Each tarball is signed by Vincent Lefèvre. This can be veri
Re: GNU MPFR 3.1.2 Release Candidate
Test on x86_64-w64-mingw32, only tfprintf.exe, tprintf.exe,
tsprintf.exe, and tstrtofr.exe FAILED, the other tests passed.
=
4 of 160 tests failed
(1 test was not run)
=
[tversion] GMP: header 5.1.1, library 5.1.1
[tversion] MPFR tuning parameters from default
PASS: tversion.exe
PASS: tinternals.exe
PASS: tinits.exe
PASS: tisqrt.exe
PASS: tsgn.exe
PASS: tcheck.exe
PASS: tisnan.exe
PASS: texceptions.exe
PASS: tset_exp.exe
PASS: tset.exe
PASS: mpf_compat.exe
PASS: mpfr_compat.exe
PASS: reuse.exe
PASS: tabs.exe
PASS: tacos.exe
PASS: tacosh.exe
PASS: tadd.exe
PASS: tadd1sp.exe
PASS: tadd_d.exe
PASS: tadd_ui.exe
PASS: tagm.exe
PASS: tai.exe
PASS: tasin.exe
PASS: tasinh.exe
PASS: tatan.exe
PASS: tatanh.exe
PASS: taway.exe
PASS: tbuildopt.exe
PASS: tcan_round.exe
PASS: tcbrt.exe
PASS: tcmp.exe
PASS: tcmp2.exe
PASS: tcmp_d.exe
PASS: tcmp_ld.exe
PASS: tcmp_ui.exe
PASS: tcmpabs.exe
PASS: tcomparisons.exe
PASS: tconst_catalan.exe
PASS: tconst_euler.exe
PASS: tconst_log2.exe
PASS: tconst_pi.exe
PASS: tcopysign.exe
PASS: tcos.exe
PASS: tcosh.exe
PASS: tcot.exe
PASS: tcoth.exe
PASS: tcsc.exe
PASS: tcsch.exe
PASS: td_div.exe
PASS: td_sub.exe
PASS: tdigamma.exe
PASS: tdim.exe
PASS: tdiv.exe
PASS: tdiv_d.exe
PASS: tdiv_ui.exe
PASS: teint.exe
PASS: teq.exe
PASS: terf.exe
PASS: texp.exe
PASS: texp10.exe
PASS: texp2.exe
PASS: texpm1.exe
PASS: tfactorial.exe
PASS: tfits.exe
PASS: tfma.exe
PASS: tfmod.exe
PASS: tfms.exe
fixme:msvcrt:pf_printf_a multibyte characters printing not supported
Error in test 8, got '% a. 15, b. -1, c. td'
Error in test #8: mpfr_vfprintf printed 21 characters instead of 20
FAIL: tfprintf.exe
PASS: tfrac.exe
PASS: tfrexp.exe
PASS: tgamma.exe
PASS: tget_flt.exe
PASS: tget_d.exe
PASS: tget_d_2exp.exe
PASS: tget_f.exe
PASS: tget_ld_2exp.exe
SKIP: tget_set_d64.exe
PASS: tget_sj.exe
PASS: tget_str.exe
PASS: tget_z.exe
PASS: tgmpop.exe
PASS: tgrandom.exe
PASS: thyperbolic.exe
PASS: thypot.exe
PASS: tinp_str.exe
PASS: tj0.exe
PASS: tj1.exe
PASS: tjn.exe
PASS: tl2b.exe
PASS: tlgamma.exe
PASS: tli2.exe
PASS: tlngamma.exe
PASS: tlog.exe
PASS: tlog10.exe
PASS: tlog1p.exe
PASS: tlog2.exe
PASS: tmin_prec.exe
PASS: tminmax.exe
PASS: tmodf.exe
PASS: tmul.exe
PASS: tmul_2exp.exe
PASS: tmul_d.exe
PASS: tmul_ui.exe
PASS: tnext.exe
PASS: tout_str.exe
PASS: toutimpl.exe
PASS: tpow.exe
PASS: tpow3.exe
PASS: tpow_all.exe
PASS: tpow_z.exe
fixme:msvcrt:pf_printf_a multibyte characters printing not supported
Error in test 8, got '% a. 15, b. -1, c. td'
Error in test #8: mpfr_printf printed 21 characters instead of 20
FAIL: tprintf.exe
PASS: trandom.exe
PASS: trec_sqrt.exe
PASS: tremquo.exe
PASS: trint.exe
PASS: troot.exe
PASS: tround_prec.exe
PASS: tsec.exe
PASS: tsech.exe
PASS: tset_d.exe
PASS: tset_f.exe
PASS: tset_ld.exe
PASS: tset_q.exe
PASS: tset_si.exe
PASS: tset_sj.exe
PASS: tset_str.exe
PASS: tset_z.exe
PASS: tset_z_exp.exe
PASS: tsi_op.exe
PASS: tsin.exe
PASS: tsin_cos.exe
PASS: tsinh.exe
PASS: tsinh_cosh.exe
Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...);
expected: "0010610209857723, -1.2345678875e+07, 0.032258"
got: "0010610209857723, -1.2345678875e+07, 0.00"
FAIL: tsprintf.exe
PASS: tsqr.exe
PASS: tsqrt.exe
PASS: tsqrt_ui.exe
PASS: tstckintc.exe
PASS: tstdint.exe
Check overflow failed (3) with:
s=
x=0.100001110100111011100110011001100110011001101E24
FAIL: tstrtofr.exe
PASS: tsub.exe
PASS: tsub1sp.exe
PASS: tsub_d.exe
PASS: tsub_ui.exe
PASS: tsubnormal.exe
PASS: tsum.exe
PASS: tswap.exe
PASS: ttan.exe
PASS: ttanh.exe
PASS: ttrunc.exe
PASS: tui_div.exe
PASS: tui_pow.exe
PASS: tui_sub.exe
PASS: turandom.exe
PASS: tvalist.exe
PASS: ty0.exe
PASS: ty1.exe
PASS: tyn.exe
PASS: tzeta.exe
PASS: tzeta_ui.exe
[tversion] GMP: header 5.1.1, library 5.1.1
[tversion] MPFR tuning parameters from default
PASS: tversion.exe
On Sat, Mar 9, 2013 at 12:09 AM, Vincent Lefevre wrote:
> The release of GNU MPFR 3.1.2 ("canard à l'orange" patch level 2)
> is imminent. Please help to make this release as good as possible
> by downloading and testing this release candidate:
>
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.gz
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.zip
>
> The MD5's:
> 3a95e02c8dc2897638eb998da837e63a mpfr-3.1.2-rc1.tar.bz2
> a273dd7752039b8753e09afdd9f0506b mpfr-3.1.2-rc1.tar.gz
> d8019782b2d3007c60fd292856a59104 mpfr-3.1.2-rc1.tar.xz
> abb2a2fde5109219ab1bef2d55cb5742 mpfr-3.1.2-rc1.zip
>
> The SHA1's:
> 38b1cd6f6ab0190d4b991d4bcdb24d112c9f mpfr-3.1.2-rc1.tar.bz2
> 9a64b70a3d55c7f8a7faf81cf8f1ad74453dab3b mpfr-3.1.2-rc1.tar.gz
> 36d0de647a00527f88c762363e449fcfc6be1375 mpfr-3.1.2-rc1.tar.xz
> fc1b9df7a3779c115d1b4eb1aff5cc0f42b5307a mpfr-3.1.2-rc1.zip
>
> The signatures:
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz.asc
> http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2.asc
> http://www.mpfr.org/mpfr-3.1.
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
I use stable/v2.x of mingw-w64, not trunk. On Tue, Mar 12, 2013 at 4:43 PM, wrote: > > > -Original Message----- From: Dongsheng Song > Sent: Tuesday, March 12, 2013 2:25 PM > To: gcc@gcc.gnu.org ; m...@loria.fr > Subject: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate > > >> Test on x86_64-w64-mingw32, only tfprintf.exe, tprintf.exe, >> tsprintf.exe, and tstrtofr.exe FAILED, the other tests passed. > > > Why would those tests fail for your x86_64-w64-mingw32 build, but not for my > x86_64-w64-mingw32 build ? > What was the configure command that you ran ? > What version of MS Windows do you have ? > > Cheers, > Rob
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
On Tue, Mar 12, 2013 at 6:54 PM, wrote:
> You have in your test output:
>
>
> Error in mpfr_vsprintf (s, "%.*Zi, %R*e, %Lf", ...);
> expected: "0010610209857723, -1.2345678875e+07, 0.032258"
> got: "0010610209857723, -1.2345678875e+07, 0.00"
>
> That "0.00" for the "%Lf" usually indicates that the "%Lf" formatting is
> not supported.
> Is that the case here ? or did the test *really* arrive at a wrong
> answer of "0.00" ?
>
> With the (gcc-4.7.0) x86_64-w64-mingw32 compiler that I use, I need to first
> define __USE_MINGW_ANSI_STDIO if I want support for "%Lf" formatting:
>
> #
> C:\_32\C>type try.c
>
> #include
>
> int main(void) {
>
>long double x = 0.347L;
>printf("%Lf\n", x);
>
>return 0;
> }
>
>
> C:\_32\C>x86_64-w64-mingw32-gcc -o try.exe try.c
>
> C:\_32\C>try
> 0.00
>
> C:\_32\C>x86_64-w64-mingw32-gcc -o try.exe -D__USE_MINGW_ANSI_STDIO try.c
>
> C:\_32\C>try
> 0.347000
>
> C:\_32\C>
> #
>
> Is it the same for your compiler ?
Yes.
> Was __USE_MINGW_ANSI_STDIO defined when you built mpfr ? (It is *not*
> defined for my build - but I think configure detects that for me, and skips
> any tests that involve the "%Lf" format.)
>
> Cheers,
> Rob
>
Re: [MPFR] Re: GNU MPFR 3.1.2 Release Candidate
On Tue, Mar 12, 2013 at 8:02 PM, Zimmermann Paul wrote: >Hi Dongsheng, > >> > Is it the same for your compiler ? >> >> Yes. > > then you should define __USE_MINGW_ANSI_STDIO as pointed out by Rob. > Perfect, now all tests passed !
Re: r207119 - in /branches/gcc-4_7-branch/gcc: fort...
This broken gcc 4.7 build due to use C++ grammar in C source file:
static void
skip_list (int nest_level = 0)
{
...
}
gcc -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -Ifortran
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/fortran
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/../include
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/../libcpp/include
-I/home/cauchy/obj/i686-w64-mingw32-gcc47/gcc/./gmp
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gmp
-I/home/cauchy/obj/i686-w64-mingw32-gcc47/gcc/./mpfr
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/mpfr
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/mpc/src
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/../libdecnumber
-I/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/../libdecnumber/bid
-I../libdecnumber
/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/fortran/module.c
-o fortran/module.o
/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/fortran/module.c:3868:27:
error: expected ‘;’, ‘,’ or ‘)’ before ‘=’ token
/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/fortran/module.c:
In function
‘load_derived_extensions’:/home/cauchy/vcs/svn/gcc/branches/gcc-4_7-branch/gcc/fortran/module.c:4231:6:
warning: implicit declaration of function ‘skip_list’
[-Wimplicit-function-declaration]
make[2]: *** [fortran/module.o] Error 1
On Sun, Jan 26, 2014 at 10:49 PM, wrote:
>
> Author: mikael
> Date: Sun Jan 26 14:49:47 2014
> New Revision: 207119
>
> URL: http://gcc.gnu.org/viewcvs?rev=207119&root=gcc&view=rev
> Log:
> fortran/
> PR fortran/58007
> * module.c (fp2, find_pointer2): Remove.
> (mio_component_ref): Don't forcedfully set the containing derived type
> symbol for loading. Remove unused argument.
> (mio_ref): Update caller
> (skip_list): New argument nest_level. Initialize level with the new
> argument.
> (read_module): Add forced pointer components association for derived
> type symbols.
>
> testsuite/
> PR fortran/58007
> * gfortran.dg/unresolved_fixup_1.f90: New test.
> * gfortran.dg/unresolved_fixup_2.f90: New test.
>
>
> Added:
> branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_1.f90
> branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/unresolved_fixup_2.f90
> Modified:
> branches/gcc-4_7-branch/gcc/fortran/ChangeLog
> branches/gcc-4_7-branch/gcc/fortran/module.c
> branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
>
Re: GNU MPC 1.0 release candidate
Test on secondary gcc platform i686-w64-mingw32: ... GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: i686-w64-mingw32-gcc GCC: yes GCC version: 4.7.2 PASS: tget_version.exe === All 64 tests passed === Regards, Cauchy On Sat, Jul 7, 2012 at 11:13 PM, Andreas Enge wrote: > > We are pleased to announce the immediate availability of the first release > candidate for GNU MPC 1.0 at >http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz >sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 > > Reports on successful installations and potential problems are very > welcome; > please include the configuration triple of your platform, and the gcc, gmp > and mpfr versions used (these are output at the end of 'make check'). > > The status of successful and failed builds can be seen at >http://www.multiprecision.org/index.php?prog=mpc&page=platforms > > In particular, we need to compile on the primary and secondary gcc > platforms > before the release. > > Thank you very much for your help, > > Andreas
Re: GNU MPC 1.0 release candidate
Test on x86_64-w64-mingw32 : GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: i686-w64-mingw32-gcc -m64 GCC: yes GCC version: 4.7.2 PASS: tget_version.exe === All 64 tests passed === On Sat, Jul 7, 2012 at 11:13 PM, Andreas Enge wrote: > We are pleased to announce the immediate availability of the first release > candidate for GNU MPC 1.0 at >http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz >sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 > > Reports on successful installations and potential problems are very welcome; > please include the configuration triple of your platform, and the gcc, gmp > and mpfr versions used (these are output at the end of 'make check'). > > The status of successful and failed builds can be seen at >http://www.multiprecision.org/index.php?prog=mpc&page=platforms > > In particular, we need to compile on the primary and secondary gcc platforms > before the release. > > Thank you very much for your help, > > Andreas
Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call
gcc-4.2.3-RC-20080125 is OK, so it's a regress.
2008/1/28, Andrew Pinski <[EMAIL PROTECTED]>:
> 2008/1/27 Cauchy Song <[EMAIL PROTECTED]>:
> > $ uname -mrsp
> > OpenBSD 4.2 i386 Intel(R) Pentium(R) M processor 1.73GHz ("GenuineIntel"
> > 686-class)
>
> > ../../gcc-4.3-20080125/gcc/read-rtl.c: In function 'join_c_conditions':
> > ../../gcc-4.3-20080125/gcc/read-rtl.c:790: error: missing sentinel in
> > function call
>
> We have:
> result = concat ("(", cond1, ") && (", cond2, ")", NULL);
>
>
> So I think this is a bug in openbsd's headers.
>
> Thanks,
> Andrew Pinski
>
BUG in libstdc++-v3/config/os/generic/error_constants.h
snip libstdc++-v3/config/os/generic/error_constants.h not_supported = ENOTSUP, snip libstdc++-v3/config/os/generic/error_constants.h OpenBSD 4.2 not defined ENOTSUP, only EOPNOTSUPP ! snip /usr/include/sys/errno.h #define EOPNOTSUPP 45 /* Operation not supported */ snip /usr/include/sys/errno.h This affect gcc 4.3/trunk only. Maybe we should add a new file libstdc++-v3/config/os/bsd/openbsd/error_constants.h like mingw32 ? Dongsheng
[gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call
See: http://www.linuxonly.nl/docs/2/0_Page_1.html
It's very clear, you should use a type cast:
result = concat ("(", cond1, ") && (", cond2, ")", (char *)NULL);
instead of:
result = concat ("(", cond1, ") && (", cond2, ")", NULL);
Dongsheng
2008/1/29, Kaveh R. GHAZI <[EMAIL PROTECTED]>:
> On Sun, 27 Jan 2008, Andrew Pinski wrote:
>
> > 2008/1/27 Cauchy Song <[EMAIL PROTECTED]>:
> > > $ uname -mrsp
> > > OpenBSD 4.2 i386 Intel(R) Pentium(R) M processor 1.73GHz ("GenuineIntel"
> > > 686-class)
> >
> > > ../../gcc-4.3-20080125/gcc/read-rtl.c: In function 'join_c_conditions':
> > > ../../gcc-4.3-20080125/gcc/read-rtl.c:790: error: missing sentinel in
> > > function call
> >
> > We have:
> > result = concat ("(", cond1, ") && (", cond2, ")", NULL);
> >
> >
> > So I think this is a bug in openbsd's headers.
> > Andrew Pinski
>
>
> It would be helpful to receive preprocessed source code with the compiler
> options to trigger the bug. See http://gcc.gnu.org/bugs.html#report
> for details on what to send, and what not to send, in a proper bug report.
>
> As Andrew pointed out, since the concat call here is NULL terminated, the
> problem is likely not in GCC sources. But the .i file would show for
> sure.
>
> Thanks,
> --Kaveh
> --
> Kaveh R. Ghazi [EMAIL PROTECTED]
>
Results for 4.3.0 20080125 (experimental) (GCC) testsuite on i386-unknown-openbsd4.2
LAST_UPDATED: Obtained from SVN: trunk revision 131847
Native configuration is i386-unknown-openbsd4.2
=== g++ tests ===
Running target unix
FAIL: g++.dg/cpp/_Pragma1.C (test for excess errors)
FAIL: g++.dg/cpp0x/vt-34103.C (internal compiler error)
FAIL: g++.dg/cpp0x/vt-34103.C (test for excess errors)
FAIL: g++.dg/eh/gcsec1.C (test for excess errors)
FAIL: g++.dg/ext/complit4.C (test for excess errors)
WARNING: g++.dg/ext/complit4.C compilation failed to produce executable
FAIL: g++.dg/init/cleanup3.C scan-assembler-not _tcf
FAIL: g++.dg/opt/mmx2.C (test for excess errors)
FAIL: g++.dg/other/i386-1.C (test for excess errors)
WARNING: g++.dg/other/i386-1.C compilation failed to produce executable
FAIL: g++.dg/other/i386-2.C (test for excess errors)
FAIL: g++.dg/other/mmintrin.C (test for excess errors)
FAIL: g++.dg/other/offsetof1.C (test for excess errors)
FAIL: g++.dg/other/offsetof2.C (test for excess errors)
FAIL: g++.dg/other/offsetof2.C execution test
FAIL: g++.dg/other/pr34435.C (test for excess errors)
FAIL: g++.dg/parse/offsetof1.C (test for excess errors)
FAIL: g++.dg/parse/offsetof2.C (test for excess errors)
FAIL: g++.dg/template/offsetof1.C (test for excess errors)
WARNING: program timed out.
FAIL: g++.dg/pch/externc-1.C (test for excess errors)
WARNING: program timed out.
FAIL: g++.dg/pch/pch.C (test for excess errors)
ERROR: (DejaGnu) proc "bgerror {write(spawn_id=2): broken pipe}" does not exist.
FAIL: g++.dg/pch/uninst.C (test for excess errors)
ERROR: tcl error sourcing
/home/dongsheng/wc/tmp/gcc-4.3-20080125/gcc/testsuite/g++.dg/pch/pch.exp.
=== gcc tests ===
Running target unix
FAIL: gcc.c-torture/execute/20071018-1.c execution, -O0
FAIL: gcc.c-torture/execute/20071018-1.c execution, -O1
FAIL: gcc.c-torture/execute/20071018-1.c execution, -O2
FAIL: gcc.c-torture/execute/20071018-1.c execution, -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/20071018-1.c execution, -O3 -g
FAIL: gcc.c-torture/execute/20071018-1.c execution, -Os
FAIL: gcc.c-torture/execute/990127-2.c execution, -O2
FAIL: gcc.c-torture/execute/990127-2.c execution, -Os
FAIL: gcc.dg/cpp/Wmissingdirs.c (internal compiler error)
FAIL: gcc.dg/cpp/Wmissingdirs.c -Wmissing-include-dirs (test for warnings, line
)
FAIL: gcc.dg/cpp/Wmissingdirs.c (test for excess errors)
FAIL: gcc.dg/cpp/_Pragma6.c (test for excess errors)
FAIL: gcc.dg/20050105-2.c (test for excess errors)
FAIL: gcc.dg/bitfld-12.c (test for errors, line 10)
FAIL: gcc.dg/bitfld-12.c (test for excess errors)
FAIL: gcc.dg/builtins-20.c (test for excess errors)
FAIL: gcc.dg/builtins-57.c (test for excess errors)
FAIL: gcc.dg/builtins-58.c scan-assembler-not pow
FAIL: gcc.dg/builtins-59.c scan-tree-dump gimple "__builtin_cexpi"
FAIL: gcc.dg/builtins-59.c scan-tree-dump-not gimple "sincos"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "cexpi"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "sin"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "cos"
FAIL: gcc.dg/builtins-61.c scan-tree-dump optimized "return 0.0"
FAIL: gcc.dg/builtins-62.c scan-tree-dump-times optimized "cexpi" 3
FAIL: gcc.dg/c99-float-1.c (test for excess errors)
FAIL: gcc.dg/c99-tgmath-1.c (test for excess errors)
FAIL: gcc.dg/c99-tgmath-2.c (test for excess errors)
ERROR: gcc.dg/c99-tgmath-2.c: error executing dg-final: couldn't open
"c99-tgmath-2.s": no such file or directory
UNRESOLVED: gcc.dg/c99-tgmath-2.c: error executing dg-final: couldn't open
"c99-tgmath-2.s": no such file or directory
FAIL: gcc.dg/c99-tgmath-3.c (test for excess errors)
ERROR: gcc.dg/c99-tgmath-3.c: error executing dg-final: couldn't open
"c99-tgmath-3.s": no such file or directory
UNRESOLVED: gcc.dg/c99-tgmath-3.c: error executing dg-final: couldn't open
"c99-tgmath-3.s": no such file or directory
FAIL: gcc.dg/c99-tgmath-4.c (test for excess errors)
ERROR: gcc.dg/c99-tgmath-4.c: error executing dg-final: couldn't open
"c99-tgmath-4.s": no such file or directory
UNRESOLVED: gcc.dg/c99-tgmath-4.c: error executing dg-final: couldn't open
"c99-tgmath-4.s": no such file or directory
FAIL: gcc.dg/initpri1.c execution test
FAIL: gcc.dg/single-precision-constant.c (test for excess errors)
FAIL: gcc.dg/single-precision-constant.c execution test
FAIL: gcc.dg/va-arg-2.c In file included from (test for warnings, line 6)
FAIL: gcc.dg/va-arg-2.c #error 1 (test for errors, line 4)
FAIL: gcc.dg/va-arg-2.c #error 2 (test for errors, line 5)
FAIL: gcc.dg/wint_t-1.c (test for excess errors)
FAIL: gcc.dg/format/array-1.c (test for excess errors)
FAIL: gcc.dg/format/array-1.c (test for excess errors)
FAIL: gcc.dg/format/asm_fprintf-1.c (test for excess errors)
FAIL: gcc.dg/format/asm_fprintf-1.c (test for excess errors)
FAIL: gcc.dg/format/attr-1.c (test for excess errors)
FAIL: gcc.dg/format/attr-1.c (test for excess errors)
FAIL: gcc.dg/format/attr-2.c (test for excess errors)
FAIL: gcc.dg/format/attr-2.c (test for excess errors)
FAIL: gcc.dg/format/attr-3.c (test
Re: [gcc-4.3-20080125] Bootstrap failure on i386-unknown-openbsd4.2: missing sentinel in function call
But the current xgcc in gcc 4.3 building issue the warning yet. 2008/1/31, Andrew Pinski <[EMAIL PROTECTED]>: > On Jan 30, 2008 7:38 PM, Dongsheng Song <[EMAIL PROTECTED]> wrote: > > See: http://www.linuxonly.nl/docs/2/0_Page_1.html > > > It says: > This is because NULL is not of the right type: it is defined as > integer 0 instead of a pointer with the value 0. > > Except that is wrong from what the C99 standard says about the NULL macro: > The macros are > NULL > which expands to an implementation-defined null pointer constant > > So no casting is needed as it is already a pointer type if we follow > the C99 standard (I think C90 says the same thing except I don't have > C90 in front of me). > > Thanks, > > Andrew Pinski >
Re: Results for 4.3.0 20080125 (experimental) (GCC) testsuite on i386-unknown-openbsd4.2
Sorry for my mail conf.
Building & test as:
$ mkdir obj && cd obj
$ bash ../gcc-4.3-20080125/configure --prefix=/usr/local/gcc-4.3.x \
--enable-languages=c,c++,fortran \
--with-gmp=/usr/local --with-mpfr=/usr/local
$ gmake CFLAGS='-O2 -pipe' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' bootstrap
$ sudo gmake install && gmake -k check
patch as attachment.
Dongsheng
2008/1/31, Dongsheng Song <[EMAIL PROTECTED]>:
> LAST_UPDATED: Obtained from SVN: trunk revision 131847
>
> Native configuration is i386-unknown-openbsd4.2
>
> === gcc Summary ===
>
> # of expected passes48932
> # of unexpected failures341
> # of unexpected successes 1
> # of expected failures 164
> # of unresolved testcases 14
> # of untested testcases 78
> # of unsupported tests 412
> /home/dongsheng/wc/tmp/obj/gcc/xgcc version 4.3.0 20080125 (experimental)
> (GCC)
>
>
> Compiler version: 4.3.0 20080125 (experimental) (GCC)
> Platform: i386-unknown-openbsd4.2
> configure flags: --prefix=/usr/local/gcc-4.3.x
> --enable-languages=c,c++,fortran --with-gmp=/usr/local --with-mpfr=/usr/local
>
diff -udr -x contrib gcc-4.3-20080125.orig/gcc/builtins.c gcc-4.3-20080125/gcc/builtins.c
--- gcc-4.3-20080125.orig/gcc/builtins.c Thu Dec 6 21:25:37 2007
+++ gcc-4.3-20080125/gcc/builtins.c Tue Jan 29 05:21:15 2008
@@ -12729,13 +12729,13 @@
int inexact;
mpfr_t m1, m2;
- mpfr_inits2 (prec, m1, m2, NULL);
+ mpfr_inits2 (prec, m1, m2, (char *)NULL);
mpfr_from_real (m1, ra1, GMP_RNDN);
mpfr_from_real (m2, ra2, GMP_RNDN);
mpfr_clear_flags ();
inexact = func (m1, m1, m2, GMP_RNDN);
result = do_mpfr_ckconv (m1, type, inexact);
- mpfr_clears (m1, m2, NULL);
+ mpfr_clears (m1, m2, (char *)NULL);
}
}
@@ -12775,14 +12775,14 @@
int inexact;
mpfr_t m1, m2, m3;
- mpfr_inits2 (prec, m1, m2, m3, NULL);
+ mpfr_inits2 (prec, m1, m2, m3, (char *)NULL);
mpfr_from_real (m1, ra1, GMP_RNDN);
mpfr_from_real (m2, ra2, GMP_RNDN);
mpfr_from_real (m3, ra3, GMP_RNDN);
mpfr_clear_flags ();
inexact = func (m1, m1, m2, m3, GMP_RNDN);
result = do_mpfr_ckconv (m1, type, inexact);
- mpfr_clears (m1, m2, m3, NULL);
+ mpfr_clears (m1, m2, m3, (char *)NULL);
}
}
@@ -12819,13 +12819,13 @@
int inexact;
mpfr_t m, ms, mc;
- mpfr_inits2 (prec, m, ms, mc, NULL);
+ mpfr_inits2 (prec, m, ms, mc, (char *)NULL);
mpfr_from_real (m, ra, GMP_RNDN);
mpfr_clear_flags ();
inexact = mpfr_sin_cos (ms, mc, m, GMP_RNDN);
result_s = do_mpfr_ckconv (ms, type, inexact);
result_c = do_mpfr_ckconv (mc, type, inexact);
- mpfr_clears (m, ms, mc, NULL);
+ mpfr_clears (m, ms, mc, (char *)NULL);
if (result_s && result_c)
{
/* If we are to return in a complex value do so. */
@@ -12933,7 +12933,7 @@
long integer_quo;
mpfr_t m0, m1;
- mpfr_inits2 (prec, m0, m1, NULL);
+ mpfr_inits2 (prec, m0, m1, (char *)NULL);
mpfr_from_real (m0, ra0, GMP_RNDN);
mpfr_from_real (m1, ra1, GMP_RNDN);
mpfr_clear_flags ();
@@ -12941,7 +12941,7 @@
/* Remquo is independent of the rounding mode, so pass
inexact=0 to do_mpfr_ckconv(). */
result_rem = do_mpfr_ckconv (m0, type, /*inexact=*/ 0);
- mpfr_clears (m0, m1, NULL);
+ mpfr_clears (m0, m1, (char *)NULL);
if (result_rem)
{
/* MPFR calculates quo in the host's long so it may
diff -udr -x contrib gcc-4.3-20080125.orig/gcc/c-aux-info.c gcc-4.3-20080125/gcc/c-aux-info.c
--- gcc-4.3-20080125.orig/gcc/c-aux-info.c Thu Aug 9 06:29:12 2007
+++ gcc-4.3-20080125/gcc/c-aux-info.c Tue Jan 29 04:55:25 2008
@@ -90,14 +90,14 @@
add a blank after the data-type of course. */
if (p == type_or_decl)
-return concat (data_type, " ", type_or_decl, NULL);
+return concat (data_type, " ", type_or_decl, (char *)NULL);
saved = *p;
*p = '\0';
- qualifiers_then_data_type = concat (type_or_decl, data_type, NULL);
+ qualifiers_then_data_type = concat (type_or_decl, data_type, (char *)NULL);
*p = saved;
return reconcat (qualifiers_then_data_type,
- qualifiers_then_data_type, " ", p, NULL);
+ qualifiers_then_data_type, " ", p, (char *)NULL);
}
/* Given a tree node which represents some "function type", generate the
@@ -122,13 +122,13 @@
const char *this_type;
if (*formal_list)
- formal_list = concat (formal_list, ", ", NULL);
+ formal_list = concat (formal_list, ", ", (char *)NULL);
this_type = gen_type ("", TREE_VALUE (formal_type), ansi);
formal_list
= ((strlen (this_type))
- ? concat (formal_list, affix_data_type (this_type), NULL)
- : concat (formal_list, data_type, NULL));
+
Re: Results for 4.3.0 20080125 (experimental) (GCC) testsuite on i386-unknown-openbsd4.2
NO. If no "--disable-werror" option, bootstrap will fail. So I use a type cast, no very care about the pointer type. 2008/2/1, Vincent Lefevre <[EMAIL PROTECTED]>: > On 2008-01-31 11:59:32 +0800, Dongsheng Song wrote: > > - mpfr_inits2 (prec, m1, m2, NULL); > > + mpfr_inits2 (prec, m1, m2, (char *)NULL); > > Is there any reason to use (char *) instead of (void *)? > > Note that m1 and m2 are MPFR pointers (mpfr_ptr type, which is in > the reality __mpfr_struct * but that's internal). > > -- > Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> > 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> > Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) >
Re: GCC 4.3.0 Status Report (2008-02-14)
g++ 4.3 broken on OpenBSD, see: http://gcc.gnu.org/ml/libstdc++/2008-02/msg00034.html Dongsheng 2008/2/14, Jakub Jelinek <[EMAIL PROTECTED]>: > Status > == > > We are in Stage 3 and the trunk is open for regression and documentation > fixes only. We have reached our goal of zero open P1 regressions (in fact > several times, but each time different P1s appeared), so 4.3.0 release > candidate will be created early next week. There is still time to get > important bugfixes into the release candidate. On Monday > branches/gcc-4_3-branch will be created, and the trunk subsequently open for > Stage 1 of 4.4. 4.3 branch will be afterwards frozen until the release > candidate is created, any changes to the branch will require RM approval. > > Quality Data > > > Progress has been made over the last 2.5 weeks, on P1 regressions > as well as P2 regressions. > > Priority # Change from Last Report > -- --- > P1 0- 2 > P2 74- 14 > P3 4+ 2 > - -- --- > Total 78- 14 > > There are still 38 P4 and 91 P5 regressions, this is the last chance to get > them fixed before the release candidate. > > Previous Report > === > > http://gcc.gnu.org/ml/gcc/2008-01/msg00507.html >
Re: New x86-64 micro-architecture levels
I fully agree these names (100/101, A/B/C/D) are not very intuitive, I recommend using isa tags by year (e.g. x64_2010, x64_2014) like the python's platform tags (e.g. manylinux2010, manylinux2014).
