Neil Booth wrote:
> Howard Hinnant wrote:-
>
>> I've been reviewing the age-old issue of interpreting
>> * as the end-of-line indicator as is the current
>> practice with gcc.
>
> FWIW I support abandoning this behaviour too.
>
> Neil.
I would like it to be retained in at least one case: CRL
Eric Fisher wrote:
> I think it's very interesting. I want to split a insn of loading SF
> data through SI symbol, such as (set (reg:SF 5 $5) (mem/u/f:SF
> (symbol_ref/u:SI ("*$LC0".
> I want to it firstly load the address into a register, then load the
> data through the register. So I define
'Neil Booth' wrote:
> Dave Korn wrote:-
>
>>
>> I would like it to be retained in at least one case: CRLF line endings
>> should still work, specifically backslash-CR-LF should be usable to
>> indicate a continued line. So how about having gcc accept
Scott Robert Ladd wrote:
> Robert Dewar wrote:
>> Seems a weak argument to me. Changing gcc would create incompatibilities
>> with previous behavior of gcc, and that is FAR more significant than
>> worrying about other compilers in my opinion. Having gcc compile
>> non-portable code accepted by oth
Jeff Stevens wrote:
> Is there a HowTo out there on how to cross compile GCC
> to run on another platform? I have an x86 host
> running linux, and an embedded PowerPC 440SP target
> running linux. I would like to compile GCC to run on
> the target but am having some difficulties. I have
> compil
Dave Korn wrote:
> Jeff Stevens wrote:
>> Is there a HowTo out there on how to cross compile GCC
>> to run on another platform? I have an x86 host
>> running linux, and an embedded PowerPC 440SP target
>> running linux. I would like to compile GCC to run on
>&
Richard Kenner wrote:
> When I do it, it looks like after I log out, something is still running.
> Is there something I have to stop?
Yep.
http://gcc.gnu.org/wiki/SSH%20connection%20caching
" To create the socket, you need to open a master connection. Just ssh to
gcc.gnu.org using the Contro
Richard Kenner wrote:
> Note that the open connection has your authentication tokens to the
> remote server. If you leave the machine where you started the master
> SSH session, you should usually kill it. "
>
> I missed that part.
>
> So what's the recommended way to kill it? I adde
Daniel Berlin wrote:
> In the meanwhile, 1.3.0rc1 of SVN will become available at sometime in
> the next hour or so at:
>
> http://lolut.utbm.info/pub/subversion-1.3.0-rc1/
This doesn't seem to build OOTB on Cygwin, possibly (but I'm not an expert
on this side of things) related to libtool p
Daniel Berlin wrote:
> On Fri, 2005-10-28 at 14:13 +0100, Dave Korn wrote:
>> Daniel Berlin wrote:
>>
>>> In the meanwhile, 1.3.0rc1 of SVN will become available at sometime in
>>> the next hour or so at:
>>>
>>> http://lolut.utbm.info/pub/
Daniel Berlin wrote:
> [ Mark, my emails to gcc-announce are dropped on the floor, can you
> forward this there? ]
>
> The new SVN repository is up.
snip
[EMAIL PROTECTED] /gnu/HEAD> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/trunk
Enter passphrase for ke
Mike Stump wrote:
> On Oct 28, 2005, at 9:20 AM, Dave Korn wrote:
>> snip
>> [EMAIL PROTECTED] /gnu/HEAD> svn co svn+ssh://[EMAIL PROTECTED]/svn/gcc/
>> trunk
>> Enter passphrase for key '/home/dk/.ssh/id_rsa':
>&g
Per Bothner wrote:
> Joe Buck wrote:
>> So you want the compiler to only consider '\\$" a continuation,
>
> Not my preference, but that is my proposal, in the interest
> of compatibility.
>
>> but to have an unsilenceable warning about '\\ *$'?
>
> Not unsilenceable - but on-by-default. It coul
Per Bothner wrote:
> Dave Korn wrote:
>> Per, please. We've been through these ***exact*** interchanges before.
>> You're now just reiterating the entire thread. You aren't adding
>> anything new,
>
> I didn't see my specific proposal ('\\&#x
Mark Mitchell wrote:
> This rather horrid URL:
>
>
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=
allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&kn
own_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_ty
pe=allword
Phil Edwards wrote:
> On Fri, Nov 04, 2005 at 12:58:11AM +0100, Giovanni Bajo wrote:
>> Joern RENNECKE <[EMAIL PROTECTED]> wrote:
>>
>>> P.S.: When I use a diff-cmd with -N, I not only get a diff for the 44
>>> files that are different, but also a header for each of the 752 files
>>> that are iden
Richard Kenner wrote:
> #if defined ENABLE_CHECKING
> gcc_assert (handled_component_p (ref))
> #endif
>
> If the comment says it has to be an ARRAY_REF, why not just check for
> that?
Given that we're supposed to be passing in an ARRAY_REF and we don't want it
to return true if
Daniel Berlin wrote:
> The use in tree-ssa-loop-niter.c is really trying to skip out on
> inferring loop bounds from pointer to structure accesses in the case of
> things like:
>
>
> struct a
> {
> char foo[1];
> };
>
>
> struct a *b = malloc (sizeof (struct a) + 100);
> b->foo = "I like can
Daniel Berlin wrote:
[cc list trimmed because it's just one of those silly friday afternoon things]
> On Fri, 2005-11-04 at 16:23 +0000, Dave Korn wrote:
>> Daniel Berlin wrote:
>>
>>> The use in tree-ssa-loop-niter.c is really trying to skip out on
>>>
Morning gcc-hackers!
I was wondering why combine could piece together two insns like these:
(insn 11 5 12 0 0x1002f330 (set (reg:QI 74)
(mem:QI (reg/v/f:SI 70) [0 S1 A8])) 25 {movqi} (insn_list 3 (nil))
(expr_list:REG_DEA
Giovanni Bajo wrote:
> Manu Abraham wrote:
>
>> When one does a
>>
>> typedef uint8_t array[10];
>>
>> what does really happen ?
>
> This question does not concern the development of the GCC compiler in any
> way
??? Unless, surely, the answer wanted was something along the lines of:
`Th
Richard Earnshaw wrote:
> On Mon, 2005-11-21 at 21:46, Ian Lance Taylor wrote:
>
>>
>> In principle the combiner could make sure that the same number and
>> type of volatile memory references occur both before and after the
>> combination, and reject it if not.
>
> It would also have to ensure t
Robert Dewar wrote:
> Richard Kenner wrote:
>
>> The issue is that we currently don't combine if volatile is anywhere in
>> sight, whether or not we'd be affecting that access. Just because you
>> have something volatile on the LHS doesn't mean we can't combine into
>> the RHS. A good example are
Robert Dewar wrote:
> Dave Korn wrote:
>> Robert Dewar wrote:
>>
>
>> Isn't it pretty much implied by point 1, "Not more than one volatile
>> memory ref appears in the instructions being considered"?
>
> No, that allows a volatile ref
Mike Stump wrote:
> On Nov 28, 2005, at 3:00 AM, Richard Earnshaw wrote:
>> Possibly, but I think the more interesting observation is listed in
>> parenthesis: Can a volatile access ever alias a non-volatile access?
>> Logic would suggest that a program is unpredictable if written in such a
>> way
YaniMan wrote:
> Hello!
>
> Maybe you got this type of mails, but maybe not. So i send it. :)
Hey! Maybe you got this type of replies, but maybe not. So I send it too!
:)
> Could you put an option into the compiler, to produce other error /
> warning outputs?
> The "file.c:line: error messag
Will L (sent by Nabble.com) wrote:
>> Re: GCC mailing list archive search omits results after May 2005
>
> I have been following this thread of discussion. I am a little puzzled.
It shows! Your post is based on a misunderstanding of what "free" means in
this context. Perhaps things will be cl
Richard Guenther wrote:
> Between Dec 12 and today there has been a ~10% compile-time regression
> and a 1.3% memory usage regression on the tramp3d tester. Due to
> bootstrap problems in between these days I cannot restrict the window
> more.
>
> Richard.
Already noted at
http://gcc.gnu.org/
[EMAIL PROTECTED] wrote:
> Dear all,
> I'm opening a new branch and would like to request some assistance
> updating the online material. Specifically, how do I add the branch
> information to http://gcc.gnu.org/svn.html#devbranches. Also, would it be
> possible to create an associated project pa
[EMAIL PROTECTED] wrote:
> But... it used to be the case that the compiler didn't try to warn about
> uninitialized variables embedded in structs (or so I seem to remember...)
> So I was wondering if this was some kind of regression...
I would consider that to be a bug, not a feature. Just be
Robert Dewar wrote:
> Daniel Berlin wrote:
>
>>> The chain of inferences that the compiler would need to do to properly
>>> diagnose this case is beyond the scope of the mechanical
>>> transformations. The reasoning you need to implement to catch these
>>> cases could even be reduced to the haltin
Philippe De Muyter wrote:
> For a mmu-less embedded target, I would like to generate code to run at
> a fixed location in read-only memory, but with the data segment located
> anywhere in memory. Therefore, the accesses to the data segement must go
> through an indirection table (GOT).
>
> I do n
Jian-ping.Hui wrote:
> Now my question is: Why there are such difference between the two version
> gcc?
This is a VFAQ. See http://gcc.gnu.org/gcc-3.4/changes.html#cplusplus
> Could I compile b.cpp by simply changing some compiler options?
No, you will have to fix the invalid code to be f
Kaveh R. Ghazi wrote:
> PS: --with-local-prefix= wasn't documented in cpp.texi, only in
> install.texi
Why would you expect to find install instructions in the preprocessor
manual, rather than the installation manual?
cheers,
DaveK
--
Can't think of a witty .sigline today
Kaveh R. Ghazi wrote:
> > Why would you expect to find install instructions in the
> > preprocessor manual, rather than the installation manual?
>
> Because the problem was caused by the preprocessor. I was looking for
> a *runtime* flag to change this behavior, (hence cpp.texi). Only in
> hin
On 28/01/2011 23:05, Ian Lance Taylor wrote:
> So it seems like people want it both ways. Some people want to invoke a
> symlink which points to the real gcc, which requires canonicalization.
> Some people want the real gcc to be a symlink which points elsewhere,
> which requires non-canonicalizat
a is to have fully-debugged
support for LTO+plugin in the 2.20.1 release, to support 4.6.0 when it comes
out.
cheers,
DaveK
--
Apologies if dup - ENOPATCH first time I hit send.
>From 6cad541c1902edf5ceb483a20666a90be954e3d4 Mon Sep 17 00:00:00 2001
From: Dave Korn
Date: Mon, 31 J
On 01/02/2011 14:30, Joel Sherrill wrote:
> On 02/01/2011 04:54 AM, Dave Korn wrote:
>> On 01/02/2011 02:33, Joel Sherrill wrote:
>>> Should LTO work with a target not using gold?
>>Yes, it should, but some work is needed at the binutils end. I am
>> testing
On 01/02/2011 17:15, H.J. Lu wrote:
> On Tue, Feb 1, 2011 at 2:54 AM, Dave Korn wrote:
>> On 01/02/2011 02:33, Joel Sherrill wrote:
>>> Hi,
>>>
>>> There are ~100 failures on each *-rtems* target
>>> in the latest test runs when various lto related
&g
On 01/02/2011 18:01, H.J. Lu wrote:
>>> FWIW, your recan linker patch doesn't fix LTO 8, which is:
>>>
>>> http://sourceware.org/bugzilla/show_bug.cgi?id=12277
>> It wasn't supposed to, we've been through this before. It needs both the
>> link-order fix *and* the rescan-libs fix. The combined p
Sorry all, been offline for a couple of days after my pc blew up.
On 07/02/2011 20:50, Angelo Graziosi wrote:
> I do not understand the logic here: break GCC trunk for something that
> hasn't been yet released.
But GCC trunk has not been released either yet! GCC trunk and Cygwin trunk
are
On 08/02/2011 11:07, Richard Guenther wrote:
> On Mon, Feb 7, 2011 at 11:27 PM, FX wrote:
>>> GCC maintainers is this OK for your policy?
>> Personally, I don't think it's a good thing to do: a secondary platform
>> that only supports the latest released version of said platform does not
>> indica
On 08/02/2011 16:08, Dave Korn wrote:
> Sorry all, been offline for a couple of days after my pc blew up.
>
> On 07/02/2011 20:50, Angelo Graziosi wrote:
>
>> I do not understand the logic here: break GCC trunk for something that
>> hasn't been yet released.
>
On 23/02/2011 17:59, DJ Delorie wrote:
> Ian Lance Taylor writes:
>> I believe lThese option files were adapted from Windows, and they are
>> primarily for use on Windows, which has much stricter limits on command
>> line length than most Unix systems. We should implement whatever
>> Windows impl
On 24/02/2011 03:56, DJ Delorie wrote:
> The GNU "doschk" (in non-gnu/) utility can tell you what's legal and what
> isn't.
>
> http://www.delorie.com/gnu/dl/ftp.gnu.org/non-gnu/doschk/doschk-1.1.tar.gz/doschk-1.1/doschk.c
>
> Note, however, that @files used by gcc *in djgpp* will *not* support
On 25/02/2011 15:20, Kyle Girard wrote:
> foo.hh
> ==
>
> class A
> {
> };
>
> class foo
> {
> A a;
> public:
> void bar(A & aa);
> };
>
>
> foo.cc
> ==
>
> #include "foo.hh"
>
> void foo::bar(A & aa)
> {
> a = aa;
> }
>
>
> However the gimple generated via g++-4.5 -c -fdum
On 25/02/2011 15:43, Matthias Kretz wrote:
> I fully understand why it happened. So I imply your answer is that ctors do
> not have a return value and my expectation, as explained above, is wrong.
You'd already know if ctors had return values, because you'd have had to be
writing return statem
On 25/02/2011 19:21, Kyle Girard wrote:
> I was hoping to see the assignment.
> Looking at the gimple output there is no way to see that 'a' was
> assigned in bar(). So that it can be used in wik(). Am I
> misunderstanding something shouldn't there be a way to see the
> assignment in bar? Do I
On 02/03/2011 03:23, Jack Howarth wrote:
>Is anyone else building java with lto-bootstrap? At r170606 I am seeing a
> bootstrap
> failure which appears as...
> make[4]: *** No rule to make target `.deps/gij.Plo'. Stop.
> make[3]: *** [all-multi] Error 2
> make[3]: *** Waiting for unfinished
On 02/03/2011 05:10, Jack Howarth wrote:
>I tried again without --enable-build-with-cxx and it worked. I'll see if I
> can
> reproduce it again with --enable-build-with-cxx.
Bizarre. Can't see how that would be related, but you never know what kind
of odd knock-on effects a bug can have..
On 02/03/2011 07:56, Liu wrote:
> The wrong code is :
> L9284: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, {);
> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT + (13)])
> goto L9285;
> goto ret0;
>
> L9285: ATTRIBUTE_UNUSED_LABEL
> x3 = XEXP (x2, |);
> if (x3 == const_int_rtx[MAX_SAVED_C
On 02/03/2011 21:37, Ralf Wildenhues wrote:
> * Jack Howarth wrote on Wed, Mar 02, 2011 at 06:08:22PM CET:
>> On Wed, Mar 02, 2011 at 07:16:19AM +0100, Ralf Wildenhues wrote:
>>> Jack, the actual issue you're seeing might well be the result of some
>>> missing dependency. With parallel build failu
On 02/03/2011 15:14, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> On 02/03/2011 07:56, Liu wrote:
>>
>>> The wrong code is :
>>> L9284: ATTRIBUTE_UNUSED_LABEL
>>> x3 = XEXP (x2, {);
>>> if (x3 == const_int_rtx[MAX_SAVED_CONST_INT +
On 06/03/2011 07:02, Anthony Green wrote:
> All of the -flto tests fail for moxie-elf...
>
> http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg00399.html
>
> It turns out that this is because it fails to link with the code in
> libgloss when I enable -flto.
>
> I link the test code with a special
On 07/03/2011 15:39, Basile Starynkevitch wrote:
> So please accept (at least temporily) the usefulness of debug & trace
> printing.
>
> My question then is how to implement it nicely?
> And I don't know if debug printing should go to stdout or to stderr.
MELT is for writing new passes, right
On 16/03/2011 00:54, Jack Howarth wrote:
> On Tue, Mar 15, 2011 at 08:37:38PM -0400, Robert Dewar wrote:
>> On 3/15/2011 8:11 PM, Jack Howarth wrote:
>>
>>> FSF legal could solve these problems in a minute. Don't shove a blanket
>>> dislaimer for all employees at the employer. Give them two opt
On 16/03/2011 00:33, Ian Lance Taylor wrote:
> Robert Dewar writes:
>
>> On 3/15/2011 8:03 PM, Ian Lance Taylor wrote:
>>> Jack Howarth writes:
>>>
Is anyone else having problems getting the FSF copyright
clerk to complete the FSF paperwork? I am going on six months
now and th
On 17/03/2011 18:29, Jeff Law wrote:
> On 03/17/11 12:25, David Daney wrote:
>>> Instruction sequence #1 has been combined into a single equivalent
>>> instruction. Instruction sequence #2 moved. Register usage is also
>>> different but equivalent.
> In my experience, there's all kinds of reasons
On 28/03/2011 19:52, FX wrote:
>> this is a known issue and strictly cygwin related. Please update your
>> cygwin environment to newest version, or disable decimal-floating
>> point by option.
>
> Well, maybe this is known, but it is not noted on the GCC 4.6.0 release
> notes, nor on the target-s
On 29/03/2011 09:50, Bernd Roesch wrote:
> Hello
>
> On 28.03.11, you wrote:
>
>> I think that the right place for the note is at
>>
>> http://gcc.gnu.org/install/specific.html#x-x-cygwin
>>
>> It should say something like:
>>
>> Versions of Cygwin older than x.y.z fail to build the decimal fl
On 28/03/2011 08:25, Jakub Jelinek wrote:
> The GNU Compiler Collection version 4.6.0 has been released.
Were there any changes (other than perhaps repackaging) after the second RC
(dated 20110321)?
cheers,
DaveK
On 29/03/2011 15:32, Jakub Jelinek wrote:
> On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote:
>> On 28/03/2011 08:25, Jakub Jelinek wrote:
>>> The GNU Compiler Collection version 4.6.0 has been released.
>> Were there any changes (other than perhaps repackag
Hi all,
From http://gcc.gnu.org/wiki/whopr/driver:
> When the WPA phase produces the definition of the COMDAT symbol in a new
> object file, that definition should not be in a COMDAT group.
But it appears that it is:
> davek@gcc10:~/gcc/obj.patched/gcc/testsuite/g++$ grep section
> g+
On 06/05/2011 09:00, Andreas Schwab wrote:
> Ian Lance Taylor writes:
>
>> The difference is that with -E the -o option is passed to cc1, whereas
>> without it the -o option is passed to the assembler or the linker. The
>> GNU assembler and linker both have the usual Unix behaviour of only
>> usi
On 25/09/2011 13:56, David Brown wrote:
> There is a big difference between defining an object as "const", and
> merely declaring it as const or accessing it as const. When you access
> it as const, you are saying "/I/ won't change the object with this
> access". When you declare an object as co
On 05/10/2011 04:56, Iain Buclaw wrote:
> On 5 October 2011 00:10, Ian Lance Taylor wrote:
>> Iain Buclaw writes:
>>
>>> First question that pops up after having a quick look is, are there
>>> any tips around for writing the scripts for the testsuite? I'm not too
>>> familiar with Dejagnu, and t
On 15/10/2011 23:44, H.J. Lu wrote:
> Hi,
>
> ---plugin option for ar/nm is very long. I am proposing to add
> a --plugin-gcc option. It can be implemented with
>
> 1. Move LTOPLUGINSONAME from gcc to config/plugins.m4.
> 2. Define LTOPLUGINSONAME for ar/nm.
> 3. For --plugin-gcc, ar/nm call p
On 04/11/2011 17:33, Joel Sherrill wrote:
> Hi,
>
> I am testing powerpc-rtems on the head and
> have gotten a weird error compiling libgcc.
> It is definitely a regression from 4.6.
> I have no idea who might be the best person
> to help resolve this.
>
> /home2/joel/build/b-powerpc-gcc/powerpc-
On 01/12/2011 21:40, Georg-Johann Lay wrote:
> It's not unusual because:
>
> * It's not unusual to write down SFRs as violatile memory like
> (*((volatile unsigned int*) 0x1234)) or as a cast to a composite
> that reflects the SFRs bit(field)s.
>
> * It's not unusual that microcontrollers ca
Hi list,
Running "make -j8 install" in a fresh build of head, I saw loads of the
following error messages coming out in the log:
> cp: cannot create regular file
> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/adainclude/a-ztmoau.adb':
> File exists cp: cannot create regular
On 05/12/2011 21:43, Jeff Law wrote:
> When the uninitialized & initialized to 10 paths meet, the compiler
> (correctly) pretends the value for the uninitialized path is 10 as
> well.
Wouldn't that be a good point at which to issue an uninitialised-use warning?
cheers,
DaveK
On 03/12/2011 12:16, Dave Korn wrote:
> Running "make -j8 install" in a fresh build of head, I saw loads of the
> following error messages coming out in the log:
>
>> cp: cannot create regular file
>> `/gnu/gcc/install.obj3/gnu/usr/lib/gcc/i686-pc-cygwin/4.7.0/ad
On 07/12/2011 19:14, Christian Joensson wrote:
> I am trying to build gcc trunk on cygwin (with the snapshot of
> 20111207) and get this:
> /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o
> In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0,
> from /usr/
On 12/12/2011 20:20, Christian Joensson wrote:
> Exception in thread "main" java.lang.NoClassDefFoundError: loaded
> class gnu.classpath.tools.jar.messages was in fact named
> gnu.classpath.tools.jar.Messages
I think I discovered recently that you absolutely have to have
obcaseinsensitive=0 to
On 03/01/2012 17:43, Bruno Haible wrote:
> https://lists.gnu.org/mailman/listinfo/language-experts
Or https://lists.nongnu.org/mailman/listinfo/language-experts if you want to
avoid the certificate mismatch security warning :)
cheers,
DaveK
On 19/01/2012 16:51, Ludovic Courtès wrote:
> Right. But how would you write feature tests that would check (1)
> whether the GNU C language is supported,
Try and compile a conftest that uses it. If you wanted a possibly
over-engineered solution, write one conftest for each feature of GNU C
On 17/01/2012 21:16, Paul S wrote:
> For example the i386 seems to use predicates and constraints of the form
> <*_operand> and for the reload versions of these instructions -
> and I haven't been able to find definitions of these or a mention in
> gcc_internals.pdf of any special meaning assigne
On 20/01/2012 11:19, Peter Rosin wrote:
> Dave Korn skrev 2012-01-20 01:15:
>
> *snip*
>
>>That could be tricky because I guess you won't be able to use
>> libtool at configure time.
>
> *snip*
>
> It's possible to use libtool at conf
On 20/01/2012 23:28, Jonathan Wakely wrote:
> 2012/1/20 Ludovic Courtès:
>> Yeah, but it’s a shame that those compilers define __GNUC__ without
>> supporting 100% of the GNU C extensions. With this approach, you would
>> also need to add !defined for Clang, PGI, and probably others.
>
> May I pol
On 27/01/2012 16:46, Andreas Krebbel wrote:
> Divide_1::probe_1() -> __divdi3
>|SIGFPE
>V
> catch_fpe -> _Jv_Throw
>
> After doing the instruction parsing in order to figure out whether
> it's actually the INT_MIN/-
On 27/01/2012 16:58, Dave Korn wrote:
> On 27/01/2012 16:46, Andreas Krebbel wrote:
>> So the CFAs of __divdi3 and probe_1 are the same!
>>
>> This triggers the assertion in _Unwind_RaiseException_Phase2 which
>> assumes that it is about to pass the frame with the
On 27/01/2012 17:01, Andrew Haley wrote:
> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>> Starting with this IRA patch:
>> http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00028.html
>> __divdi3 does *not* need a stack frame at all.
>>
>> So the CFAs of __divdi3 and probe_1 are the same!
>
> I'm c
On 27/01/2012 17:16, Andrew Haley wrote:
> On 01/27/2012 05:14 PM, Dave Korn wrote:
>> On 27/01/2012 17:01, Andrew Haley wrote:
>>> On 01/27/2012 04:46 PM, Andreas Krebbel wrote:
>>>> Starting with this IRA patch:
>>>> http://gcc.gnu.org/ml/gcc-patches/201
On 04/02/2012 10:20, James Courtier-Dutton wrote:
>> #include
>> #include
>>
>> int main (void)
>> {
>> double x, c, s;
>> volatile double v;
>>
>> x = 1.0e22;
>> s = sin (x);
>> printf ("sin(%.17g) = %.17g\n", x, s);
>>
>> v = x;
>> x = v;
>> c = cos (x);
>> s = sin (x);
>> printf ("s
On 05/02/2012 19:01, Vincent Lefevre wrote:
> On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote:
>> But it is indistinguishable from 10^22+pi. So both -0.8522008497671888
>> and 0.8522008497671888 are correct results, or anything inbetween.
>
> No, 10^22 and 10^22+pi are different numbers.
O
Richard Guenther wrote:
> On Mon, Jul 13, 2009 at 5:39 AM, Jack Howarth wrote:
>> On Mon, Jul 13, 2009 at 01:52:51AM +0100, Dave Korn wrote:
>>>> __complex__ long long f ()
>>>> {
>>>> int i[99];
>>>> __complex__ long lon
Mohamed Shafi wrote:
> Hello all,
>
> Is it possible to emit a assembler directive at the end of each sections?
> Say like section_end
> Is there any support for doing something like this in the back-end files?
> Or should i need to the make changes in the gcc sources?
> Is so do does anyone know
Kai Tietz wrote:
> Hello,
>
> I noticed, while trying to build libjava for x64 windows, that the
> configure script fails to generate link to
> 'libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc'. This
> file isn't existing. Is there a fix for this?
>
> Thanks in advance for the answer
Kai Tietz wrote:
> * gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: Implementation
> for native win32.
>
> Tested for x86 and x64 mingw targets. Ok for apply?
+ for (a = 0; a < length; a++, count++)
+ *bytes++= (jbyte) rand ();
Surely not, the standard C library rand() f
Kai Tietz wrote:
> Yes, I agree to this as I said in the patch post. Can we assume that
> any win32 target has a working wincrypt.h file?
Hmmm... it is supported since win2k. I imagine DGJPP runs on 9x targets,
and believe it or not there are still some Cygwin users on NT4. I would think
it n
Kai Tietz wrote:
Oh, I forgot to address:
> I just suggested this patch, to have at least an implementation here
> for win32 for further improvement
This is the java security package. Having a vulnerable implementation is
worse IMO than having none at all; I think it would be better to just
Andrew Pinski wrote:
> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>> Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This
>> is built-in to gcc, not a dependency on the host libc which might not
>> be c99..'
>
> Except uintptr_t is required to be provided by a non host
Kai Tietz wrote:
> There are a lot of issues about casting HANDLE values into jint types,
> which is for x86 valid, but for x64 can lead potential to pointer
> truncations. Those part need some review by libjava maintainers. My
> patch simply casts those kind of pointers via __UINTPTR_TYPE__ into
Kai Tietz wrote:
> 2009/7/19 Dave Korn :
>> Kai Tietz wrote:
>>
>>> There are a lot of issues about casting HANDLE values into jint types,
>>> which is for x86 valid, but for x64 can lead potential to pointer
>>> truncations. Those part need some review b
Kai Tietz wrote:
> The patch I sent here is more a head-up (and it fixes build for 32-bit
> windows builds, too).
Ok, I see the point in a headsup (but I'm not sure it was worth spending the
time to generate the patch). I take it the sole problem with the 32-bit build
is the missing natVMSecu
Andrew Haley wrote:
>
> Yes, you can change them. Yes, they are part of an ABI. native_fd should be
> a jlong.
That's the best possible answer to our questions! Kai? I'll leave this
with you; I'm busy tracking down libffi FAILs right now.
cheers,
DaveK
Hi team,
I'd like to have some basic BZ perms if I may, so I can help out with
cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at
least ones that I created myself, depending how fine-grained it is), and
perhaps be allowed to change status on other bugs too (I occasi
Richard Guenther wrote:
> On Sun, Jul 19, 2009 at 7:29 PM, Dave
> Korn wrote:
>>Hi team,
>>
>> I'd like to have some basic BZ perms if I may, so I can help out with
>> cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at
>&g
Gregory Casamento wrote:
> If not, I would like to know what the GNUstep project can do to help
> make this happen.
Persuade Apple to de-embargo their engineers from showing their faces in
public round here?(*)
At least from the outside, it appears that Apple(**) is simply not
interested in
Danny Backx wrote:
Hi Danny,
> The difference between the last two printf statements points out, I
> think, that a problem exists around printf. Might be float to double
> conversion.
Could also be stdargs. Or float arg passing in general. Or arg promotion.
Are you using soft or hard fp?
301 - 400 of 1443 matches
Mail list logo
