Lets suppose I build GNU's sed using gcc 4.2.0 on AIX. At link time,
the flag -L/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0/../../.. is
passed along with -L/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/4.2.0 to
ld. sed links and runs fine.
In the executable, this list of paths is kept and
From: "Tobias Burnus"
Hi Kaveh,
Kaveh R. GHAZI wrote:
I'm trying to create complex number expressions that contain inf or
nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I).
If it does not need to be C (e.g. to try MPC in the middle end), you
could use Fortran:
! compile with gfor
Dear mailing list:
My research group (the High-Confidence Operating Systems group at
Stony Brook University;
home page http://www.fsl.cs.sunysb.edu/hcos/) continues to use a
modified branch of
Subversion GCC that hosts plug-ins written in C, C++, and (with a
little work) Python.
We publis
-msym32 changes DWARF's address_size from 64 bits to 32 bits. This means that
while symbols are 64-bit (due to ELF64), target addresses in the debug info
are 32-bit.
There is support for this in DWARF of course in fact you can specify different
address_size for each compilation unit which nicely
Gerald Pfeifer wrote:
>> We should just update the licenses on the trunk. The change from GPLv2
>> to GPLv3 in the midst of the 4.2.x release cycle was confusing to
>> people. I see no reason to do that again.
>
> This matches my understanding as well. I do believe that GCC 4.4 should
> be re
On Wed, 28 Jan 2009, Mark Mitchell wrote:
> Joseph S. Myers wrote:
>> Will the transition to use GPLv3+exception need to be made on release
>> branches before any more releases are made from them (so that if anyone
>> should volunteer to the SC to make any further 4.2 releases, before the
>> poi
Snapshot gcc-4.4-20090130 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090130/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Michael Meissner wrote:
> I am just starting to think about adding OpenCL support into future
> versions of GCC, as it looks like a useful way of programming highly
> parallel type systems, particularly with hetrogeneous processors. At
> this point, I am wondering what kind of interest people have
On Fri, Jan 30, 2009 at 03:08:47PM +0100, Basile STARYNKEVITCH wrote:
> Hello All,
>
> OpenCL http://www.khronos.org/opencl/ is a new standard proposing an API
> for GPUs (targetting vector processing on heterogenous systems, like GPU
> + CPU). It suggests some restricted & specialized C dialect
Sebastian Redl writes:
> Ian Lance Taylor wrote:
>> LLVM byte code is generated by LLVM, not gcc. The question here is
>> whether it is desirable to permit using LLVM to generate LLVM byte
>> code and to then use GCC to turn that byte code into machine code.
>> (It will not be desirable
Ian Lance Taylor wrote:
> LLVM byte code is generated by LLVM, not gcc. The question here is
> whether it is desirable to permit using LLVM to generate LLVM byte
> code and to then use GCC to turn that byte code into machine code.
> (It will not be desirable to apply the exception if GCC i
After the e-mail flurry, here is my personal summary of the issues
regarding the GCC Runtime Library Exception
(http://www.gnu.org/licenses/gcc-exception.html). I personally think
that this includes all the substantive issues which were raised,
though I understand that others may disagree.
* The
Quoting Joe Buck :
On Thu, Jan 29, 2009 at 04:34:09AM -0800, Joern Rennecke wrote:
Quoting Ian Lance Taylor :
> I'm not sure what your point is here. newlib is not under the GPL in
> any case. It is not affected by the gcc runtime library license.
The old runtime library exception allowed yo
On Thu, Jan 29, 2009 at 04:34:09AM -0800, Joern Rennecke wrote:
> Quoting Ian Lance Taylor :
> > I'm not sure what your point is here. newlib is not under the GPL in
> > any case. It is not affected by the gcc runtime library license.
>
> The old runtime library exception allowed you to distribu
Дмитрий Дьяченко wrote:
> Hello, g++-current ( [trunk revision 143790] ) produce incorrect
> warning. Need I file bug-report?
>
No need, thanks, we have already middle-end/38937. If you want, you can
add to it your testcase, useful in order to better test the patch linked
therein on i686-linux (
enable-__cxa_atexit
--enable-version-specific-runtime-libs --enable-languages=c,c++
--no-create --no-recursion
Thread model: posix
gcc version 4.4.0 20090130 (experimental) [trunk revision 143790] (GCC)
# uname -a
Linux localhost.localdomain 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 19:19:45
EST 2008 i686 i686 i386 GNU/Linux
Hello All,
OpenCL http://www.khronos.org/opencl/ is a new standard proposing an API
for GPUs (targetting vector processing on heterogenous systems, like GPU
+ CPU). It suggests some restricted & specialized C dialect to code
"kernel" functions (kernel in OpenCL means running on the GPU).
Is
Hello,
I try to make modulo scheduling work more efficiently for our VLIW target. I
found one serious issue that prevents current SMS algorithm from achieving high
IPC is so-called "transitive closure" problem, where scheduling window is only
calculated using direct predecessors and successors.
> This sounds like a genuine bug in gcc, then. As far as I can see,
> Andrew is right -- if the ARM hardware requires a legitimate object
> to be placed at address zero, then a standard C compiler has to use
> some other value for the null pointer.
I think changing that would cause more trouble th
Andy Armstrong wrote:
The ARM exception table looks like this:
0x Reset
0x0004 Undefined instruction
0x0008 Software interrupt
0x000C Prefetch Abort
0x0010 Data Abort
0x0014 Reserved
0x0018 IRQ
0x001C FIQ
so only the reset vector is at 0.
Right, so the res
Ross Smith wrote:
This sounds like a genuine bug in gcc, then. As far as I can see, Andrew
is right -- if the ARM hardware requires a legitimate object to be
placed at address zero, then a standard C compiler has to use some other
value for the null pointer.
That's not quite the story. It's
On 30 Jan 2009, at 05:11, Ross Smith wrote:
Zoltán Kócsi wrote:
On Thu, 29 Jan 2009 08:53:10 +
Andrew Haley wrote:
We're talking about gcc on ARM. gcc on ARM uses 0 for the null
pointer constant, therefore a linker cannot place an object at
address zero. All the rest is irrelevant.
Um, t
22 matches
Mail list logo
