--- Comment #25 from tromey at gcc dot gnu dot org 2006-12-29 07:58 ---
FWIW I've been looking at this area for PR 29966.
I don't see how overflow checking could be added to
_cpp_lex_direct. However I did end up adding an
assertion to _cpp_lex_token, to try to expose a hidden
assumption
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 07:44 ---
This problem if it is a real issue, is not a GCC issue at all, GCC does not do
dynamic loading or even the static linking.
The problem here is you don't understand elf semantics. since we know that
Func1 is local t
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-29 07:43 ---
I looked at this a bit tonight.
It is straightforward to remove -finput-charset from the second
invocation of cc1 (needed several places -- gcc.c but also the
c++ and objc lang-specs).
I think this approach fails if
If i have a shared lib with some name like FTPobex with funtion name
Func1()
{
printf("First function");
}
And i have my local function
void main()
{
Func1();/i call this function here using shared lib
}
//local function
gcc produces unassemblable assembly code.
//testcase:
struct S
{
signed int a:17;
} x;
typedef typeof (x.a) foo;
template
T* inc(T* p) { return p+1; }
int main ()
{
foo x[2] = { 1,2 };
int y[2] = { 1,2 };
*inc(x);
*inc(y);
return 0;
}
result
$ g++ -S bug.cpp
$ g++ -c bug.s
bug.s:
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 06:23 ---
Since you don't have a G5, you should do --disable-multilib.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The system is a Dual 800 MHz PowerPC G4 (7450) (QuickSilver) running under
Darwin 8.8.0.
The command sequence is as follows:
cd gcc
mkdir build
cd build
../configure
make >make.log
Periodically, the following appears:
../../gcc/config/rs6000/altivec.md:xxx: warning" operand 3 missing mod
--- Comment #9 from hjl at gcc dot gnu dot org 2006-12-29 06:09 ---
Subject: Bug 30040
Author: hjl
Date: Fri Dec 29 06:09:06 2006
New Revision: 120256
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120256
Log:
2006-12-28 H.J. Lu <[EMAIL PROTECTED]>
Backport from mainl
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-12-29 04:45 ---
I think the first step is to report it to sun so they track it and hopefully
one day fix their toolchain. Does anyone have a support contract who can file
a report?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #3 from ghazi at gcc dot gnu dot org 2006-12-29 04:45 ---
I think the first step is to report it to sun so they track it and hopefully
one day fix their toolchain. Does anyone have a support contract who can file
a report?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #4 from ghazi at gcc dot gnu dot org 2006-12-29 04:36 ---
A similar error that may be related was posted here:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01713.html
The testcase in my post was from a gcc bootstrap.
--
ghazi at gcc dot gnu dot org changed:
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-29 04:30 ---
I think this same problem will occur with #include_next
and #pragma once. cpp doesn't currently seem to differentiate between
the PCH case and other kinds of preprocessing.
--
tromey at gcc dot gnu dot org change
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-29 04:29 ---
I think this will also occur for _Pragma("once")
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28165
--- Comment #1 from tromey at gcc dot gnu dot org 2006-12-29 03:28 ---
This happens because destringize_and_run calls cpp_push_buffer.
The new buffer has a non-null 'prev'; do_pragma_system_header
checks for prev==NULL to determine whether the directive is
in the primary source file.
I'
--- Comment #13 from tromey at gcc dot gnu dot org 2006-12-29 02:54 ---
I am testing a patch for this.
It pedwarns on '#foo' in an expression, and also when #assert or
#unassert is used. It also warns about these when -Wdeprecated
is given.
--
tromey at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-29 01:57 ---
*** Bug 30326 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:57 ---
*** This bug has been marked as a duplicate of 30323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-29 01:56 ---
2.8.1.1 Sharing Attribute Rules for Variables Referenced in a Construct
line 7 on page 64:
Variables with const-qualified type having nomutable member are shared.
Variables with predetermined sharing attributes m
Compiling the following code with "gcc -fopenmp -O -Wall"
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i < 20; i++)
A[i] = x;}
}
foo.c: In function '
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-29 01:49 ---
Real testcase:
void foo()
{
int A[20];
const int x = 3;
int i;
#pragma omp parallel for shared(x)
for(i = 0; i < 20; i++)
A[i] = x;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 ---
*** Bug 30325 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 ---
*** This bug has been marked as a duplicate of 30323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 ---
*** Bug 30324 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30323
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-29 01:46 ---
*** This bug has been marked as a duplicate of 30323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
Compiling the following code with "gcc -fopenmp -O -Wall"
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i < 20; i++)
A[i] = x;}
}
foo.c: In function '
Compiling the following code with "gcc -fopenmp -O -Wall"
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i < 20; i++)
A[i] = x;}
}
foo.c: In function '
Compiling the following code with "gcc -fopenmp -O -Wall"
I get a hosed error message:
void foo()
{
int A[20];
const int x = 3;
#pragma omp parallel for shared(x)
for(i = 0; i < 20; i++)
A[i] = x;}
}
foo.c: In function '
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-12-28 23:50 ---
*** Bug 30316 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-28 23:50 ---
*** This bug has been marked as a duplicate of 29585 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 23:42 ---
> [I think most of these "interesting" foldings should be deferred]
This is not an interesting fold anyways, unlike say the range generator.
Also this is really a reassociate issue.
if we wrote the function like:
in
int bar(int i)
{
return -i-1+i+1;
}
optimizes to
;; Function bar (bar)
Analyzing Edge Insertions.
bar (i)
{
:
return i + 1 + ~i;
}
(instead of return 0; which we catch at rtl level later)
Either i+1 needs to be folded to -~i, we need to re-associate earlier
or something needs to do tree-c
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-12-28 23:11
---
I will work at it.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Ass
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-28 22:16 ---
I can reproduce it this time and now I am reducing the testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
--- Comment #3 from deji_aking at yahoo dot ca 2006-12-28 22:07 ---
I'm sorry, it seems I'd posted the .cpp of a different code other than the one
that ICEd(signal.cc). However, the .cpp of signal.cc doesn't ICE for me too. In
any case I've done as you requested and put signal.ii on
ftp:
--- Comment #4 from tkoenig at gcc dot gnu dot org 2006-12-28 21:39 ---
Additional data points:
Reading/writing unformatted sequential doesn't work with g77
(fails with an error message on open), and it fails with ifort 8
for records longer than 2**18 bytes (ifort's default buffer size)
--- Comment #3 from tkoenig at gcc dot gnu dot org 2006-12-28 21:22 ---
This is deep regression country; in the time
I have to devote to this, I couldn't work it out.
Unassigning myself (for now).
--
tkoenig at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-12-28 21:20 ---
Confirmed, the crash is within the library:
$ gfortran -g xzero_size_array.f90
$ gdb ./a.out
GNU gdb 6.4.90-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General P
U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-thread
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-12-28 20:32 ---
Doesn't seem to work. gcc.c-torture/execute/vrp-5.c fails because
[5, +INF] + [5, +INF] is combined to [10, +INF-1] (and 5 + +INF-5 is zero
anyways).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls
--with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
--enable-bootstrap --enable-thread
--- Comment #2 from kargl at gcc dot gnu dot org 2006-12-28 19:37 ---
The following appears to work, so Vivek if you have a critical
need to get an application compiled. You can split the line.
module amod
! The following is a work around.
character (len=1), parameter :: aa = "z"
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-28 19:35 ---
Created an attachment (id=12845)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12845&action=view)
preliminary patch
needs proper testing / splitting.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30318
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 19:19 ---
Confirmed, even as of today.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
U:\vrao\fortran>type gfort_bug_returns.f90
module amod
character (len=1), parameter :: aa = "z", bb(1) = (/aa/)
end module amod
U:\vrao\fortran>gfortran -v
Using built-in specs.
Target: i386-pc-mingw32
Configured with: ../trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/hom
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 19:12 ---
This option no longer exists and 3.3 is no longer maintained.
So, I am closing this.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from tromey at gcc dot gnu dot org 2006-12-28 19:11 ---
This isn't really a gcc bug per se, so I am closing it.
If someone wants to implement one or all of these on a branch,
that is still fine.
--
tromey at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from tromey at gcc dot gnu dot org 2006-12-28 18:47 ---
I checked in the fix.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-28 18:45 ---
Subject: Bug 30001
Author: tromey
Date: Thu Dec 28 18:45:48 2006
New Revision: 120245
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120245
Log:
PR preprocessor/30001:
* charset.c (_cpp_conver
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-28 18:41 ---
Subject: Bug 30237
Author: pault
Date: Thu Dec 28 18:41:25 2006
New Revision: 120244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120244
Log:
2006-12-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2006-12-28 18:41 ---
Subject: Bug 30034
Author: pault
Date: Thu Dec 28 18:41:25 2006
New Revision: 120244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=120244
Log:
2006-12-28 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-28 17:43 ---
Can you rerun the command line that ICEs and add -save-temps and then attach
the .i file? The .cpp file you provided does not ICE for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30316
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-28 16:03 ---
I think the range folding should late in compiling after VRP2 happens. This
will also help out code that is written like:
if (i > 0)
if (i <= 5)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30317
--- Comment #12 from rob1weld at aol dot com 2006-12-28 15:45 ---
(In reply to comment #11)
> Fix checked in.
I'm not an expert with Java but am trying to compile gcc 4_2 branch (CVS)
and I have the same problem as is described in this bug report. The fixes
mentioned in this report _see
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-12-28 14:55 ---
No, I still say you are incorrect.
Can you give the output of the original confgure which should show you which
ld/as GCC is going to use?
By default the toplevel configure looks into PREFIX/${TARGET} for ld/as. If
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-12-28 14:48
---
(In reply to comment #10)
> Any progress on this?
There are two way of fixing this as far as I can see:
teach real.c about how to fold IBM 128bit long double format
use MPFR instead
I would use the latter if I got
--- Comment #10 from dwmw2 at infradead dot org 2006-12-28 14:32 ---
Any progress on this?
--
dwmw2 at infradead dot org changed:
What|Removed |Added
CC|
--- Comment #5 from gin at mo dot msk dot ru 2006-12-28 13:32 ---
Subject: Re: -B$(build_tooldir)/bin/
It actually broke build of gcc (version 3.0.3) at least on one class
of systems, i386-pc-sco3.2v5, as follows.
Had on that system gnu binutils installed with PREFIX. Had gcc
configu
VRP should, if overfow is defined, create anti-ranges if plus or minus
cause wrapping.
void test2 (unsigned int i)
{
if (i <= 0x0fffa)
{
return;
}
if (i == 0x0)
{
return;
}
{
unsigned int v = i + 2;
{
if (v != 0)
{
if (v
fold and VRP interact badly if we have a range test like
if (i > 0 && i <=5)
...
as we fold that to
if ((unsigned int) i + 0x0 > 4)
...
for which VRP fails to extract a range for i. If we write the
range test so that fold doesn't see it, VRP is happy:
if (i > 0)
if (i <= 5)
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-12-28 12:14 ---
The testcase in comment #1 is fixed by comparison canonicalization of i <= j -
1
to i < j. Of course it fails again if we use a temporary for j - 1 like in the
testcases in other comments.
--
http://gcc.gnu.org
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-28 12:03 ---
Confirmed. compare_values needs to be teached to look at value ranges for
operands and decide on overflow there - but only for substitute and fold as
earlier we can have invalid intermediate value ranges.
--
rgu
61 matches
Mail list logo
