Hi All,
I wanted to install gcc-3.4 on my ppc-linux m/c. I tried cross
compiling, but cought up with error which i'm not familiar with as i'm
new here.
The following is the error log on make:
-
[EMAIL
[EMAIL PROTECTED] wrote on 24/09/2007 09:19:09:
Hi All,
I wanted to install gcc-3.4 on my ppc-linux m/c. I tried cross
compiling, but cought up with error which i'm not familiar with as i'm
new here.
GCC list is about development of GCC so I think you should try the
gcc-help mailing list
Hi I want to extract the complete AST-tree from GCC (using 4.1.2).
I´ve tried to use -fdump-translation-unit but it seems like its dosent
include information in ex. for and if statements. If i use
-fdump-tree-orignal-raw i get each function but not the external variables
if they are not used in
We are portinng GCC 4.2.1 to a 2-issue VLIW processor. There are some
special instructions which can only be issued on the second slot (slot
1). I tried to specify using following DFA constructs.
;; Define this instruction can only be issued on slot 1
(define_insn_reservation psr_y 1
On 9/24/07, Johan Bohlin [EMAIL PROTECTED] wrote:
My question is... Anyone knows a way
to get all information ? Maybe changing a flag in the source code or
something.
Debugging dumps are always incomplete. Mostly by design, but in
general because we just dump what seems useful for debugging.
On 9/23/07, Gary Funck [EMAIL PROTECTED] wrote:
The operand, op:
(gdb) p op
$49 = 0x2e1ebc60
(gdb) pt
var_decl 0x2e1ebc60 D.3609
This symbol was not marked for renaming and the program is already in
SSA form. When your pass introduces new symbols, you need to add them
to the
Perhaps you could also try
-fdump-tree-gimple
or
-fdump-tree-gimple-raw
In both cases you dump out the GIMPLE form, AST based.
Best,
T.
Hi I want to extract the complete AST-tree from GCC (using 4.1.2).
I´ve tried to use -fdump-translation-unit but it seems like its dosent
include
On 20/09/2007, Doug Gregor [EMAIL PROTECTED] wrote:
We can't seem to decide whether ISO C++ really forbids comparisons
between pointers and integers or not. The first two are for == and !=,
the second two are for , , =, =. Why the inconsistency?
typeck.c: error (ISO C++ forbids
On 24/09/2007, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/23/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
And *before* salias? Does it make a difference? It suits me better for
my purposes.
Can't do it before salias.
I didn't want to add a dummy pass mainly because i didn't want
On 9/24/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
I don't understand is why PROPerties are not associated with TODO_
functions in a way that if a pass don't have the properties it
requires, it can call the appropriate TODO_ function. That way, if
some pass needs PROP_alias but none has
On 24/09/2007, Diego Novillo [EMAIL PROTECTED] wrote:
On 9/24/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
I don't understand is why PROPerties are not associated with TODO_
functions in a way that if a pass don't have the properties it
requires, it can call the appropriate TODO_
On 9/24/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
I don't get it. If you ask for PROP_alias and aliases have been
computed, then PROP_alias is enabled and you don't need to compute
them again.
You do if alias information has gone stale due to transformations.
The SSA form is another
On 24/09/2007, Diego Novillo [EMAIL PROTECTED] wrote:
On 9/24/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
I don't get it. If you ask for PROP_alias and aliases have been
computed, then PROP_alias is enabled and you don't need to compute
them again.
You do if alias information has
On 9/24/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
That is exactly what I had in mind. If you invalidate a property then
the property is destroyed and whoever asks for it must invoke the
relevant function to enable it again. Is that a problem?
In principle, I don't think that'd be a
On 9/24/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
On 24/09/2007, Daniel Berlin [EMAIL PROTECTED] wrote:
On 9/23/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
And *before* salias? Does it make a difference? It suits me better for
my purposes.
Can't do it before salias.
On 9/24/07, Diego Novillo [EMAIL PROTECTED] wrote:
On 9/24/07, Manuel López-Ibáñez [EMAIL PROTECTED] wrote:
That is exactly what I had in mind. If you invalidate a property then
the property is destroyed and whoever asks for it must invoke the
relevant function to enable it again. Is that
On Mon, Sep 24, 2007 at 09:36:25AM -0400, Diego Novillo wrote:
On 9/23/07, Gary Funck [EMAIL PROTECTED] wrote:
The operand, op:
(gdb) p op
$49 = 0x2e1ebc60
(gdb) pt
var_decl 0x2e1ebc60 D.3609
This symbol was not marked for renaming and the program is already in
SSA
Diego, a bit more info. It seems that gimplify_operand
is being called in the rewrite_uses pass of
tree-ssa-loop-ivopts.c. gimplify_operand() is working
on this expr:
plus_expr 0x2e0ee5f0
type integer_type 0x2ded5600 unsigned int public unsigned SI
size integer_cst
On 9/24/07, Gary Funck [EMAIL PROTECTED] wrote:
I would have thought gimplify_expr's internal mechanisms would
mark veriables as referenced, when it needs to?
No, it doesn't. It simply converts to GIMPLE. Once you inserted the
new statement, you will need to call mark_symbols_for_renaming()
Bingfeng Mei [EMAIL PROTECTED] writes:
We are portinng GCC 4.2.1 to a 2-issue VLIW processor. There are some
special instructions which can only be issued on the second slot (slot
1). I tried to specify using following DFA constructs.
;; Define this instruction can only be issued on slot 1
Sorry if this has been discussed before, but the c99-tgmath-* tests
are failing on most newlib targets. The problem is that tgmath.h
unconditionally includes complex.h, which non-linux newlibs don't
provide. What's the best fix? Including complex.h from tgmath.h
seems reasonable on the face of
On 24/09/2007, Jonathan Adamczewski [EMAIL PROTECTED] wrote:
What about something like the following?
struct proxy {
T t;
proxy(T t_) : t(t_) {}
proxy operator=(const T r) { foo(t, r); return *this; }
};
struct B { proxy get() { return proxy(bar); } };
int main ()
{
B
ÎâêØ wrote:
(define_insn *shift_predicate_cmp
[(set (const_int 0)
(and:BI (and:BI (match_operand:BI 1 register_operand c)
(and:BI (match_operand:DI 2 gr_reg_or_8bit_adjusted_operand rL)
(match_operand:DI 3 gr_register_operand r)))
Snapshot gcc-4.1-20070924 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070924/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
This affects parisc all hpux versions except for possibly 11.31. I've
experimented with not including complex.h. With a couple of other
testsuite changes (complex - __complex__), the tgmath tests behave
in a semi-reasonable manner if complex arguments are avoided. However,
I don't really see
I'm trying to get libfortran (all_l4.c) building for m32c, and it
complains (eventually) that it can't add PSI (pointer) and HI
(integer) types together. I've backtracked to the statement just
before it's lowered to rtl, see below. Note that pointers are PSI
mode (24 bits) for this chip. My
--- Comment #8 from jakub at gcc dot gnu dot org 2007-09-24 06:36 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #4 from chrbr at gcc dot gnu dot org 2007-09-24 07:10 ---
Created an attachment (id=14248)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14248action=view)
volatile nrv patch
--
chrbr at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from chrbr at gcc dot gnu dot org 2007-09-24 07:14 ---
the attached patch was hanging in my sandbox. will submit it along with a
testsuite case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19531
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-24 08:36 ---
-v output when compiling, that is,
g++ -Wall -O3 -march=native -c videospeed.cc -v
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33540
Reported by John Harper,
http://gcc.gnu.org/ml/fortran/2007-09/msg00397.html
The following
use module
use module, only: xrenamed = x
surely makes xrenamed available; however, -- see clause (3) below -- it does
not make 'x' available. In gfortran the symbol 'x' is also imported into the
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-24 08:52 ---
Post script: Fortran 95 contains the same in 11.3.2; the only difference is
that Fortran 2003 talks also about defined-operators.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33541
Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/1abc1549a6a164f1/
One should re-check it as only g95 and Portland reject it whereas Pathscale,
gfortran, ifort, sunf95,openf95 and especially NAG f95 and Lahey accept it.
The following program is obviously wrong as
--- Comment #14 from pcarlini at suse dot de 2007-09-24 09:06 ---
I think Gaby said the issue doesn't exist anymore after Roger work. Otherwise,
please reopen, thanks.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pcarlini at suse dot de 2007-09-24 09:15 ---
Hi Janis, a regression hunt would be useful, indeed... Thanks!
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2007-09-24 09:17 ---
Subject: Bug 33316
Author: jakub
Date: Mon Sep 24 09:17:10 2007
New Revision: 128709
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128709
Log:
PR debug/33316
* dwarf2out.c (modified_type_die):
--- Comment #6 from jakub at gcc dot gnu dot org 2007-09-24 09:18 ---
Fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33316
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19407
The gccinstall documentation can be generated from the install.texi2html
script, but not from the install.texi file.
make html invokes makeinfo on the install.texi file, but it doesn't generate
the full HTML documentation.
The texi file as-is might not be buggy, because the PDF documentation
--- Comment #8 from reichelt at gcc dot gnu dot org 2007-09-24 10:53
---
Fixed on mainline.
Probably by the fix for PR 19407.
Jason, would you mind backporting your patch to the branches?
--
reichelt at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-24 11:06 ---
The regular perl testsuite fails as well:
t/op/override.ok
t/op/pack.Invalid type ']' in unpack at
op/pack.t line 1363.
# Looks like you planned 13864
--- Comment #5 from ebuddington at wesleyan dot edu 2007-09-24 11:24
---
Created an attachment (id=14249)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14249action=view)
output of 'g++ -Wall -O3 -march=native -v -c test.cc'
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33540
--- Comment #10 from dgregor at gcc dot gnu dot org 2007-09-24 12:15
---
Subject: Bug 33185
Author: dgregor
Date: Mon Sep 24 12:14:57 2007
New Revision: 128711
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128711
Log:
2007-09-24 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #5 from dgregor at gcc dot gnu dot org 2007-09-24 12:15 ---
Subject: Bug 33112
Author: dgregor
Date: Mon Sep 24 12:14:57 2007
New Revision: 128711
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128711
Log:
2007-09-24 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #7 from ubizjak at gmail dot com 2007-09-24 12:39 ---
Fixed by http://gcc.gnu.org/viewcvs?view=revrevision=128710:
2007-09-24 Kai Tietz [EMAIL PROTECTED]
PR middle-end/33472
* config/i386/i386.c (return_in_memory_ms_64): Handle return types for
--- Comment #3 from bonzini at gnu dot org 2007-09-24 12:39 ---
CCing resident memory-hog bug killer.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #6 from dgregor at gcc dot gnu dot org 2007-09-24 12:52 ---
Fixed by the patch below
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-09-24 13:07 ---
haha, 300MB is nothing unusual. Btw, there's no libjava/interpreter.cc but
libjava/interpret.cc. And that uses only ~200MB on x86_64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32653
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-24 13:10 ---
Created an attachment (id=14250)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14250action=view)
testcase
Btw, here's the (partly preprocessed) testcase I used.
--
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-24 13:45 ---
See PR33502 and http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01721.html for the
patch which causes the regression.
See also http://gcc.gnu.org/ml/fortran/2007-09/msg00394.html
--
burnus at gcc dot gnu dot org
--- Comment #11 from dgregor at gcc dot gnu dot org 2007-09-24 13:46
---
Subject: Bug 33185
Author: dgregor
Date: Mon Sep 24 13:46:40 2007
New Revision: 128717
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128717
Log:
2007-09-24 Douglas Gregor [EMAIL PROTECTED]
PR
--- Comment #12 from dgregor at gcc dot gnu dot org 2007-09-24 13:47
---
Fixed, for real. Thanks for the ice_canonical.cpp test-case: it illustrated the
(other) underlying problem that wasn't apparent in 33112.
--
dgregor at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from jason at gcc dot gnu dot org 2007-09-24 13:53 ---
I'm reluctant to backport the changes to 4.2 now because they're fairly
intrusive; I'm not sufficiently confident yet that the change in typedef
handling won't introduce other problems.
--
--- Comment #3 from martinezfive at comcast dot net 2007-09-24 13:59
---
I spoke with the people at EDG and they have confirmed their compiler's
acceptance of the code indeed constitutes a bug. Since almost every last EDG
developer is also a member of the ISO C++ Core Committee (and
--- Comment #3 from pcarlini at suse dot de 2007-09-24 14:07 ---
On it.
--
pcarlini at suse dot de changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Comment #4 from bangerth at dealii dot org 2007-09-24 14:30 ---
My reasoning would be that in the call d%g, the type of the two
expressions are 'double' and 'A'. So to call the user-defined
operator%, only the first argument has to be converted to 'A' for which
a conversion
--- Comment #1 from jakub at gcc dot gnu dot org 2007-09-24 15:16 ---
Subject: Bug 33506
Author: jakub
Date: Mon Sep 24 15:16:23 2007
New Revision: 128718
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128718
Log:
PR c++/33506
* langhooks.h (struct
When I compile the program listed below with the snapshot version of gfortran
dated September 24 I get the following spurious warning:
pp.f90:3.15:
rft = TRANSFER(' ', 0.0)
1
Warning: Intrinsic TRANSFER at (1) has partly undefined result: source size 1
result size 4
PROGRAM printd
On 24 Sep 2007 15:48:19 -, michael dot a dot richmond at nasa dot
gov [EMAIL PROTECTED] wrote:
When I compile the program listed below with the snapshot version of gfortran
dated September 24 I get the following spurious warning:
pp.f90:3.15:
rft = TRANSFER(' ', 0.0)
1
--- Comment #1 from pinskia at gmail dot com 2007-09-24 15:53 ---
Subject: Re: New: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot
of gfortran
On 24 Sep 2007 15:48:19 -, michael dot a dot richmond at nasa dot
gov [EMAIL PROTECTED] wrote:
When I compile the program
--- Comment #4 from pcarlini at suse dot de 2007-09-24 16:46 ---
I see, thanks. Well, if I can bother you a bit more about your very welcome
work on attribute aligned, I noticed also PR10179. Thanks again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21385
--- Comment #9 from pcarlini at suse dot de 2007-09-24 17:05 ---
In any case, the pre-processed code doesn't compile anymore with 4.2 and
mainline.
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #7 from jason at redhat dot com 2007-09-24 17:05 ---
Subject: Re: wrong constructor called -- default argument in
constructor not seen
rguenth at gcc dot gnu dot org wrote:
Looks like non-regression wrong-code bugs get no attention :/
Actually, I've fixed several of
I just tried compiling mainline on my dusty alphaev67-dec-osf5.1 and discovered
that recent RTL CFG changes have broken the way that exceptions are implemented
on alpha/Tru64. Natively, this is seen with configure and make bootstrap
as a breakage configuring libstdc++-v3 where the exception model
--- Comment #2 from burnus at gcc dot gnu dot org 2007-09-24 17:26 ---
(In reply to comment #0)
When I compile the program listed below with the snapshot version of gfortran
dated September 24 I get the following spurious warning:
pp.f90:3.15:
rft = TRANSFER(' ', 0.0)
--- Comment #5 from jsm28 at gcc dot gnu dot org 2007-09-24 17:36 ---
Working on a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from appfault at hotmail dot com 2007-09-24 17:48 ---
Due to lack of responsiveness, a separate Bug 33394 was opened for the missing
test case. Verified this is generically in concept a duplicate of bug 21334,
although the technical details are in fact not the same.
--- Comment #5 from pcarlini at suse dot de 2007-09-24 18:01 ---
Isn't the C++ front-end also fixed? I can confirm that currently the error
comes from cp_parser_jump_statement. In general, the check in build_bc_goto is
apparently dead: I have been able to build and test with
$ cat 0.cpp
template typename R, typename T, R ( T::* method )()
static inline R dispatch( T object )
{
return ( object.*method )();
}
struct X
{
virtual ~X();
virtual void f();
};
void test1( X obj )
{
void ( *f )( X ) = dispatch void, X, X::f ;
f( obj );
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-09-24 18:07 ---
If this has already been fixed on the trunk, then what is the issue?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33546
--- Comment #2 from pcarlini at suse dot de 2007-09-24 18:10 ---
Maybe the underlying issue is tree-optimization/3713, not fixed in
less-than-trivial cases?
--
pcarlini at suse dot de changed:
What|Removed |Added
--- Comment #3 from pluto at agmk dot net 2007-09-24 18:21 ---
(In reply to comment #1)
If this has already been fixed on the trunk, then what is the issue?
4.3 is not ready for production use.
4.2.2 is quite stable and this missed optimization
introduces a redundant branch which is
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-09-24 18:24 ---
And enhancements only go for the next version and never on production code
(release branches) (like any sane product release should happen, even physicial
ones).
--
pinskia at gcc dot gnu dot org changed:
--- Comment #8 from bangerth at dealii dot org 2007-09-24 18:57 ---
(In reply to comment #7)
Actually, I've fixed several of those in the past few weeks.
I think this very much appreciated fact was what caused Richard to CC:
you on this PR :-)
--
--- Comment #3 from kargl at gcc dot gnu dot org 2007-09-24 18:57 ---
Tobias,
We may want to hide the warning behind a -Wshort-transfer option
(or some other appropriate name). Afterall, if a programmer
wrote 'rft = transfer(' ', 0.0)', then s/he probably meant it.
--
kargl at
--- Comment #4 from burnus at gcc dot gnu dot org 2007-09-24 19:17 ---
We may want to hide the warning behind a -Wshort-transfer option
(or some other appropriate name).
Maybe; I think having a warning by default would be more reasonable but it
should be hideable.
Afterall, if a
--- Comment #15 from pinskia at gcc dot gnu dot org 2007-09-24 19:45
---
The testcase in comment #12 was fixed via
http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00696.html .
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3713
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-09-24 19:46 ---
Fixed via http://gcc.gnu.org/ml/gcc-cvs/2007-09/msg00696.html .
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from sgk at troutmask dot apl dot washington dot edu
2007-09-24 19:59 ---
Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran
On Mon, Sep 24, 2007 at 07:17:54PM -, burnus at gcc dot gnu dot org wrote:
--- Comment #4 from
Compiling the following simple snippet:
void foo(void)
{
int i = 0x4E+0x23;
}
triggers the error message indicated in the summary.
Analysis of the problem shows that the macro VALID_SIGN() used inside
lex_number() (libcpp/lex.c) misidentifiex the plus sign following the
E (possible
--- Comment #5 from falk at debian dot org 2007-09-24 20:18 ---
As noted by Edvin Török, the bug is not fixed for the original test case
(although it is fixed for the small test case). A small test case that still
fails is
int f(void);
void acceptloop_th(int *t) {
int options = 0;
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:24
---
Subject: Bug 33538
Author: fxcoudert
Date: Mon Sep 24 20:24:11 2007
New Revision: 128724
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128724
Log:
PR fortran/33538
* scanner.c, parse.c,
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:26
---
Patch reverted, trunk should be back on track. Sorry.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-09-24 20:28
---
It would be nice to find a patch that doesn't break bootstrap on plenty of
platforms :)
I'll be on it when I have time, PR 33538 indicates the trouble caused by my
first patch, now reverted.
--
fxcoudert at
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-09-24 20:54 ---
we clearly don't do enhancements for a release branch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jason at gcc dot gnu dot org 2007-09-24 20:54 ---
Subject: Bug 33239
Author: jason
Date: Mon Sep 24 20:54:34 2007
New Revision: 128725
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128725
Log:
PR c++/33239
* pt.c (resolve_typename_type): Don't
--- Comment #1 from burnus at gcc dot gnu dot org 2007-09-24 20:55 ---
Re-reading the Fortran standard, I believe now that already call foo(10) is
invalid (although it is not ambiguous).
Two or more accessible entities, other than generic interfaces or
defined operators, may have the
--- Comment #7 from jason at gcc dot gnu dot org 2007-09-24 20:56 ---
Fixed for 4.3.0.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from jason at gcc dot gnu dot org 2007-09-24 21:00 ---
Fixed in 4.3.0. Not sure if the fix should go into 4.2.x, since it's an ABI
change.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from schwab at suse dot de 2007-09-24 21:13 ---
0x4E+0x23 is a single preprocessing number. If that cannot be turned into a
valid token then the program is malformed. Put in some space.
--
schwab at suse dot de changed:
What|Removed
--- Comment #8 from tobi at gcc dot gnu dot org 2007-09-24 21:15 ---
Subject: Bug 33269
Author: tobi
Date: Mon Sep 24 21:15:00 2007
New Revision: 128732
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=128732
Log:
PR fortran/33269
fortran/
* io.c (check_format_string): Move NULL
On 24 Sep 2007 19:59:37 -, sgk at troutmask dot apl dot washington
dot edu [EMAIL PROTECTED] wrote:
The programmer for whatever reason could be using rft as temporary storage.
Yes, I know it's a hypothetical situation, but the following is legal code
and should not give a warning.
Though I
--- Comment #6 from pinskia at gmail dot com 2007-09-24 21:26 ---
Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran
On 24 Sep 2007 19:59:37 -, sgk at troutmask dot apl dot washington
dot edu [EMAIL PROTECTED] wrote:
The programmer for whatever
--- Comment #7 from patchapp at dberlin dot org 2007-09-24 21:45 ---
Subject: Bug number PR7
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-09/msg01712.html
--
--- Comment #9 from patchapp at dberlin dot org 2007-09-24 21:48 ---
Subject: Bug number PR33269
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-09/msg01797.html
--
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2007-09-24 21:49 ---
Subject: Re: Spurious warning in TRANSFER intrinsic in Sept 24 snapshot of
gfortran
On Mon, Sep 24, 2007 at 09:26:01PM -, pinskia at gmail dot com wrote:
On 24 Sep 2007 19:59:37 -, sgk
--- Comment #24 from bangerth at dealii dot org 2007-09-24 22:07 ---
Since the original issue is resolved and the audit trail of the bug already
very long, I'll close this PR. If you feel that the missed optimization
isn't addressed yet, please open a new report with this issue that
--- Comment #5 from wilson at gcc dot gnu dot org 2007-09-24 22:53 ---
Echoing what Andrew Pinski already said, this isn't C code, this is RTL code,
the format of which is specified by the read-rtl.c file. Specifically, see the
read_brace_string function, which accepts backslash
I am getting a core dump with a program compiled with gcc-4.1.2 (64bit). The
program crashed inside the function call pam_authenticate.
The program uses the pam library and is compiled by the following command:
gcc-4.1.2/bin/gcc -mlp64 pam_test.c -lpam -o pt
-bash-3.00$ ldd pt
--- Comment #8 from pcarlini at suse dot de 2007-09-24 23:33 ---
Therefore, if I understand correctly, we want to reject the code and 4.2.0 was
already implementing that behavior. This is not a regression, we can close it
as fixed. If I'm mistaken, please reopen, thanks.
--
pcarlini
1 - 100 of 114 matches
Mail list logo
