--- Comment #5 from pinskia at gcc dot gnu dot org 2009-06-07 06:57 ---
You have to read the code to understand how that happens.
But basically GOMP_parallel_start does:
gomp_team_start (fn, data, num_threads, gomp_new_team (num_threads));
Where gomp_new_team creates the *thr (which i
--- Comment #4 from bart dot vanassche at gmail dot com 2009-06-07 06:52
---
(In reply to comment #3)
> Except this is a false positive as thread 4 is not created when the thread 2
> writes to *thr. It looks like valgrind does not know what is happening here
> really.
I'm not sure tha
--- Comment #7 from dominiq at lps dot ens dot fr 2009-06-07 06:37 ---
On powerpc-apple-darwin9 with -m64, but not with default -m32, I also see the
following new failures:
ERROR: gcc.dg/vect/vect-42.c: error executing dg-final: syntax error in target
selector "target !vect_hw_misalign"
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-06-07 06:22 ---
Except this is a false positive as thread 4 is not created when the thread 2
writes to *thr. It looks like valgrind does not know what is happening here
really.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-07 06:15 ---
Can you show the internal compiler error?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40365
--- Comment #2 from bart dot vanassche at gmail dot com 2009-06-07 06:14
---
(In reply to comment #1)
> >==21970==at 0x71A35FD: gomp_iter_dynamic_next (iter.c:190)
>
> Is a bogus warning as that is thread specific data:
> struct gomp_thread *thr = gomp_thread ();
> struct gomp_
I am trying to build Olex2 (sourceforge) project on x64 system with Pentium
6600Q and 6Gb of memory, using any 64bit Linux and it crashes gcc C++ on large
template expansion (>0.5k templates a class) with internal compiler error,
which happens in different files depending on the gcc version (4.1,
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-06-07 00:11 ---
>==21970==at 0x71A35FD: gomp_iter_dynamic_next (iter.c:190)
Is a bogus warning as that is thread specific data:
struct gomp_thread *thr = gomp_thread ();
struct gomp_work_share *ws = thr->ts.work_share;
--
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2009-06-06 23:27
---
I can confirm that at least the three tests that are run (1 to 3) PASS on
darwin with the following patch:
Index: gcc/testsuite/gcc.target/i386/excess-precision-1.c
===
--- Comment #1 from dopefishjustin at gmail dot com 2009-06-06 23:18
---
Created an attachment (id=17958)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17958&action=view)
.i file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40364
Got an ICE trying to compile MAME with the mingw-w64-bin_i686-mingw_20090605
snapshot of mingw-w64:
In file included from src/emu/cpu/tms9900/ti990_10.c:9:0:
src/emu/cpu/tms9900/99xxcore.h:149:25: warning: "TMS99105A_ID" is not defined
src/emu/cpu/tms9900/99xxcore.h:157:25: warning: "TMS99110A_ID"
--- Comment #2 from reichelt at gcc dot gnu dot org 2009-06-06 22:54
---
The original testcase doesn't crash anymore, but now an even simpler version
crashes:
double sqrt(double x) { double d; asm("" : "=t"(d)
--- Comment #10 from joseph at codesourcery dot com 2009-06-06 22:22
---
Subject: Re: [4.5 regression] ICE with __complex__
double
On Sat, 6 Jun 2009, hjl dot tools at gmail dot com wrote:
> That is why we shouldn't close a bug report without checking
> in a testcase.
Closing a bra
--- Comment #9 from hjl dot tools at gmail dot com 2009-06-06 22:16 ---
(In reply to comment #8)
> The bug reappeared between 2009-05-22 and 2009-05-29 on the trunk.
>
That is why we shouldn't close a bug report without checking
in a testcase.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-06 21:17 ---
FIXED on the trunk (4.5). Close.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-06 21:10 ---
Subject: Bug 37203
Author: burnus
Date: Sat Jun 6 21:09:57 2009
New Revision: 148238
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148238
Log:
2009-06-06 Daniel Franke
PR fortran/37203
IMHO, current save/restore registers strategy is not optimal. Look:
# cat test.c
#include
void print(char *mess, char *format, int text)
{
printf(mess);
printf(format,text);
}
void main()
{
print("X=","%d\n",1);
}
# gcc --version
gcc (GCC) 4.5.0 20090601 (experimental)
#
--- Comment #5 from kargl at gcc dot gnu dot org 2009-06-06 20:34 ---
Closing as invalid. The code submitted by Alain is invalid Fortran
as described by the excerpts from the Fortran 2003 standard
quoted in Comment #1. The Standard does not require a compiler to
detect and report the i
--- Comment #8 from reichelt at gcc dot gnu dot org 2009-06-06 20:32
---
The bug reappeared between 2009-05-22 and 2009-05-29 on the trunk.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-06-06 20:27
---
The bug disappeared between 2009-05-22 and 2009-05-29.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from reichelt at gcc dot gnu dot org 2009-06-06 20:11
---
This was fixed on the trunk and for GCC 4.4.1 by Jason's patch for PR38064.
Jason, would you mind adding this as another testcase to the testsuite so that
we can close the bug?
--
reichelt at gcc dot gnu dot o
The source code of libgomp should be reviewed carefully whether all variables
that are accessed by more than one thread are protected by a consistent locking
strategy. When analyzing OpenMP programs with Helgrind or DRD, several data
races are reported. The test I ran myself and the results are as
--- Comment #7 from burnus at gcc dot gnu dot org 2009-06-06 18:51 ---
Subject: Bug 32890
Author: burnus
Date: Sat Jun 6 18:51:29 2009
New Revision: 148237
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148237
Log:
fortran/
2009-06-06 Daniel Franke
PR fortran/32890
--- Comment #1 from steven at gcc dot gnu dot org 2009-06-06 17:56 ---
I tested the patch on arm-elf ("-march=armv7-r" and "-march=armv7 -mthumb"),
trunk revision 148235, -Os, unpatched and patched, with CSiBE:
armv7-r:
unpatched : 3557127 bytes
patched : 3554655 bytes
win: 2472 bytes
--- Comment #6 from eres at il dot ibm dot com 2009-06-06 17:32 ---
(In reply to comment #5)
> With the patch in comment #3 the failures are gone:
> make -k check-gcc RUNTESTFLAGS="vect.exp=*.c --target_board=unix'{,-m64}'"
Thanks for checking, I'll submit the patch then.
--
http:/
--- Comment #5 from dominiq at lps dot ens dot fr 2009-06-06 17:24 ---
With the patch in comment #3 the failures are gone:
make -k check-gcc RUNTESTFLAGS="vect.exp=*.c --target_board=unix'{,-m64}'"
...
=== gcc Summary ===
# of expected passes2829
# of expec
--- Comment #4 from eres at il dot ibm dot com 2009-06-06 16:46 ---
(In reply to comment #3)
> Created an attachment (id=17957)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17957&action=view) [edit]
> A patch to fix the fails
I appreciate it if you could test whether the attached
--- Comment #3 from eres at il dot ibm dot com 2009-06-06 16:43 ---
Created an attachment (id=17957)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17957&action=view)
A patch to fix the fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40359
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-06-06 16:09
---
Correction "have not" regtested the patch above.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40334
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-06-06 16:08
---
In the test case, the the first EOF is generated in transfer.c (hit_eof) which
sets the end file conditions. The second EOF is generated in list_read.c:1689.
When returning from he error condition, the end file c
--- Comment #2 from dominiq at lps dot ens dot fr 2009-06-06 15:49 ---
Subject: Re: [4.5 Regression] Revision 148211 caused a
lot of failures in the vect test suite.
> It might be that i686 should be added to
> check_effective_target_vect_hw_misalign.
It does, but I still have 9 ext
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||16996
nThis||
Sta
elf "xgcc (GCC) 4.5.0 20090606
(experimental) [trunk revision 148236]", with options -march=armv7-r -Os -dAP"
without patches results in this code:
.file "t.c"
.text
.align 2
.global foo
.type foo, %function
foo:
First, this bug report is very similar to the closed bug 35693. I could find no
way to re-open that bug report, and in any case this is a different version of
gcc, a different machine etc.
I believe the 'solution' given there, which involves setting LD_LIBRARY_PATH is
not really the right answer,
--- Comment #7 from hubicka at gcc dot gnu dot org 2009-06-06 13:41 ---
It seems to make sense to bump cost of idiv a bit, given the fact that there
are register pressure implications.
I would like to however understand what code sequences we produce that are
estimated to be long but en
--- Comment #1 from eres at il dot ibm dot com 2009-06-06 11:00 ---
It might be that i686 should be added to
check_effective_target_vect_hw_misalign.
Please try the following patch:
Index: testsuite/lib/target-supports.exp
===
On i686-apple-darwin9, revision 148211 caused a lot of failures in the vect
test suite with both -m32 and -m64:
< FAIL: gcc.dg/vect/costmodel/i386/costmodel-vect-31.c scan-tree-dump-times
vect "vectorization not profitable" 1
< FAIL: gcc.dg/vect/costmodel/i386/costmodel-vect-31.c scan-tree-dump-ti
--- Comment #16 from jv244 at cam dot ac dot uk 2009-06-06 07:08 ---
(In reply to comment #13)
> Subject: Bug 40168
Richard, this empty constructor patch was also OKed for 4.4 and has been on
mainline for a while.
http://gcc.gnu.org/ml/fortran/2009-05/msg00288.html
Do you intend to c
38 matches
Mail list logo