Ok, so the mist is clearing. We produce assembly, including directives,
etc, and target gputils initially (because it exists, and it works), and
then later, do a port for binutils.
Is there anyone thats familiar with any of the other microcontroller ports
like the AVR port, so that we can
On Mon, 2006-03-13 22:49:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: pault
Date: Mon Mar 13 22:49:56 2006
New Revision: 112028
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112028
2006-03-13 Paul Thomas [EMAIL PROTECTED]
Modified:
trunk/configure
[...]
-
#
Hi
This cut down example does not compile with gcc 3.4.x / 4.0.x or 4.1.0.
test.cpp: In constructor 'ThreeT::Three()':
test.cpp:20: error: 'm_Public' was not declared in this scope
It does compile with VS2005 / VS6
class One
{
public:
One();
~One();
public:
int
On Tuesday 14 March 2006 03:16, Waldek Hebisch wrote:
Jeffrey A Law wrote:
On Mon, 2006-02-27 at 20:08 +0100, Waldek Hebisch wrote:
What do you mean by abuse? TYPE_MAX_VALUE means maximal value
allowed by given type.
As long as you're *absolutely* clear that a variable with a
Hi,
Since 3.4, (template-)dependent lookup has been changed to conform
to the standard. In particular, from http://gcc.gnu.org/gcc-3.4/changes.html:
In a template definition, unqualified names will no longer find members
of a dependent base.
This allows lookups to be bound at template
Paolo Bonzini schrieb:
I have a patch. Will keep you posted.
Paolo
Now it's completly broken!!!
Configuring stage 1 in ./binutils
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
checking host system type... config.sub: missing
On Tue, 2006-03-14 11:37:07 +0100, Rainer Emrich [EMAIL PROTECTED] wrote:
Paolo Bonzini schrieb:
I have a patch. Will keep you posted.
Paolo
Now it's completly broken!!!
...in multiple ways.
Using a cross-compiler to build a compiler running on some target is
broken for me since
Steven Bosscher [EMAIL PROTECTED] wrote on 14/03/2006 01:32:09:
Hi Ayal,
The SMS implementation in GCC, in modulo-sched.c, uses line notes
to find insn locations, see find_line_note. Why are you using
line notes instead of insn locators? Line notes are on the list
of Things That Should
On 14. Mrz 2006, at 01:53 Uhr, Mike Stump wrote:
Am I the only one who gets those:
DOMElement.m:283: warning: pointer type mismatch in conditional
expression
I doubt it.
;-)
For stuff like:
objs[1] = _ns ? _ns : (id)null;
or
return [pathes isNotNull] ? pathes : nil;
And here all
Rainer Emrich wrote:
Paolo Bonzini schrieb:
I have a patch. Will keep you posted.
Paolo
Now it's completly broken!!!
But I didn't commit anything, and not even posted it, because of the
breakage... :-)
Paolo
Most existing GCC ports for microcontrollers rely on a matching Binutils
port in order to provide an assembler (GAS) and linker (GNU ld). GCC
itself always produces assembler output (which may or may not be saved
to a file).
Colm O' Flaherty wrote:
All,
I've been thinking a bit more about
Note that there is some interesting documentation regarding adding a new
backend (PIC, for example), and general gcc development issues at:
http://gcc.gnu.org/readings.html This section answers a couple of the
questions I have already asked, or was about to ask! RTFM, I guess.. :)
In the
On Tue, 2006-03-14 09:56:40 +0100, Jan-Benedict Glaw [EMAIL PROTECTED] wrote:
On Mon, 2006-03-13 22:49:57 -, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:
# Guess values for system-dependent variables and create Makefiles.
-# Generated automatically using autoconf version 2.13
-#
On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote:
Among other differences, it decides that we're cross-building, which
isn't true in this case. This results in vax-linux-uclibc-gcc being
used to build libiberty for the build system (which is
i686-linux-gnu). No wonder that `genmode' cannot
On Tue, 2006-03-14 08:56:38 -0500, Andrew Pinski [EMAIL PROTECTED] wrote:
On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote:
Among other differences, it decides that we're cross-building, which
isn't true in this case. This results in vax-linux-uclibc-gcc being
used to build libiberty for
On 3/14/06, Ayal Zaks [EMAIL PROTECTED] wrote:
The line notes are not used to find insn locations -- we carry them along
because we had to. If we no longer need to worry about keeping each line
note adjacent to its insn during scheduling, that would simplify things.
Please advise.
You should
Here is a sample program which does the right thing (no spurious console
windows, all output visible) when run either from a console or from a
console-free environment, such as a Cygwin xterm. This is the code
we'll be working into libiberty -- unless someone has a better solution!
The potential
Hello,
On 3/13/06, Thomas Yeh [EMAIL PROTECTED] wrote:
Hi All,
I am trying to use the latest autovectorization gcc code to generate
functionally correct SSE instructions, and I have the following questions:
Where is the latest stable gcc version with autovector? (is this 4.1.0?)
and
On 14 March 2006 18:52, Ross Ridge wrote:
Here is a sample program which does the right thing (no spurious console
windows, all output visible) when run either from a console or from a
console-free environment, such as a Cygwin xterm. This is the code
we'll be working into libiberty --
Andrew Pinski wrote:
On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote:
Among other differences, it decides that we're cross-building, which
isn't true in this case. This results in vax-linux-uclibc-gcc being
used to build libiberty for the build system (which is
i686-linux-gnu). No
Andrew (and everybody else),
I upgraded autoconf because the build crashed when I tried to regenerate
the fortran library. There were already symbols present that were not
recognised by my autoconf (I kept no record of which - it was the
default with FC3). I upgraded to the version
Is this really worth it? Could this whole problem be solved by you
switching to rxvt? Maybe the only problem is that your xterm is broken.
Nothing is broken. The problem is that Cygwin applications run in a
slightly special environment, where there may not be a console attached to
the
On 14 March 2006 19:22, Paul Brook wrote:
Is this really worth it? Could this whole problem be solved by you
switching to rxvt? Maybe the only problem is that your xterm is broken.
Nothing is broken. The problem is that Cygwin applications run in a
slightly special environment, where
Dave Korn writes:
I don't understand why you think Mark's code needs to search the PATH or
append '.exe', when it invokes CreateProcess that does all that for you?
I've already answered that question: subtle differences in the other
behaviours could cause problems. The search behaviour and
On Tuesday 14 March 2006 19:46, Ross Ridge wrote:
Dave Korn writes:
I don't understand why you think Mark's code needs to search the PATH or
append '.exe', when it invokes CreateProcess that does all that for you?
I've already answered that question: subtle differences in the other
Greetings.
I am experiencing a major performance problem with the log() function on
the x86_64 platform. It can be illustrated with the following little
test program:
testlog.cxx===
#include math.h
main()
{
float f = 0;
for ( int i = 0; i 1e8; ++i )
f
I think it is a glibc issue.
H.J.
-
On Tue, Mar 14, 2006 at 01:18:34PM -0800, Torsten Rohlfing wrote:
Greetings.
I am experiencing a major performance problem with the log() function on
the x86_64 platform. It can be illustrated with the following little
test program:
Daniel Berlin wrote:
On Mon, 2006-03-13 at 16:25 -0700, Tom Tromey wrote:
Mike == Mike Mattie [EMAIL PROTECTED] writes:
Mike Has anyone ever tried to build a scripting interface into the guts of
Mike GCC with something like SWIG ?
I've heard of a couple efforts along these lines -- once with
Ross Ridge wrote:
Arguably, not having a console window attached a shell window is broken
in the Cygwin environment.
Paul Brook wrote:
How exactly do you suggest implementing this?
The same way Cygwin rxvt implements this.
By implication you're saying that you shouldn't able to use gcc
On Sun, Mar 12, 2006 at 09:16:47PM -0800, Mark Mitchell wrote:
Christopher Faylor wrote:
I don't see any reason why cygwin should be causing a console window to
flash when spawn is used.
Maybe this is something that should be pursued in the Cygwin list. The
test cases will be useful but
On Sun, Mar 12, 2006 at 09:43:12PM -0800, Mark Mitchell wrote:
Mark Mitchell wrote:
What cygcheck output would be helpful? I've never run cygcheck until
just now, and it seems to have lots of options.
By the way, I don't see any reason to suspect that there's a Cygwin bug.
The situation is:
Christopher Faylor wrote:
ptys are supposed to have invisible consoles associated with them. Since
xterm uses an invisible console I still don't see why there should be
a console popup.
This still sounds like a cygwin problem to me.
As a test case, I'd recommend the latest code I posted.
Mark Mitchell wrote:
As a test case, I'd recommend the latest code I posted. If a MinGW
application tries to open CONOUT$ with CreateFile, it gets
INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is
available.
I should have said in a Cygwin xterm somewhere in that
In:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg02102.html
you add restrap unconditionally, and yet it was already defined
above, thus causing make to say:
mrs $ make
Makefile:13094: warning: overriding commands for target `restrap'
Makefile:12386: warning: ignoring old commands for
On Tue, Mar 14, 2006 at 04:56:21PM -0800, Mark Mitchell wrote:
Mark Mitchell wrote:
As a test case, I'd recommend the latest code I posted. If a MinGW
application tries to open CONOUT$ with CreateFile, it gets
INVALID_HANDLE_VALUE, so the OS doesn't seem to think the console is
available.
I
Christopher Faylor wrote:
And, if it can't open CONOUT$ in cygwin's xterm, that's a bug...
Great!
But that's also irrelevant to the broader issue as to whether or not we
try to get this right in libiberty. The issue isn't Cygwin; the issue
is whether or not we operate correctly when gcc is
Hi all,
what is the difference beetween this abi?
The standard arm procedure call is the first one. What is introduced in the
apcs-gnu? Is there some documentation about the last one?
Regards
Michael
This message was sent using
Mike Stump wrote:
In:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg02102.html
you add restrap unconditionally, and yet it was already defined above,
thus causing make to say:
Yeah, I had delayed a bit the fix hoping that Dan J. would rip out the
old bootstrap mechanism. He did not, so
--- Comment #4 from hochstein at algo dot informatik dot tu-darmstadt dot
de 2006-03-14 08:27 ---
This is a GCC bug although my first test program did not show this.
Consider this program:
void a()
{
}
void b()
{
__asm(nop\n nop\n nop\n nop\n nop\n nop);
// ...
// (repeat
--- Comment #91 from mueller at gcc dot gnu dot org 2006-03-14 09:24
---
well, of course, because your libstdc++ is compiled with the wrong (LSB
incompliant btw) stdc++ allocator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-03-14 09:53 ---
Subject: Bug 26659
Author: rguenth
Date: Tue Mar 14 09:53:36 2006
New Revision: 112048
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112048
Log:
2006-03-14 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #8 from rguenth at gcc dot gnu dot org 2006-03-14 09:54 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-14 09:57 ---
Fixed on the mainline.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-14 09:57 ---
Subject: Bug 26667
Author: rguenth
Date: Tue Mar 14 09:57:43 2006
New Revision: 112049
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112049
Log:
2006-03-14 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-14 10:27 ---
if the output of config.guess does not match your --host=... string you are
building a cross compiler. Try making those match or also specify --build.
--
rguenth at gcc dot gnu dot org changed:
What
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-14 10:33 ---
Right. I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-14 10:51 ---
Usually these kind of wrong jumps get fixed up by the linker by inserting
trampolines. So this looks like a binutils bug.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
__uint128_t sqr_1(__uint64_t x)
{
return (x * (__uint128_t)x);
}
gcc-4.1.1-20060308 produces an ugly code:
sqr_1: xorl%edx, %edx # D.1810
movq%rdi, %rax # x, D.1810
movq%rdx, %rcx #, tmp62
imulq %rdi, %rcx # D.1810, tmp62
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-14 12:50 ---
Subject: Bug 26672
Author: rguenth
Date: Tue Mar 14 12:50:10 2006
New Revision: 112050
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112050
Log:
2006-03-14 Richard Guenther [EMAIL PROTECTED]
PR
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Component|other |target
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-14 13:30 ---
Subject: Bug 26672
Author: rguenth
Date: Tue Mar 14 13:30:08 2006
New Revision: 112051
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112051
Log:
2006-03-14 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-03-14 13:30 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-14 13:30 ---
Is this really a regression, if not please close it as fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26667
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-03-14 13:32 ---
This particular testcase does not expose a regression. But because of the
times==0 bug I can cause arbitrary ininling that was not done in 4.0. In any
case, it would be a low-priority regression.
--
--- Comment #3 from grigory_zagorodnev at linux dot intel dot com
2006-03-14 13:32 ---
It appears that configuration scheme changed in revision 112028 of trunk
without any notice.
[trunk revision 112027]
Host type:
--build=BUILD configure for building on BUILD
When compiling the AWS HEAD release I get the following Error message:
gcc -c -O2 -gnatws -gnatn -I- -gnatA
/work/rpm/BUILD/AWS-release_2_1a/src/aws-client.adb
gcc -c -O2 -gnatws -gnatn -I- -gnatA
/work/rpm/BUILD/AWS-release_2_1a/src/aws-net-sets.ads
+===GNAT BUG
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-14 13:35 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #1 from charlet at gcc dot gnu dot org 2006-03-14 13:38 ---
Well, if it's CVS HEAD, it's not a release.
Anyway, please post self contained (reduced if possible) sources showing
the problem, as well as standalone command line (simplified if possible).
Thanks.
Arno
--
--- Comment #2 from krischik at users dot sourceforge dot net 2006-03-14
13:45 ---
Created an attachment (id=11047)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11047action=view)
The sources, concaternated and ziped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Keywords|wrong-code |diagnostic
Target Milestone|--- |4.1.1
--
krischik at users dot sourceforge dot net changed:
What|Removed |Added
Severity|normal |major
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26678
--- Comment #3 from charlet at gcc dot gnu dot org 2006-03-14 13:52 ---
Thanks for the sources. If you get a chance to reduce the problem, that
will certainly give this report higher priority.
I am also surprised by the location: tree-ssa-structalias.c, I thought
strict aliasing was
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-14 13:58 ---
Confirmed. The asm matches what we get from expand unfortunately.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-14 14:00 ---
Testcase:
typedef int __int128 __attribute__((mode(TI)));
__int128 foo(long x)
{
return x*(__int128)x;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26674
--- Comment #4 from krischik at users dot sourceforge dot net 2006-03-14
14:02 ---
Hi Arnaud,
The HEAD is indeed a typo - should have been release_2_1a. For head we have a
different problem (bug:26162).
As for the compiler, it is the unmodified release version:
GNAT 4.1.0
gcc (GCC)
During bootstrap line 3072 of varasm.c generates a warning that
shift = width of type, and the build dies due to -Werror.
This diagnosis is correct but the shift is unreachable.
Environment:
System: Linux dps 2.6.15 #2 PREEMPT Sat Jan 7 17:47:27 GMT 2006 i686 GNU/Linux
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-14 14:29 ---
What compiler are you using to get that warning?
There should be no warning as shift is a variable and n is a variable and
should be zero.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-14 14:31 ---
And I don't see why you using SIZEOF_UNSIGNED_INT as unsigned int does not come
in anywhere.
Now hashval_t does but that could be anything.
--
pinskia at gcc dot gnu dot org changed:
What
$ g++ -v
Using built-in specs.
Target: i386-unknown-netbsdelf3.0.
/.../
Thread model: posix
gcc version 4.0.2
$cat main.cc
struct Coord {};
template typename E class Array {};
class Env;
class Obstacle
{
Obstacle(const struct Coord pos, Env* env)
{
Please find the message :
gfortran -c -O -ffree-form -v -save-temps fspak90.f90
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure
--prefix=/cosmic/coudert/tmp/gfortran-20060310/irun
--enable-languages=c,fortran --host=i386-linux
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-14 14:44 ---
Fixed in 4.0.3.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2006-03-14 14:47
---
I am also surprised by the location: tree-ssa-structalias.c, I thought
strict aliasing was disabled for Ada. Are you using FSF GCC sources or sources
modified ?
Structure aliasing is indeed disabled for Ada
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-14 14:53 ---
A note is that it works on x86_64 (and I cannot test i686 because Ada does not
have mulitilib support:( ).
if Ada did have multilib support I could reduce this easier.
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from patchapp at dberlin dot org 2006-03-14 14:56 ---
Subject: Bug number PR26672
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/2006-03/msg00841.html
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-14 14:59 ---
Can you attach fspak90.f90 (if it is legal to do so)?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26681
--- Comment #4 from joseph at codesourcery dot com 2006-03-14 15:11 ---
Subject: Re: boostrap failure due to warning in
gcc/varasm.c
On Tue, 14 Mar 2006, pinskia at gcc dot gnu dot org wrote:
What compiler are you using to get that warning?
There should be no warning as shift is a
--- Comment #2 from Herve dot Chapuis at tours dot inra dot fr 2006-03-14
15:14 ---
Subject: Re: internal compiler error
pinskia at gcc dot gnu dot org a écrit :
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-14 14:59
---
Can you attach fspak90.f90 (if it is
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-14 15:14 ---
A simplier example from progsf90:
module ranlib
CONTAINS
LOGICAL FUNCTION qrgnin()
LOGICAL qrgnsn
ENTRY qrgnsn(qvalue)
end function
end module
--
The following simple.f90 program:
PROGRAM hello_world
PRINT *,Hello, World!
END PROGRAM hello_world
does not compile with the following arguments:
gfortran -fwhole-program -O2 -o simple simple.f90
~/gcc_install/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../libgfortranbegin.a(fmain.o)(.text+0x23):
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-14 15:19 ---
I have a fix already in mind for this simple issue. Though -fwhole-program is
not going to be fixed for Fortran code until the front-end stops having more
than one decl per function.
--
pinskia at gcc dot gnu
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-14 15:22 ---
I cannot reproduce this ICE with 4.2.0 20060312. I do run into another ICE
compiling fspak90 but that is filed as PR 24558.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26681
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|bootstrap |middle-end
Keywords||build
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-14 15:27 ---
Actually can you try it again after:
2006-03-14 Richard Guenther [EMAIL PROTECTED]
* configure: Regenerate with autoconf 2.13.
I think the toplevel configure was exposing this.
--
pinskia at gcc dot
--- Comment #4 from Herve dot Chapuis at tours dot inra dot fr 2006-03-14
15:37 ---
Subject: Re: internal compiler error
pinskia at gcc dot gnu dot org a écrit :
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-14 15:22
---
I cannot reproduce this ICE with
Did a search -- didn't see this...I'm porting threaded software between
solaris and linux and came across this...
bash2 :2 [EMAIL PROTECTED] 01:30:15; gcc -v
Reading specs from
/usr/local/gcc-3.4.5/lib/gcc/sparc-sun-solaris2.8/3.4.5/specs
Configured with: /usr/local/src/gnu/gcc-3.4.5/configure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-14 18:42 ---
Fixed in 4.2.0 by saying -pthread on solaris is now the same as -pthreads.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
All,
If the warning isn't bogus then we probably need to do the shift in two steps
(i.e. hwi = (hwi (shift - 1)) 1) as done elsewhere to avoid the
potential warning.
--- joseph at codesourcery dot com [EMAIL PROTECTED] wrote:
--- Comment #4 from joseph at codesourcery dot com
--- Comment #6 from graham dot stott at btinternet dot com 2006-03-14
18:55 ---
Subject: Re: boostrap failure due to warning in gcc/varasm.c
All,
If the warning isn't bogus then we probably need to do the shift in two steps
(i.e. hwi = (hwi (shift - 1)) 1) as done elsewhere to
On Mar 14, 2006, at 1:55 PM, Graham Stott wrote:
All,
If the warning isn't bogus then we probably need to do the shift in
two steps
(i.e. hwi = (hwi (shift - 1)) 1) as done elsewhere to avoid the
potential warning.
The only reason why it is bogus is because well it is dead code :).
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-14 18:57 ---
Subject: Re: boostrap failure due to warning in gcc/varasm.c
On Mar 14, 2006, at 1:55 PM, Graham Stott wrote:
All,
If the warning isn't bogus then we probably need to do the shift in
two steps
(i.e. hwi =
--- Comment #5 from sayle at gcc dot gnu dot org 2006-03-14 19:19 ---
Subject: Bug 26557
Author: sayle
Date: Tue Mar 14 19:19:14 2006
New Revision: 112063
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112063
Log:
PR middle-end/26557
* stmt.c (emit_case_nodes):
--- Comment #17 from sayle at gcc dot gnu dot org 2006-03-14 19:21 ---
Subject: Bug 26489
Author: sayle
Date: Tue Mar 14 19:21:25 2006
New Revision: 112064
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112064
Log:
PR other/26489
Backport from mainline.
*
--- Comment #13 from sayle at gcc dot gnu dot org 2006-03-14 19:25 ---
Subject: Bug 19543
Author: sayle
Date: Tue Mar 14 19:25:25 2006
New Revision: 112065
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112065
Log:
PR middle-end/19543
Backport from mainline.
--- Comment #3 from kargl at gcc dot gnu dot org 2006-03-14 19:37 ---
Subject: Bug 18537
Author: kargl
Date: Tue Mar 14 19:37:49 2006
New Revision: 112066
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112066
Log:
PR 18537
* gfortran.h: Wrap Copyright line.
--- Comment #4 from kargl at gcc dot gnu dot org 2006-03-14 19:41 ---
This catchs most of the offending tabs. I'm not sure
that it will catch them all.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
Trying to build the latest gcc mainline source (SVN revision 112063) on Darwin
(OS X 10.4.5 G5)
/Users/perrin/gcc_MAINLINE/gcc/configure
--prefix=/Users/perrin/gcc_MAINLINE/INSTALL/112063/ --enable-threads=posix
--enable-languages=c,c++, --disable-multilib
then
make -j 3 bootstrap; make
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-14 20:16 ---
This has nothing to do with fixincludes but instead:
cc1: warnings being treated as errors
/Users/perrin/gcc_MAINLINE/gcc/gcc/reg-stack.c:186: warning:
'stack_regs_mentioned_data' defined but not used
This was
1 - 100 of 125 matches
Mail list logo
