Compiling this simple C++ program with 4.3 or 4.4:
#include stddef.h
const char* foo() { return new char[~static_castsize_t(0)]; }
gives this warning:
foo.cc: In function const char* foo():
foo.cc:2: warning: large integer implicitly truncated to unsigned type
The warning is bogus: there is
--- Comment #3 from simartin at gcc dot gnu dot org 2008-07-06 07:55
---
Patch submitted here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00440.html
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2008-07-06 09:37 ---
Still doesn't work. You need to replace one line for the test case of comment
#0 though, because the tree optimizers are now smart enough to see that (i/32)
is always 0. So replace
for (i = 0; i = 10; i++)
--- Comment #11 from steven at gcc dot gnu dot org 2008-07-06 09:59 ---
It looks like we don't use a known number of loop iterations at all anymore
after this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36262
--- Comment #5 from info at milde dot cz 2008-07-06 10:16 ---
Subject: Re: segmentation fault
pinskia at gcc dot gnu dot org napsal(a):
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-07-05 19:06
---
You need to provide the preprocessed source as directed by the
--- Comment #8 from rwild at gcc dot gnu dot org 2008-07-06 09:47 ---
Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00452.html
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
The following code produces correct output with g++ -O, but wrong output with
g++ -O2:
The basic calculation should be just a product of two complex numbers, each
equal to (1,1), so the output should be (and is with g++ -O):
a = (0,2)
However, on my system, the output with the -O2 flag is:
a =
--- Comment #15 from steven at gcc dot gnu dot org 2008-07-06 08:53 ---
Patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00430.html
We should re-evaluate the need for gcse.c load-PRE after Daniel's patch goes
in. The last time I looked at what loads gcse.c load-PRE would move,
--- Comment #1 from michael at jarvis dot net 2008-07-06 11:31 ---
Created an attachment (id=15863)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15863action=view)
preprocessed source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36742
--- Comment #2 from michael at jarvis dot net 2008-07-06 11:40 ---
(From update of attachment 15863)
g++ -v outputs:
Using built-in specs.
Target: i686-apple-darwin9
Configured with: ../gcc-4.2.2/configure --prefix=/sw --prefix=/sw/lib/gcc4.2
--mandir=/sw/share/man
--- Comment #14 from irar at il dot ibm dot com 2008-07-06 11:54 ---
All those failures occur because vector multiplication of shorts to shorts is
not supported on power. Paolo's patch changed the order of type conversion and
multiplication, and removed type conversions.
All those
--- Comment #15 from irar at il dot ibm dot com 2008-07-06 11:55 ---
(In reply to comment #14)
Also Victor tried to reproduced the behavior that Kenny described in
comment #3
comment #1
Sorry,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
--- Comment #16 from irar at il dot ibm dot com 2008-07-06 11:57 ---
(In reply to comment #15)
(In reply to comment #14)
Also Victor tried to reproduced the behavior that Kenny described in
comment #3
comment #1
Grrr, it was in the problem description not in the comments.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-07-06 12:20 ---
So we can optimize
void __attribute__((noinline))
bar (int i)
{
asm ();
}
extern void link_error (void);
void
foo (void)
{
int i;
for (i = 0; i = 320; i++)
{
bar (i);
if (i 320)
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-07-06 12:27
---
I don't think we used it before either? Still the _computing_ of niters
can be easily re-instantiated - it wasn't the expensive thing here. But I
had the impression SCEV computes niters itself when needed, so
When I compile the snapshot of 07/04/08 on an HP-PA workstation under Debian
Linux 4.0 I get the following messages:
libtool: compile: /home/mrichmon/gcc-4.4-20080704/g95/./gcc/xgcc
-B/home/mrichmon/gcc-4.4-20080704/g95/./gcc/
-B/home/mrichmon/irun/hppa1.1-unknown-linux-gnu/bin/
--- Comment #22 from rguenth at gcc dot gnu dot org 2008-07-06 13:29
---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-07-06 13:34 ---
I think it is still useful to increase the quality of reported bugs.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|eres at il dot ibm dot com |unassigned at gcc dot gnu
|
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-07-06 13:40 ---
Confirmed. Works with gcc 4.3. Aliasing problem, -O2 -fno-strict-aliasing
works.
So eventually a libstdc++ issue?
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from paolo dot carlini at oracle dot com 2008-07-06 14:14
---
You can categorize as libstdc++, but I'm afraid nobody is going to do much, for
many reasons: nothing substantive changed, possibly affecting the aliasing, in
complex and string; the but cannot be reproduced
Consider:
#include iostream
struct S
{
S(): i(2) {}
S(S const) {}
int i;
};
void f(S x) { x.i = 0; }
int main()
{
S y;
f(static_castS(y));
std::cout y.i '\n';
}
Expected output: 2
Actual output: 0
Thus, the assignment to the independent local
--- Comment #1 from gcc-bugzilla at contacts dot eelis dot net 2008-07-06
14:48 ---
Forgot to mention: compile with -std=c++0x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36744
Trunk fails to build Qt4 on both s390 and s390x.
./cc1plus -quiet -O2 -fPIC qregexp.3.ii
qregexp.3.ii: In member function 'void QVectorT::realloc(int, int) [with T =
QRegExpAutomatonState]':
qregexp.3.ii:99: internal compiler error: in gen_reg_rtx, at emit-rtl.c:868
Please submit a full bug
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-07-06 18:24 ---
Created an attachment (id=15864)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15864action=view)
testcase
Testcase reduced with a cross from x86_64 to s390x.
--
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||krebbel at gcc dot gnu dot
|
gfortran builds main part of David Bailey's multi-precision F90 library
correctly, but it gives syntax errors when compiling the array modules
extension of this library (mpmod90v.f). g95 and the online Lahey source
checker both compile this without errors.
The library I am talking about can be
--- Comment #1 from kris at kuhlmans dot net 2008-07-06 18:28 ---
Created an attachment (id=15865)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15865action=view)
gzipped source code that triggers problem
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36746
--- Comment #8 from bunk at stusta dot de 2008-07-06 18:45 ---
See the duplicate #35454:
This is a problem often seen when compiling Linux kernels.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32424
--- Comment #2 from chris dot fairles at gmail dot com 2008-07-06 19:33
---
(In reply to comment #0)
Consider:
#include iostream
struct S
{
S(): i(2) {}
//S(S const) {}
S(S const);
The cctor need only be defined as well to get the same behavior (gcc 4.4.0,
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-06 19:48 ---
The problem is the combination of
implicit type(t)(x)
with the DIMENSION statement. Reduced test case:
module m
type t
integer :: i
end type t
contains
subroutine s(x)
implicit type(t)(x)
--- Comment #3 from chris dot fairles at gmail dot com 2008-07-06 19:51
---
(In reply to comment #2)
(In reply to comment #0)
struct S
{
S(): i(2) {}
//S(S const) {}
S(S const);
The cctor need only be defined as well to get the same behavior (gcc 4.4.0,
-std=c++0x,
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-06 20:11 ---
I think the problem is in gfc_match_rvalue():
case FL_VARIABLE:
variable:
if (sym-ts.type == BT_UNKNOWN gfc_peek_ascii_char () == '%'
gfc_get_default_type (sym, sym-ns)-type == BT_DERIVED)
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-06 21:52 ---
Try the patch in http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00259.html .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ghazi at gcc dot gnu dot org 2008-07-06 22:22 ---
Another C/C++ conflict (?) that could be possibly implemented in this warning
feature, enum declaration scoping:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00470.html
Not sure what the exact error message was.
--- Comment #6 from kkojima at gcc dot gnu dot org 2008-07-06 22:22 ---
Created an attachment (id=15866)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15866action=view)
a test case
Fortunately I could get a testcase with building cernlib-2006 for x86.
For the attached testcase,
--
kkojima at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #8 from pinskia at gcc dot gnu dot org 2008-07-06 22:26 ---
Not sure what the exact error message was.
Easy, the decls were not defined :). Basically the enums get the scope of the
struct they are defined in for C++ but in C, they get the global scope. A
warning for this
--- Comment #2 from michael dot a dot richmond at nasa dot gov 2008-07-06
23:57 ---
(In reply to comment #1)
Try the patch in http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00259.html .
When I apply the patch I get the message:
patching file function.c
patch unexpectedly ends in
--- Comment #3 from hjl at gcc dot gnu dot org 2008-07-07 00:34 ---
Subject: Bug 36720
Author: hjl
Date: Mon Jul 7 00:34:16 2008
New Revision: 137547
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=137547
Log:
2008-07-06 H.J. Lu [EMAIL PROTECTED]
PR target/36720
--- Comment #4 from hjl dot tools at gmail dot com 2008-07-07 00:41 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from eric dot norum at usask dot ca 2008-07-07 01:51 ---
Created an attachment (id=15867)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15867action=view)
Running under GDB reveals a NULL pointer dereference
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
--- Comment #3 from michael dot a dot richmond at nasa dot gov 2008-07-07
02:19 ---
gfortran appears to run correctly with the patch applied
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36743
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2008-07-07 02:50
---
I am on it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-07-07 02:53 ---
This is another sizetype issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
46 matches
Mail list logo
