On Wed, 15 Apr 2009, DJ Delorie wrote:
> > yes; however, maybe it would be easier to wait till Richard finishes the
> > work on not representing the overflow semantics in types (assuming that's
> > going to happen say in a few weeks?), which should make the fix
> > unnecessary,
>
> Another though
> Note that the issue is with our representation of POINTER_PLUS_EXPR
> which insists on using sizetype for the pointer offset argument
> (where I don't remember if m32c uses a bigger or smaller mode for
> sizetype than for pointers). Whenever the sizes of the modes for
> pointers and sizetype do
On Wed, 15 Apr 2009, DJ Delorie wrote:
>
> As of this fix (yes, I know it was some time ago - I've been busy),
> the m32c-elf build fails building the target libiberty:
>
> ./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \
> -auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-string
All the problems of PPL 0.10.1 we are aware of have been
fixed in the snapshot of PPL 0.10.2 available at
ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
In particular here is what has changed:
- Correctly detect GMP 4.3.0.
- Fixed the C interface library version information.
- Test program tes
On Thu, Apr 16, 2009 at 2:08 PM, Roberto Bagnara wrote:
>
> All the problems of PPL 0.10.1 we are aware of have been
> fixed in the snapshot of PPL 0.10.2 available at
>
> ftp://ftp.cs.unipr.it/pub/ppl/snapshots/
>
> In particular here is what has changed:
>
> - Correctly detect GMP 4.3.0.
>
>
> I'm not sure if this is the same problem, but didn't I suggest in
> the past to fix this up during expansion? That is, if we end up
> with a POINTER_PLUS_EXPR with different mode size pointer and offset
> promote (or demote) the offset argument to pointer size properly?
>
> What happened to th
Suggested Messaging: Messaging seems redundant in indicating that function has
been redifined twice. One of the messages should be removed. More to the point,
I think the messaging may be erroneous - code fragment follows.
g++-4 Diagnostic Messaging
In file included from partition.cpp:66:
i
On Thu, Apr 16, 2009 at 12:06 PM, Arthur Schwarz
wrote:
>
>
>
> Suggested Messaging: Messaging seems redundant in indicating that function
> has been redifined twice. One of the messages should be removed. More to the
> point, I think the messaging may be erroneous - code fragment follows.
>
>
>
>
> Can you show code that reproduces the issue? My best
> guess is that a
> header file is included twice, and lacks guards, hence the
> message is
> correct: the function is being defined twice, from the same
> source
> location.
>
> -- James
>
Code (unadulterated and full of original
I forgot to say 'thanks James', thanks.
Well, spurred on by the whimsy that I need a solution to the problem (however
dolorous), I experimented. I've commented most everything at least once and the
net effect is that only the 'operator<<' gets a nasty message. I've checked the
include files th
Thanks to everyone.
The rock has dropped. The answer is quoted below:
"My best guess is that a header file is included twice, and lacks guards, hence
the message is correct: the function is being defined twice, from the same
source location."
I had put my friends following my 'include guard'
Snapshot gcc-4.5-20090416 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090416/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote:
> The rock has dropped. The answer is quoted below:
>
> "My best guess is that a header file is included twice, and lacks guards,
> hence the message is correct: the function is being defined twice, from the
> same source location."
Hi All,
Is there any advantage of using switch-case over if-else. I mean any internal
optimizations, gcc can do on a Linux i386 machine?.
Is it saving any machine instructions for us ?.
Regards,
Shameem
_
So many new options, so
Ian Lance Taylor wrote:
> My plan going forward is as follows (when we are back in stage 1):
FWIW, I think this is a great plan.
Thanks,
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
On Thu, Apr 16, 2009 at 09:07:58PM -0700, Shameem Ahamed wrote:
> Is there any advantage of using switch-case over if-else. I mean any internal
> optimizations, gcc can do on a Linux i386 machine?.
The optimizations in question are architecture-independent, though there
would undoubtedly be proc
On Thu, Apr 16, 2009 at 10:12:10PM -0700, Joe Buck wrote:
> I don't know how much of that work got into the compiler, probably
> it isn't in the 4.2.x version we're using now.
I should clarify that remark. In production work right now I'm
not using the current gcc, and am not using profile-direct
17 matches
Mail list logo
