This patch has now been committed.
It breaks bootstap on x86_64-apple-darwin14:
...
make[3]: Entering directory `/opt/gcc/p_build/libcc1'
make all-am
make[4]: Entering directory `/opt/gcc/p_build/libcc1'
make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', needed by
Seems removing that makes the configure.ac change unneeded.
Bootstrapped/regtested on x86_64-linux and i686-linux (libcc1
is built after compare, by stage3 compiler), and built
with --disable-bootstrap on i686-linux (libcc1 is built by
the system compiler in that case). Ok for trunk?
This patch fixes pr44735 and pr60593. Otherwise I have regstrapped the
three patches without regression.
Thanks,
Dominique
I've committed the patch now.
It (r214840) breaks bootstrap on darwin:
...
/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.3.0/bin/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.3.0/lib/ -isystem
/opt/gcc/gcc4.10w/x86_64-apple-darwin13.3.0/include
does this fix it?
The answer after a quick update is yes, further testing scheduled for
tonight.
Thanks,
Dominique
On Thu, Sep 4, 2014 at 6:15 PM, Joseph S. Myers jos...@codesourcery.com wrote:
gcc/c-family:
2014-09-05 Joseph Myers jos...@codesourcery.com
* c-cppbuiltin.c (c_cpp_builtins): Also define
__LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
__LIBGCC_EH_FRAME_SECTION_NAME__,
...
I believe the above hunk in r214954 ...
... broke the build for the
following configurations in contrib/config-list.mk: ...
See pr63188 for darwin. The same patch should probably
fix the problem for hppa64-hpux* too.
Dominique
Perhaps it would be safer simply to revert that hunk of the original patch
unless/until (1) and (2) above are addressed?
Given that the original patch addresses 'only' a missed-optimization
(and causes ice-on-valid), it makes sense to me.
(1) Iain already asked the questions more than two
On darwin I get
FAIL: gcc.target/i386/fentry-override.c (test for excess errors)
UNRESOLVED: gcc.target/i386/fentry-override.c scan-assembler-not __fentry__
FAIL: gcc.target/i386/fentry.c (test for excess errors)
UNRESOLVED: gcc.target/i386/fentry.c scan-assembler __fentry__
with -m32. The
AFAICT the lines 11200-11222 in gcc/fortran/resolve.c are a copy of
the lines 11176-11198. The following patch removes the duplicated
lines. OK for the trunk?
Dominique
--- ../_clean/gcc/fortran/resolve.c 2014-09-20 13:56:57.0 +0200
+++ gcc/fortran/resolve.c 2014-09-20
r194221
It breaks bootstrap on x86_64-apple-darwin10:
/opt/gcc/build_a/./gcc/xg++ -B/opt/gcc/build_a/./gcc/ -nostdinc++ -nostdinc++
-I/opt/gcc/build_a/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/opt/gcc/build_a/x86_64-apple-darwin10.8.0/libstdc++-v3/include
The attached patch fixes a regression introduced on the trunk to ...
This breaks bootstrap on x86_64-apple-darwin10:
../../work/gcc/varasm.c:2094:13: error: 'pending_assemble_externals_processed'
defined but not used [-Werror=unused-variable]
static bool pending_assemble_externals_processed;
Hi jack,
+// { dg-skip-if Darwin lacks RLIMIT_AS in setrlimit { *-*-darwin* } }
The comment is not fully accurate. See pr55679 comment #17 for some analysis
and another candidate patch for rlimit-mmap-test-1.c (it will detect any fix
by Apple).
Cheers,
Dominique
I have just built gcc 4.6.4 r194560 and I see the following warnings:
../../p6_work/gcc/varasm.c:2107:30: warning: 'pending_assemble_externals_set'
defined but not used [-Wunused-variable]
../../p6_work/gcc/varasm.c:2112:13: warning:
'pending_assemble_externals_processed' defined but not used
Dear Paul,
With your patch applied on top of a clean revision 194590, the executable
for unlimited_polymorphic_1.f03 gives a Segmentation fault -
invalid memory reference at
Program received signal SIGSEGV, Segmentation fault.
0x00011d1c in MAIN__ () at
Dear Paul,
Apparently you have forgotten to commit the update for
same_type_as_1.f03.
Dominique
I think revision 194665 breaks bootstrap on at least x86_64-apple-darwin10:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros
That doesn't make much sense. What do the lines around this look like?
I am currently bootstrapping r194675 with revision 194665 reverted.
The diff between gcc/auto-host.h with(-)/without(+) r194665 reverted
and --enable-checking=release for (+) looks like:
--- ../build_w/gcc/auto-host.h
I think I understand at least part of the problem:
(1) I configure gcc with
../work/configure --prefix=/opt/gcc/gcc4.8w
--enable-languages=c,c++,fortran,objc,obj-c++,java,ada,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
--enable-build-with-cxx
i.e.,
The following patch allowed me to proceed for c,c++,lto,fortran,ada,objc,obj-c++
up to libada which has the same problem:
--- ../_clean/gcc/configure 2012-12-20 17:19:54.0 +0100
+++ ../p_work/gcc/configure 2012-12-21 23:44:46.0 +0100
@@ -10321,9 +10321,9 @@ $as_echo
Sorry for the late and lengthy answer. To make the story short, I think
the decision to remove -fno-whole-file should be based on the answer to the
following questions:
(1) Is there any hint of -fno-whole-file misbehavior (as suggested by the
second point of the Reasoning)?
As said in my
Hi,
AFAIU the regexps, they are not doing what they are supposed to do
on powerpc-apple-darwin9: the assembly reads
fmr f1,f0
i.e., fmr \[0-9\]+ or fmr 1 are never found.
If I use fmr f?\[0-9\]+,f?\[0-9\]+, then the test fails,
in line with the other powerpc.
If I use lfd
PS. IIRC some previous discussions around such darwin peculiarities
the f? decoration may be too simplistic to cover all the powerpc
flavors (A. Pinski may know better).
I have found the links for that: r168960 (pr41146). A. Pinski asked to
add %?. I don't know which ppc platform uses it and
In order to bootstrap r195167 with the new ISL/CLooG versions,
I had to apply the following patch:
--- ../work/configure 2013-01-14 19:32:00.0 +0100
+++ configure 2013-01-14 19:42:15.0 +0100
@@ -5848,7 +5848,7 @@ else
int
main ()
{
-if (strncmp (isl_version (), isl-0.10,
Jack,
How exactly did you test this? I am using isl 0.11.1 and cloog 0.18.0 from
fink
installed in /sw out of tree. This fails in config.log as...
Same here (the libs are not in /sw but in /mp) and I got the same errors before
I did the changed in my previous post.
Dominique
Jack,
Without the change for isl, I get at configure time:
-g -O2 -I/opt/mp/include -I/opt/mp/include
checking for version 0.10 of ISL... no
-g -O2 -I/opt/mp/include -I/opt/mp/include
checking for version 0.11 of ISL... (cached) no
configure: error: Unable to find a usable ISL. See config.log
FAIL: g++.dg/tls/thread_local-wrap3.C scan-assembler _ZTH1i
FAIL: g++.dg/gomp/tls-wrap3.C -std=c++98 scan-assembler _ZTH1i
FAIL: g++.dg/gomp/tls-wrap3.C -std=c++11 scan-assembler _ZTH1i
Ah, yes; those are specifically testing for the aliases that we can't
generate on darwin. I'll add
Of course, that should be PR 50627 in the ChangeLog.
I think you need both PR 50627 and 56054.
The patch fixes these PRs, full testing in progress.
Dominique
Tobias,
AFAICT, the links in
Additionally, the GNU Fortran compilers supports the OpenMP specification
(version 3.1, @url{http://openmp.org/@/wp/@/openmp-specifications/}).
@@ -545,6 +546,10 @@ for them, which work with GNU Fortran. They can be found
at
I just finished a clean bootstrap of r195576 with your patch.
I have used it to clean the XPASS of gfortran.dg/do_1.f90 for -O0
and -O1 with the following patch:
--- /opt/gcc/_clean/gcc/testsuite/gfortran.dg/do_1.f90 2012-10-18
20:35:25.0 +0200
+++
Tobias,
Might be in the PDF version (untested), but they do work in the HTML
version at http://gcc.gnu.org/onlinedocs/gfortran/Standards.html
I think my mistake was to use the links as they appear at
http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01446.html
I was biased because I have found that
The test fails on x86_64-apple-darwin10 with
FAIL: 18_support/quick_exit/quick_exit.cc (test for excess errors)
Excess errors:
/opt/gcc/work/libstdc++-v3/testsuite/18_support/quick_exit/quick_exit.cc:36:3:
error: 'at_quick_exit' is not a member of 'std'
IIRC I have already asked a similar question about atan2, erf, ...
which don't appear in the std namespace on darwin.
Dominique
But the last time I checked, modern darwin defined
_GLIBCXX_USE_C99_MATH_TR1, no problems.
AFAICT this is true, but I think darwin10 was released in 2011
so I doubt it has any support for c++11.
Anyway, about the cstdlib issue the below makes available the new
functions in c_std/cstdlib
Hi jason,
The test g++.dg/cpp0x/lambda/lambda-this8.C fails on x86_64-apple-darwin10:
FAIL: g++.dg/cpp0x/lambda/lambda-this8.C -std=c++11 (test for excess errors)
Excess errors:
/opt/gcc/work/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this8.C:6:31: error:
declaration of 'void abort() throw ()'
Paolo,
The test 26_numerics/random/binomial_distribution/operators/values.cc fails
on *-apple-darwin* (see
http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01893.html)
with
[macbook] f90/bug% g++47
Rainer,
Ignore my previous comment: I just saw the quotes on the other changed
lines.
Thanks for the commit.
Dominique
Just guessing at the numbers, does the following patch fix the
failures for you?
As I am currently bootstrapping gcc, I cannot regtest right now, but running the
test manually I get 256 at -m32 (I guess this is right) while I get 272 at -m64
(so the test will fail).
Dominique
Ok, slightly updated. How about this? ...
It did not work either at -m64, but the following one seems to work
(manual testing):
--- /opt/gcc/_gcc_clean/gcc/testsuite/gcc.dg/stack-usage-1.c2011-03-28
20:27:57.0 +0200
+++ /opt/gcc/work/gcc/testsuite/gcc.dg/stack-usage-1.c
Michael,
I have applied your patch on top of revision 172217 on
x86_64-apple-darwin10.7.0.
So far I have only limited tests on the polyhedron test suite.
The test nf.f90 (containing an automatic array) executes in less than 20s,
compares
to ~28s without the patch. However capacita.f90 is
I find that both nf.f90 and capacita.f90 segfault in runtime for any stack
size.
On x86_64-apple-darwin10, nf.f90 works. However if I run it through
valgrind I get
==64815== Memcheck, a memory error detector
==64815== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==64815==
I am trying the new patch. Updating failed with
../../work/gcc/fortran/trans-array.c: In function
'gfc_trans_auto_array_allocation':
../../work/gcc/fortran/trans-array.c:4881:24: error: 'tmp' may be used
uninitialized in this function [-Werror=uninitialized]
cc1: all warnings being treated as
The resulting speed up for nf.f90 is rather remarkable. What specific
feature of the fortran leads to a 30=15s ?
I think it is the automatic array in the subroutine trisolve. Note that the
speedup is rather 27-19s and may be darwin specific (slow malloc).
Note also that -fstack-arrays
I have opened PR48590 for at least one issue that I see. ...
The fix for pr48590 (r172427) does not speedup fatigue.f90 compiled
with -fstack-arrays.
Dominique
Eric,
I am not sure to understand the sentence:
There is apparently an ACATS failure on x86-64/Darwin, but I've installed the
testcase as gnat.dg/opt19.adb in the tree.
The only failure I had was pr50433, now fixed by revision 179046. With it,
all the ADA tests pass (including
I'm hoping the graphite people have an even a better idea... If not, Ok.
I have filed pr50023 two month ago CCing Sebastian Pop asking the question:
Why not on powerpc? and I have the patch (comment#2) since over a month.
I think that if the graphite people have an even a better idea, they had
I don't know enough about Fortran to know whether the same issues arise
there. Perhaps in Fortran a common symbol is always a common symbol and
can never be a defined symbol. If that is the case then for Fortran I
think it would be safe to change the alignment of the common symbol. Of
The testcase failed with ...
It is fixed by the following patch
--- ../_clean/gcc/testsuite/gfortran.dg/public_private_module_3.f90
2012-04-15 11:18:00.0 +0200
+++ gcc/testsuite/gfortran.dg/public_private_module_3.f90 2012-04-15
19:09:10.0 +0200
@@ -58,3 +58,4 @@
Alternatively you could put the static assertion with the comment
into the l field, i.e.
/* Statically assert that N is 2 or 4. */
unsigned long l[(N == 2 || N == 4) ? N : -1];
I certainly prefer this alternative (the use of extern for that purpose
being extremely confusing
Dear Mikael,
Your set of patches works as defined, i.e., it fixes pr45586 without
regression on the test suite. However, If the test suite is run with
-flto, there are still some failures depending on the way gcc is
configured.
Configured with: ../p_work/configure
... In the meantime is it by any chance better if the first patch in the serie
is replaced by the attached one?
With the new patch for trans-expr.c (keeping those for
trans-types.c and trans.h), typebound_proc_27.f03 -flto -O
now works, but not class_array_7.f03 nor the other tests
I have tried
With the modified patch, gfortran.dg/restrict_type_compat_1.f90 fails
for a regular test:
FAIL: gfortran.dg/restrict_type_compat_1.f90 -O scan-tree-dump-times
original VIEW_CONVERT_EXPR 13
A manual check shows only 6 instances of VIEW_CONVERT_EXPR.
Cheers,
Dominique
Oleg,
Bootstrap fails at revision 190996 on powerpc-apple-darwin9 with:
g++ -c -g -DIN_GCC -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common
Could you please commit this (I can't at the moment)?
Sorry, I don't have write access.
Dominique
Also, Jack, why is the variable called ac_cv_x86_rdrand rather than
glibcxx_x86_rdrand to be consistent with every other variable in
libstdc++-v3/acinclude.m4? And why _GLIBCXX_X86_RDRAND not something
like _GLIBCXX_HAVE_AS_X86_RDRAND? The bootstrap failure is fixed, but
Although I cannot
Fixed with the attached.
Followed by the same failure on darwin. Fixed with
--- ../_clean/gcc/config/darwin.c 2012-07-09 22:06:21.0 +0200
+++ ../p_work/gcc/config/darwin.c 2012-09-11 11:53:02.0 +0200
@@ -1878,7 +1878,7 @@ darwin_asm_named_section (const char *na
This is ok, of course.
Then could you please commit it (I don't have write access)?
TIA
Dominique
I have regstapped r187893 with the following patch
[karma] gcc/darwin_buildw% diff -up ../_gcc_clean/libcpp/lex.c
../work/libcpp/lex.c
--- ../_gcc_clean/libcpp/lex.c 2012-05-25 08:54:05.0 +0200
+++ ../work/libcpp/lex.c2012-05-27 13:25:08.0 +0200
@@ -592,7 +592,8 @@
Alan,
I think the following patch
--- ../_gcc_clean/gcc/testsuite/gcc.target/powerpc/powerpc.exp 2012-05-02
14:25:40.0 +0200
+++ ../work/gcc/testsuite/gcc.target/powerpc/powerpc.exp2012-05-29
21:14:48.0 +0200
@@ -47,4 +47,5 @@ set-torture-options $SAVRES_TEST_OPTS
Yes indeed, and it would be wise to ensure torture-options.exp is
loaded too. I'm committing the following as obvious.
Thanks
Hmm, this will be because darwin is PIC by default. Does adding
-static to the dg-options line in savres.c fix the darwin fail?
With the following change
---
Please try out this patch on Darwin. Bootstrapped and regression
tested powerpc-linux.
I have applied the patch to r188026 and updated the build.
As patched the test gcc.target/powerpc/savres.c now fails with
FAIL: gcc.target/powerpc/savres.c (test for excess errors)
Excess errors:
This is really stretching my testsuite knowledge. Maybe add
/* { dg-additional-options -mdynamic-no-pic { target *-*-darwin* } } */
Using
/* { dg-options -fno-inline -fomit-frame-pointer } */
/* { dg-additional-options -mdynamic-no-pic { target *-*-darwin* } } */
works for me on
Back when we added C++11 auto deduction, I thought we could shortcut the
normal deduction in some templates, when the type is adequately
describable (thus the late, unlamented function describable_type). Over
time various problems with this have arisen, of which this is the most
recent; as a
Hi,
Before revision 188728, the test gcc.dg/tree-ssa/vrp68.c failed
because link_error appeared twice in the dump file.
After r188728 it fails also at link time and link_error appears
three time:
FAIL: gcc.dg/tree-ssa/vrp68.c (test for excess errors)
Excess errors:
Undefined symbols:
On Tue, 19 Jun 2012, Richard Guenther wrote:
Richard Guenther rguent...@suse.de writes:
We are too eager to bump alignment of some decls when vectorizing.
The fix is to not bump alignment of decls the user explicitely
aligned or that are used in an unknown way.
I thought
Did you mean to put a bugzilla link here?
Yes;-( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53565
copy and paste from the wrong window).
Dominique
Does this make sense to you?
I cannot answer the question, but the patch survived clean bootstrap on
x86_64-apple-darwin10 and powerpc-apple-darwin9 and a full regtest
on the former with the following new failures between r188841 and
r188858:
FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[
This (r188876) breaks bootstrap:
see http://gcc.gnu.org/ml/gcc-regression/2012-06/msg00311.html
/export/gnu/import/git/gcc-test-intel64corei7/bld/./prev-gcc/g++
-B/export/gnu/import/git/gcc-test-intel64corei7/bld/./prev-gcc/
-B/usr/local/x86_64-unknown-linux-gnu/bin/ -nostdinc++
As I don't have access to a Darwin machine to test a fix, would you
mind updating the test?
The failures are gone with the obvious patch:
diff -up ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c
gcc/testsuite/gcc.dg/pubtypes-2.c
--- ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c 2009-11-25
Hi Tobias,
I am puzzled by the subject: the test gfortran.dg/c_f_pointer_shape_tests_5.f90
does
not need the patch to succeed (at least after 4.5.3, it fails only for 4.4.6).
Note that the similar test in
http://gcc.gnu.org/ml/fortran/2012-04/msg00115.html
fails because c_f_pointer(x, ptr,
Mikael,
There is a typo in your test gfortran.dg/inline_sum_4.f90:
arr(1, :, :, = should be arr(1, :, :, :) =.
Thanks for the patch.
Dominique
Mikael,
After the previous fix, the test fails with
real*8 arr(4, 4, 4, 4)
1
Warning: Nonstandard type declaration REAL*8 at (1)
Replacing
real*8 arr(4, 4, 4, 4)
with
real(8) :: arr(4, 4, 4, 4)
fixes the failures (due to the compilation with -pedantic-errors).
Dominique
Request for testing because I have no access to a Darwin machine.
I just finished a clean bootstrap with the (second!-) patch on
x86_64-apple-darwin10; regtesting scheduled for tonight.
Bootstrapping powerpc-apple-darwin9 is now at stage 2.
Dominique
PS AFAICT pr26840 is indeed fixed.
Hi Sterling,
On x86_64-apple-darwin10 the test fails with
FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler .section\t.debug_pubnames
FAIL: g++.dg/debug/dwarf2/pubnames-2.C scan-assembler
_GLOBAL__sub_I__ZN3one3c1vE0+[ \t]+[#;]+[ \t]+external name
FAIL: g++.dg/debug/dwarf2/pubnames-2.C
Following http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02901.html, I have
applied
the following patch on x86_64-apple-darwin10
--- ../_clean/gcc/config.gcc2011-11-05 22:25:37.0 +0100
+++ gcc/config.gcc 2011-11-06 12:35:57.0 +0100
@@ -350,7 +350,7 @@ i[34567]86-*-*)
I have a few questions:
(1) Is sqrtl the only missing Fortran intrinsic?
(2) Is there a list of missing intrinsics and platforms?
(3) Does it make any sense to support REAL(10) if sqrtl
is missing?
Cheers,
Dominique
See http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01087.html . ...
With this patch on top of revision 172429 (and the second patch for
-fstack-arrays) I now get
Date Time : 14 Apr 2011 20:48:24
Test Name
Michael,
Yes, this is due to the DECL_EXPR statement which is rendered by the
dumper just the same as a normal decl. The testcase looks for exactly one
such decl, but with -fstack-arrays there are exactly two for each such
array.
The testsuite is run without -fstack-arrays, so I dont'
I have forgotten to say that the 125 and 516 thresholds are for
x86_64-apple-darwin10. On powerpc-apple-darwin9 they are
repsectively 172 and 638.
Dominique
Honza,
I will also look into the estimate_size ICE reported today.
This has been fixed by revision 172603 and now the thresholds are
the same with/without -flto. For the fine tuning I have posted
some results on pr48636.
Cheers,
Dominique
Honza,
Your patch seems to make --param max-inline-insns-auto= ineffective:
gfc -Ofast -funroll-loops -ftree-loop-linear -fomit-frame-pointer --param
max-inline-insns-auto=4000 -fwhole-program -fstack-arrays ac.f90
8.105u 0.005s 0:08.11 99.8% 0+0k 0+5io 0pf+0w
while the timing was ~2.7s
For me, I get everything inlined except for:
Oops! looking at my mail, I realized that I did not timed fatigue, but ac.
With the patch the only difference for fatigue is that the threshold for
full inlining decreased from 125 to 113.
Sorry for the noise.
Dominique
The attached patch fixes SMS testsuite failures seen on PowerPC and SPU.
On powerpc-apple-darwin9 the patch fixes all the SMS failures but for
FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS loop with subreg in lhs 1
with -m64. Also tested on x86_64-apple-darwin10 without regression.
Thanks
Does the attached patch resolve the failure with sms-8.c?
Yes. Thanks for the update.
Dominique
I have regstrapped several time with the patch without regression or failure on
my own tests.
Could someone review the patch?
Dominique
Regstrapped on x86_64-apple-darwin10 and powerpc-apple-darwin9 (see
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg03125.html )
without regression.
Thanks,
Dominique
After doing a binary search, the first revision which breaks bootstrap on
my environment with Ada enabled is the following:
r178353 | vries | 2011-08-31 09:04:25 +0200 (Wed, 31 Aug 2011) | 8 lines
...
This is probably related to pr50251 also caused by r178353.
Dominique
A function not declared inline with an always_inline attribute is a bug.
If the test case is buggy, why is it not spotted on non ppc platforms?
Dominique
Ping?
...
* gfortran.dg/vect/pr32380.f: XFAIL on PowerPC and ia-64.
This fixes the failure on powerpc-apple-darwin9 (see
http://gcc.gnu.org/ml/gcc-testresults/2012-02/msg01809.html ).
The fix is a little bit brutal since two loops are vectorized
on powerpc-apple-darwin9, but I don't think
Iain,
I have posted at http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg01799.html
the regtests on powerpc-apple-darwin9 with the patch. I still get the following
failures
FAIL: libffi.call/err_bad_abi.c -O0 -W -Wall execution test
FAIL: libffi.call/err_bad_abi.c -O2 execution test
FAIL:
+/* { dg-final { scan-assembler movl.*, (_?var|\\(%) } } */
It works for me too.
Thanks,
Dominique
I'm fine with whatever you guys come up with...
Likewise. I have no preference. Whatever gets approved is ok with me.
So let's pick the Iain's proposal:
Index: gcc/testsuite/c-c++-common/cxxbitfields-3.c
===
---
I've committed the patch.
It caused:
../../../work/libitm/config/posix/rwlock.cc: In member function 'bool
GTM::gtm_rwlock::write_lock_generic(GTM::gtm_thread*)':
../../../work/libitm/config/posix/rwlock.cc:196:56: error: comparison between
signed and unsigned integer expressions
I regression tested the patch on i686-*-freebsd. No problems occurred.
Can one of the other gfortran reviewers/committers cast a quick glance
over the patch. I would like to commit this within next day or two.
I have applied the patch on trunk (incremental update). I did not get any
The patch at
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01600/vec-tests-avx2_fixes-7.patch
fixes the XPASS, tested on powerpc-apple-darwin9 and x86_64-apple-darwin10.
Thanks,
Dominique
-freal-4-real-8 is not equivalent to -fdefault-real-8 and -fdefault-double-8.
-freal-4-real-8 interprets any 4-byte real type, whether it is a
default real type or explicitly declared as 4-byte, as a 8-byte double
precision type, and that applies to all variables, functions and
constants.
Hi Tobias,
Your patch passed my tests and in top of that fixes the ICE for pr51522.f90.
However I don't understand the errors:
[macbook] f90/bug% gfc -w pr51522.f90
pr51522.f90:268.10:
integer(c_int) function vect_Utils_vuTriIneqHolds_c(u, v, tol, exception)
1
Error: Parameter
I get the build failure: ...
I got the same failure. The following patch
--- ../_clean/libcpp/macro.c2012-01-09 11:15:22.0 +0100
+++ ../work/libcpp/macro.c 2012-01-09 12:28:06.0 +0100
@@ -217,7 +217,7 @@ static const char * const monthnames[] =
const uchar *
* g++.dg/cpp0x/constexpr-rom.C: Add -G0 where applicable.
It fails on powerpc-apple-darwin9 with
FAIL: g++.dg/cpp0x/constexpr-rom.C (test for excess errors)
Excess errors:
g++: error: unrecognized option '-G'
TIA
Dominique
Kai,
I think there is a typo in the test g++.dg/torture/pr51344.C causing
a regression:
FAIL: g++.dg/torture/pr51344.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O1 (test for excess errors)
FAIL: g++.dg/torture/pr51344.C -O2 (test for excess errors)
FAIL:
101 - 200 of 360 matches
Mail list logo
