--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-03-28
08:15 ---
logical, optional, intent(in) :: back
myscan = scan (str, substr, back)
I thought passing non-present optional arguments down to routines as an
optional argument is within the confines of the
--- Comment #2 from jakub at gcc dot gnu dot org 2006-03-28 08:20 ---
On x86-64 Linux? -m32 -m64 works just fine, for cc1 obviously (-m64 wins)
and for gas as well (--32 --64 is passed, the last one wins).
The reason why -m64 -m32 doesn't work is that for cc1 -m32 wins and for
gas we
--- Comment #1 from rmathew at gcc dot gnu dot org 2006-03-28 09:24 ---
This looks like a duplicate of 26878 except for the listed patches and the
actual error message. Both have been filed by the same person.
Claudio: Can you try with a recent snapshot from the mainline SVN
--- Comment #2 from paulthomas2 at wanadoo dot fr 2006-03-28 09:46 ---
Subject: Re: Automatic conversion for optional parameters
of missing dummies
toon at moene dot indiv dot nluug dot nl wrote:
--- Comment #1 from toon at moene dot indiv dot nluug dot nl 2006-03-28
08:15
Hi,
% gfortran --help -v
says:
[...]
-Wtabs Warn about nonconforming uses of the tab
character
[...]
but it warns when -Wno-tabs is specified:
% gfortran gfcbug35.f -Wno-tabs
Warning: Nonconforming tab character in column 1 of line 1
Trivial testcase omitted.
Cheers,
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-28 10:13 ---
Subject: Bug 26779
Author: pault
Date: Tue Mar 28 10:13:50 2006
New Revision: 112442
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112442
Log:
2006-03-28 Paul Thomas [EMAIL PROTECTED]
PR fortran/26779
--- Comment #3 from pault at gcc dot gnu dot org 2006-03-28 10:18 ---
According to the standard:
12.4.1.5 Restriction on dummy arguments not present.
.
Except as noted in the list above, it may be supplied as an actual argument
corresponding to an optional dummy argument, which
--- Comment #11 from pluto at agmk dot net 2006-03-28 10:34 ---
it looks like 4.1.1 and 4.2.0 still produce unoptimal code.
#include math.h
double test(double x)
{
if (x 0.0)
return cos(x);
else
return sin(x);
}
[ 4.1.1-0.20060322 /
--- Comment #2 from zerocool at modemsoft dot it 2006-03-28 11:00 ---
(In reply to comment #1)
This looks like a duplicate of 26878 except for the listed patches and the
actual error message. Both have been filed by the same person.
Yes , but i try with different version : 4.03
simple program such as:
#define file a.\h
#include file
#include a.\h
Compiled by: gcc -E a.c
If the header file a.\h exists, the first #include directive be processed
properly, but nor the second #include directive, Why?
--
Summary: character \ in #include directive
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-03-28 12:08 ---
With this testcase, problem reproduces both in 4.1 and in mainline:
int try (int *a)
{
return a + -1 a;
}
int main(void)
{
int bla[100];
if (try (bla + 50))
abort ();
return 0;
}
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-28 13:33 ---
We had this some time ago, but the discussion stopped at the point where people
said that pointers do not wrap. I believe that a + -1 is done using unsigned
arithmetic, so this may be the bug. I also know where
Fold at the moment does not fold comparisons involving signed variables with
a constant offset. Like we get from number-of-iterations analysis for
int foo0(int i0, int i1)
{
int i, j = 0;
for (i=i0; i=i1+1; ++i)
++j;
return j;
}
where niter-may_be_zero ends up as i0 + 1 i1 + 2 which
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-28 13:59 ---
Testcase:
void foo0(int i0, int i1)
{
if (!(i0 + 1 i1 + 1 == i0 i1))
link_error ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26898
--- Comment #4 from patchapp at dberlin dot org 2006-03-28 14:00 ---
Subject: Bug number PR c/26818
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01615.html
--
Fold currently does not fold a lot of TRUTH_AND/OR_EXPRs created by
tree-ssa-loop-niter.c:tree_simplify_using_condition_1. Like for the testcase
int foo0(int i0, int i1)
{
int i, j = 0;
for (i=i0; i=i1+1; ++i)
++j;
return j;
}
with PR26898 fixed. We there get
i0D.1520_4
int foo0(int i0, int i1)
{
int i, j = 0;
for (i=i0; i=i1+1; ++i)
++j;
return j;
}
we cannot figure out the number of iterations for this loop because of
PR26898 and PR26899.
--
Summary: Number of iterations not know for simple loop
Product: gcc
--- Comment #6 from malitzke at metronets dot com 2006-03-28 14:45 ---
As no further comments are forthcoming I am taking the liberty to mark this PR
as resolved.
--
malitzke at metronets dot com changed:
What|Removed |Added
--- Comment #7 from reichelt at gcc dot gnu dot org 2006-03-28 14:50
---
The problem is not fixed.
The reduced testcase from comment #4 still crashes.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
/mnt/gnu/gcc-3.3/objdir/gcc/gcj
-B/mnt/gnu/gcc-3.3/objdir/hppa2.0w-hp-hpux11.11/
libjava/ -B/mnt/gnu/gcc-3.3/objdir/gcc/ --bootclasspath '../lib' --classpath .
-
C -d classes
../../../../../gcc/libjava/classpath/tools/gnu/classpath/tools/*.ja
va
double plus_1( double x )
{
asm volatile
(
fadd %2
: =t (x)
: 0 (x), u (1.0)
);
return x;
}
with -fomit-frame-pointer gcc produces:
plus_1:
fldl4(%esp) \
fld1 |- why just not fld1 ; fldl 4(%esp) ?
fxch
--- Comment #9 from law at redhat dot com 2006-03-28 15:01 ---
Subject: Re: [4.2 Regression] ACATS c35507m
cd2a23e cxh1001 failures
On Tue, 2006-03-28 at 03:56 +, kenner at vlsi1 dot ultra dot nyu dot
edu wrote:
--- Comment #8 from kenner at vlsi1 dot ultra dot nyu
--- Comment #5 from apl at alum dot mit dot edu 2006-03-28 15:09 ---
Created an attachment (id=11135)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11135action=view)
simpler test that still fails in 4.x compilers
compile with
g++ -c -Werror -Wall -Wextra -O2 b.cxx
--
apl
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-28 15:13 ---
Note that we in principle know the number of iterations - just we cannot prove
the loop runs at least once in number of iterations analysis. Of course we
know this because we did loop header copying on the loop and
I am getting this error running a make on mysql on the aix 5.1 os.
I am using 4.0 of the gnu compiler
--
Summary: default.c:577: internal compiler error: in
get_indirect_ref_operands, at tree-ssa-operands.c:1449
Product: gcc
Version: 4.0.0
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-28 15:14 ---
Zdenek may also have an idea on this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
The enclosed demonstrates. define either SUPPRESS_BUG or SUPPRESS_BUG2 to show
that either not using inheritance or using a template called typer instead of
type will suppress the bug.
--
Summary: A template named the same as its member confuses lookup
through
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-28 15:16 ---
Eh, of course we don't preserve loop information beyond CH. But if we did,
this would be possible?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
--- Comment #1 from dave at boost-consulting dot com 2006-03-28 15:16
---
Created an attachment (id=11136)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11136action=view)
Preprocessed C++ source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26904
--- Comment #6 from apl at alum dot mit dot edu 2006-03-28 15:21 ---
I was wrong, this is still broken in GCC 4.0.2 and 4.1.0 although the original
test case doesn't demonstrate the bug.
/tools/linux/gcc-4.1.0/bin/g++ -c -Werror -Wall -Wextra b.cxx -O2
cc1plus: warnings being treated
--
law at redhat dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kenner at gcc dot gnu dot
|dot org |org
--- Comment #4 from law at gcc dot gnu dot org 2006-03-28 15:35 ---
Subject: Bug 26796
Author: law
Date: Tue Mar 28 15:35:47 2006
New Revision: 112453
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112453
Log:
PR tree-optimization/26796
* tree-ssa-dom.c
--- Comment #5 from law at redhat dot com 2006-03-28 15:38 ---
Subject: Re: [4.2 Regression] ACATS ICE c34002a c52005
spurious storage_error
On Wed, 2006-03-22 at 19:28 +, ebotcazou at gcc dot gnu dot org
wrote:
--- Comment #2 from ebotcazou at gcc dot gnu dot org
if you have the visibility-hidden pragma in effect and you override it with a
per-class visibility-default attribute emits a direct call instead of a call
through the PLT.
Reduced-testcase .i file to be attached.
--
Summary: default-visibility class symbol improperly resolved as
--- Comment #1 from benjamin at smedbergs dot us 2006-03-28 16:09 ---
Created an attachment (id=11138)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11138action=view)
Reduced testcase, .i
gcc -fPIC -shared -o libfoo.so nsAppRunner-test6.i
Tested with 4.1 branch after the commit
ICE when cross-compiling on x86_64 host for armeb target.
Included the command that makes GCC fail (minus all -I include paths) with an
ICE, the output. I will attach the preprocessed C file in a direct follow-up.
See also existing bug 23442 on a different platform.
armeb-linux-gcc
--- Comment #1 from likewise at gmx dot net 2006-03-28 16:37 ---
Created an attachment (id=11139)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11139action=view)
preprocessed C file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26906
--- Comment #2 from likewise at gmx dot net 2006-03-28 16:40 ---
By removing the optimization flag (-Os) the compiler no longer ICEs. Also, -O1,
-O2, -O3 are OK.
--
likewise at gmx dot net changed:
What|Removed |Added
--- Comment #3 from likewise at gmx dot net 2006-03-28 16:47 ---
Created an attachment (id=11140)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11140action=view)
preprocessed C file (bzip2'd)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26906
If I use filebuf::sungetc() at the beginning of a file, the result of the next
sbumc() call is not
allways the first character in the file:
#include fstream
#include iostream
using namespace std;
int main()
{
ifstream infile(test.dat);
filebuf* inbuf=infile.rdbuf();
int res;
//at
--- Comment #8 from malitzke at metronets dot com 2006-03-28 17:07 ---
You are correct. At least as far as the second batch from S.Pop (dated
2006-03-27)
goes. As I did not keep my gcc-4.2.0 binaries relative to the first batch from
S.Pop (dated 2006-03-26) I can not reproduce the non
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-28 17:34 ---
I should note that you are using Redhat's GCC and should have reported it to
them before it was reported here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26897
--- Comment #1 from pcarlini at suse dot de 2006-03-28 17:38 ---
There is nothing wrong with the current behavior: simply, at the beginning of
the file a putback position cannot be made available (i.e., a seek -1 fails),
and, consistently, sungetc() returns traits::eof(), it suffices to
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-28 17:40 ---
This was fixed in 4.0.1.
*** This bug has been marked as a duplicate of 21173 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #40 from pinskia at gcc dot gnu dot org 2006-03-28 17:40
---
*** Bug 26903 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21173
--- Comment #10 from mkuvyrkov at gcc dot gnu dot org 2006-03-28 17:42
---
Reopen this bug as the patch, which fixes it was reverted from the mainline.
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Summary|[3.3/3.4 Regression] bogus |bogus
--
mkuvyrkov at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot
|dot org
--- Comment #8 from pbrook at gcc dot gnu dot org 2006-03-28 18:03 ---
Subject: Bug 23623
Author: pbrook
Date: Tue Mar 28 18:03:06 2006
New Revision: 112460
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112460
Log:
2006-03-28 Paul Brook [EMAIL PROTECTED]
PR
foo.c:
asm (
.globl bar\n\t
bar:\n\t
movl $5, %eax\n\t
ret
);
main() {
return bar();
}
$ gcc -g2 foo.c; ./a.out; echo $?
5
$ gcc foo.c -g3; ./a.out; echo $?
Segmentation fault
139
Disassembly of the a.out compiled with -g3 gives:
(gdb) disass main
Dump of assembler code for function
--- Comment #1 from ed at catmur dot co dot uk 2006-03-28 18:31 ---
Created an attachment (id=11141)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11141action=view)
foo.s
Output of gcc -g3 -S foo.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26908
C source attached.
muurbloem:~/vc/gub/target/darwin-x86/build/glib-2.9.6$
PATH=/home/lilydev/vc/gub/target/darwin-x86/system/usr/cross/bin/:$PATH
/home/lilydev/vc/gub/target/darwin-x86/system/usr/cross/bin/i686-apple-darwin8-gcc
-DHAVE_CONFIG_H -I.
--- Comment #1 from hanwen at xs4all dot nl 2006-03-28 18:34 ---
Created an attachment (id=11142)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11142action=view)
trigger for ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26909
--- Comment #7 from apl at alum dot mit dot edu 2006-03-28 18:40 ---
It's not minor, it causes incorrect code to be generated because it folds the
expression to zero!
--
apl at alum dot mit dot edu changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-28 18:45 ---
There is no garentee that bar will be in the text section.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Compiling gcc-4.2-20060325 compiles on my FC5 box with the following error
message (gcc-4.1.0-3.src.rpm upgraded to gcc-4.2-20060325.src.rpm):
../xgcc -B ./ -O2 -c -DUNPROTOIZE -g -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-28 18:55 ---
Reducing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26909
Currently our java/util/zip/InflaterInputStream differs
from Classpath's. Putting ours into Classpath causes regressions there.
Putting Classpath's into libgcj causes regressions in libgcj.
Probably one or both Inflater implementations is incorrect in some way.
--
Summary:
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-28 19:04 ---
I checked in the fix to svn head.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-03-28 19:05 ---
Subject: Bug 26441
Author: tromey
Date: Tue Mar 28 19:05:21 2006
New Revision: 112465
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112465
Log:
Correcting PR number in ChangeLog:
PR libgcj/26441:
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
Created an attachment (id=11143)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11143action=view)
initial patch
This patch mostly fixes the problem.
However it is missing some minor bits for windows.
Also it
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
I'm handling this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tromey at gcc dot gnu dot org 2006-03-28 19:09 ---
I'm handling this.
See the patch attached to PR 13671.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from law at redhat dot com 2006-03-28 19:13 ---
Subject: Re: [4.1/4.2 Regression] missed jump
threading after unroller
On Wed, 2006-03-22 at 16:06 +0100, Richard Guenther wrote:
On 3/22/06, Jeffrey A Law [EMAIL PROTECTED] wrote:
On Wed, 2006-03-22 at 12:14
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from ed at catmur dot co dot uk 2006-03-28 19:15 ---
OK, so it's tetex that's broken. Sorry for the invalid report.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26908
--- Comment #18 from quanah at stanford dot edu 2006-03-28 19:23 ---
Unsuprisingly,the build still fails after changing it to use make boostrap in
the same exact way:
/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran
--- Comment #7 from roger at eyesopen dot com 2006-03-28 19:34 ---
This should now be fixed on mainline.
--
roger at eyesopen dot com changed:
What|Removed |Added
--- Comment #4 from kargl at gcc dot gnu dot org 2006-03-28 19:38 ---
Subject: Bug 26816
Author: kargl
Date: Tue Mar 28 19:38:26 2006
New Revision: 112468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112468
Log:
Steven G. Kargl [EMAIL PROTECTED]
PR fortran/26816
--- Comment #1 from kargl at gcc dot gnu dot org 2006-03-28 19:46 ---
I'll fix this sometime today. Thanks for the bug report.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2006-03-28 19:47 ---
Fixed on trunk and 4.1 branch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
All show:
FAIL: 25_algorithms/prev_permutation/1.cc execution test
From:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01866.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01789.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg01793.html
--
Summary: failing
--- Comment #19 from kargl at gcc dot gnu dot org 2006-03-28 20:18 ---
(In reply to comment #18)
Unsuprisingly,the build still fails after changing it to
use make boostrap in the same exact way:
../../../../gcc-4.0.3/libgfortran/intrinsics/selected_int_kind.f90 -fPIC
I've scanned
--- Comment #1 from pcarlini at suse dot de 2006-03-28 20:20 ---
*** This bug has been marked as a duplicate of 26304 ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #15 from pcarlini at suse dot de 2006-03-28 20:20 ---
*** Bug 26911 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #20 from ebotcazou at gcc dot gnu dot org 2006-03-28 20:31
---
Unsuprisingly,the build still fails after changing it to use make boostrap
in the same exact way:
Maybe unsurprisingly, but this eliminates a whole category of problems.
Could you remove
--- Comment #21 from ebotcazou at gcc dot gnu dot org 2006-03-28 20:41
---
/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/gfortran
-B/afs/ir.stanford.edu/src/pubsw/languages/gcc-build/sun4x_58/gcc/
-B/usr/pubsw/sparc-sun-solaris2.8/bin/
--- Comment #22 from quanah at stanford dot edu 2006-03-28 20:56 ---
I can look at only building GMP static, rather than static shared.
I have a build of 4.1 happening on Solaris 9 at the moment after fixing the ksh
issue.
--Quanah
--
--- Comment #8 from falk at debian dot org 2006-03-28 20:58 ---
Huh? The code does
((UInt16(word) 0x3700) == (UInt16(0x3000) UInt16(word 0x8800))) ==
UInt16(0x8000);
which is of course always 0, the left part of the comparison is a comparison,
which can be only 0 or 1, and the
--- Comment #2 from trumsko at yahoo dot com 2006-03-28 20:58 ---
o.k. I read the comments to libstdc++/9439 and browsed through section 27.5.2
of the ISO standtard again. Unfortunatly I didn't find the proof, that the
example program realy behaves contrary to the standard, as I only
--- Comment #23 from quanah at stanford dot edu 2006-03-28 20:59 ---
Created an attachment (id=11144)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11144action=view)
selected_int_kind.f90
selected_int_kind.f90 (it is just what is shipped with the gcc-4.0.3 source...)
--
--- Comment #24 from quanah at stanford dot edu 2006-03-28 20:59 ---
I will look at removing the libintl/libiconv bits, but in the past gcc failed
to find them without adding those flags.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #25 from ebotcazou at gcc dot gnu dot org 2006-03-28 21:03
---
selected_int_kind.f90 (it is just what is shipped with the gcc-4.0.3
source...)
Except that it is generated on the fly by mk-sic-ink.sh...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #26 from ebotcazou at gcc dot gnu dot org 2006-03-28 21:07
---
Except that it is generated on the fly by mk-sic-ink.sh...
Sorry, I was talking about selected_int_kind.inc... Could you attach this one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26889
--- Comment #3 from pcarlini at suse dot de 2006-03-28 21:15 ---
(In reply to comment #2)
My opinion is, that an abitrary number of sungetc() at the beginning of a file
should not have the effect, that the next sbumpc() returns the first character
of the file. Independent to the
--- Comment #9 from apl at alum dot mit dot edu 2006-03-28 21:26 ---
Created an attachment (id=11145)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11145action=view)
simplified test case
--
apl at alum dot mit dot edu changed:
What|Removed
--- Comment #4 from pcarlini at suse dot de 2006-03-28 21:27 ---
(In reply to comment #3)
And this is not true: any number of sungetc() at the beginning of the file
fails (all return eof()) and the next sbumpc() exactly returns the first char
of file. Indeed, If I run your testcase
--- Comment #10 from apl at alum dot mit dot edu 2006-03-28 21:28 ---
No, you misread the parentheses. I've removed all the EXCESS ONES, leaving
answer = (UInt16(word 0x3700) == UInt16(0x3000))
(UInt16(word 0x8800) == UInt16(0x8000));
Showing that we're testing
--- Comment #2 from roger at eyesopen dot com 2006-03-28 21:46 ---
I believe that this may not be a g++ bug. The wording of the standard is:
[conv.ptr] An null pointer constant is an *integral* constant expression
(_expr.const_) rvalue of integer type that evaluates to zero.
Ignoring
--- Comment #5 from pcarlini at suse dot de 2006-03-28 21:58 ---
Ok, now I see, the underlying issue is a duplicate of libstdc++/26777, already
fixed in mainline and pending for 4.1.1. Sorry again about the initial
misunderstanding.
*** This bug has been marked as a duplicate of 26777
--- Comment #7 from pcarlini at suse dot de 2006-03-28 21:58 ---
*** Bug 26907 has been marked as a duplicate of this bug. ***
--
pcarlini at suse dot de changed:
What|Removed |Added
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|4.2.0 |4.1.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26777
--- Comment #11 from falk at debian dot org 2006-03-28 21:59 ---
Ah. I can reproduce it now. Here is a C test case:
void abort(void);
__attribute__((noinline))
int f (unsigned short word) {
return (word 0x1) (((unsigned short) (word 0x8000)) == 0x8000);
}
int main(void) {
if
--- Comment #4 from sebastian dot pop at cri dot ensmp dot fr 2006-03-28
22:44 ---
Created an attachment (id=11146)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11146action=view)
first step
with this patch scev returns (int) (char) {0,+,1} but then
chrec_convert_aggressive is
--- Comment #3 from schwab at suse dot de 2006-03-28 23:01 ---
But [expr.const] also says:
An integral constant-expression can involve only literals (2.13), enumerators,
...
Thus enumerators are also integral constant expressions. The distinction
between integral and enumeration is
--- Comment #4 from schwab at suse dot de 2006-03-28 23:09 ---
Ignore my last comment. The type matters, and what is needed is indeed a
constant of _integer_ type, but enumerators are not of integer type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14644
--- Comment #8 from paolo at gcc dot gnu dot org 2006-03-29 00:12 ---
Subject: Bug 26777
Author: paolo
Date: Wed Mar 29 00:12:21 2006
New Revision: 112477
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112477
Log:
2006-03-28 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #9 from sebastian dot pop at cri dot ensmp dot fr 2006-03-29
00:27 ---
Created an attachment (id=11147)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11147action=view)
proposed fix
this patch (not tested yet) fixes the problem: it avoids a division by zero.
Part of
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-03-29 01:03 ---
(In reply to comment #1)
Note that we in principle know the number of iterations - just we cannot prove
the loop runs at least once in number of iterations analysis. Of course we
know this because we did loop
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |blocker
GCC build triplet|i686-linux |
GCC host
1 - 100 of 112 matches
Mail list logo
