> Committed as r202101.
This cause a bootstrap failure:
...
libtool: compile: /opt/gcc/build_w/./gcc/xg++ -B/opt/gcc/build_w/./gcc/
-nostdinc++ -nostdinc++
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/libstdc++-v3/include/x86_64-apple-darwin10.8.0
-I/opt/gcc/build_w/x86_64-apple-darwin10.8.0/
> I've just merged ubsan into trunk. Please send complaints my way.
Bootstrap is broken on x86_64-apple-darwin10:
Making all in ubsan
make[4]: *** No rule to make target `../interception/libinterception.la',
needed by `libubsan.la'. Stop.
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-
> bootstrapped x86_64-darwin12 for c,c++ and fortran ...
Bootstrapped x86_64-apple-darwin10 for c,c++,fortran,java and
also tested asan.exp and ubsan.exp for gcc and g++.
Thanks for the patch,
Dominique
The test g++.dg/torture/pr58380.C fails:
FAIL: g++.dg/torture/pr58380.C -O0 (test for excess errors)
FAIL: g++.dg/torture/pr58380.C -O1 (test for excess errors)
FAIL: g++.dg/torture/pr58380.C -O2 (test for excess errors)
FAIL: g++.dg/torture/pr58380.C -O3 -fomit-frame-pointer (test for exc
> Adam Butcher wrote:
> From: abutcher
> * lambda.c (lambda_function): Return template result if call operator is
> a template.
>
> I believe that that patch causes the following build failure of cp/lambda.c:
> ...
> PS: I am not positive since I use a patched tree and I haven't bisec
> This is a followup on Thomas' proposal at
> ...
This commit (r202518) breaks bootstrap on x86_64-apple-darwin10
(I have bootstrapped r202538 with the commit reverted):
/opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/
-B/opt/gcc/gcc4.9w/x86_64-apple-darwin10.8.0/bin/
-B/opt/gcc/gcc4.9w/x
The bootstrap failure is fixed with the following patch:
[macbook] gcc/work% diff -up ../_clean/gcc/ada/gcc-interface/Makefile.in
gcc/ada/gcc-interface/Makefile.in
--- ../_clean/gcc/ada/gcc-interface/Makefile.in 2013-09-12 13:18:34.0
+0200
+++ gcc/ada/gcc-interface/Makefile.in 2013-09-
The new test gcc.dg/tree-ssa/slsr-39.c fails in 64 bit mode (see
http://gcc.gnu.org/ml/gcc-regression/2013-09/msg00455.html ).
Looking for MEM in the dump returns
_12 = MEM[(int[50] *)_17];
MEM[(int[50] *)_20] = _13;
TIA
Dominique
Hi Tobias,
I have tested your patch, mostly the added test cases.
I think the test gfortran.dg/class_optional_2.f90 should be split:
it has too much tests lumped together. In addition
the test gfortran.dg/class_optional_1.f90 does not compile
because "symbol 'i' at (1) has no IMPLICIT type" (three
> > It appears that the patch should also special case the "scan-assembler
> > .internal.*Foo.methodEv"
> > tests in g++.dg/ext/visibility/pragma-override1.C and
> > g++.dg/ext/visibility/pragma-override2.C
> > on darwin as well...
>
> Done, thanks.
Jason,
These tests are still failing on d
The following patch fixes PR52945 on Darwin. It as beem approved
by Jan Hubicka in PR52945#c5. Since I don't have write permission,
could someone commit it for me?
TIA
Dominique
2012-10-08 Dominique d'Humieres
PR gcc/52945
* testsuite/gcc.dg/lto/pr52634_0.c: skip the test on
Dodji,
The following tests are failing (with -m32):
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for warnings, line 9)
FAIL: g++.dg/cpp0x/gen-attrs-36.C (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-37.C (test for excess errors)
FAIL: g++.dg/cpp0x/gen-attrs-8.C (test for warnings, line 5)
FA
> > These tests are still failing on darwin. I think tha
> > target { ! *-*-solaris2* } { ! *-*-darwin* }
> > sould be replaced with
> > target { ! { *-*-solaris2* *-*-darwin* } }
>
> Could someone with a darwin box handy make the appropriate change?
I have never really understood the logic of the
On x86_64-apple-darwin10 The following tests:
g++.dg/gomp/tls-5.C
g++.dg/tls/thread_local-cse.C
g++.dg/tls/thread_local-order*.C
g++.dg/tls/thread_local*g.C
fail with
sorry, unimplemented: dynamic initialization of non-function-local thread_local
variables not supported on this target
In addit
> These don't work because of the lack of alias support; that's why I put
> dg-require-alias in the tests. Do I need a different magic incantation?
I understand nothing about alias, weak, ... stuff, but from pr52945, if you need
weak-alias, then you have also to use
/* { dg-require-weak "" } */
> >> FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test
> >> FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test
>
> These ought to work. Can you debug the problem?
Backtrace for thread_local4.C
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x1503 o
Hi,
The tests gcc.dg/vect/vect-82_64.c and gcc.dg/vect/vect-83_64.c are
failing on powerpc*-*-* (see for instance
http://gcc.gnu.org/ml/gcc-testresults/2012-10/msg01054.html ).
This is fixed with the following patch
diff -up gcc/testsuite/gcc.dg/vect/vect-82_64.c
../work/gcc/testsuite/gcc.dg/vec
Jack,
> > That's PR 54407, so not a regression.
>
> ... The pthreads support is definitely improved in darwin11 and later.
Do you confirm that 30_threads/condition_variable/54185.cc is passing on
darwin11 and 12?
If yes, I'll test a patch to skip it on darwin10 and older.
Dominique
Hi Tobias,
I did not yet appied you latest patch to gfortran, but I ran the new tests
with gfortran patched with the previous patch and both pass (manual
testing without option, but -fcoarray=single). Note that for
class_optional_1.f90, valgrind --leak-check=full gives
==45665== 4 bytes in 1 bloc
Tobias,
The previous class_optional_2.f90 runs after your commit, but it takes
~168s (so it may have run with the previous patch also, but I was not
patient enough to see it). The culprits are given by the following
profile:
+ 100.0%, start, a.out
| + 100.0%, main, a.out
| | + 100.0%, MAIN__, a.o
> Can you confirm that the class_optional_1.f90 of the trunk works correctly?
Yes: I have regtested with
make -k check-gfortran RUNTESTFLAGS="dg.exp=class_optional*
--target_board=unix'{-m32,-m64}'"
without failures.
The profile I have posted was for the former version of class_optional_2.f90.
Janus,
Your patch works as advertised without disturbing my pet bugs.
Just a nit pick: the double parentheses in
+ if ((CLASS_DATA (select_type_stack->selector)->attr.dimension
|| CLASS_DATA (select_type_stack->selector)->attr.codimension))
do not seem necessary.
Note for Paul: I
> 2012-10-17 Michael Meissner
>
> * config/rs6000/rs6000.opt (rs6000_isa_flags): New flag word to
> replace target_flags that gives us 63 possible switches.
> (x_rs6000_isa_flags): Save area for rs6000_isa_flags.
> (x_rs6000_isa_flags_explicit): Save area for
> ...
Boot
> > Eric and Dominique could you try it on your respective systems? Thanks in
> > advance.
>
> It works for me, thanks.
It does not for me:
In file included from ../../work/gcc/config/rs6000/rs6000.c:1475:0:
../../work/gcc/config/rs6000/rs6000-cpus.def:54:0: error: "MASK_STRICT_ALIGN"
redefined
Could someone commit the patch at
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00758.html ?
TIA
Dominique
This patch (r192676) is probably causing
FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c execution, -Os
FAIL: gcc.c-torture/execute/builtins/memmove-chk.c execution, -Os
FAIL: gcc.c-torture/execute/builtins/mempcpy-chk.c execution, -Os
FAIL: gcc.c-torture/execute/builtins/memset-chk.c exec
The test libgomp.graphite/force-parallel-6.c is not valid as it tries
to write Y[2*N] for Y defined as
int X[2*N], Y[2*N], B[2*N];
This patch fixes the bounds of the loops in order to make the test valid
Since I don't have write access, could someone commit the patch if it
is approved?
Dominiqu
Following the changes in [PATCH] Add option for dumping to stderr (issue6190057)
the tests gcc.dg/vect/vect-8[23]_64.c fails on powerpc*-*-*.
This patch adjust the dump files and has been tested on powerpc-apple-darwin9.
If approved could someone commit it for me (no write access).
Note that thes
Mike, Sharad,
> Committed in r192750.
Thanks for the review and the commit.
Dominique
Sriraman,
The tests gcc.target/i386/funcspec-5.c and gcc.target/i386/pr57756.c fail
on targets for which -msse is the default (see
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01365.html or
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01345.html ).
This is fixed with the following patch:
> I see why pr57756.c could fail, if -msse4.2 is turned on by default. I
> think this test needs {dg-options "-mno-sse4.2"}.
This change allows the test to pass. The failure of
gcc.target/i386/funcspec-5.c is
/opt/gcc/work/gcc/testsuite/gcc.target/i386/funcspec-5.c:34:1: warning: SSE
instructio
Paolo Carlini wrote:
> Patch is Ok with me. Before committing you may want to test -m32 too.
Obviously, you did not!-(see
http://gcc.gnu.org/ml/gcc-testresults/2013-10/msg01471.html
FAIL: tr2/dynamic_bitset/pr58729.cc execution test
On x86_64-apple-darwin12, the failure is
Assertion failed: (pd
> I am seeing a bootstrap failure that seems related: ...
Me too,
Dominique
Could someone review and commit the patch at
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02105.html ?
TIA
Dominique
> I think I blew by it the first time with the OK? at the end of the line?
> maybe I thought you thought it was trivial and checked it in
The patch is indeed trivial, but I don't have write access to CVS, so
someone else has to commit it.
Dominique
> :-) We stop using cvs a long time ago.
I meant SVN, just showing my age!-)
> Be sure to attach patches to be applied instead of cut-n-paste if you use
> Mail, it destroys the text cut and pasted.
I did not use Mail. Did you have troubles with Tabs? Apparently the post on the
list has them r
Revision 205848 breaks bootstrap on x86_64-apple-darwin13: pr59445.
TIA
Dominique
Hi Uros,
This patch fix pr58630. However I still think that the tests
func-2a.c, func-indirect-2a.c, vaarg-4a.c, and vaarg-5a.c
should not be restricted to linux: they pass on darwin.
TIA
Dominique
> OTOH, I can't test darwin properly, please provide the patch and I'll
> commit it for you.
Basically the patch I have in my tree since the PR replace 'linux' with '*'
(see below).
Since I can only test darwin, there is no guarantee that the tests pass on
non-linux,
non-darwin platforms. So if
Hi Jerry,
Glad to see you back!
I stumbled on this pr while trying to clean the files left after the tests
(see http://gcc.gnu.org/ml/fortran/2013-10/msg00083.html, note that
gfortran.dg/c_loc_test_22.f90 has already been applied). I have a pending
patch cleaning the remaining files; the full cle
> I got ...
me too on x86_64-apple-darwin13 with -m32 (gcc and g++).
r206009 is OK, r206026 is not.
Dominique
> must be introduced between r2060178 and r206026.
Likely r206026.
The ICE is
/opt/gcc/work/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:136:30: internal
compiler error: in gen_lowpart_general, at rtlhooks.c:51
/opt/gcc/work/gcc/testsuite/c-c++-common/ubsan/overflow-1.c:12:29: note: in
defini
> Hello,
>there's updated version of the patch.
>
> Tested on x86_64 with enable bootstrap.
>
> Martin
This caused pr59541.
TIA
Dominique
I was about to open a PR for the same failures on darwin.
Since the tests are supposed to be run, I think they should be skipped
on CPUs not supporting axv instructions. Would not it be better to use
/* { dg-require-effective-target avx_runtime } */
?
Dominique
LAST_UPDATED: Updated Mon Jan 6 10:13:16 CET 2014 to revision 206354.
=== acats tests ===
=== acats Summary ===
# of expected passes2320
# of unexpected failures0
Native configuration is x86_64-apple-darwin10.8.0
=== g++ tests
> This fixes the gimple verification ICEs in the Fortran testsuite.
> ...
This patch causes 6300+ regressions (-m32/-m64 all languages but go).
However the following change
--- ../_clean/gcc/lto/lto.c 2014-01-04 15:51:44.0 +0100
+++ gcc/lto/lto.c 2014-01-08 08:26:09.0 +0
> However, I don't quite see the necessity for changing the module
> format (apart from the fact that it makes your patch slightly
> simpler).
I think it should otherwise reading old module gives
"Expected left parenthesis".
Cheers,
Dominique
> This patch replaces some reference members with pointers, ...
> ...
> Tested x86_64-linux, committed to trunk.
This breaks bootstrap (see https://gcc.gnu.org/ml/gcc-regression/2014-08/):
...
libtool: compile: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc
-B/opt/gcc/build_w/./gcc -nostdinc++
-L/
As Mikael said in https://gcc.gnu.org/ml/fortran/2014-08/msg00047.html
> the testcase should check that the code generated is actually working,
> not just that the ICE disappeared. ...
thus I think the test should be run, i.e., '! { dg-do compile }' should
be replaced with '! { dg-do run }' (I ha
> the testcase should check that the code generated is actually working,
> not just that the ICE disappeared.
I agree. Note that there is a test in the comment 3 of PR60255 that
can be used to check the run time behavior (and possibly check the
vtab issue).
Dominique
> My knowledge of unlimited polymorphic types is limited, but I think that
> this is not correct.
My knowledge of unlimited polymorphic types is even more limited,
then I cannot comment about the correctness of the patch. However
> The new length of the string has to be stored somewhere. If you
> Here is a failing testcase.
I was about to post the same test. The test fails with two counts:
(1) len(P) == 80,
(2) deallocate(P) fails with
a.out(882,0x7fff75e1d310) malloc: *** error for object 0x7fc801c04978:
incorrect checksum for freed object - object was probably modified after being
f
> Makes sense, I've attached new patch (retested as usual).
Well, you probably did not test with -m32:
Running target unix/-m32
FAIL: c-c++-common/asan/pr62089.c -O0 output pattern test, is
=
FAIL: c-c++-common/asan/pr62089.c -
> So the negative version is -Wno-use-no-only? That sounds weird.
What about -Wuse-without-only?
I can also confirm that the test succeeds without the ' ! { dg-bogus "has no
ONLY qualifier" }'.
Dominique
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 wrote:
>
> gcc/c-family:
> 2014-09-05 Joseph Myers
>
> * c-cppbuiltin.c (c_cpp_builtins): Also define
> __LIBGCC_EH_TABLES_CAN_BE_READ_ONLY__,
> __LIBGCC_EH_FRAME_SECTION_NAME__, __LIBGCC_JCR_SECTION_NAME__,
> __LIB
...
> 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
The tests introduced in revision 204544 fail with -m32
(see http://gcc.gnu.org/ml/gcc-regression/2013-11/msg00213.html
or http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg00526.html ).
This revision may also causes the failures of
gfortran.dg/typebound_operator_9.f03 and
FAIL: gfortran.fortran-tor
According to http://gcc.gnu.org/ml/gcc-regression/2013-11/msg00197.html
revision 204538 is breaking several tests. On x86_64-apple-darwin* the
failures I have looked at are of the kind
/opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_9.f03: In function
'nabla2_cart2d':
/opt/gcc/work/gcc
> I doubt the patch affects Fortran (there are language-independent changes,
> but they are fairly small and shouldn't affect code not using _Atomic
> qualifiers).
The Fortran failures seem related to revision 204538.
Dominique
> Thank you for the report. I have submitted a bug fix patch waiting to
> be reviewed.
The patch fixes the fortran failures (tested on gfortran an libgomp only).
Thanks,
Dominique
> I hope this patch will fix the issues people have seen with atomics
> tests failing on 32-bit architectures with missing __atomic_*_16 (or
> at least replace them by different problems). I'm running tests on
> x86_64-unknown-linux-gnu; perhaps someone seeing the 32-bit problems
> could test it t
Typical very long run output:
[Book15] f90/bug% gcc49 -std=c11 -pedantic-errors -pthread
-D_POSIX_C_SOURCE=200809L
/opt/gcc/work/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-5.c
-L/opt/gcc/build_w/x86_64-apple-darwin13.0.0/i386/./libatomic/.libs -latomic
-m32
[Book15] f90/bug% time a.out
Bootstrapping with ada id broken by revision 204708
(at least on x86_64-apple-darwin13):
...
# gnattools1
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../gcc/ada/tools -f
../Makefile \
"CC=../../xgcc -B../../" "CXX=../../xg++ -B../../
-B../../../x86_64-apple-darwin13.0.0/
On Wed Nov 13 07:53:25 2013, Jeff Law wrote:
> I'll have a patch going through testing overnight.
If you have a patch, could you post it please?
TIA
Dominique
The test c-c++-common/cilk-plus/PS/reduction-3.c fails on *-apple-darwin*
because it has no malloc.h header. Tested on x86_64-apple-darwin13.
OK?
Note that although I have the FSF papers signed, I don't have write access.
If approved, someone will have to commit the patch for me.
Dominique
2013-
Adjust the following tests to take into account the change of
"Length of Public Names Info" to "Pub Info Length"
in revision 203936. Tested on x86_64-apple-darwin13. OK?
Dominique
2013-11-18 Dominique d'Humieres
PR testsuite/59043
* g++.dg/pubtypes.C: Adjust the regular expres
> Thanks: Committed revision 205038.
This seems to break several g++ tests: see
http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html
On x86_64-apple-darwin13, the ICE is
cc1: error: cannot load plugin ./one_time_plugin.so
dlopen(./one_time_plugin.so, 10): image not found
/opt/gcc/work/gcc
Basile,
http://gcc.gnu.org/ml/gcc-testresults/2013-11/msg01482.html is for
x86_64-unknown-linux-gnu. However I cannot infer from the pointer
what is the ICE. Nevertheless I'll try your patch.
Thanks for the answer.
Dominique
Basile,
The patch fixes most of the plugin failures except:
FAIL: g++.dg/plugin/selfassign.c compilation
The error is
/opt/gcc/work/gcc/testsuite/g++.dg/plugin/selfassign.c: In function 'void
warn_self_assign(gimple)':
/opt/gcc/work/gcc/testsuite/g++.dg/plugin/selfassign.c:227:75: error:
'may
Patch:
--- ../_clean/gcc/testsuite/gfortran.dg/implicit_4.f90 2014-10-07
00:21:56.0 +0200
+++ gcc/testsuite/gfortran.dg/implicit_4.f902014-10-07 19:09:45.0
+0200
@@ -6,7 +6,7 @@ END
SUBROUTINE a
IMPLICIT REAL(b-j)
-implicit none ! { dg-error "Type IMPLICIT NONE stat
Hi Joost,
Why do you want -fno-math-errno to be the default for gfortran?
AFAICT such default is not documented and the flag works
(checked on your test gfortran.dg/errnocheck_1.f90).
For -fassociative-math, the manual says
For Fortran the option is automatically enabled when both -fno-signed-ze
> I resend patch within new thread. ...
This patch fixes pr61377. Could it be committed ASAP?
TIA,
Dominique
> I think it is really weird if a coding style warning is included in -Wall.
I fully agree. In top of that the patch looks like a blind enforcement of this
coding style.
What is the rationale of
+ SUBROUTINE S2
+ USE foo, ONLY: bar ! { dg-bogus "has no ONLY qualifier" }
+ END SUBROUTINE
?
> Ok for trunk. Thanks!
Please don't rush! The behavior of -fno-signed-zeros -fno-trapping-math
implying associative math has been changed (as in reverted) between r165758
(implied associative math) and r165930 (lost associative math). AFAICT
it could be due to 165823. Investigating! I am also loo
Dear Paul,
> This was a slip up on my part. The fix is obvious - OK for trunk and 4.9?
The patch fixes the ICE. Any progress about the double temporary?
[Book15] f90/bug% gfc pr61406.f90 -Warray-temporaries
pr61406.f90:6.18:
associate (n => [cos(theta), sin(theta)])
1
Warni
Patch posted at https://gcc.gnu.org/ml/fortran/2014-05/msg00155.html.
TIA
Dominique
> This explicitly tests that no bogus error message is issued
> for a use statement that has an only qualifier ?
I don't see the need for '! { dg-bogus "has no ONLY qualifier" }'.
AFAICT there is no warning emitted for this line (unless you add -Wall)
and if some day it happens that an error/warni
> This patch fixes PR61446. ...
Confirmed, it also allows to bootstrap Core* targets.
Could it be reviewed and committed ASAP?
TIA
Dominique
> (I am not RTL reviewer, so I can't approve the patch).
Is https://gcc.gnu.org/ml/gcc-regression/2014-06/ accepatble?
Dominique
> Yes, these are bootstraps with non-default configurations.
Core2 is the default for darwin and bootstrap is also broken for it
without the patch.
Dominique
How does this affect pr60732?
Dominique
Dear Paul,
Late thanks for the review, the patch has been committed to trunk at r211405.
> OK for trunk and, I would suggest 4.9.
I am now trying to do the back port to 4.9 and I got two failures:
FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O* scan-tree-dump-times original
"builtin_free" 18
> Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin13.2.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86
I have done the change to tree t = NULL_TREE; then bootstrap fails with
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/toplev.o differs
I'll try your full patch later (currently bootstrapping r211698).
Thanks,
Dominique
I have bootstrapped r211707 with the full patch (among others!).
> It does not. So the above is IMHO very likely completely unrelated,
> perhaps Darwin specific, issue.
More likely related to the fact that I only resumed bootstrap after the change
tree t = NULL_TREE; and an update from r211700 t
> The following change in predicates.md seems to be a bit premature.
> There is still the point about Darwin's PIC issue for unspec-gotpcrel.
The change is indeed incompatible with the patch in pr61387 comment 9.
And without it the failures are back!-(
Kai, what is wrong with Iain's patch in com
The tests gcc.dg/globalalias-2.c and gcc.dg/localalias-2.c fail on darwin with
/opt/gcc/work/gcc/testsuite/gcc.dg/globalalias-2.c:20:2: warning: alias
definitions not supported in Mach-O; ignored
I think they should be protected by
/* { dg-require-alias "" } */
Dominique
In addition of pr61644 and pr61646, this commit breaks a lot of
fortran tests with -flto -O0.
TIA
Dominique
FAIL: gfortran.dg/actual_array_constructor_1.f90 -g -flto (internal compiler
error)
FAIL: gfortran.dg/alloc_comp_assign_6.f90 -g -flto (internal compiler error)
FAIL: gfortran.dg/allo
> Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
the addition of '-g -flto'. Is it worth pushing in this direction?
Cheers,
Dominique
> Note that testusite passes with the patch; ...
Confirmed. There is a typo
s/fileds/fields/
I have seen the failures because I now run the gfortran testsuite with
Is the following patch OK for trunk?
2014-07-05 Dominique d'Humieres
PR testsuite/61453
* gfortran.dg/gfortran.dg/bind_c_array_params_2.f90:
Adjust regexp for more targets.
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.
On Mon, 05 May 2014, I have posted
https://gcc.gnu.org/ml/fortran/2014-05/msg00012.html.
On IRC Tobias Burnus remarked that the *.mod file in
gfortran.dg/vect/fast-math-real8-pr40801.f90
should be cleaned automatically. This is not done because the cleaning is done
in gfortran-dg-runtest and not
> "myBindC,%r2" will work on hppa*-*-*. I don't believe preceding stuff
> is needed on hppa.
Sorry, the relation with -flto has been lost in my repost of this patch.
Without something before 'myBindC', the symbol appears twice when compiled
with -flto, once in the assembly itself and once in the
> On hppa, the ",%r2" uniquely identifies the call. The test passes
> with -flto.
Then is the following patch OK for hppa*-*-*?
+++ gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 2014-07-05
22:20:49.0 +0200
@@ -16,7 +16,7 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final {
> I'm fixing that with the following (will commit as obvious).
Marek,
With your patch g++.dg/ipa/imm-devirt-2.C sitll fails in 32 bit mode
because the mangling is C::_ZThn16_N1C3fooEi. This is fixed by something
such as
--- ../_clean/gcc/testsuite/g++.dg/ipa/imm-devirt-2.C 2014-07-05
23:22:5
In https://gcc.gnu.org/ml/fortran/2014-06/msg00150.html
I wrote
> I am now trying to do the back port to 4.9 and I got two failures: ...
Actually I did not applied the right patch, with it the testsuite pass without
regression. Still OK for 4.9.1?
TIA
Dominique
> On condition that your commit the right patch :-), OK for 4.9.1
Indeed! Committed as r212329.
Thanks for the review.
Dominique
1 - 100 of 377 matches
Mail list logo
