--- 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.
-
--- 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 lev
--- 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
un
--- 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
--
usr/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 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 'pair'
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
using std::pair;
int foo() {
pair components[3];
components[0].first = 0;
return 0;
}
$ g++ -Wunused -c Wunuse
--- 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 -fdefault-intege
--- 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 .si
A call to std::num_get fails to parse negative values (specifically -0 in my
example).
/** Begin Test **/
#include
#include
#include
int main ()
{
unsigned long val = 1;
std::stringbuf sb ("-0");
std::istream is (&sb);
std::ios_base::iostate err (std::ios_base::goodbit);
--- 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=gcc&view=rev&rev=146297
Log:
PR target/38627
* config/sh/lib1funcs.asm [__
--- 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
Assig
--- 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 #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 #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 flags
--- 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 more
--
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 #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
Status|ASSIGN
--- 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=gcc&view=rev&rev=146292
Log:
PR 31567
* gcc.c (create_at_file): New.
--- 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 li
--- 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
--
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 po
--- 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
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 "
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 compi
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
si
--- 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
-
--- 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 #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 #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 #3 from stephanemarcotte at 3d-p dot com 2009-04-17 15:38
---
Isolate to the method:
Matrix::Matrix & operator*=( double f ) ...
The template takes 2 args, but the above makes g++ crash. If I take out one
parameter (e.g., Matrix), then I get a compiler error as expected.
--- 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=17652&action=view)
the .ii file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
--- 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=17651&action=view)
Source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39797
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
--with-gxx-inc
--- 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 se
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
voi
--- 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
Status|A
--- 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=gcc&view=rev&rev=146267
Log:
2009-04-17 Thomas Quinot
PR ada/35953
*
--- 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 ref
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P5 |P3
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 round-t
--- 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=17650&action=view)
Patch being tested
Here is a rather hackish patch that I'm testing. It looks correct so far with
the case of bu
--- 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
Status|U
--
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
--- 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
Status|ASSIGNE
--- 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=gcc&view=rev&rev=146240
Log:
2009-04-17 Richard Guenther
PR tree-optimizatio
--- 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
--
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 #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
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 ref[N
--- 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
PR c++/39242
* pt.c (instantiate_decl): Do not instantiate extern, non-inline
declared functions.
thus, if the funct
--- 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 c
--- 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 #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
--- 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=gcc&view=rev&rev=146223
Log:
PR testsuite/39792
* g++.dg/ext/complit11.C: Add
--- 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 cours
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;
functio
57 matches
Mail list logo
