Hello Everyone
I wanted to let you know that if there is someone interested in
working on the libJIT approach instead of using LLVM overkill under a
Google Summer of Code code project and more general on this topic or
as a diploma I am ready to mentor and help with this.
Thanks,
Kirill
On Thu, Apr 16, 2009 at 02:08:32PM +0200, Roberto Bagnara wrote:
All the problems of PPL 0.10.1 we are aware of have been
fixed in the snapshot of PPL 0.10.2 available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
In particular here is what has changed:
- Correctly detect GMP 4.3.0.
-
On Thu, 16 Apr 2009 14:08:32 +0200
Roberto Bagnara bagn...@cs.unipr.it wrote:
All the problems of PPL 0.10.1 we are aware of have been
fixed in the snapshot of PPL 0.10.2 available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
In particular here is what has changed:
- Correctly
On Apr 16, 2009, at 8:44 PM, Joe Buck wrote:
On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote:
The rock has dropped. The answer is quoted below:
My best guess is that a header file is included twice, and lacks
guards, hence the message is correct: the function is being
At least, let's get it archived on GCC mailing lists.
On Fri, Apr 17, 2009 at 11:25 AM, Torbjorn Granlund t...@gmplib.org wrote:
Vincent Lefevre vinc...@vinc17.org writes:
FYI, here's a simple testcase:
/* With GCC 4.3.2 and -O2 option: output value is 1 instead of 0.
* If
Joe == Joe Buck joe.b...@synopsys.com writes:
Joe If, for definitions, the compiler keeps track of this detail, it
Joe would be possible to reliably print
Joe foo.h:11 error: redefinition of `a' (file was included more than once)
Joe if the printable line number is the same but the internal line
On Fri, Apr 17, 2009 at 11:58:48AM -0600, Tom Tromey wrote:
Chris Clang just prints the include stack information when anything
Chris in the include stack differs between two consecutive
Chris diagnostics.
We could easily do that too.
FWIW, I think this would be quite useful.
--
Daniel
Hi all,
My target architecture has an load multiple instruction requiring a
certain number of consecutive registers. I've been working on handling
this case and trying to convince the local register allocator that he
really does want to try to get those consecutive registers for the
loads. But
One of the many options is in using the Common Intermediate Language
and .NET to store portable programs. Does this sound like a good idea
to you?
.NET has been design to be as much portable as possible.
You should understand that it is not the best way of handling of other
people work with a
On Fri, Apr 17, 2009 at 12:10:27PM -0700, Kirill Kononenko wrote:
One of the many options is in using the Common Intermediate Language
and .NET to store portable programs. Does this sound like a good idea
to you?
To the extent that the effect is to create a portable binary format,
I expect
Joe Buck wrote:
On Fri, Apr 17, 2009 at 12:10:27PM -0700, Kirill Kononenko wrote:
One of the many options is in using the Common Intermediate Language
and .NET to store portable programs. Does this sound like a good idea
to you?
To the extent that the effect is to create a portable binary
On Fri, Apr 17, 2009 at 01:14:40PM -0700, Mark Mitchell wrote:
Joe Buck wrote:
On Fri, Apr 17, 2009 at 12:10:27PM -0700, Kirill Kononenko wrote:
One of the many options is in using the Common Intermediate Language
and .NET to store portable programs. Does this sound like a good idea
to
Hi Guys,
I see the following in the changes for GCC 4.4:
Support for a number of older systems and recently unmaintained or
untested target ports of GCC has been declared obsolete in GCC 4.4.
Unless there is activity to revive them, the next release of GCC will
have their sources permanently
On Fri, 17 Apr 2009, Paul Smedley wrote:
* Generic a.out on IA32 and m68k (i[34567]86-*-aout*,
m68k-*-aout*)
For the record, the Generic a.out support for IA32 is used by my GCC
4.3.3 and upcoming GCC 4.4.x ports for OS/2. I don't yet have the
patches in any form ready enough to be
This bug report only concerns gnatxref not the gnat compiler.
Given the following :
package bug_op is
type Vector is array (1 .. 1) of Integer;
function (A, B : Vector) return Vector;
end bug_op;
with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
package body bug_op is
V : Vector;
function
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-04-17 08:26
---
Ah. I see what goes on then. The new logic assumes that GOMP_barrier does not
change shrd (which is a local non-address-taken static variable in main,
accessed from the OMP clone main.omp_fn.0). This is of
--- Comment #2 from jakub at gcc dot gnu dot org 2009-04-17 08:47 ---
Subject: Bug 39792
Author: jakub
Date: Fri Apr 17 08:46:52 2009
New Revision: 146223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146223
Log:
PR testsuite/39792
* g++.dg/ext/complit11.C: Add
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-17 08:54 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
The following testcase aborts with -O2 -funroll-loops, but passes with plain
-O2 for me on today's trunk.
--cut here
extern void abort();
void foo(int *a, int n)
{
int i;
for (i = 0; i n; i++)
{
a[i] *= 2;
a[i+1] = a[i-1] + a[i-2];
}
}
enum {N = 16};
int a[N];
int
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-17 10:12
---
Frankly, I don't think this is an issue. What we really want, is that all
inline functions get inlined anyway, debug mode or not, and this is correctly
happening, as far as I can see. Out of line functions are
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-17 09:23 ---
We had this for a short time but then see
2009-02-24 Richard Guenther rguent...@suse.de
PR c++/39242
* pt.c (instantiate_decl): Do not instantiate extern, non-inline
declared functions.
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-17 09:18 ---
This would be inlining of static-initialization-and-destruction functions
if they get optimized to return a constant initializer.
It's not easy to do as they cannot be easily removed late in the compilation.
Of
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.4.0 4.5.0
Known to work||4.3.2
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-04-17 10:29
---
Subject: Bug 39746
Author: rguenth
Date: Fri Apr 17 10:29:26 2009
New Revision: 146240
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146240
Log:
2009-04-17 Richard Guenther rguent...@suse.de
PR
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
On the SPU, all single-precision floating-point arithmetic always
takes place in round-to-zero rounding mode. The Fortran front-end
always assumes round-to-nearest mode. This causes a number of issues:
- Both real-string and string-real transformations (e.g. printf, scanf)
operate in
--- Comment #16 from rguenth at gcc dot gnu dot org 2009-04-17 10:29
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from ramana at gcc dot gnu dot org 2009-04-17 11:07 ---
Created an attachment (id=17650)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17650action=view)
Patch being tested
Here is a rather hackish patch that I'm testing. It looks correct so far with
the case of
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P5 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39794
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-17 12:19 ---
-fno-ivopts also fixes this. The unrolling happening on the RTL level
for the loop in foo() somehow is broken.
We end up with
(gdb) p a
$1 = {0, 1, 4, 2, 10, 12, 24, 44, 72, 18, 20, 22, 24, 26, 28, 50}
(gdb) p
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-17 10:50 ---
Thus, wontfix.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-17 09:14 ---
Confirmed. The code was accepted with 3.3.6
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from paolo dot carlini at oracle dot com 2009-04-17 10:27
---
Of course s/extern inline/extern template
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38132
--- Comment #1 from charlet at gcc dot gnu dot org 2009-04-17 13:39 ---
Subject: Bug 35953
Author: charlet
Date: Fri Apr 17 13:39:10 2009
New Revision: 146267
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146267
Log:
2009-04-17 Thomas Quinot qui...@adacore.com
PR
--- Comment #2 from charlet at gcc dot gnu dot org 2009-04-17 13:41 ---
Fixed on trunk
--
charlet at gcc dot gnu dot org changed:
What|Removed |Added
libstdc++ ensures that cin/cout/cerr are constructed before they are used, but
the scheme fails when using constructor priorities. Constructors with a
priority are run before constructors without a priority, which is the
appropriate behaviour. However, this means that this program:
#include
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-17 15:06
---
I see. I would be tempted to ask you to propose a fix at once, seems pretty
simple, basically a bit of configury and very few lines of actual code.
However, I wonder if we have something similar elsewhere, I
Version Info:
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--- Comment #1 from stephanemarcotte at 3d-p dot com 2009-04-17 15:27
---
Created an attachment (id=17651)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17651action=view)
Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
--- Comment #2 from stephanemarcotte at 3d-p dot com 2009-04-17 15:27
---
Created an attachment (id=17652)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17652action=view)
the .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
--- Comment #3 from stephanemarcotte at 3d-p dot com 2009-04-17 15:38
---
Isolate to the method:
Matrix::MatrixT,M,N operator*=( double f ) ...
The template takes 2 args, but the above makes g++ crash. If I take out one
parameter (e.g., MatrixT, M), then I get a compiler error as
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-17 15:40
---
I can reproduce only with 4_2-branch (no longer maintained) and 4_3-branch. I
can't with 4_4-branch and mainline.
--
paolo dot carlini at oracle dot com changed:
What|Removed
--- Comment #5 from stephanemarcotte at 3d-p dot com 2009-04-17 15:41
---
Also, if I remove the derivation from the MatrixBase abstract base class, the
error disappears.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
--- Comment #6 from stephanemarcotte at 3d-p dot com 2009-04-17 15:45
---
the template also declares the methods M() and N(), when M, N are also template
parameters. (The code snippet is obviously buggy.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-17 16:41 ---
As per comment above appears fixed in all release branches today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
In C++, the statement 'k = int()' will zero 'k'. This somewhat inconsistent
behavior (e.g. initialize a struct with a default constructor is a no-op) is
somewhat annoying because it results in all STL containers zeroing their
contents. I've encountered a few rare cases where this resulted in a
The following code:
inline int foo(int x)
{
return x;
}
static void bar(int a, int *ptr)
{
do
{
int b;
if (b 40)
{
ptr[0] = b;
}
b += 1;
ptr++;
}
while (--a != 0);
}
void foobar(int a, int *ptr)
{
bar(foo(a), ptr);
}
generates correct warning when
Reported by Alexei Matveev at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ed70666b0c90b655
* * *
The following does not make sense:
MODULE m
TYPE, PRIVATE :: type; ...
CONTAINS
SUBROUTINE foo()
TYPE :: bar
TYPE(type) :: x
The last line is rejected with
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-17 20:49 ---
g++-4.3 -S t.C
t.C:21: error: could not convert template argument MatrixBase::M to unsigned
int
t.C:21: error: could not convert template argument MatrixBase::N to unsigned
int
t.C: In member function const
Some builtin functions are marked as not throwing exceptions, even when
-fnon-call-exceptions is in use. As a result, the compiler will assume these
functions will not throw exceptions -- but they might. For example, the buitin
va_arg might cause a SEGV, which would become an exception, if the
--- Comment #2 from dnovillo at gcc dot gnu dot org 2009-04-17 20:51
---
Proposed patch: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01379.html
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-17 20:55 ---
This is because we zero-initialize uninitialized variables during inlining.
Honza, do you remember why we do this?
/* By inlining function having uninitialized variable, we might
extend the
--- Comment #3 from dnovillo at gcc dot gnu dot org 2009-04-17 21:12
---
Subject: Bug 31567
Author: dnovillo
Date: Fri Apr 17 21:11:46 2009
New Revision: 146292
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146292
Log:
PR 31567
* gcc.c (create_at_file): New.
--- Comment #4 from dnovillo at gcc dot gnu dot org 2009-04-17 21:13
---
Fixed.
--
dnovillo at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31567
--- Comment #2 from andris dot pavenis at iki dot fi 2009-04-17 21:15
---
One needs additional information (like preprocessed source,
used operating system etc.) to do anything with this bug report.
See page http://gcc.gnu.org/bugs.html (already mentioned
in GCC error message) for
--- Comment #2 from amonakov at gcc dot gnu dot org 2009-04-17 21:55
---
I attempted to investigate the miscompilation on the 4.4 branch.
The problem seems to appear in dse2 pass. Basically, after encountering
313 dx:DI=ax:DI+0x4
187 {[di:DI+dx:DI]=[di:DI+dx:DI]0x1;clobber
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-17 22:06 ---
Best to CC Zadeck on DSE problems.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jb at gcc dot gnu dot org 2009-04-17 22:13 ---
I'm not sure how this could be fixed in a proper way without breaking the
procedure call ABI. Gfortran follows pretty much every other Fortran compiler
in providing character length as a hidden argument of type default
--- Comment #1 from jb at gcc dot gnu dot org 2009-04-17 22:18 ---
Confirmed, assigning to myself.
--
jb at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kkojima at gcc dot gnu dot org 2009-04-17 22:20 ---
Subject: Bug 38627
Author: kkojima
Date: Fri Apr 17 22:20:40 2009
New Revision: 146297
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146297
Log:
PR target/38627
* config/sh/lib1funcs.asm
A call to std::num_get fails to parse negative values (specifically -0 in my
example).
/** Begin Test **/
#include cassert
#include locale
#include sstream
int main ()
{
unsigned long val = 1;
std::stringbuf sb (-0);
std::istream is (sb);
std::ios_base::iostate err
--- Comment #10 from anmol at freescale dot com 2009-04-17 22:39 ---
I am working on this problem and see that for generic ELF OS's,
defining ASM_DECLARE_OBJECT_NAME (gcc/config/elfos.h) to use the
size of the initializer (as against the size of the type) to emit
the true size in the
--- Comment #7 from dominiq at lps dot ens dot fr 2009-04-17 22:42 ---
Compiling the code in comment #1 gives:
[ibook-dhum] f90/bug% gfc42 pr31243.f90
pr31243.f90:12.15:
print *, len(ch)
1
Error: Result of LEN overflows its kind at (1)
It compiles with
When compiling the following program using the mainline GCC (4.5) with -Wunused
flag, we get a bogus unused value warning on the array declaration:
$ cat Wunused-14.C
#include utility
using std::pair;
int foo() {
pairint, const char* components[3];
components[0].first = 0;
return 0;
}
$
--- Comment #1 from lcwu at gcc dot gnu dot org 2009-04-17 23:07 ---
This bogus warning started to show up after the fix for PR c++/39551 was
submitted (at revision 146132). And the root cause for the issue is that C++
front-end generates the following code to initialize the local
/local/info --disable-stage1-checking
--enable-checking=release --with-gmp=/usr/local --with-mpfr=/usr/local
Thread model: posix
gcc version 4.5.0 20090417 (experimental) [trunk revision 146277] (GCC)
Thanks,
Rob
PS: The middle-end now permits the _build_ of gcc with the Language Ada
selected
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-18 01:17
---
Oops, apparently we never parsed correctly negative values for unsigned. The
fix is simple.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #4 from t dot artem at mailcity dot com 2009-04-18 01:44
---
Test configuration:
Software: Linux kernel 2.6.28.9 x86, GCC 4.2.4, GCC 4.4.0 RC,
http://www.rarlab.com/rar/unrarsrc-3.8.5.tar.gz
Hardware: AMD64 Dual Core CPU 5600, 1MB x 2 level 2 cache
RAM: DDR2 800MHz 4GB
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-18 02:24 ---
(In reply to comment #4)
Test configuration:
Software: Linux kernel 2.6.28.9 x86, GCC 4.2.4, GCC 4.4.0 RC,
http://www.rarlab.com/rar/unrarsrc-3.8.5.tar.gz
Hardware: AMD64 Dual Core CPU 5600, 1MB x 2 level 2
--- Comment #2 from ian at airs dot com 2009-04-18 05:40 ---
You are much more familiar with the library than I am. I don't know if this
issue arises anywhere else. cin/cout/cerr is sort of an obvious case. It
didn't really occur to me that there might be similar issues elsewhere.
71 matches
Mail list logo
