Dave Korn wrote:
Patch prepared, I'll finish writing it up and submit to the newlib list
later tonight, but first I'm going to have a celebratory beer or two on
the way home...
I have applied the patch
(http://sourceware.org/ml/newlib/2007/msg00292.html) an GCC-4.3
(core+gfortran) builds
Daniel Berlin wrote:
On 3/27/07, Antoine Eiche [EMAIL PROTECTED] wrote:
Dear all,
I want to insert functions calls during a new pass.
Which version of GCC?
The problem is to
create parameters. At this time, I successfully create a function call
with two constante as parameter and insert it
On Thu, Mar 29, 2007 at 09:38:02PM -0700, Ian Lance Taylor wrote:
Provided we keep locations on statements, specifically including
GIMPLE_MODIFY_EXPR, does it really help us to keep locations on
expressions within statements in optimized code? What could the
debugger do with that information,
Hi ,
I am working on Shared flat file support for uClinux (No MMU ARM ).The
gcc version
I am using is 2.95 and 3.4.0.Theory of operation is similar to that
implemented for m68k.One of the major requirement is to call functions
via GOT.
so a code
**c-code**
foo()
{}
main()
{
On 3/29/07, Daniel Jacobowitz [EMAIL PROTECTED] wrote:
On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote:
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Why will expressions have location? It seems to me preferable to save
the memory. After a few
On Fri, 2007-03-30 at 17:57 +0530, vivek tyagi wrote:
Hi ,
This is the wrong list for these sorts of questions, you should really
be asking on gcc-help.
I am working on Shared flat file support for uClinux (No MMU ARM ).The
gcc version
I am using is 2.95 and 3.4.0.Theory of operation is
Hi there,
I maintain a GCC port for a small 16 bit processor called XAP2+. I'm
having problems with strings of wide characters.
I have the following defines, among others:
#define BITS_PER_UNIT 16
...
#define WCHAR_TYPE int
#define WCHAR_TYPE_SIZE 16
So, I'm
Mark Mitchell wrote on 03/22/07 22:10:
PR 29585 (Novillo): ICE-on-valid
This one seems to be a bug in the C++ FE, compounded by alias analysis
papering over the issue. We are failing to mark DECLs in vtbl
initializers as addressable. This causes the failure during aliasing
because it is added
I am working on Shared flat file support for uClinux (No MMU ARM ).The
gcc version
I am using is 2.95 and 3.4.0.Theory of operation is similar to that
You really need to be using the latest gcc (ie. svn trunk, aka 4.3) before we
can help you.
gcc also has a uclinux target. You should be
Hi there,
I am trying to install gfortran from the sources on my computer but I
doesn't work.
My computer is an Apple's MacBook Pro with an Intel CPU.
The sources I use are gcc-4.1.2 and i just want to install gfortran.
The configure I use is :
./configure --prefix=$HOME/.../gcc412
Hi Aurélien,
A few remarks:
1. you don't show us the actual compilation error message: why is
make failing?
2. maybe you don't know, but there are binaries available from
http://gcc.gnu.org/wiki/GFortranBinaries, if that helps.
3. you should definitely quote the system compiler and cctools
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Aldy Hernandez [EMAIL PROTECTED] writes:
There are a number of other compilers with successful IR
implementations, and some of them are open source, such as LLVM or
Open64. Since you are essentially proposing a new IR, I
Diego Novillo wrote:
I traced the problem back to the building of vtables. I'm simply
calling cxx_mark_addressable after building the ADDR_EXPR (I'm wondering
if building ADDR_EXPR shouldn't just call langhooks.mark_addressable).
Looks fine to me. Many places in the front end use
On 3/29/07, Aldy Hernandez [EMAIL PROTECTED] wrote:
After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
to continue overloading trees will be more work in the long run than doing the
actual separation between tuples and trees. This business of this is
a tree, but not
I think something like
struct gimple_statment_base
{
enum gimple_stmt_code code : 8;
unsigned int subcode : 24;
source_locus locus;
tree block;
Just jumping late into the debug info discussion, RTL locators are
combining TREE blocks and source_locuses into single
There are a lot of us that are happy to devote time and people
resources to helping you with this (both design and implementation),
so if you feel like you don't have time to go look at other IR's or
something, please let us help :)
That would be great, especially the bit about looking at
Jason Merrill wrote on 03/30/07 11:45:
Looks fine to me. Many places in the front end use build_address rather
than build1 (ADDR_EXPR) to avoid this issue.
Yeah, I found other cases in Java and in c-*.c. In one case, we are
building the address of a LABEL_DECL for a computed goto
Diego Novillo wrote:
Interestingly enough, mark_addressable refuses to mark the label as
addressable, but we need the label addressable so that it's processed
properly by the compute_may_aliases machinery.
Given that we need to be very consistent about addressability marking in
the FEs,
Hi FX, Hi all
Thanks for the binairies. I wanted to install it from sources but I
used the binairies. And I think i found a bug : the binairy fails if
the directory /usr/local/bin doesn't exist.
As you've requested, here are 2 files.
out_conf is the output of the configure
out_make is the
Diego Novillo wrote:
This one seems to be a bug in the C++ FE, compounded by alias analysis
papering over the issue.
Doh! Thank you for tracking this down.
Mark, does this look OK? (not tested yet)
Index: cp/class.c
===
out_make is the output of the make. In fact it is the output of the
make launch a second time. (To big otherwise.)
Yes, but it's missing the standard error file. Please use:
make out_make 2 err_make
or something similar.
FX
On Fri, Mar 30, 2007 at 01:59:12PM +0100, Thomas Gill wrote:
Hi there,
I maintain a GCC port for a small 16 bit processor called XAP2+. I'm
having problems with strings of wide characters.
I have the following defines, among others:
#define BITS_PER_UNIT 16
...
#define
Daniel Berlin wrote:
On 3/30/07, Antoine Eiche [EMAIL PROTECTED] wrote:
Daniel Berlin wrote:
On 3/27/07, Antoine Eiche [EMAIL PROTECTED] wrote:
Dear all,
I want to insert functions calls during a new pass.
Which version of GCC?
The problem is to
create parameters. At this time, I
Mark Mitchell wrote on 03/30/07 12:22:
So, I think the right fix is (a) the change above, (b) remove the
TREE_ADDRESSABLE setting from mark_vtable_entries (possibly replacing it
with an assert.)
After removing the papering over TREE_ADDRESSABLE we were doing in the
aliaser, I found that other
Diego Novillo wrote on 03/30/07 13:21:
This patch bootstraps all default languages. I'll test Ada later on,
but I need input from all the FE folks.
Sigh. I forgot to include Mark's suggestion in the patch. With this
patch, calling build_address in dfs_accumulate_vtbl_inits is not
strictly
On Mar 30, 2007, at 7:45 AM, Aurélien Benoit-Lévy wrote:
Do you have any idea of what went wrong and any idea of what should
I do ?
Hum, I'd be tempted to say, try a gcc-4.2 snapshot. If it doesn't
work, we'll fix it for you. :-)
Ian Lance Taylor wrote:
I agree, but what is happening now is that no newline at end of file
is an error even when -pedantic is not specified. I don't think that
is acceptable.
I completely agree.
The convention in the C++ front end is to say:
if (pedantic)
pedwarn (...);
for things
One thing that I'm wondering about this patch is why hasn't this been
done before? We seem to purposely separate TREE_ADDRESSABLE from
ADDR_EXPR. Perhaps to prevent pessimistic assumptions? The current
aliasing code removes addressability when it can prove otherwise.
One concern I have in
Dear,
I felt a bit disappointed while learning about the throw qualifier.
I think a more useful qualifier can be created in order to describe
the possible exceptions a method can throw, in the following way:
int TheClass::exceptMethod() _throw TheException {
throw TheException();
}
In this
Richard Kenner wrote on 03/30/07 13:45:
One concern I have in marking a DECL addressable that early on is that
it may stay stuck even if the ADDR_EXPR is later eliminated. This can
be common in inlined situations, I thought.
The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
variables that do not need it anymore, so that should not be a problem.
Yes, but you're calling the lang hook, which in theory, is allowed
to do all sorts of different things. How do those get undone when we find
*they* aren't
Hi all,
i must add a new pass to gcc. I want to receive from command line an
integer value at compilation time. I have modify the file common.opt but
tha value of the variable is alwais 0.
I have add the following row:
my-variable=
Common Var (my_variable)init(-1).
Comments
I want to
On Mar 30, 2007, at 11:05 AM, Sergio Giro wrote:
int TheClass::exceptMethod() _throw TheException {
throw TheException();
}
In this case, the gcc would check at runtime that the only exception
the method exceptMethod may throw is TheException.
It does.
Moreover
int
On Mar 30, 2007, at 11:24 AM, albino aiello wrote:
i must add a new pass to gcc. I want to receive from command line
an integer value at compilation time. I have modify the file
common.opt but tha value of the variable is alwais 0.
I have add the following row:
my-variable=
Common Var
On 3/30/07, Mike Stump [EMAIL PROTECTED] wrote:
? Just what did you want that isn't in the standard again? Is the
feature you want just static checking for exception specifications at
compile time?
Yes, it is. Please read compile time when it says runtime. The
errors mentioned are compile
On Mar 30, 2007, at 11:59 AM, Sergio Giro wrote:
The errors mentioned are compile errors,
So, you want a strict subset of the language standard. This is best
done with something like -fstatic-exception-specifications or maybe -
Wexception-specifications -Werror. If you wanted finer
I was just poking around with the latest snapshot for fun when I came
across a huge problem: the make would fail without reason. It wouldn't
give any actual reason at all. It would be building the HTML parser
and after a bit would just give up. make gave the error [error 1]
about the target file,
On 3/30/07, Richard Kenner [EMAIL PROTECTED] wrote:
The aliaser is fairly aggressive at removing TREE_ADDRESSABLE from
variables that do not need it anymore, so that should not be a problem.
Yes, but you're calling the lang hook, which in theory, is allowed
to do all sorts of different
The lang hook is supposed to mark the variable as addressable.
The lang hook should not be changing other things that have an affect
on the *middle end*. No exceptions.
But how is it supposed to mark the variable as addressable? If this
just means setting TREE_ADDRESSABLE, what's the point
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
Joe Buck
Sent: Monday, March 19, 2007 2:02 PM
To: Andrew Pinski
Cc: Florian Weimer; Steven Bosscher; gcc@gcc.gnu.org
Subject: Re: Building mainline and 4.2 on Debian/amd64
On Mon, Mar 19, 2007 at
On 3/30/07, Richard Kenner [EMAIL PROTECTED] wrote:
The lang hook is supposed to mark the variable as addressable.
The lang hook should not be changing other things that have an affect
on the *middle end*. No exceptions.
But how is it supposed to mark the variable as addressable? If this
Hi. Just wanted to share that the following macro gives an error on latest
versions of GCC, but is reported to work on 2.95.3 (tested on MorphOS but
should be the same for other OSses of course).
Both an old version of SASC(AmigaOS) and Borland (on X86) worked fine.
#includestdio.h
#define
You could just remove the '##'.
Soma
On 3/30/07, JoseD [EMAIL PROTECTED] wrote:
Hi. Just wanted to share that the following macro gives an error on latest
versions of GCC, but is reported to work on 2.95.3 (tested on MorphOS but
should be the same for other OSses of course).
Both an old
But how is it supposed to mark the variable as addressable? If this
just means setting TREE_ADDRESSABLE, what's the point of having the hook?
It also issues language specific warnings
Then one suggestion is that we rename the langhook to warn_addressable and
set TREE_ADDRESSABLE
On Mar 30, 2007, at 12:32 PM, Null Heart wrote:
I was just poking around with the latest snapshot for fun
Two thoughts come to mind. First, qualify your system with a known
to build, known to be good compiler. Build it 20 times, if it never
fails to build, you probably have a good
Hi,
I'm using g++ 4.1.1 under Fedora Core 5 in an X86 system.
I read the GCC manual and it says -Wall includes the -Wswitch-enum
and -Wswitch-default warnings. But I had to supply these command
line options explicitly before the warnings are generated. Is the
manual wrong or is there a bug in
On 3/30/07, Mike Stump [EMAIL PROTECTED] wrote:
On Mar 30, 2007, at 12:32 PM, Null Heart wrote:
I was just poking around with the latest snapshot for fun
Two thoughts come to mind. First, qualify your system with a known
to build, known to be good compiler. Build it 20 times, if it never
Snapshot gcc-4.3-20070330 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070330/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Mar 30, 2007, at 2:10 PM, Null Heart wrote:
... No file failed.
You've not read the output correctly. The file named by make failed,
that file named is gnu/javax/swing/text/html/parser/HTML_401F.lo.
GCJ did not give an error.
That then is a bug is gcj, a failed compile should
Building gcc4-4.3.0-20070331 fails on PPC Darwin7 with:
...
/sw/src/fink.build/gcc4-4.3.0-20070331/darwin_objdir/./prev-gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20070331/darwin_objdir/./prev-gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -I../../gcc-4.3-20070331/libcpp -I.
On Mar 30, 2007, at 5:10 PM, Dominique Dhumieres wrote:
../../gcc-4.3-20070331/libcpp/directives.c:2086: error: pointer
targets in initialization differ in signedness
Re-update and build again, should work now I think.
Hi people
I want to talk an interesting topic of GCC hierarchy of subhierarchies.
By example, i want to add my personal option of optimization to GCC
but I see that it's very monolithic.
I don't see the subhierarchy of optimation stage in the snapshot tree.
Sincerely yours, J.C. Pizarro
Hi Richard ,Paul
This is the wrong list for these sorts of questions, you should really
be asking on gcc-help.
The project I am working on require changes to be made in the gcc
backend(probably front end too for complete solution).so I thought
best to discuss it with developers.
Is there
JoseD wrote:
Hi. Just wanted to share that the following macro gives an error on latest
versions of GCC, but is reported to work on 2.95.3 (tested on MorphOS but
should be the same for other OSses of course).
Both an old version of SASC(AmigaOS) and Borland (on X86) worked fine.
--- Comment #3 from bonzini at gnu dot org 2007-03-30 08:23 ---
still occurs at -O2 (testing with checking disabled).
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #36 from rguenth at gcc dot gnu dot org 2007-03-30 09:18
---
Thanks for the analysis! This should help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
--- Comment #37 from rguenth at gcc dot gnu dot org 2007-03-30 10:01
---
The (target) difference seems to be that I get (on x86_64)
mask_lo_45 = 0x0 D.33492_44;
with a value range of [0,64] for D.33492_44 and a resulting value range of
[0, +INF] for mask_lo_45, not
--- Comment #38 from rguenth at gcc dot gnu dot org 2007-03-30 10:15
---
Ok, got it now - the crucial point is where width comes from:
#define HOST_WIDE_INT long
#define HOST_BITS_PER_WIDE_INT (4*8)
struct tree_type
{
unsigned int precision : 9;
};
int
sign_bit_p (struct tree_type
--- Comment #3 from rakdver at gcc dot gnu dot org 2007-03-30 10:36 ---
Subject: Bug 31383
Author: rakdver
Date: Fri Mar 30 10:36:19 2007
New Revision: 123359
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123359
Log:
PR tree-optimization/31383
* tree-data-ref.c
--- Comment #39 from rguenth at gcc dot gnu dot org 2007-03-30 10:47
---
Created an attachment (id=13300)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13300action=view)
patch
The problem is that we in rshift_double() do
if (SHIFT_COUNT_TRUNCATED)
count %= prec;
which for
When trying to build the OOo code warning-free we turned all useful warnings on
and get rid of them.
But there is one warning that would be really useful missing. It is not
required for code correctness or safety at all, but it would be most useful to
have better understandable code.
What I/we at
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-30 11:00
---
We should also diagnostic better the cases of negative of too large NCOPIES
argument, for both parameters (in simplification routine) and non-parameters.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31304
Look out the output:
1. When no O2 option set, the output is:
send out: 50 Time: 1165250900
192.168.1.1 10
2. When -O2 option is set, the output is:
192.168.1.1 send out: 50 Time: 1165250934
10
It proves that the execution sequence has been changed. I think
--- Comment #1 from windows2000d at gmail dot com 2007-03-30 11:47 ---
Created an attachment (id=13301)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13301action=view)
The sample code show the bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31398
--
windows2000d at gmail dot com changed:
What|Removed |Added
Severity|normal |blocker
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31398
$ cat a.f90
integer(kind=1) :: i
integer(kind=8) :: c = 0
do i = -huge(i), huge(i), 2
c = c + 1
end do
print *, c
end
$ gfortran a.f90 ./a.out
0
I think it has to do with the comment on top of gfc_trans_do:
TODO: Large loop counts
The code above
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known
--- Comment #44 from manu at gcc dot gnu dot org 2007-03-30 12:25 ---
(In reply to comment #43)
A couple of days ago in irc I agreed to come up with a version of the patch
that just handles the C tests. So far it works fine with C but breaks
everything else, but I haven't forgotten
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-30 12:49
---
(In reply to comment #0)
the loop count should be
changed from
count = (to + step - from) / step
to something else that cannot overflow.
I think it should be:
unsigned count = (step0 ? tofrom : tofrom) ?
hello,
I am trying to build gcc-3.4.5 and gcc-3.4.6
for i960 as target.
my host machine:i686-pc-linux-gnu
target maccine:i960-unknown-coff
native compiler on my machine: gcc-4.0
operating system/gc version:gcc version 4.0.0 (Red Hat
4.0.0-8)on Fedora core-4
i have already installed
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-30 13:03 ---
You are relying on undefined behavior.
*** This bug has been marked as a duplicate of 11751 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #74 from rguenth at gcc dot gnu dot org 2007-03-30 13:03
---
*** Bug 31398 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
To deploy testing versions of applications built with (yet unreleased) versions
of gcc may be difficult due to linked in libraries as libgfortran and libgomp.
Similar to -static-libgcc, options like -static-libgfortran or -static-libgomp
would help to avoid problems. Especially for libgomp, one
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-30 15:21 ---
Looks like the kind of bug that cfglayout mode might introduce.
Will investigate...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-30 15:21 ---
Looks like the kind of bug that cfglayout mode might introduce.
Will investigate...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-30 15:22 ---
Which target is this, BTW?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tbm at gcc dot gnu dot org 2007-03-30 15:29 ---
I've seen it on x86_64 and ia64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
--- Comment #1 from hjl at lucon dot org 2007-03-30 15:47 ---
You may want to look at
http://gcc.gnu.org/ml/gcc/2005-12/msg00783.html
--
hjl at lucon dot org changed:
What|Removed |Added
the following program demonstrates, what I think, a flaw in std::string find.
According to me and (see comp.lang.c++ and c.l.c++.moderated) many others,
find( astring, string::npos ) should always return string::npos.
But G++ seems to wrap around an start searching at the begin of the string.
--- Comment #40 from rth at gcc dot gnu dot org 2007-03-30 16:14 ---
The reason we do that is to match the way the arithmetic would be performed
on the host as much as possible. This could be important if someother part
of the compiler already relied on SHIFT_COUNT_TRUNCATED to
--- Comment #1 from pcarlini at suse dot de 2007-03-30 17:25 ---
Yes, this is stupid bug, it's an unintended behavior caused by unsigned
overflow. Will be fixed before the end of the day, but isn't a regression, thus
only in 4_2-branch and mainline.
--
pcarlini at suse dot de
--- Comment #41 from rth at gcc dot gnu dot org 2007-03-30 17:30 ---
Created an attachment (id=13302)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13302action=view)
alternate patch
I'm inclined to take this approach to the problem. Note that the result
range we get from this is
--
pcarlini at suse dot de changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401
--- Comment #2 from paolo at gcc dot gnu dot org 2007-03-30 18:11 ---
Subject: Bug 31401
Author: paolo
Date: Fri Mar 30 18:10:50 2007
New Revision: 123361
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123361
Log:
2007-03-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #3 from paolo at gcc dot gnu dot org 2007-03-30 18:11 ---
Subject: Bug 31401
Author: paolo
Date: Fri Mar 30 18:11:22 2007
New Revision: 123362
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123362
Log:
2007-03-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #4 from pcarlini at suse dot de 2007-03-30 18:12 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-03-30 18:41 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
Hello,
there seems to be a gcc problem with the target 'sh-elf':
/home/mstein/sim/sh-elf/build/./gcc/xgcc -B/home/mstein/sim/sh-elf/build/./gcc/
-nostdinc -B/home/mstein/sim/sh-elf/build/sh-elf/newlib/ -isystem
/home/mstein/sim/sh-elf/build/sh-elf/newlib/targ-include -isystem
--- Comment #11 from cvs-commit at developer dot classpath dot org
2007-03-30 18:58 ---
Subject: Bug 29869
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey tromey 07/03/30 17:57:44
Modified files:
. : ChangeLog
--- Comment #1 from mstein at phenix dot rootshell dot be 2007-03-30 19:15
---
Created an attachment (id=13303)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13303action=view)
preprocessed source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31403
--- Comment #13 from fche at redhat dot com 2007-03-30 19:21 ---
Case 1, is also too hard to fix as it would make us lose a lot of
optimizations.
If aoliva is correct in comment# 11, then some information is being lost
that could be retained with some additional effort. That would
--- Comment #1 from eweddington at cso dot atmel dot com 2007-03-30 19:55
---
Dr. John,
Can you provide additional information:
- What AVR processor was this compiled for? You don't have the required -mmcu=
flag in your command line.
- Can you provide a disassembly listing showing
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Last reconfirmed|2007-03-30 15:21:40 |2007-03-30
--- Comment #9 from paolo at gcc dot gnu dot org 2007-03-30 20:46 ---
Subject: Bug 26099
Author: paolo
Date: Fri Mar 30 20:45:57 2007
New Revision: 123366
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123366
Log:
gcc/
2007-03-30 Paolo Carlini [EMAIL PROTECTED]
PR
--- Comment #1 from eweddington at cso dot atmel dot com 2007-03-30 20:58
---
The test program works for me for AVR GCC 4.1.1. (WinAVR distro 20070122)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29932
--- Comment #3 from steven at gcc dot gnu dot org 2007-03-30 21:05 ---
TREE_COMPLEXITY is history
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #45 from manu at gcc dot gnu dot org 2007-03-30 21:13 ---
I have fixed all failing testcases in the C front-end. I am going to send the
fixes to janis, if someone else is interested, let me know it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
--- Comment #6 from steven at gcc dot gnu dot org 2007-03-30 21:16 ---
At the end of loop2, the tryagain label is turned into a deleted label note.
This happens because the label has zero uses left in cfglayout. There are only
unconditional jumps to it, unconditional jumps are removed
--- Comment #3 from sdirkse at gams dot com 2007-03-30 21:36 ---
I installed gcc 20070329 and the problem I was having is solved. I suppose
that makes it a duplicate of PR30980.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
U:\vrao\fortrantype xlen_trim.f90
integer :: ic(1) = len_trim((/a/))
print*,ic=,ic
end
U:\vrao\fortrangfortran -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
1 - 100 of 123 matches
Mail list logo
