--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-24 05:45
---
Patch committed on trunk.
2007-11-23 Christopher D. Rickett <[EMAIL PROTECTED]>
* trans-common.c (build_common_decl): Fix the alignment for
BIND(C) common blocks.
--
jvdelisle at gcc dot gnu
--- Comment #15 from tom dot browder at gmail dot com 2007-11-24 02:36
---
Tried:
g++ -c -Wconversion test_conversion.cc
using g++ trunk of svn version 30392 and had no warnings.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
--- Comment #1 from pluto at agmk dot net 2007-11-24 02:30 ---
the warning isn't emitted when i change ++r_ into r_++.
t.cpp.003t.original changes:
- (void) NON_LVALUE_EXPR < ++((struct X *) this)->r_> >>>
+ (void) ((struct X *) this)->r_++ >>>
--
http://gcc.gnu.org/bugzilla/sho
long f( long& );
template < typename T, bool B >
struct X
{
X() : r_()
{
B ? f( r_ ) : ++r_;
}
long r_;
};
X< int, false > h;
$ /opt/gcc43/bin/g++ t.cpp -Wall -c
t.cpp: In constructor 'X::X() [with T = int, bool B = false]':
t.cpp:11: instantiated
--- Comment #2 from manu at gcc dot gnu dot org 2007-11-24 01:42 ---
An @opindex is present for -fstack-protector in mainline and in 4.1 and 4.2
branches, so it should appear in the option index in future releases.
--
manu at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-11-24 01:16 ---
This works for me now, so closing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-11-24 00:41
---
Reviewed and OK. I will commit after regression testing completed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34135
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-11-24 00:37
---
fixed on trunk
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Sta
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2007-11-24 00:36
---
Fixed on trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2007-11-24 00:29
---
Subject: Bug 33317
Author: jvdelisle
Date: Sat Nov 24 00:29:14 2007
New Revision: 130392
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130392
Log:
2007-11-23 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-11-24 00:29
---
Subject: Bug 34209
Author: jvdelisle
Date: Sat Nov 24 00:29:14 2007
New Revision: 130392
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130392
Log:
2007-11-23 Tobias Burnus <[EMAIL PROTECTED]>
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-24 00:25
---
Subject: Bug 34209
Author: jvdelisle
Date: Sat Nov 24 00:25:01 2007
New Revision: 130391
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130391
Log:
2007-11-23 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2007-11-24 00:25
---
Subject: Bug 33317
Author: jvdelisle
Date: Sat Nov 24 00:25:01 2007
New Revision: 130391
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130391
Log:
2007-11-23 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from burnus at gcc dot gnu dot org 2007-11-24 00:13 ---
FIXED on the trunk (4.3.0). Does not affect earlier versions of gfortran.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
When configure is called in the build-i686-cygwin/libiberty subdir, CC is set
correctly to build gcc, but CPP is inherited as "powerpc-linux-gcc -E".
It seems like we should be setting CPP to "${CC_FOR_BUILD} -E" in all the
places where CC is set to ${CC_FOR_BUILD}.
diff -urN gcc-4.2.2-orig/Makef
--- Comment #3 from burnus at gcc dot gnu dot org 2007-11-24 00:11 ---
Subject: Bug 34187
Author: burnus
Date: Sat Nov 24 00:11:38 2007
New Revision: 130386
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130386
Log:
2007-11-23 Tobias Burnus <[EMAIL PROTECTED]>
PR fort
--- Comment #7 from mueller at gcc dot gnu dot org 2007-11-23 23:11 ---
Fixed for 4.3
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|NE
--- Comment #6 from mueller at gcc dot gnu dot org 2007-11-23 23:02 ---
Subject: Bug 34197
Author: mueller
Date: Fri Nov 23 23:02:21 2007
New Revision: 130385
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130385
Log:
2007-11-23 Dirk Mueller <[EMAIL PROTECTED]>
Richard
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-11-23 22:39 ---
Confirmed. libgcc2.c doesn't have a ffs implementation for targets with 2
byte integers.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-11-23 22:34 ---
The testcase in comment #1 is also a regression really because the build2_stat
issues are all regressions ;).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-11-23 22:29 ---
So the testcase from comment #3 is actually a regression?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-11-23 22:16
---
I think that future standard compliance is important so I move that we make
-fno-backslash the default behavior.
I also agree that if backslash is enabled that we issue a runtime warning for
situations like \w.
--- Comment #10 from burnus at gcc dot gnu dot org 2007-11-23 21:50 ---
FIXED on the trunk (4.3.0). I do not indent to backport it to GCC 4.2.x; but I
can be convince otherwise.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-23 21:39 ---
Please read the documentation and other info on the web site.
Then, if you still can't make it work, post specific questions,
along with what you tried, what platform you are using,
and what the results were, to the g
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-11-23 21:14
---
This appears to fix the problem:
}
void
! gfc_resolve_nearest (gfc_expr *f, gfc_expr *a, gfc_expr *p)
{
+ if (p != NULL && p->ts.kind < a->ts.kind)
+ {
+ if (a->ts.kind == gfc_kind_max (a,p))
+
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-23 21:11 ---
In particular, this is caused by the pt.c (tsubst) change:
@@ -8555,16 +8545,15 @@
gcc_assert (type != unknown_type_node);
/* Reuse typedefs. We need to do this to handle dependent attributes,
- specificall
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-23 21:03 ---
Subject: Bug 34192
Author: burnus
Date: Fri Nov 23 21:03:48 2007
New Revision: 130383
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130383
Log:
2007-11-23 Tobias Burnus <[EMAIL PROTECTED]>
Stev
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-23 20:51 ---
Fixed just on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2007-11-23 20:50
---
With the patch for PR34192 and using the following:
program test
implicit none
real(8), volatile :: r8
r8 = 0.0_8
print *, nearest(r8, 1.0_8)
print *, nearest(nearest(r8, 1.0_8), 1.0_8)
print *, neare
--- Comment #5 from jakub at gcc dot gnu dot org 2007-11-23 20:50 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-23 20:49 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-23 20:49 ---
Subject: Bug 30293
Author: jakub
Date: Fri Nov 23 20:49:02 2007
New Revision: 130382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130382
Log:
PR c++/30293
PR c++/30294
* decl.c (cp_fi
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-23 20:49 ---
Subject: Bug 30294
Author: jakub
Date: Fri Nov 23 20:49:02 2007
New Revision: 130382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130382
Log:
PR c++/30293
PR c++/30294
* decl.c (cp_fi
--- Comment #6 from steven at gcc dot gnu dot org 2007-11-23 20:48 ---
*** Bug 6585 has been marked as a duplicate of this bug. ***
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #17 from steven at gcc dot gnu dot org 2007-11-23 20:48 ---
And we're not going to keep every ra bug open. This just spoils bugzilla
search results.
*** This bug has been marked as a duplicate of 17236 ***
--
steven at gcc dot gnu dot org changed:
What|R
--- Comment #16 from rask at gcc dot gnu dot org 2007-11-23 20:43 ---
(In reply to comment #
> I think the bug can be closed as fixed now.
I'm not so convinced. This part
> leal(%ecx,%edx), %esi
> movl%esi, %edx
> movl4(%esp), %esi
should have been
--- Comment #3 from jakub at gcc dot gnu dot org 2007-11-23 20:39 ---
Introduced by
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128681
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from shockenhull at niceberg dot com 2007-11-23 20:21
---
this bug seem to be related to the fact that std::string's name mangling is
optimized by shortening it to a special encoding which might bypass the
underscore prefix option
is there an option to disable the specia
--- Comment #8 from patchapp at dberlin dot org 2007-11-23 20:05 ---
Subject: Bug number PR 34192
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-11/msg01240.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #1 from sjackman at gmail dot com 2007-11-23 20:01 ---
It's worth noting that __ffsi2 generates terrible code on the AVR: a 194 byte
function. avr-libc also provides ffs (16-bit, not 32-bit as in __ffssi2) which
is written in assembler and 24 bytes long. As a workaround, you
ffs((uint8_t)x) and ffs((uint16_t)x) generate a call to __ffshi2, but this
function does not exist in libgcc.a, giving the error
undefined reference to `__ffshi2'.
Test case:
int main(int argc)
{
return ffs(argc);
}
--
Summary: ffs builtin calls undefined __ffshi2
--- Comment #1 from burnus at gcc dot gnu dot org 2007-11-23 19:30 ---
Created an attachment (id=14628)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14628&action=view)
Longer test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34209
--- Comment #3 from kargl at gcc dot gnu dot org 2007-11-23 19:29 ---
(In reply to comment #1)
>
> gfortran's default behavior should match whatever g77 did
> with C escape sequences.
>
Found it.
http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Backslash-in-Constants.html#Backslash-in-Con
This is with x86_64-unknown-linux-gnu with glibc-2.6.1.
Run-time-lib follow up for compile-time PR 34192.
The following program should print as third number a 0.0, but it does not do
so:
4.94065645841246544E-324
9.88131291682493088E-324
9.88131291682493088E-324
program test
implicit none
--- Comment #10 from manu at gcc dot gnu dot org 2007-11-23 19:16 ---
Fixed in GCC 4.3
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #9 from manu at gcc dot gnu dot org 2007-11-23 19:15 ---
Subject: Bug 5310
Author: manu
Date: Fri Nov 23 19:15:09 2007
New Revision: 130381
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130381
Log:
2007-11-23 Mark Mitchell <[EMAIL PROTECTED]>
Manuel Lo
--- Comment #14 from fang at csl dot cornell dot edu 2007-11-23 19:10
---
Yes, thank you all for the quick response. Will test upcoming snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34198
--- Comment #2 from jb at gcc dot gnu dot org 2007-11-23 19:05 ---
IMHO F2003 compatibility is be more important than g77 compatibility, so I
would be ok with making -fno-backslash the default. That being said, at the
very least -fno-backslash should be enabled with -std=f2003.
Though I
--- Comment #4 from patchapp at dberlin dot org 2007-11-23 18:55 ---
Subject: Bug number PR c/23722
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-11/msg01237.html
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from tbm at cyrius dot com 2007-11-23 18:25 ---
*** Bug 34208 has been marked as a duplicate of this bug. ***
--
tbm at cyrius dot com changed:
What|Removed |Added
-
--- Comment #5 from tbm at cyrius dot com 2007-11-23 18:25 ---
Yep, it's the same testcase.
*** This bug has been marked as a duplicate of 34206 ***
--
tbm at cyrius dot com changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-23 17:59 ---
I think this s a dup of bug 34206.
--
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
|
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-11-23 17:54 ---
(In reply to comment #3)
> Please backport to the 4_2-branch, too. Looks like this was only applied to
> trunk.
So this is not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Remove
--- Comment #3 from tbm at cyrius dot com 2007-11-23 17:40 ---
Still there with current SVN (r130380).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34208
--- Comment #2 from tbm at cyrius dot com 2007-11-23 17:32 ---
Program received signal SIGSEGV, Segmentation fault.
htab_find_with_hash (htab=0x0, element=0x2b03ce11eb60, hash=2042772844)
at libiberty/hashtab.c:269
269 const struct prime_ent *p = &prime_tab[htab->size_prime_ind
--- Comment #2 from sjackman at gmail dot com 2007-11-23 17:30 ---
I've always used `goto *123;' on embedded targets as a feature to be able to
jump to a constant address. This particularly useful feature should not be
removed. Is a simple change of syntax being suggested, such as `goto
--- Comment #1 from tbm at cyrius dot com 2007-11-23 17:28 ---
Created an attachment (id=14627)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14627&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34208
Seen with trunk from 2007-11-16:
(sid)1802:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot/bin/g++ -c
deluge-torrent-storage.cc
deluge-torrent-storage.cc: In member function 'int
std::piece_manager::identify_data(const std::vector
>&, int, std::vector >&, int&, const
std::multimap,
std::allocator > >&
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-11-23 17:14
---
I decided to close this because of FX comment as well as I think it is not
valid to backspace on a non-seekable stream
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from hainque at adacore dot com 2007-11-23 17:11 ---
Subject: Re: New: [4.3 regression] FAIL: gnat.dg/release_unc_maxalign.adb
execution test
andreasmeier80 at gmx dot de wrote:
> gnat.dg/release_unc_maxalign.adb execution test fails for me since
> 20.11.2007. At 19.11
andreasmeier80 at gmx dot de wrote:
> gnat.dg/release_unc_maxalign.adb execution test fails for me since
> 20.11.2007. At 19.11.2007 it whas worked.
Thanks for opening the PR. We have identified what is causing this
and are qualifying a candidate fix. This is an old bug actually, showing
up on
--- Comment #12 from patchapp at dberlin dot org 2007-11-23 17:10 ---
Subject: Bug number PR 34174
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-11/msg01232.html
--
http://gcc.gnu.org/bugzilla/
Hi is I have a This snip that will compile but print only one bingo instead of
two.
The gcc is version 4.1.2
==
#include
using namespace std;
class A {
public:
A () {}
template
A(T const &orig) {
cout<<"bingo!"<
--- Comment #1 from kargl at gcc dot gnu dot org 2007-11-23 16:26 ---
As I've stated before, I think putting machine dependent code
into the Fortran frontend is a bad idea. You'll soon see a
tangled mess of #ifdef ... #else ... #endif code, which will
become difficult to maintain.
gfor
in building GCC 4.3.3-20071116 on my solaris sparc 10 (latest patches) boxes, i
receive the follow message:
configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla attaching
/apps/tmp/gcc43/sparc-sun-solaris2.10/libgfortran/config.log
here's my configure
--- Comment #17 from patchapp at dberlin dot org 2007-11-23 15:15 ---
Subject: Bug number PR33317
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-11/msg01228.html
--
http://gcc.gnu.org/bugzilla/s
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-11-23 14:29
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #19 from rguenth at gcc dot gnu dot org 2007-11-23 14:29
---
Subject: Bug 34176
Author: rguenth
Date: Fri Nov 23 14:28:59 2007
New Revision: 130379
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130379
Log:
2007-11-23 Richard Guenther <[EMAIL PROTECTED]>
M
--- Comment #8 from pault at gcc dot gnu dot org 2007-11-23 14:13 ---
This is not regtested yet but seems to be OK:
Index: gcc/fortran/decl.c
===
*** gcc/fortran/decl.c (révision 130286)
--- gcc/fortran/decl.c (copie de t
--- Comment #13 from manu at gcc dot gnu dot org 2007-11-23 14:12 ---
(In reply to comment #12)
> (In reply to comment #11)
> > Fixed.
> >
>
> I think this fix is wrong. Warning about user-provided casts goes against the
> idea of Wconversion.
>
Forget it. I didn't read the testcase
--- Comment #12 from manu at gcc dot gnu dot org 2007-11-23 13:58 ---
(In reply to comment #11)
> Fixed.
>
I think this fix is wrong. Warning about user-provided casts goes against the
idea of Wconversion.
See also
http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01221.html
for a more
--- Comment #11 from rask at gcc dot gnu dot org 2007-11-23 13:46 ---
> dp-bit.c:964: internal compiler error: in change_address_1, at
> emit-rtl.c:1783
That is because it needs an offsetted address during and after reload, and the
fr30 doesn't have that. It can happen on trunk too.
--- Comment #11 from jakub at gcc dot gnu dot org 2007-11-23 13:43 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #10 from jakub at gcc dot gnu dot org 2007-11-23 13:39 ---
Subject: Bug 34198
Author: jakub
Date: Fri Nov 23 13:39:44 2007
New Revision: 130377
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130377
Log:
PR c++/34198
* c-common.c (conversion_warning):
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-11-23 13:21 ---
Created an attachment (id=14626)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14626&action=view)
reduced testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34206
./cc1plus -quiet -O2 bug-343711_storage.min.ii
Program received signal SIGSEGV, Segmentation fault.
0x010aa445 in htab_find_with_hash (htab=0x0, element=0x2b7075926540,
hash=246566056) at /space/rguenther/src/svn/trunk/libiberty/hashtab.c:566
566 htab->searches++;
(gdb) up
#1 0
--- Comment #3 from aldot at gcc dot gnu dot org 2007-11-23 12:24 ---
Please backport to the 4_2-branch, too. Looks like this was only applied to
trunk.
--
aldot at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-11-23 11:24 ---
Remember C is not C++.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34204
--- Comment #1 from aldot at gcc dot gnu dot org 2007-11-23 10:59 ---
Created an attachment (id=14625)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14625&action=view)
reduced from gcc/tree.h
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34205
--- Comment #7 from pault at gcc dot gnu dot org 2007-11-23 10:59 ---
A workaround is to put the ENTRY declaration after the type specification:
MODULE complex
IMPLICIT NONE
PRIVATE
PUBLIC :: cx, OPERATOR(+)
TYPE cx
REAL :: imag
END TYPE cx
INTERFACE OPERATOR (+)
MOD
With current trunk:
In file included from toolchain_build_armeb_nofp
u/gcc-4.3.0/gcc/c-lang.c:26:
toolchain_build_armeb_nofpu/gcc-4.3.0/gcc/tree.h:371: error: width of 'code'
exceeds its type
Works if omitting -march=iwmmxt -mabi=iwmmxt
Sample:
/there/build_armeb/staging_dir/usr/bin/armeb-linu
--- Comment #4 from j at uriah dot heep dot sax dot de 2007-11-23 10:57
---
Is the missed optimization in the following code the same?
volatile unsigned char *reg_a = (unsigned char *)42;
volatile unsigned char *reg_b = (unsigned char *)34;
extern void a(void);
extern void b(void);
ex
--- Comment #1 from schwab at suse dot de 2007-11-23 10:25 ---
These are not redefinitions. The definitions are all tentative.
--
schwab at suse dot de changed:
What|Removed |Added
--
-
#include
int i;
int i;
int i;
int i;
int i;
int main()
{
i = i +1;
printf("%d", i);
return 0;
}
Even with a "-Wall" -- not a single warning is issued!
--
Summary: GCC no more com
--- Comment #2 from dominiq at lps dot ens dot fr 2007-11-23 09:13 ---
This bug is really annoying, could someone test that the patch in
http://gcc.gnu.org/ml/fortran/2007-08/msg00142.html
does not break anything on other platforms? If it does not, could it be
committed?
TIA
Dominiqu
Currently, \ are treated by default as C-style escape characters with some
special treatment to allow foo = "\"
At least for Windows paths, the result of path = 'c:\windows\somewhere\big.txt'
is surprising as the \w remains but the \b is replaced.
I believe one should give a warning that \w d
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c8dd08d6da052499/
Test case created by James Van Buskirk.
The following code gives an ICE after diagnosing the error in "size[1]" (which
is by the way valid Fortran 2008 syntax for a coarray "size".)
==26143== Invalid
89 matches
Mail list logo
