Hi,
What functions from the GNU's C standard library ( libc ) are thread
safe? Of a particular interest are transcendental functions ( like
'exp', 'sin' etc. ) - are they thread safe?
Are there any requirements/guidelines/assurances regarding thread safety
of functions from the C library?
On 8 Dec 2008, at 21:09, Andrew Pinski wrote:
On Mon, Dec 8, 2008 at 1:04 PM, IainS [EMAIL PROTECTED]
acoustics.co.uk wrote:
following on from http://gcc.gnu.org/ml/gcc/2008-05/msg00202.html
As I mentioned; it is emulated. So it works, by default, though it is
hm. At the moment it
2008/12/8 Ian Lance Taylor [EMAIL PROTECTED]:
Alexandre Pereira Nunes [EMAIL PROTECTED] writes:
I can provide these, tough as for the copyright assignment, the
document mentions I can declare the changes in public domain, and
since I already published something (which may or may not be
Ralf Corsepius [EMAIL PROTECTED] writes:
1) Is gcc -r officially supported by gcc?
It apparently works, but I can't find it documented anywhere in GCC's
documentation.
When invoking the linker, a -r option on the command line will be
passed to the linker. The same is true of -A, -d, -eSYM,
On Tue, 2008-12-09 at 07:19 -0800, Ian Lance Taylor wrote:
Ralf Corsepius [EMAIL PROTECTED] writes:
1) Is gcc -r officially supported by gcc?
It apparently works, but I can't find it documented anywhere in GCC's
documentation.
When invoking the linker, a -r option on the command line
David Livshin [EMAIL PROTECTED] writes:
What functions from the GNU's C standard library ( libc ) are thread
safe? Of a particular interest are transcendental functions ( like
exp', 'sin' etc. ) - are they thread safe?
Are there any requirements/guidelines/assurances regarding thread
safety
Ralf Corsepius [EMAIL PROTECTED] writes:
So what would you recommend: To use gcc -r or gcc -Wl,-r ?
Ah, when you put the question like that, I would recommend ld -r.
This is the one case where you get no advantage from using the gcc
driver to invoke the linker, and it can actually mess you up
hi,
The following is a simplification of my problem:
struct Base { virtual void func() = 0; };
struct Derived : Base { inline void func() {...} };
Derived d = ...;
d.func();
This last call is not being inlined. Is this normal? (As I said my example is
more complex, I didn't check if the
Ian Lance Taylor wrote:
David Livshin [EMAIL PROTECTED] writes:
What functions from the GNU's C standard library ( libc ) are thread
safe? Of a particular interest are transcendental functions ( like
exp', 'sin' etc. ) - are they thread safe?
Are there any
Marco Correia [EMAIL PROTECTED] writes:
The following is a simplification of my problem:
struct Base { virtual void func() = 0; };
struct Derived : Base { inline void func() {...} };
Derived d = ...;
d.func();
This last call is not being inlined. Is this normal? (As I said my example is
Marco Correia wrote:
hi,
The following is a simplification of my problem:
struct Base { virtual void func() = 0; };
struct Derived : Base { inline void func() {...} };
Derived d = ...;
d.func();
This last call is not being inlined. Is this normal?
Yes. The compiler cannot know that d
Ian Lance Taylor [EMAIL PROTECTED] writes:
Ralf Corsepius [EMAIL PROTECTED] writes:
So what would you recommend: To use gcc -r or gcc -Wl,-r ?
Ah, when you put the question like that, I would recommend ld -r.
This is the one case where you get no advantage from using the gcc
driver to
On Tue, 2008-12-09 at 08:10 -0800, Adam Nemet wrote:
Ian Lance Taylor [EMAIL PROTECTED] writes:
Ralf Corsepius [EMAIL PROTECTED] writes:
So what would you recommend: To use gcc -r or gcc -Wl,-r ?
Ah, when you put the question like that, I would recommend ld -r.
This is the one case
Ralf Corsepius writes:
So, my questions actually were aiming at
* whether
gcc ... -nostdlib -r
and
gcc ... -nostdlib -Wl,-r
are equivalent
* if the fact that gcc -r appears to work, can be exploited or whether
this is a random accident and/or intentionally undocumented feature,
David Livshin [EMAIL PROTECTED] writes:
I thought that gcc mailing list is appropriate as I need this
information in order to implement auto-parallelizer for the
gcc-generated code. How the gcc-supported parallelizer (
-ftree-parallelize-loops=n ) treats the calls to library routines?
Sorry,
... is the problem one of SPECs ?
I don't think so, unless we can key off -pthread or something.
.. or does every single TLS case need a darwin-specific addition to
reference -lgcc_eh ?
We can add that via tls.exp.
.. I guess also that target-supports.exp would need some modification to
Status
==
The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.
As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100. We're close -- there are 5
A little additional info:
PPC darwin8 (if configured --enable-tls --enable-threads) fails the
check_effective_target_{tls, tls_runtime, tls_native} with a compiler
ICE
viz, for example:
tls_native7888.c:3: internal compiler error: in
rs6000_legitimize_tls_address, at
Hi,
Is this one in the list?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
Can Ada build on any Arm platform? arm-rtems had
good test results for 4.3.2 but broke a few months ago.
I suspect it doesn't build targeting any Arm.
And I doubt this one is on the list but I am convinced
Szia
Pár napja kérdezted hogy nem e tudok egy jó letölt#337;s oldalt. És én
most találtam egyet.
Tele van jobbnál jobb filmekkel, és olcsó! 1 db sms elküldése után 500
kb/sec-el töltöttem napokig a legújabb premier filmeket és meséket!
Küldj most SMS-t,és 5 nap helyet,25-öt adunk,ez
On Tue, Dec 9, 2008 at 9:12 PM, Joel Sherrill [EMAIL PROTECTED] wrote:
Hi,
Is this one in the list?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
Can Ada build on any Arm platform? arm-rtems had
good test results for 4.3.2 but broke a few months ago.
I suspect it doesn't build
Richard Guenther wrote:
On Tue, Dec 9, 2008 at 9:12 PM, Joel Sherrill [EMAIL PROTECTED] wrote:
Hi,
Is this one in the list?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
Can Ada build on any Arm platform? arm-rtems had
good test results for 4.3.2 but broke a few months ago.
I suspect
On 12/9/08, Joel Sherrill [EMAIL PROTECTED] wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
Can Ada build on any Arm platform?
The only existing GNAT Ada compiler I could find for ARM (while
thinking about doing it for the new Debian eabi port) is Adacore's
Windows-Nucleus OS
Martin Guy wrote:
On 12/9/08, Joel Sherrill [EMAIL PROTECTED] wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37440
Can Ada build on any Arm platform?
The only existing GNAT Ada compiler I could find for ARM (while
thinking about doing it for the new Debian eabi port) is
Mark Mitchell wrote:
Status
==
The trunk remains Stage 4, so only fixes for regressions (and changes
to documentation) are allowed.
As stated previously, the GCC 4.4 branch will be created when there
are no open P1s and the total number of P1, P2, and P3 regressions is
under 100. We're
On Tue, 9 Dec 2008, Vladimir Makarov wrote:
Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit
before submitting patch removing the old register allocator. So nothing
prevents to remove the old RA.
I am going to submit the patch removing the old RA for review today.
Hans-Peter Nilsson wrote:
On Tue, 9 Dec 2008, Vladimir Makarov wrote:
Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit
before submitting patch removing the old register allocator. So nothing
prevents to remove the old RA.
I am going to submit the patch removing
On Tue, 9 Dec 2008, Vladimir Makarov wrote:
Hans-Peter Nilsson wrote:
Vladimir, have you had chance to look at supporting
LOAD_EXTEND_OP (implicit sign-extension) in IRA?
http://gcc.gnu.org/ml/gcc/2008-10/msg00458.html
I'm guessing no, but hope it's not forgotten.
It seems I missed that,
On Tue, Dec 9, 2008 at 8:39 PM, Mark Mitchell [EMAIL PROTECTED] wrote:
The other issue that remains is removing the old register allocator.
Vladimir, it's time to do this. What -- if anything -- is preventing
that?
What about sched-ebb? Wasn't that supposed to be removed after the
selective
Hans-Peter Nilsson wrote:
On Tue, 9 Dec 2008, Vladimir Makarov wrote:
Today Jeff Law (many thanks to him!) approved a big patch I wanted to commit
before submitting patch removing the old register allocator. So nothing
prevents to remove the old RA.
I am going to submit the patch removing
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-09 08:41 ---
The patch in comment #2 fixes the ICE without regression on i686-apple-darwin9.
Is not the obvious rule applying here?
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
--- Comment #1 from jv244 at cam dot ac dot uk 2008-12-09 08:42 ---
Tobias,
you might be interested to check if your recent patch also fixed these bugs.
Otherwise I should be able to give it a round of testing before the weekend.
--
jv244 at cam dot ac dot uk changed:
--- Comment #2 from jakub at gcc dot gnu dot org 2008-12-09 08:56 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2008-12-09 09:00 ---
Something as simple as this would already fix the broken link.
Index: gcc/doc/sourcebuild.texi
===
--- gcc/doc/sourcebuild.texi(revision 142582)
--- Comment #12 from hp at gcc dot gnu dot org 2008-12-09 09:17 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-12-09 11:06 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-09 13:44 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from mikael at gcc dot gnu dot org 2008-12-09 13:53 ---
(In reply to comment #3)
The patch in comment #2 fixes the ICE without regression on
i686-apple-darwin9.
I didn't expect any regression with that patch.
However, I wonder whether we are not missing something.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-12-09 11:07 ---
Subject: Bug 38445
Author: rguenth
Date: Tue Dec 9 11:06:34 2008
New Revision: 142590
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142590
Log:
2008-12-09 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-09 10:36 ---
Subject: Bug 38450
Author: jakub
Date: Tue Dec 9 10:35:15 2008
New Revision: 142588
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142588
Log:
PR ada/38450
* gcc-interface/utils.c
--- Comment #10 from joseph at codesourcery dot com 2008-12-09 13:40
---
Subject: Re: dead link on onlinedocs/gccint/Top-Level.html
On Tue, 9 Dec 2008, steven at gcc dot gnu dot org wrote:
[EMAIL PROTECTED] ??? This manual is apparently not available online. Keep
the cross
But
Due to a backend bug, dbr had picked a delay slot insn for annul-true which was
not actually elegible for annul-true. When I fixed the bug, I found that
instead an insn from the target path was chosen, the restore of the return
address, as the target is an epilogue.
The original instruction, mov
--- Comment #11 from ebotcazou at gcc dot gnu dot org 2008-12-09 10:58
---
a current snapshot from the branch, exluding r142149 works for me. I'll try to
reduce the applied patches until the builds succeeds again with r142149, but
again, this may take a while.
The only possibility
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-09 14:12 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
While compiling compression code for LZMA for use with an embedded ARM target I
have discovered a regression from previous editions of GCC.
I have pared this down to a trivial example (attached) which boils down to a
application specific modulus operation (please note this is the *minimal* test
--- Comment #1 from vince at simtec dot co dot uk 2008-12-09 14:51 ---
Created an attachment (id=16854)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16854action=view)
Trivial test code to show behaviour
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38453
--- Comment #12 from doko at ubuntu dot com 2008-12-09 15:28 ---
sorry for not noticing earlier; indeded, this is a patch by CodeSourcery to
enable to build libobjc.
see http://lists.debian.org/debian-gcc/2008/04/msg00240.html
I don't see this defined on the trunk. I suppose this
/* { dg-do compile } */
/* { dg-options -O2 } */
typedef __SIZE_TYPE__ size_t;
extern inline __attribute__((gnu_inline, always_inline, artificial)) void *
memcpy (void *__restrict dest, const void *__restrict src, size_t len)
{
return __builtin___memcpy_chk (dest, /* { dg-warning will always
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #13 from jakub at gcc dot gnu dot org 2008-12-09 16:06 ---
Works with upstream 4.3 and on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from ebotcazou at gcc dot gnu dot org 2008-12-09 16:35
---
sorry for not noticing earlier; indeded, this is a patch by CodeSourcery to
enable to build libobjc.
see http://lists.debian.org/debian-gcc/2008/04/msg00240.html
Thanks. The definition of EH_USES looks
--- Comment #9 from jakub at gcc dot gnu dot org 2008-12-09 16:57 ---
Subject: Bug 35468
Author: jakub
Date: Tue Dec 9 16:55:35 2008
New Revision: 142598
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142598
Log:
PR tree-optimization/35468
* tree-ssa-ccp.c
--- Comment #8 from sje at gcc dot gnu dot org 2008-12-09 16:59 ---
Subject: Bug 37326
Author: sje
Date: Tue Dec 9 16:57:49 2008
New Revision: 142599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142599
Log:
PR testsuite/37326
*
the following code works on x86_64 as 64-bit binary, but the alignment
constraints of heap-allocated structs are not matched, when compiling 32-bit
code:
#include assert.h
template int size = 4
struct aligned_buffer
{
char padding;
float data[size] __attribute__((aligned((16;
};
--- Comment #9 from sje at cup dot hp dot com 2008-12-09 17:05 ---
Fixed by skipping the test on hppa64.
--
sje at cup dot hp dot com changed:
What|Removed |Added
--- Comment #10 from jakub at gcc dot gnu dot org 2008-12-09 17:09 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-09 17:14 ---
I have not yet tracked this down to the patch that produced this regression.
I have tracked this down to r138207 AKA tuples branch merge.
*.ifcvt dump looks the same (the only difference is:
- # SMT.10D.1968_19 =
--- Comment #1 from brian at dessent dot net 2008-12-09 17:14 ---
Subject: Re: New: aligned struct members in heap-allocated code
This is a dup of pr15795. Basically, operator new is just a wrapper
around malloc from the libc, and malloc returns an allocation with a
fixed alignment
--- Comment #2 from tim at klingt dot org 2008-12-09 17:23 ---
well, would be nice to read something like that in the attribute documentation
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38455
--- Comment #5 from burnus at gcc dot gnu dot org 2008-12-09 17:28 ---
(In reply to comment #4)
For example, I tried to adapt the testcase in PR 33295 to the c_funloc case.
The resulting program is rejected with the following error:
Error: Can't convert
--- Comment #1 from hjl at gcc dot gnu dot org 2008-12-09 17:39 ---
Subject: Bug 38420
Author: hjl
Date: Tue Dec 9 17:38:09 2008
New Revision: 142601
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142601
Log:
2008-12-09 H.J. Lu [EMAIL PROTECTED]
PR testsuite/38420
--- Comment #42 from rguenth at gcc dot gnu dot org 2008-12-09 17:43
---
*** Bug 38455 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-12-09 17:43 ---
*** This bug has been marked as a duplicate of 15795 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
I would like to make a suggestion regarding the problem I posed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38443 (sorry I didn't check with
the trunk).
To repeat it: the scope of a variable begins in its initializer instead of
after it, making e.g. the following program output some random
--- Comment #30 from amylaar at gcc dot gnu dot org 2008-12-09 18:22
---
I think the testcase pr27574.C should be added to the testsuite before
closing this bug.
--
amylaar at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-12-09 18:32
---
Now on to this one. :-) Is 20081115 the date of the first failure? 08 was
fine?
There are test results for IA-64/Linux (suse-linux and unknown-linux) both
4.3.3
and 4.4.0 posted on the gcc-testresults on a
--- Comment #31 from amylaar at gcc dot gnu dot org 2008-12-09 18:48
---
Sorry, I only checked for the presence of the original testcase name in
the testsuite, and thus missed the fact that there is a new test called
local-var-in-contructor.C [sic] .
--
amylaar at gcc dot gnu dot
--- Comment #1 from brian at dessent dot net 2008-12-09 18:53 ---
Subject: Re: New: Suggestion: slight improvement of scoping rules
I seriously don't think you will ever convince anyone to change a facet
of gcc which is currently following the standard to something that is
--- Comment #4 from steven at gcc dot gnu dot org 2008-12-09 18:53 ---
I have had no trouble bootstrapping 4.4 on ia64-unknown-linux-gnu (Debian) in
the last two weeks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
--- Comment #2 from steven at gcc dot gnu dot org 2008-12-09 18:59 ---
This is what -Wshadow is for. We can't invent a new C dialect or fix the
standard.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from lc235951 at students dot mimuw dot edu dot pl
2008-12-09 19:09 ---
I know I can turn on warnings or use some tricks like UNIQUIFY(), but it's just
cumbersome with large macros.
I also know that changing the standard is considered not done, but in this
case it
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-12-09 19:12 ---
Confirmed. As is, the testcase hangs for me and does not ICE. However, valgrind
shows
==3159==
pr37744.f90:22.19:
--- Comment #3 from mikael at gcc dot gnu dot org 2008-12-09 19:13 ---
Subject: Bug 35983
Author: mikael
Date: Tue Dec 9 19:12:27 2008
New Revision: 142605
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142605
Log:
2008-12-09 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #8 from mmitchel at gcc dot gnu dot org 2008-12-09 19:20
---
With respect to Comment #4: I see no reason for C++ to be different than C in
this respect, and thus I see no reason not to perform the computation at
compile-time.
In general, although some in the committees do
--- Comment #6 from mikael at gcc dot gnu dot org 2008-12-09 19:22 ---
Subject: Bug 37469
Author: mikael
Date: Tue Dec 9 19:20:18 2008
New Revision: 142606
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142606
Log:
2008-12-09 Mikael Morin [EMAIL PROTECTED]
PR
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-12-09 19:27 ---
Subject: Bug 36457
Author: dfranke
Date: Tue Dec 9 19:25:55 2008
New Revision: 142607
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142607
Log:
2008-12-09 Daniel Franke [EMAIL PROTECTED]
PR
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38434
--- Comment #20 from mmitchel at gcc dot gnu dot org 2008-12-09 19:34
---
HJ --
As Richard says, you should not have checked in the new testcases without
XFAILs and without having fixed the bug.
Furthermore, your patch to the middle-end is without explanation. What is the
problem?
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38271
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38427
--
mmitchel at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38454
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-12-09 19:29 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
c-common.c:handle_packed_attribute about line 5117 gives a warning for types
where __attribute__ ((__packed__)) is applied but has no effect. That
particular warning should be removed or perhaps moved to a separate flag,
because it emits warnings for code such as:
struct x
{
char c;
int x
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot
|dot org
--- Comment #2 from jv244 at cam dot ac dot uk 2008-12-09 19:41 ---
This is a simple testcase for one of the first segfaults, observed with current
graphite branch:
gfortran -c -O2 -ffree-form -fgraphite -fgraphite-identity test.f90
test.f90: In function matmov:
test.f90:1: internal
--
mikael at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot
|dot org
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-09 19:33 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #5 from doko at ubuntu dot com 2008-12-09 19:50 ---
which versions of binutils/glibc are used? for debian these are binutils-2.18.1
and glibc-2.7.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
For
# a_1 = PHI b_1, c_1
b_1 = a_1;
copy-propagation propagates a_1 into b_1 instead of c_1 into a_1 and b_1.
This is because handling of PHI and copy nodes is different. Either
Index: tree-ssa-copy.c
===
--- tree-ssa-copy.c
--- Comment #9 from dfranke at gcc dot gnu dot org 2008-12-09 19:54 ---
Subject: Bug 37468
Author: dfranke
Date: Tue Dec 9 19:53:02 2008
New Revision: 142608
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142608
Log:
2008-12-09 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-12-09 19:54 ---
Subject: Bug 36376
Author: dfranke
Date: Tue Dec 9 19:53:02 2008
New Revision: 142608
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142608
Log:
2008-12-09 Daniel Franke [EMAIL PROTECTED]
PR
--- Comment #3 from dfranke at gcc dot gnu dot org 2008-12-09 19:55 ---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from dfranke at gcc dot gnu dot org 2008-12-09 19:56
---
Fixed in trunk. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from sylvain dot pion at sophia dot inria dot fr 2008-12-09
20:03 ---
Incidentally, I submitted to WG21 a few days ago a proposal which will appear
in the coming mid-term mailing as N2811, named Directed Rounding Arithmetic
Operations. In the meantime, you can find it
--- Comment #3 from grosser at gcc dot gnu dot org 2008-12-09 20:08 ---
The graphite branch should now be able to compile polyhedron.
--
grosser at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from grosser at gcc dot gnu dot org 2008-12-09 20:10 ---
Thanks for these test cases.
My commit fixed at least one failure, but there are more.
To help us it would be great to get a little bit structure in the failures.
Just get for every failing test a backtrace and
--- Comment #11 from joel at gcc dot gnu dot org 2008-12-09 20:11 ---
I wondered if I had a mistake in my testing since some of the later results
didn't make sense as I thought about them. I am pretty convinced now this
is NOT a strict aliasing problem in psim.
Broken when
In the current graphite branch we fail with a SEGFAULT.
#0 0x28ed1fb1 in _malloc_prefork () from /lib/libc.so.7
#1 0x28ed6f45 in realloc () from /lib/libc.so.7
#2 0x28c9d019 in __gmp_default_reallocate () from /usr/local/lib/libgmp.so.7
#3 0x28cb0a4e in __gmpz_realloc () from
1 - 100 of 178 matches
Mail list logo
