On 22/04/2013 13:51, Angelo Graziosi wrote:
> Il 16/04/2013 10.10, Dave Korn ha scritto:
>>This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
>
>
> From comment 5 and 9 something should be fixed but with current
> snapshot, 4.9-20130421, it seems that the bu
On 18/04/2013 21:50, Vladimir Makarov wrote:
> On 04/17/2013 11:18 PM, Shiva Chen wrote:
>> Full test2.c.209r.reload is about 296kb and i can't send successfully.
>> Is there another way to send the dump file?
>>
> Did you try to compress it? Another possibility would be send dump only
> for the p
On 15/04/2013 15:50, Angelo Graziosi wrote:
> The current snapshot [*] fails to build on Cygwin as follow:
> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
> error: unrecognizable insn:
> }
> ^
> (insn 15 14 16 5 (set (reg:SI 63)
> (symbol_ref:SI ("GetModuleHandleA@4
On 16/04/2013 07:55, Dave Korn wrote:
> On 16/04/2013 07:05, Dave Korn wrote:
>> On 15/04/2013 15:50, Angelo Graziosi wrote:
>
>>> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
>>> error: unrecognizable insn:
>>> }
>
On 16/04/2013 07:05, Dave Korn wrote:
> On 15/04/2013 15:50, Angelo Graziosi wrote:
>> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
>> error: unrecognizable insn:
>> }
>> ^
>> (insn 15 14 16 5 (set (reg:SI 63)
>> (symbol_ref
On 15/04/2013 15:50, Angelo Graziosi wrote:
> The current snapshot [*] fails to build on Cygwin as follow:
> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c: In
> function ‘__gcc_register_frame’:
> /work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:106:19:
> warning: array s
On 04/04/2013 08:48, Kai Tietz wrote:
Hi Kai,
> That change is intentional and would be called __thiscall. To mix
> stdcall and regparam is no more supported AFAIK.
Why are stdcall and regparam not allowed together any more? They seem
entirely orthogonal to me, and the overall result is
Hi list,
Previously (tested with gcc-4.5.3), constructs like this:-
-- foo.h
struct sigpacket
{
int __stdcall process () __attribute__ ((regparm (1)));
};
-- foo.cpp
#include "foo.h"
int __stdcall
sigpacket::process ()
{
return 2;
}
--
... used to work, wi
On 16/03/2013 11:57, Jakub Jelinek wrote:
> GCC 4.8.0 Release Candidate available from gcc.gnu.org
>
> The first release candidate for GCC 4.8.0 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.0-RC-20130316
>
> and shortly its mirrors. It has been generated from SVN revision 1966
Hi list,
I'm in the middle of a testsuite run and just saw the following FAILs crop up:
> FAIL: g++.old-deja/g++.brendan/cvt1.C (test for excess errors)
> FAIL: g++.old-deja/g++.brendan/enum11.C (test for excess errors)
> FAIL: g++.old-deja/g++.brendan/enum8.C (test for excess errors)
> FA
On 07/03/2013 21:00, Andrew Haley wrote:
> Either Anthony or I review libffi patches in gcc.
Perhaps you two should list yourselves as such in MAINTAINERS, for the
avoidance of doubt?
> You're not going to get any more reviews.
I committed it. Thanks for the clarification.
cheers,
On 07/03/2013 16:55, Andrew Haley wrote:
> On 03/07/2013 02:09 PM, Dave Korn wrote:
>> On 06/03/2013 16:05, Jakub Jelinek wrote:
>>
>>> If no new P1 appears within a week,
>> I may be about to file one. What priority would "Java doesn't compile on a
>
On 06/03/2013 16:05, Jakub Jelinek wrote:
> If no new P1 appears within a week,
I may be about to file one. What priority would "Java doesn't compile on a
secondary platform" count as? There's a trivial bug in libffi and I already
posted a patch(*) to both -patches and upstream, but am waiti
On 06/06/2012 11:14, Richard Guenther wrote:
> The first release candidate for GCC 4.7.1 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.1-RC-20120606
>
> and shortly its mirrors. It has been generated from SVN revision 188257.
>
> I have so far bootstrapped and tested the releas
On 03/06/2012 04:43, Hans-Peter Nilsson wrote:
> On Fri, 18 May 2012, Ralf Corsepius wrote:
>> On 05/18/2012 09:24 AM, Sebastian Huber wrote:
>>> Hi,
>>>
>>> if I run the ARM GCC test suite for C and C++ with the arm-rtemseabi4.11
>>> target, then I get several unexpected errors due to:
>>>
>>> gcc
On 14/04/2012 14:58, Kai Tietz wrote:
> 2012/4/14 Nicolai Josuttis:
>> The first problem was that
>> build/gcc/gengtype-lex.c
>> was created with DOS-Newlines (CR-LF),
>> which makes the following compiling fail:
>> make[2]: Entering directory `/cygdrive/p/gcc480snap-install/build/gcc'
>> gcc -c
On 11/04/2012 20:30, Tobias Burnus wrote:
> In any case, the gfortran front end cannot really afford to loose
> developers, given that it is a hobbyist* project and given that
> attracting new developers is difficult.
>
> Tobias
>
> * In terms of the development; I assume that those who use it f
On 11/04/2012 14:21, Bernd Schmidt wrote:
> On 04/11/2012 02:57 PM, Torvald Riegel wrote:
>> However, the concern you raised is only one part of the problem. The
>> other is that, put in a simplified way, GCC is competing with LLVM about
>> new and/or non-fulltime-compiler developers. For me, it
On 11/04/2012 13:57, Torvald Riegel wrote:
> Please don't dismiss this so easily. Of course this is just an example
> and nothing major, but I believe many people will use tab completion on
> the shell, for example, and code completion is really similar. On the
> shell, or with paths names, you
On 11/04/2012 22:13, Eric Botcazou wrote:
>> So, you only know it's 2 tokens once you know all of tree.def? I'm
>> aware that this is just some arbitrary example, but I believe this
>> actually strengthens the concern I had.
>
> Well, if you don't know of FIELD_DECL, you won't go very far, really
On 11/04/2012 07:55, Jakub Jelinek wrote:
> On Tue, Apr 10, 2012 at 06:35:58PM -0700, Lawrence Crowl wrote:
>> The standard says they need not ignore them.
>>
>> I was thinking more about iterating over the contents. What in the
>> current code is an indirect function call inside of a loop becomes
On 12/04/2012 16:38, Mark Galeck (CW) wrote:
> Thank you Ian, hopefully I will be compatible then for a long time, as
> Larry Wall would say "at least until the heat death of the Universe".
>
> I can't "ignore it" :) My build system cannot handle "include_next" - it
> cannot handle the situation
On 11/04/2012 15:12, Iain Buclaw wrote:
> This has been rather long wait from my side of the pond (moving has
> taken away quite some time from my side). But I'll be in a position
> to begin discussion on arrangements this weekend for patches to be
> submitted for GCC 4.8.
>
> I would be gratefu
On 12/04/2012 16:35, Robert Dewar wrote:
> On 4/12/2012 10:48 AM, Andrew Haley wrote:
>
>> Ultimately, it's a matter of taste and experience. I'm going to find
>> it hard to write for people who don't know the relative precedence of
>> & and | .
>
> There are probably some programmers who compl
On 13/04/2012 22:45, Oleg Smolsky wrote:
> On 2012-04-11 01:50, Vincent Lefevre wrote:
>> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote:
On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
> Maybe -Wstandard isn't the best name
On 12/04/2012 22:36, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 4:00 PM, Dave Korn wrote:
>> On 12/04/2012 16:47, Gabriel Dos Reis wrote:
>>
>>> I keep talking about useful *warnings*, you keep talking about *numbers*.
>> No you don't. You said:
>>
On 12/04/2012 16:47, Gabriel Dos Reis wrote:
> I keep talking about useful *warnings*, you keep talking about *numbers*.
No you don't. You said:
>>> People easily associates some ordering to numbers (usually
>>> the greater the better or in this case the worse) which
>>> creates a
On 12/04/2012 17:03, Gabriel Dos Reis wrote:
> There is
> little ambiguity left by -Wreally-all-of-them-damn-it :-)
Actually, no, as anyone could tell you who before they discovered version
control used to have lots of files lying around called "foo.final.c",
"foo.final.reallyfinal.c", "foo.fi
On 12/04/2012 16:06, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 10:01 AM, Dave Korn
> wrote:
>> On 12/04/2012 15:55, Gabriel Dos Reis wrote:
>>> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn
>>> wrote:
>>>> On 12/04/2012 15:43, Gabriel Dos Reis
On 12/04/2012 15:55, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 9:46 AM, Dave Korn wrote:
>> On 12/04/2012 15:43, Gabriel Dos Reis wrote:
>>> People easily associates some ordering to numbers (usually
>>> the greater the better or in this case the worse) which
On 12/04/2012 15:43, Gabriel Dos Reis wrote:
> On Thu, Apr 12, 2012 at 9:38 AM, Robert Dewar wrote:
>> On 4/12/2012 10:26 AM, Gabriel Dos Reis wrote:
>>
> -W0: no warnings (equivalent to -w)
> -W1: default
> -W2: equivalent to the current -Wall
> -W3: equivalent to the current -Wal
On 11/04/2012 09:50, Vincent Lefevre wrote:
> On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
>> On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar wrote:
>>> On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
>>>
Maybe -Wstandard isn't the best name though, as "standard" usually
means somethin
On 10/04/2012 17:41, Paweł Sikora wrote:
> On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote:
>> On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote:
>>> Class hierarchy is one such feature that is useful. Assuming we have
>>> two hierarchies for gcc: one for values rooted at
On 10/04/2012 17:24, Michael Matz wrote:
> Hi,
>
> On Tue, 10 Apr 2012, Xinliang David Li wrote:
>
> exp->as_component_ref().get_field() ..
>
>>> Actually it's not questionable. The above stuff is _horrible_.
>> Specifics please. It is _horrible_ because you are more used to th
On 07/04/2012 23:58, Gabriel Dos Reis wrote:
> On Sat, Apr 7, 2012 at 5:41 PM, Dave Korn wrote:
>>> -Wunused-function
>>> -Wunused-label
>>> -Wunused-value
>>> -Wunused-variable
>> IMHO we should move the -Wunused ones into -Wextra if we're go
On 05/04/2012 10:46, Gabriel Dos Reis wrote:
> On Thu, Apr 5, 2012 at 4:39 AM, Richard Guenther
> wrote:
>
>> Btw, it would be more reasonable to enable a subset of warnings that
>> we enable at -Wall by default.
>
> Which ones for example?
>
> Here is a (partial) list:
Your list seems a bit
On 10/03/2012 09:30, niXman wrote:
> When extracting
> ftp://ftp.fu-berlin.de/unix/languages/gcc/releases/gcc-4.6.3/gcc-4.6.3.tar.bz2
> http://clip2net.com/clip/m0/1331371739-clip-8kb.png
Don't worry, it's not a virus. It's a recursive zip file:
http://research.swtch.com/zip
It's data
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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
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 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
On 28/01/2011 01:11, Joseph S. Myers wrote:
> * i[34567]86-*-pe (an alias for Cygwin in config.gcc rather than
> config.sub, so not effectively treated as an alias elsewhere).
Makes sense to me, thank you. (I've never heard of anyone using it, I don't
think it would even matter if you just re
On 23/01/2011 10:58, Daniel Marjamäki wrote:
> I fail to use 'global_namespace':
> daniel@daniel:~/gcc/build/gcc$ ./xgcc -fplugin=./myplugin2.so -c test1.c
> cc1: error: cannot load plugin ./myplugin2.so
You're running the C compiler (cc1) here, not the C++ one (cc1plus), because
you've passed
On 16/01/2011 18:49, Jack Howarth wrote:
> The unnecessary bracing immediately after...
>
> for (lp = i->landing_pads; lp ; lp = lp->next_lp);
>
> seems odd (as if the line above has accidentally gotten a ';' added).
> Is there a coding error here?
Clearly, since it would make n
On 12/01/2011 13:50, Jeff Law wrote:
> On 01/12/11 01:45, Gidi Nave wrote:
>
>> One more question:
>> GCC usually knows how to handle cases which need decomposition of
>> expressions due to architecture limitations.
>> In my case it didn't know.
>> How can I foreseen additional such cases, in ord
On 08/01/2011 02:46, Dave Korn wrote:
> Can anyone think of a recent change which might have impacted on the way
> these thunks are emitted?
Nevermind; I found it. Detailed explanation and related PR:
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00446.html.
http://gcc.gnu.org/bu
Evening all,
Something has changed in the last few weeks that has resulted in, as the
subject says, non-virtual thunks (in this case, all specifically to dtors, but
I don't know if that is relevant or mere accident) no longer being emitted as
comdat for i686-pc-cygwin; I haven't checked oth
On 21/12/2010 14:51, Joel Sherrill wrote:
> checking how to run the C preprocessor...
> /users/joel/test-gcc/b-gcc1-microblaze/./gcc/xgcc
> -B/users/joel/test-gcc/b-gcc1-microblaze/./gcc/ -nostdinc
> -B/users/joel/test-gcc/b-gcc1-microblaze/microblaze-rtems4.11/newlib/
> -isystem
> /users/joel/tes
On 13/12/2010 17:02, Frederic Riss wrote:
> Hi,
>
> I tried to enable LTO on my port, but failed to do so. On a stupid
> example, I get:
>
> $ k1-gcc -flto toto.o print.o
> lto1: internal compiler error: compressed stream: data error
> Please submit a full bug report,
> with preprocessed source i
On 12/12/2010 00:47, H.J. Lu wrote:
> Hi,
>
> Using .init_array section on Linux/x86 raised a question on
> init_priority. GCC manual says
>
> `init_priority (PRIORITY)'
> In Standard C++, objects defined at namespace scope are guaranteed
> to be initialized in an order in strict accor
On 12/12/2010 06:54, H.J. Lu wrote:
[ off-list, but it's not personal, so let's Cc the list back in, someone might
find this explanation of the mechanism useful in the archives. ]
> Can you check the assembly output? Since
>
>
> Note that the particular values of PRIORITY do not matter;
On 10/12/2010 20:49, Dave Korn wrote:
> I found a couple of new FAILs in my latest libjava testrun:
>
>> FAIL: newarray_overflow -O3 compilation from source
>> FAIL: newarray_overflow -O3 -findirect-dispatch compilation from source
>
> These turn out to be tree che
Hi lists,
I found a couple of new FAILs in my latest libjava testrun:
> FAIL: newarray_overflow -O3 compilation from source
> FAIL: newarray_overflow -O3 -findirect-dispatch compilation from source
These turn out to be tree checking failures:
> In file included from :3:0:
> newarray_ov
On 08/12/2010 18:40, Andi Kleen wrote:
> Fat LTO is just too slow. I suspect with that kind of performance
> penalty most people simply would not use it at all.
How slow is "too" slow? How many people out of a hundred won't use it? Got
numbers, or just a gut feeling?
cheers,
DaveK
1 - 100 of 1443 matches
Mail list logo
