Qifei Fan wrote:
But insn#479 is not recognized by recog() in insn-recog.c and the
compilation failed. (recog only recognizes RTL defined in md, right?)
Here the backtrace is
reload---cleanup_subreg_operands---extract_insn_cached---extract_insn-=
--recog_memoized---recog.
There is no
Should have gone here I suppose...
2010/1/25 Christian Joensson:
Hi Dave.
I see you're busy with your cygwin improvement branch... however, I
just want to give you a heads up, as for a some time, I can't build
gcc trunk, there's something with libgomp that's quite wrong.
libtool: link:
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as uint32_t/uint64_t and use
the result as a parameter for an integral hash().
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpose) register as the address, without any offset:
LOAD (R2) R1; load R1 from memory at address (R2)
STORE R1 (R2) ;
Piotr Wyderski piotr.wyder...@gmail.com writes:
However, GCC warns me about strict aliasing
rules violation, which is technically correct, but
in this case is intended. How do I perform this
conversion ina GCC-friendly way? Even that
produces a warning:
inline hash_type hash(float v) {
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as
Quoting Christian Joensson christian.joens...@gmail.com:
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Does the cygwin build work with the attached patch?
2010-01-23
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as
The use of anonymous structure does seem to be the problem. I also missed the
fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE
_DEF DIE was in the DWARF data, I could still parse the anonymous type.
Do you think the TYPE_DEF DIE should be part of the output? Is this a
On 01/25/2010 02:42 PM, Erik Trulsson wrote:
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for all integral
types. I want to provide a variant for
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpose) register as the address, without any offset:
LOAD (R2) R1
On Mon, Jan 25, 2010 at 3:42 PM, Erik Trulsson ertr1...@student.uu.se wrote:
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for
all integral types.
Andrew Haley wrote:
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
Of course it is allowed. It's a legitimate gcc extension, and it's
supported by many other compilers too.
It's a C extension, according to the documentation.
In C++ mode
Ron Louzon wrote:
The use of anonymous structure does seem to be the problem. I also missed the
fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE
_DEF DIE was in the DWARF data, I could still parse the anonymous type.
Do you think the TYPE_DEF DIE should be part of the
On 01/25/2010 03:04 PM, Joern Rennecke wrote:
Quoting Christian Joensson christian.joens...@gmail.com:
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Ok.
Paolo
On 25/01/2010 14:04, Joern Rennecke wrote:
Quoting Christian Joensson christian.joens...@gmail.com:
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Does the cygwin
Timothy Madden terminato...@gmail.com writes:
On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor i...@google.com wrote:
Timothy Madden terminato...@gmail.com writes:
Why is it so hard to store template definitions (and the set of
symbols visible to them) in an
object file, probably as a
Quoting Dave Korn dave.korn.cyg...@googlemail.com:
On 25/01/2010 14:04, Joern Rennecke wrote:
Quoting Christian Joensson christian.joens...@gmail.com:
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if
Gabriel Paubert wrote:
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpose) register as the address, without any offset:
Jon Grant j...@jguk.org writes:
I see that some of the files are located in the -L library directory
specified, crtbegin.o, crtend.o in which case, perhaps they both do
not need their full long path specified.
Most linkers do not use the -L path to search for file names on the
command line.
Bernd Roesch wrote:
a call of a function and return value with double float is on all
m68k-amigaos compiler (that use only other 68k config files but
same main source) as this.
jsr testfunc
move.l d1,-(sp)
move.l d0,-(sp)
fdmove.d (sp)+,fp1
fsmove.x fp1,fp0
lea (16,sp),sp
On 01/25/10 11:21, Sergio Ruocco wrote:
Gabriel Paubert wrote:
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
2010/1/25 Joern Rennecke:
Quoting Dave Korn dave.korn.cyg...@googlemail.com:
On 25/01/2010 14:04, Joern Rennecke wrote:
Quoting Christian Joensson christian.joens...@gmail.com:
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap
Quoting Christian Joensson christian.joens...@gmail.com:
FWIW, I still get a problem, this:
Could you show the log file from a successful libgomp build with a previous
version?
Did it usea different ar?
Hi Sergio. My port has similar addressing modes - all memory must be
accessed by one of two registers and can only be accessed indirectly,
indirect with pre increment, and indirect with post increment. The
key is GO_IF_LEGITIMATE_ADDRESS and the legitimate address helper
function. Mine looks
On 25/01/2010 19:31, Joern Rennecke wrote:
Quoting Christian Joensson christian.joens...@gmail:
FWIW, I still get a problem, this:
Could you show the log file from a successful libgomp build with a previous
version?
Did it usea different ar?
It should look something like this:
On 25 January 2010 15:51, Piotr Wyderski:
Andrew Haley wrote:
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
Of course it is allowed. It's a legitimate gcc extension, and it's
supported by many other compilers too.
It's a C extension,
On 25/01/2010 20:19, Dave Korn wrote:
am bootstrapping r156219 ATM.
Not finished yet, but I may have seen a problem already:
make[4]: Leaving directory `/gnu/gcc/obj2/i686-pc-cygwin/libgcc'
make[3]: Leaving directory `/gnu/gcc/obj2/i686-pc-cygwin/libgcc'
mkdir -p -- i686-pc-cygwin/libgomp
This probably is a new version of PR41418 then. We have the problem that
fortran is turned on in --enable-languages, so libgomp configure expects the
fortran compiler to be available.
Does this fix it for you?
Index: configure.ac
On 25/01/2010 20:58, Paolo Bonzini wrote:
This probably is a new version of PR41418 then. We have the
problem that
fortran is turned on in --enable-languages, so libgomp configure
expects the
fortran compiler to be available.
Does this fix it for you?
That succeeded for rm -rf
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Why is it still useful on recent GNU/Linux systems?
In general, it's not. But future versions of gcc may want changes to
current versions of glibc. We've seen that happen in the past, and it
is likely to happen again in the future. (E.g.,
On Sun, Jan 24, 2010 at 08:26:04PM -0500, Olexa Bilaniuk wrote:
I am on Mac OS X Snow Leopard. There has been some noise around the
forums that GCC fails for various reasons. It turns out that despite
having all the requirements to run 64-bit systems, including a 64-bit
processor (an Intel
On 25/01/2010 22:38, Dave Korn wrote:
On 25/01/2010 20:58, Paolo Bonzini wrote:
Does this fix it for you?
That succeeded for rm -rf i686-pc-cygwin/libgomp; make
configure-target-libgomp all-target-libgomp. I'll leave a full bootstrap
running overnight
That completed fine.
On 01/25/2010 11:38 PM, Dave Korn wrote:
On 25/01/2010 20:58, Paolo Bonzini wrote:
This probably is a new version of PR41418 then. We have the
problem that
fortran is turned on in --enable-languages, so libgomp configure
expects the
fortran compiler to be available.
Does this fix it
--- Comment #18 from jakub at gcc dot gnu dot org 2010-01-25 08:22 ---
It is no longer marged regression, so no longer release critical.
Anyway, the goal should be to reenable the asserts in dwarf2out.c and fix the
issues, because they really result in wrong unwind info. Only the
--- Comment #8 from mario-baumann at web dot de 2010-01-25 08:24 ---
Hi Jonathan, thanks for the hint!
I attached a version (goo.cpp) without boost.
g++ -c goo.cpp
goo.cpp: In member function 'void EvalT::eval(int_0) [with int V = 0, T =
Mtrl]':
goo.cpp:42:9: instantiated from
--- Comment #9 from mario-baumann at web dot de 2010-01-25 08:26 ---
Created an attachment (id=19702)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19702action=view)
new c++ source file (independent of boost)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 08:30 ---
(In reply to comment #3)
Today I am not able to reproduce the error. The compiler is working. Where
exactly does the file m.mod reside? In the user directory or in a compiler
directory?
By default in the current
--- Comment #5 from frank dot braun at rz dot uni-regensburg dot de
2010-01-25 08:36 ---
've got it. Modifying the .mod file by hand makes the compiler crash. Deleting
it lets it work correctly.
The compiler shouldn't crash anyway. But with a new version this problem should
be solved
--- Comment #2 from mikpe at it dot uu dot se 2010-01-25 09:33 ---
I had very recently updated binutils from 2.19.1 to 2.20 + branch updates +
some fixes from trunk. Going back to binutils 2.19.1 while changing nothing
else eliminated the StackTrace2 and Throw_3 failures from gcc-4.3.
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 09:37 ---
(In reply to comment #3)
This appears to fix this: regression tested on x86-64
I think the following patch is better. My intrinsic check was bogus.
Index: array.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-25 09:56 ---
Confirmed. Reducing.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-25 10:06 ---
I suppose this is from rths exception rewrite.
void start (void);
void ptw32_terminate (void)
{
try {
start ();
}
catch( int ) { }
catch( int ) { }
}
--
rguenth at gcc dot gnu dot org changed:
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10
---
Ok, I see that asking was a good idea, the tangle of issues is quite complex.
Anyway, this is my current proposal: let' use for now your mildly optimized and
in any case correct solution using a loop of
--- Comment #4 from bugs at 59A2 dot org 2010-01-25 10:33 ---
(In reply to comment #3)
So it's gfortran's fault you write non-portable code, and instead
of dealing with it on your end, you think that gfortran developers
should do the work to make your code compile.
Actually,
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-01-25 10:38 ---
I understand that the bootstrap problem is PR 42836 and is now fixed
(thanks for that). SRA now removes the structures in the testcase
from bug description and so I consider this to be fixed.
--
jamborm at gcc
PR37815 introduced a regression - no decls are tracked in spill slots, as they
have MEM_EXPR set to get_spill_slot_decl (false) instead of the real decl.
On the testcase I'm going to attach, the tok argument is (and clearly has to
be) live through the whole function except maybe last few
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 11:45 ---
Created an attachment (id=19703)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19703action=view)
parsetok.c.bz2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 12:03 ---
This is completely undocumented attribute, so you first need to get Apple to
actually document what it does and get the documentation into doc/extend.texi.
Especially nothing explains the relationship between weak
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
--- Comment #9 from ramana at gcc dot gnu dot org 2010-01-25 12:29 ---
Subject: Bug 38697
Author: ramana
Date: Mon Jan 25 12:29:25 2010
New Revision: 156206
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156206
Log:
Backport target/38697
Backport from trunk.
--- Comment #10 from ramana at gcc dot gnu dot org 2010-01-25 12:30 ---
Fixed on branch .
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-25 12:53 ---
This is completely undocumented attribute ...
What is the undocumented attribute? If you mean
-fno-asynchronous-unwind-tables, you don't need it for the tests to fail.
--
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-25 12:59 ---
I mean that
grep weak_import doc/*
yields nothing at all (and google for weak_import doesn't show up any useful
documentation either).
It seems that Geoff Keating's implementation of the attribute (how could it be
--- Comment #2 from ro at gcc dot gnu dot org 2010-01-25 14:54 ---
Subject: Bug 41522
Author: ro
Date: Mon Jan 25 14:54:15 2010
New Revision: 156213
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156213
Log:
PR testsuite/41522
* gcc.c-torture/compile/pr38789.c:
--- Comment #3 from ro at gcc dot gnu dot org 2010-01-25 14:55 ---
Mine.
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc
--- Comment #4 from ro at gcc dot gnu dot org 2010-01-25 14:56 ---
Fixed for 4.5.0:
http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01255.html
--
ro at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from burnus at gcc dot gnu dot org 2010-01-25 16:22 ---
Subject: Bug 42858
Author: burnus
Date: Mon Jan 25 16:21:42 2010
New Revision: 156214
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156214
Log:
2010-01-25 Tobias Burnus bur...@net-b.de
PR
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-25 16:24 ---
And FIXED. Thanks a lot for the report and sorry for breaking the code!
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenther at suse dot de 2010-01-25 16:29 ---
Subject: Re: Revisit std::function for aliasing
issues
On Mon, 25 Jan 2010, paolo dot carlini at oracle dot com wrote:
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10
---
Ok, I
--- Comment #4 from uramakrishna at gmail dot com 2010-01-25 16:30 ---
Created an attachment (id=19704)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19704action=view)
A further reduced case to show the ICE
Unable to find non-zero value for 'known_niter'.
--
GCC Version: 3.4.4 and 4.1.2
The GNU 4.1.2 C++ compiler is not generating the proper typedef DIEs in the
DWARF data.
For example, the type definition BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
The GNU 4.1.2 compiler generates the following
--- Comment #5 from amonakov at gcc dot gnu dot org 2010-01-25 17:06
---
We fail to find number of iterations after rewriting reductions out of SSA.
Before graphite pass, IR looks like (for the previous testcase, pr42771.c):
bb 9:
# j_26 = PHI j_20(10)
bb 10:
# j_33 = PHI
--- Comment #2 from zsojka at seznam dot cz 2010-01-25 17:34 ---
Since:
r155937 | rguenth | 2010-01-15 12:53:26 +0100 (Fri, 15 Jan 2010) | 10 lines
2010-01-15 Richard Guenther rguent...@suse.de
PR
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-25 17:36
---
Ageeed. Indeed, I see there is a discussion ongoing. In the present time frame
let's figure out something minimally invasive, decently (if not perfectly)
optimized, and minimally coupled one way or the other
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
--- Comment #20 from jamborm at gcc dot gnu dot org 2010-01-25 17:51
---
(In reply to comment #6)
I think if we get the old SRA behavior back for this code, we will get this
optimization in 4.5 since we remove the sptr-base and the other unnecessary
store during PRE.
We now
--- Comment #29 from amylaar at gcc dot gnu dot org 2010-01-25 18:01
---
Subject: Bug 36101
Author: amylaar
Date: Mon Jan 25 18:01:29 2010
New Revision: 156218
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156218
Log:
PR libstdc++/36101, PR libstdc++/42813
*
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-01-25 18:01 ---
Subject: Bug 42813
Author: amylaar
Date: Mon Jan 25 18:01:29 2010
New Revision: 156218
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156218
Log:
PR libstdc++/36101, PR libstdc++/42813
*
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-01-25 18:02 ---
Since PR 42585 is fixed, the optimized dump (at -O2) is
bb 2:
_T2$curr_12 = sptr_1(D)-curr;
D.1966_7 = _T2$curr_12 + -1;
sptr_1(D)-curr = D.1966_7;
return 0;
}
The generated assembly is:
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-25 18:24 ---
On i?86-linux -fomit-frame-pointer is not the default, on the contrary.
info gcc says:
`-O' also turns on `-fomit-frame-pointer' on machines where doing
so does not interfere with debugging.
and i?86-linux
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-01-25 18:30 ---
I have found the sentence you quoted in the manual too but it refers
only to -O1 (as far as I understand it). And the description of
-fomit-frame-pointer simply states that Enabled at levels -O, -O2,
-O3, -Os. So
--- Comment #10 from bangerth at gmail dot com 2010-01-25 18:39 ---
This works with gcc 4.3 and 4.4 I don't have mainline lying around
here but if it really fails there it would be a 4.5 regression
which should get it P1 status. Can someone try?
W.
--
bangerth at gmail dot com
--- Comment #3 from bangerth at gmail dot com 2010-01-25 18:42 ---
Someone on a win64 machine may have to check this.
W.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
This is a general m68k code generation regression. Starting with revision
150588 GCC for m68k generates surprising code for auto increments, eg.
for a strlcpy implementation. Compiling this code with the 4.5.0 snapshot
from 20100107 yields:
-- 4.5.0 --
_strlcpy:
movel d3,s...@-
--- Comment #11 from redi at gcc dot gnu dot org 2010-01-25 19:44 ---
Confirmed
pr42824.cc: In member function void EvalT::eval(int_0) [with int V = 0, T
= Mtrl]:
pr42824.cc:42:9: instantiated from void EvalT::eval() [with int V = 0, T =
Mtrl]
pr42824.cc:65:20: instantiated
--- Comment #2 from schwab at linux-m68k dot org 2010-01-25 19:44 ---
m68k-unknown-amigaos is not a valid target.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-01-25 19:46 ---
Mine. Got a patch.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from redi at gcc dot gnu dot org 2010-01-25 19:47 ---
CC'ing a release manager
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.5.0
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-01-25
20:20 ---
Mike Stump's comment on Geoff's implementation of the attribute weak_import in
FSF gcc is...
Not earth shattering, it just sets .weak_definition or .weak_reference for
the assembler. google can find
$ cat test.cpp
#include string
int main()
{
std::string( (unsigned) 2, (unsigned) 'M' );
}
$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--- Comment #1 from kasey dot erickson at gmail dot com 2010-01-25 20:23
---
Created an attachment (id=19705)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19705action=view)
preprocessed file
output from -save-temps
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-01-25 21:10 ---
First, something has gotten better; an arm-eabi gcc (-O2 -std=c99 -mcpu=arm9
-funroll-loops) from 20091209 gives:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
For this code:
program F03_2_9_4_1_1a
implicit none
logical :: fail = .false.
call sub1(fail)
if (fail) stop 1
contains
subroutine sub1(fail)
use omp_lib
implicit none
integer, parameter :: NT = 4
logical :: fail
integer :: i
real, allocatable, save :: A(:)
--- Comment #2 from redi at gcc dot gnu dot org 2010-01-25 21:29 ---
*** This bug has been marked as a duplicate of 42261 ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from redi at gcc dot gnu dot org 2010-01-25 21:29 ---
*** Bug 42864 has been marked as a duplicate of this bug. ***
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
For this test case:
program F03_2_9_3_6_2c
! derived from OpenMP test omp3f/F03_2_9_3_6_2c.f90
! REFERENCES
! OpenMP 3.0, p. 100, lines 10-12
! OpenMP 3.0, p. 316, lines 18-22
use omp_lib
implicit none
integer, parameter :: NT = 4
integer :: thread_num1, thread_num2,
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-25 21:59 ---
Mike Stump's comment on Geoff's implementation of the attribute weak_import in
FSF gcc is...
Could you give a pointer?
The first test was introduced by this patch
The problem is that the definition of isfinite() macro is not consistent
between version of GCC 4.3.3 and 4.4.1.
Simple test program:
include math.h
#ifdef isfinite
#error isfinite defined
#else
#error isfinite NOT defined
#endif
int main() { return 0; }
1) Test with GCC 4.4.1 (Ubuntu 9.10
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-25 22:26 ---
isfinite is C99 only.
Plus math.h is controlled by libc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-25 22:30
---
Boy, this curious way of constructing strings seems rather fancy lately ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
--- Comment #2 from mateusz at loskot dot net 2010-01-25 22:34 ---
(In reply to comment #1)
isfinite is C99 only.
Yes, of course it is and I understand it, but I'm trying to understand why the
GCC 4.3 and 4.4. behave differently?
Does it mean GCC 4.4 makes C99 elements available
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-25 22:37 ---
It depends. But really you did report it to us rather than Ubuntu first as
both are modified versions of GCC. Also you should look to see if they are
using the same version of glibc. Because maybe glibc was fixed
--- Comment #3 from meissner at gcc dot gnu dot org 2010-01-26 00:40
---
Created an attachment (id=19706)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19706action=view)
Proposed patch to fix the problem
Patch to add 3 new switches to tune whether to use a combination of
The following test case ICEs gcc-4.4.3 on sparc64 when compiled with -fPIC -m64
and any optimization level = -O1.
cat cpu_stats.i
extern int end, etext, edata;
long util_print_cpu_stats(void)
{
long vm_text, vm_init_data, vm_uninit_data, vm_sbrk_data;
vm_text = (long) (((long) (etext))
--- Comment #1 from mikpe at it dot uu dot se 2010-01-26 01:36 ---
Created an attachment (id=19707)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19707action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42868
The Itanium code for GOMP_start_critical starts
0x20334900 GOMP_critical_start:
[MMI] alloc r16=ar.pfs,1,1,0
0x20334901 GOMP_critical_start+1: addl r32=840,r1
0x20334902 GOMP_critical_start+2: nop.i 0x0
0x20334910
--- Comment #11 from chrbr at gcc dot gnu dot org 2010-01-26 07:20 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:20:27 2010
New Revision: 156229
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156229
Log:
fix PR target/42841
Modified:
trunk/gcc/ChangeLog
--- Comment #12 from chrbr at gcc dot gnu dot org 2010-01-26 07:22 ---
Subject: Bug 42841
Author: chrbr
Date: Tue Jan 26 07:21:57 2010
New Revision: 156230
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156230
Log:
fix PR target/42841
Modified:
1 - 100 of 103 matches
Mail list logo
