--- Comment #7 from jb at gcc dot gnu dot org 2007-05-22 06:52 ---
(In reply to comment #6)
> The following simplistic patch solves this problem. Sometimes I think we get
> overzealous with definitions and fancy configury. We all know the size is 10
> bytes and 12 works.
No. The non-p
--- Comment #9 from daney at gcc dot gnu dot org 2007-05-22 05:38 ---
Confirmed on a cross compiler configured:
../t1/configure --target=mipsel-linux
--with-sysroot=/usr/local/mipsel-linux-test
--prefix=/usr/local/mipsel-linux-test --with-arch=mips32 --with-float=soft
--disable-java-awt
--- Comment #2 from ejt at andrew dot cmu dot edu 2007-05-22 05:01 ---
Created an attachment (id=13600)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13600&action=view)
Preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32029
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-05-22 05:01
---
The following simplistic patch solves this problem. Sometimes I think we get
overzealous with definitions and fancy configury. We all know the size is 10
bytes and 12 works.
This works:
Index: size_from_kind.c
--- Comment #1 from ejt at andrew dot cmu dot edu 2007-05-22 05:00 ---
Created an attachment (id=13599)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13599&action=view)
Original source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32029
When there is a default template parameter based on a templated class member
type, the compiler dies a nasty death. As far as I can tell, gcc prior to 4.1
branch works fine, but all of the 4.1 branch seems to have this problem.
Quick summary... This works:
template::template Factory > class
thi
Compiling gcc 4.3.0 20070521 using "--with-gjdoc" fails. It works on 4.2.0/1. I
don't know enough about gjdoc scripting or Java to go poking around so I leave
the fix to someone more capable.
For anyone who compiled using "--with-gjdoc" and broke their make there is a
&q
--- Comment #3 from rob1weld at aol dot com 2007-05-22 03:17 ---
Created an attachment (id=13598)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13598&action=view)
Notes: diffs of 4.2.1 and 4.3.0 fold-const.c and ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32024
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-05-22 02:51 ---
Subject: Bug 32015
Author: pinskia
Date: Tue May 22 01:50:42 2007
New Revision: 124935
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124935
Log:
2007-05-21 Andrew Pinski <[EMAIL PROTECTED]>
PR tr
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 02:50 ---
Fixed, thanks for testing out this branch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-22 02:09 ---
pointer plus branch helps out with the heap allocated memory, may_alias gets
less confused with them. It does not fully fix this bug but it does help out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2462
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-22 01:51 ---
Mine, we always get the correct answer on the pointer plus branch.
On the trunk:
ANYTHING = &ANYTHING
READONLY = &ANYTHING
INTEGER = &ANYTHING
a = &ANYTHING
c_1 = &a
b = &ANYTHING
c_1 = &b
c_6 = c_1 + 32
D.1639_11
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-22 01:38 ---
PR 18412 is not really a flow sensitive issue, it is just may_alias getting
confused by pointer addition which will be fixed with the merge of the pointer
plus branch.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-22 01:37 ---
Mine, this is fixed on the pointer plus branch where aliasing is not confused
anymore.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from bliss1940-bbs at yahoo dot com 2007-05-22 01:16 ---
(In reply to comment #7)
> On arm-elf structures are padded/aligned to a 4-byte boundary. This is a
> "feature" of the ABI. The microsoft compiler obviously conforms to a different
> ABI, which is why you get differe
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31995
--- Comment #8 from pinskia at gcc dot gnu dot org 2007-05-22 00:09 ---
Subject: Bug 31995
Author: pinskia
Date: Mon May 21 23:08:54 2007
New Revision: 124927
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124927
Log:
2007-05-21 Andrew Pinski <[EMAIL PROTECTED]>
PR mi
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-22 00:09 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from pbrook at gcc dot gnu dot org 2007-05-21 23:55 ---
On arm-elf structures are padded/aligned to a 4-byte boundary. This is a
"feature" of the ABI. The microsoft compiler obviously conforms to a different
ABI, which is why you get different results. Both are "correct".
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-21 23:53 ---
(In reply to comment #5)
> (In reply to comment #3)
>
> > Try:
> > struct a33
> > {
> > struct Char1 a1;
> > struct Char1 a2;
> > };
> > And see what size/offset the structs are at. Again this is an ABI issue
>
--- Comment #5 from bliss1940-bbs at yahoo dot com 2007-05-21 23:48 ---
(In reply to comment #3)
> Try:
> struct a33
> {
> struct Char1 a1;
> struct Char1 a2;
> };
> And see what size/offset the structs are at. Again this is an ABI issue
Simply saying it's an ABI issue doesn't mak
--- Comment #6 from dfranke at gcc dot gnu dot org 2007-05-21 23:25 ---
Subject: Bug 32002
Author: dfranke
Date: Mon May 21 22:24:55 2007
New Revision: 124924
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124924
Log:
gcc/fortran:
2005-05-21 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from bliss1940-bbs at yahoo dot com 2007-05-21 23:22 ---
(In reply to comment #3)
I'm using arm-elf. Thanks for the __attribute__((packed)). That does indeed
remove the hole at the end.
I think we should agree to disagree. You say it's an ABI issue but that seems
impo
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-21 23:04
---
Fixed.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCO
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-21 23:02
---
Subject: Bug 32027
Author: fxcoudert
Date: Mon May 21 22:02:26 2007
New Revision: 124923
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124923
Log:
PR fortran/32027
* trans-stmt.c (gfc_tr
--- Comment #1 from hjl at lucon dot org 2007-05-21 22:48 ---
This patch
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01387.html
works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32027
The change for bug 31399 makes the "DO" variable inconsistent after loop:
[EMAIL PROTECTED] loop-1]$ cat foo.f90
integer(kind=1) :: i
integer(kind=8) :: c = 0
do i = 1, 5, 1
c = c + 1
end do
print *, i
if (i /= 6) call abort
do i = 1, 5, 2
c = c + 1
end do
print *, i
--- Comment #5 from andreast at gcc dot gnu dot org 2007-05-21 22:39
---
Late night comment, Paolo, I think your patch is fine but it exposed an
inconsitency in using CFLAGS/BOOT_CFLAGS in libgcc.
I could work around the problem with filtering out the mdynamic-no-pic inside
the libgcc M
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-05-21 22:37 ---
Related report: PR26976
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32002
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-21 22:24 ---
(In reply to comment #2)
> To beat a dead horse again, the data members are suitably aligned in
> Microsoft's struct. For the GNU folk to say the extra padding is for data
> alignment or is an ABI issue is misleadin
--- Comment #2 from bliss1940-bbs at yahoo dot com 2007-05-21 22:18 ---
(In reply to comment #1)
I don't think I said GCC was in error, but just different.
Maybe we can come to an agreement here, or maybe not. Let's see.
I certainly would expect the ARM7 would prefer that 4 byte oper
--- Comment #2 from janis at gcc dot gnu dot org 2007-05-21 22:17 ---
Subject: Bug 31924
Author: janis
Date: Mon May 21 21:17:23 2007
New Revision: 124913
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124913
Log:
libcpp/
PR c/31924
* expr.c (interpret_float_suff
--- Comment #10 from hjl at lucon dot org 2007-05-21 21:54 ---
(In reply to comment #9)
> (In reply to comment #6)
> > This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
> > if Linux/ia32 is also miscompiled.
>
> Can you file a new bug rather than reopening this
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-21 21:41 ---
(In reply to comment #6)
> This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
> if Linux/ia32 is also miscompiled.
Can you file a new bug rather than reopening this one (mark it as blocking t
--- Comment #8 from hjl at lucon dot org 2007-05-21 21:36 ---
According to the comment, before the change, we performed
[evaluate loop bounds and step]
count = (to + step - from) / step;
dovar = from;
for (;;)
{
body;
cycle_label:
dovar += step
coun
--- Comment #7 from hjl at lucon dot org 2007-05-21 21:19 ---
(In reply to comment #6)
> This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
> if Linux/ia32 is also miscompiled.
>
Tonto is also miscompiled on Linux/ia32.
--
http://gcc.gnu.org/bugzilla/show_b
--- Comment #6 from hjl at lucon dot org 2007-05-21 21:10 ---
This fix miscompiles tonto in SPEC CPU 2006 on Linux/x86-64. I am checking
if Linux/ia32 is also miscompiled.
--
hjl at lucon dot org changed:
What|Removed |Added
---
--- Comment #2 from rob1weld at aol dot com 2007-05-21 21:05 ---
The BUG is somewhere in here:
I put back ALL my origonal (lengthy) configure options but left off the
checking. It gets past the ICE. That is not good though...
Situation A): The checker is working fine and the code produ
--- Comment #18 from rolf dot ebert dot gcc at gmx dot de 2007-05-21 20:35
---
Created an attachment (id=13597)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13597&action=view)
Bernd's patch that fixes the problem
Bernd's patch as mentioned in comment #16
--
http://gcc.gnu.o
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-05-21 20:24
---
Can this be considered fixed?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wstrict
-prototypes -Wmissing-prototypes -fno-common -DHAVE_CONFIG_H -I. -Iada
-I.
./../gcc/gcc -I../../gcc/gcc/ada -I../../gcc/gcc/../include
-I../../gcc/gcc/../l
ibcpp/include -I../../gcc/gcc/../libdecnumber
-I../../g
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-05-21 20:16
---
The testcase of comment #7 seen through valgrind:
pr25252.f90:3.26:
module procedure X, Y,
1
Error: Syntax error in MODULE PROCEDURE statement at (1)
==12169== Invalid read of size 2
--- Comment #11 from elizabeth dot l dot yip at boeing dot com 2007-05-21
20:10 ---
Ignore Comment #10. I resubmitted my test case as a new bug (31994) last
Friday. The bug is fixed this morning.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31197
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-21 20:07 ---
Confirmed by majority vote.
$> ifort -warn all pr25095.f90
fortcom: Error: pr25095.f90, line 2: This expression cannot be evaluated.
[MODULO]
DATA (i(MODULO(j,5)),j=1,4) /4*0/
^
fortcom: Info: pr25095.f90,
--- Comment #5 from pinskia at gcc dot gnu dot org 2007-05-21 19:49 ---
So closing as fixed as 4.0.x is no longer being maintained.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from igor at roundbox dot com 2007-05-21 19:17 ---
Sorry, I should've mentioned that - no -O2, here is my command line:
g++ -g test_128.cpp -o test_128
And yes, this does seem to be specific to 4.0.x only - gcc 4.1 works fine.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-21 19:09 ---
Also if only 4.0.x is broken, then this is fixed as 4.0.x is no longer being
maintained.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
s=c,c++,fortran,java,objc' which are
not enough for what I prefer - but now it builds I can add some more options
back in.
So now my xgcc says this:
#gcc/xgcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /root/downloads/gcc-4_3-trunk/configure
Thread model: posix
g
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-21 19:08 ---
What options are you using to compile the test program? If you use -O2, then
you have an C/C++ aliasing violation in your code.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--
igor at roundbox dot com changed:
What|Removed |Added
Severity|normal |major
Component|middle-end |c++
http://gcc.gnu.
--- Comment #20 from manu at gcc dot gnu dot org 2007-05-21 18:32 ---
(In reply to comment #19)
> I think we can safely at least remove the scary [regression] from the Summary:
> first, thanks c++/30500 is now fixed and the warnings are always suppressed;
> second, Manuel is splitting ou
--- Comment #26 from manu at gcc dot gnu dot org 2007-05-21 18:16 ---
Can someone from GCC confirm me that Joerg Wunsch has a copyright assignment
in-place? If so, I will commit the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23479
--- Comment #6 from pcarlini at suse dot de 2007-05-21 18:12 ---
(In reply to comment #5)
> Use this technique. In fact, if you can, use my code.
In fact, Howard already mentioned that, at some point. To be clear, and avoid
misunderstandings, I want to clearly state that I consider you
--- Comment #30 from dberlin at gcc dot gnu dot org 2007-05-21 17:53
---
Subject: Re: [4.2 Regression] possible quadratic behaviour.
On 21 May 2007 16:01:29 -, pluto at agmk dot net
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #29 from pluto at agmk dot net 2007-05-21 17:01 -
--- Comment #18 from eweddington at cso dot atmel dot com 2007-05-21 17:17
---
Using the target specific option -mno-tablejump fixes the bug for 4.1.2 and
4.2.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636
--- Comment #5 from dave at boost-consulting dot com 2007-05-21 17:16
---
Just "adding a throwing allocator" (especially one that throws
randomly like this one) will not test the library guarantees anywhere
nearly as effectively as the STLPort tests do. The technique is
outlined in htt
--- Comment #17 from eweddington at cso dot atmel dot com 2007-05-21 17:09
---
Fails on 4.2.0.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #16 from eweddington at cso dot atmel dot com 2007-05-21 17:03
---
Fails with 4.1.2.
--
eweddington at cso dot atmel dot com changed:
What|Removed |Added
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-05-21 17:01
---
I've asked in comp.lang.fortran:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5804a24398086e50/fd2b07668628a90d
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31198
--- Comment #29 from pluto at agmk dot net 2007-05-21 17:01 ---
(In reply to comment #28)
> Change line 4275 of the patched tree-ssa-structalias.c to be rhs.var =
> vi->id instead of rhs.var = id
>
> Remove the id variable declaration.
>
> This would have only affected fortran
th
--
pcarlini at suse dot de changed:
What|Removed |Added
Severity|major |enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31970
--- Comment #1 from igor at roundbox dot com 2007-05-21 16:45 ---
Created an attachment (id=13596)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13596&action=view)
Simple test code to reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32025
With gcc 4.0.x, left bitshift on 128-bit TIMode doesn't seem to be working
properly. For example, using the attached code and compiled under 4.0.4, I
initialize a 128-bit TIMode variable called "mask" to 1U, left-shift it by the
entered number of bits and compute 0U-mask, while printing the content
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-05-21 16:25 ---
> FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
I think the all of the ICEs were due to:
2007-05-16 Eric Christopher <[EMAIL PROTECTED]>
* config/rs6000/rs6000.c (rs6000_emit_prologue): Move altive
--- Comment #18 from patchapp at dberlin dot org 2007-05-21 16:25 ---
Subject: Bug number PR18923
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/2007-05/msg01264.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #3 from gcc-tgc at jupiterrise dot com 2007-05-21 16:19 ---
(In reply to comment #2)
> patches get sent to gcc-patches@, make sure you read
> http://gcc.gnu.org/contribute.html also.
>
I noticed and I just did. Perhaps I should have started there ;)
I haven't signed any FSF
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
Component|bootstrap |middle-end
-stabs --enable-hash-synchronization --enable-gc-debug
--enable-interpreter --with-system-zlib --enable-libada --with-tls
--with-cpu=athlon-xp --with-arch=athlon-xp
--enable-stage1-checking=assert,fold,gc,misc,rtl,rtlflag,runtime,tree
Thread model: posix
gcc version 4.3.0 20070521 (experimental)
T
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:58 ---
This is now integrated, but the tests are still ad-hoc. We need a more
consistent application of eh-safety tests.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21772
--- Comment #100 from jv244 at cam dot ac dot uk 2007-05-21 15:58 ---
(In reply to comment #99)
> (In reply to comment #98)
> > Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
> > equivalent and got the ICE described in PR32018.
>
> thanks for adding this PR.
>
--- Comment #4 from bkoz at gcc dot gnu dot org 2007-05-21 15:57 ---
Dave, just to clarify, this is bug 21772. We're working on it.
;)
-benjamin
--
bkoz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2007-05-21 15:45 ---
A cast is not an lvalue.
--
schwab at suse dot de changed:
What|Removed |Added
Status|UNCONFIRM
--- Comment #3 from tru at pasteur dot fr 2007-05-21 15:43 ---
[EMAIL PROTECTED] ~]$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=pos
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |3.4.0
Version|unknown |3.2.3
http://
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 ---
*** Bug 32022 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32020
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 15:42 ---
*** This bug has been marked as a duplicate of 32020 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #99 from jv244 at cam dot ac dot uk 2007-05-21 15:40 ---
(In reply to comment #98)
> Got CP2K from CVS, created arch/Linux-i686-gfortran.sdbg from its x86-64
> equivalent and got the ICE described in PR32018.
thanks for adding this PR.
Looking at PR32018, I notice that the
--- Comment #16 from hjl at lucon dot org 2007-05-21 15:33 ---
Gcc 4.1/4.2/4.3 will fail and gcc 3.4 has no problem:
---
typedef unsigned long bngdigit;
typedef bngdigit *bng;
typedef unsigned int bngcarry;
typedef unsigned long bngsize;
bngdigit
bng_ia32_mult_sub_digit (bng a, bngsize
The following program doesn't compile due to invalid lvalue in increment. The
most strange thing is that gcc somehow ignores type coercion
int main ()
{
int **a;
void **b;
*b++;/* works fine */
*((void **)a)++; / gives error */
return 0;
}
--
Summary: Invalid lvalue in
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:25
---
Scanning the F2003 standard, MIN/MAX are the only intrinsics with a variable
number of arguments. They probably need special handling.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-21 15:21
---
Created an attachment (id=13595)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13595&action=view)
Patch for that issue; not tested yet
--
fxcoudert at gcc dot gnu dot org changed:
What|Re
--- Comment #3 from pcarlini at suse dot de 2007-05-21 15:00 ---
This specific bug is already fixed and must be marked as duplicate. Then we
have 21772, more general. We know what we are doing, thanks.
*** This bug has been marked as a duplicate of 25288 ***
--
pcarlini at suse dot
--- Comment #7 from pcarlini at suse dot de 2007-05-21 15:00 ---
*** Bug 32017 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25288
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++
--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-21 14:29 ---
For GFORTRAN_SIG* one could also add an option to backtrace/dump in this case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32021
The following environment variables exist in gfortran (inherited from g95, cf.
http://ftp.g95.org/G95Manual.pdf). They are not documented and don't seem to
work, however they are partially implemented.
GFORTRAN_FPU_PRECISION can probably be removed (cf. -mpc32, -mpc64 and -mpc80)
GFORTRAN_MEM_INI
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-21 14:27 ---
GCC 3.2 is no longer maintained. This works with the new C++ parser that went
in
for GCC 3.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from dave at boost-consulting dot com 2007-05-21 14:25
---
I won't push the subject any further, but again, if you don't adopt the tests
mentioned in the threads cited above, you will almost certainly have further
exception safety bugs lurking. Howard Hinnant can verify
--- Comment #10 from pault at gcc dot gnu dot org 2007-05-21 14:21 ---
Fixed on trunk. The patch will be backported to 4.2, as soon as the dust has
settled on trunk and 4.2 is open again.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from pault at gcc dot gnu dot org 2007-05-21 14:18 ---
Fixed on trunk
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Summar
--- Comment #9 from pault at gcc dot gnu dot org 2007-05-21 14:16 ---
Subject: Bug 31994
Author: pault
Date: Mon May 21 13:16:06 2007
New Revision: 124903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124903
Log:
2007-05-21 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #11 from pault at gcc dot gnu dot org 2007-05-21 14:16 ---
Subject: Bug 31867
Author: pault
Date: Mon May 21 13:16:06 2007
New Revision: 124903
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124903
Log:
2007-05-21 Paul Thomas <[EMAIL PROTECTED]>
PR fortran
--- Comment #5 from ubizjak at gmail dot com 2007-05-21 14:01 ---
(In reply to comment #4)
> > Please look to PR tree-optimization/24695
>
> Are you sure about the number? PR24695 is
Oops, PR24659.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32014
The following code demonstrates that GCC raises an invalid error on certain
template function syntax. It is the same error than on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19552 but on a NON-DEPENDENT name,
so the error is not appropriate here.
Please also note that this code compiles on MSVC++
--- Comment #4 from dominiq at lps dot ens dot fr 2007-05-21 13:15 ---
> Please look to PR tree-optimization/24695
Are you sure about the number? PR24695 is
[csl-arm-branch] Bootstrap failure with current csl-arm-branch
and has only three comments.
--
http://gcc.gnu.org/bugzilla/
The following program should not compile (without warnings) on two counts, but
in fact only fails on one, and not for the right reason, as far as I can see.
class C
{
public:
C(const char *);
operator const char *();
};
void
foo (bool b)
{
// Prove that the implicit convertions work both wa
--- Comment #3 from ubizjak at gmail dot com 2007-05-21 13:06 ---
(In reply to comment #1)
> FAIL: gcc.dg/vect/vect-intfloat-conversion-4a.c scan-tree-dump-times
> vectorized
> 1 loops 1
> FAIL: gcc.dg/vect/vect-intfloat-conversion-4b.c scan-tree-dump-times
> vectorized
> 1 loops 1
T
--- Comment #4 from andreast at gcc dot gnu dot org 2007-05-21 13:06
---
Nope. It clinches somehow with this one: config/mh-ppc-darwin. Here the
BOOT_CFLAGS is set to -g -O2 -mdynamic-no-pic.
In the libgcc Makefile.in I see that MULTILIB_CFLAGS is set to CFLAGS + extra
stuff. CFLAGS it
--- Comment #5 from pault at gcc dot gnu dot org 2007-05-21 13:05 ---
Daniel cleared this one on trunk.
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 127 matches
Mail list logo
