David Daney writes:
> Tom Tromey wrote:
> > I'm finally ready to do another classpath import,
>
> Do you plan on another classpath import before the 4.1 release?
This is an interesting question. Potentially, a classpath import can
have a hugely destabilizing effect. However, IMO each Classp
Jon Masters writes:
>
> GCC 4.0 has been shortlisted in this year's Linux Awards:
>
> * http://www.linuxawards.co.uk/content/view/14/40/
> * Best Linux/Open Source Developer Tool.
>
> BUT...none of the folks in the office can apparently contact anyone
> about being available
Arnaud Charlet writes:
> Here are my first impressions on trying to use subversion.
>
> Note that I didn't go to any doc or wiki page yet, I simply copy/pasted
> the commands I saw on the gcc list. I am familiar with cvs commands and
> expect most things to be handled similarly.
>
> - firs
Daniel Berlin writes:
>
> > It seems to be incredibly hard to find out which branch a file is on.
>
> Huh?
>
> The file is where it is.
> Branches are just seperate directories.
> If it's in the 4.0 directory, it's on the 4.0 branch
>
> Revision numbers don't tell you what branch so
Daniel Berlin writes:
> On Wed, 2005-10-19 at 17:40 +0200, Paolo Carlini wrote:
> > Giovanni Bajo wrote:
> >
> > >I'll add others:
> > >
> > >I would also notice that most people don't RTFM. I spent many efforts in
> > >writing the Wiki page, and the benefits of SVN are apparent if you spen
Giovanni Bajo writes:
> Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
>
> > I'm looking forward to solutions that lower the entry barrier,
> > specifically with repect too OpenSSH, diff and svk.
>
>
> I'm going to write something in the wiki about svk. There's much FUD
> spreading
> in t
Richard Kenner writes:
> What I keep seeing are increasingly complex solutions in order to
> keep efficiency the same as it is now. This is a very large
> distributed cost, which can't be ignored.
No, but neither should the cost be puffed up, as it is being at the
moment. SSH connection cach
Lars Gullik Bjønnes writes:
> Bernd Schmidt <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > It seems that svn is unable to send all its requests to the svn
> | > repo over one ssh connection. In one test I just did I had to enter
> | > the ssh password five times.
> |
>
Vivaldo writes:
> Dear Sir,
>
> I have found a difficult do work with long double. I have written a
> simple test code and compiled it with gcc 4.0.0. The code was the following
>
> #include
> #include
>
> using namespace std;
>
> main(){
>
> long double x,y,a;
> x = 1.000
Diego Novillo writes:
> On Saturday 12 November 2005 12:05, Per Bothner wrote:
> > A "function-never-returns-null" attribute doesn't seem like
> > the right mechanism. Instead, there should be a "never-null"
> > attribute on pointer types. A "function-never-returns-null" is
> > just a functi
Diego Novillo writes:
> On Saturday 12 November 2005 12:19, Andrew Haley wrote:
>
> > Couldn't we attach an assertion to the tree? That way we could just
> > use the inference logic we already have.
> >
> We already do that. In Per's test case,
>
Bernd Schmidt writes:
> David Daney wrote:
> > Perhaps not in general, but one unstated premise of this whole thread is
> > that for some GCC targets (most Unix like operating systems) you *can*
> > count on a SIGSEGV when you dereference a null pointer. The java front
> > end takes advant
Bernd Schmidt writes:
> Andrew Haley wrote:
> > Bernd Schmidt writes:
> > > David Daney wrote:
> > > > Perhaps not in general, but one unstated premise of this whole thread
> > is
> > > > that for some GCC targets (most Unix like operatin
Tom Tromey writes:
> >>>>> "Andrew" == Andrew Haley <[EMAIL PROTECTED]> writes:
>
> Bernd> Speaking of which, has anyone ported gcj to a MMU-less uClinux
> Bernd> platform yet?
>
> Andrew> It's impossible with the current con
Romain Failliot writes:
> 2005/11/13, Florian Weimer <[EMAIL PROTECTED]>:
> > There is a GCC front end, but it has zero chance of being integrated
> > into FSF GCC at this stage. The run-time library license contains
> > this little gem:
> >
> > * (ii) Any derived versions of t
Richard Earnshaw writes:
> - Then, incrementally, we can bypass the parse layer to call routines
> directly in the assembler. This can be done both for directives and for
> assembly of instructions. *but it can all be done incrementally*.
>
> The main difficulty is preserving -S output in
Richard Henderson writes:
>
> I will say that staticly linked linuxthreads tls is known to be
> broken. Or at least known to me. I encountered this while doing
> OpenMP work on RHEL3. The problem I saw doesn't appear with nptl.
Ah, that's a useful clue. I can confirm that this is definit
Tom Tromey writes:
>
> Java is fairly dynamic, as I'm sure you know. So, I'm much more
> interested in the JITting possibilities than in link time
> optimizations; the latter is cool and probably useful to embedded
> users of gcj, but I'd imagine for all our recent binary compatibility
> de
holderlin writes:
> So I am wondering whether g++-3.3.5 changes its object model.
The V3 multi-vendor standard C++ ABI is used in GCC releases 3.0 and above.
http://www.codesourcery.com/cxx-abi/
Andrew.
Alan Modra writes:
> On Sun, Dec 04, 2005 at 12:35:31AM +0100, Gerald Pfeifer wrote:
> > spawns a recursive make (GNU make 3.80) that consumes some 450MB of memory
> > and triggers a system load of 12+, basically rendering the machine dead
> > for about a minute.
> >
> > On a different mac
Jack Howarth writes:
> My second question is how univeral are the strict-aliasing
> rules used by gcc?
They are applicable to every compiler that implements ISO C++. In
other words, code that violates aliasing constrains is not legal C++.
> In other words, is it safe to say that by corr
Florian Weimer writes:
> * Richard Guenther:
>
> > What makes you think it is?
>
> I think there was some release announcement on Slashdot when the
> branch was created. 8-)
... thereby maintaining the reputation for accuracy for which Slashdot
is justly famous.
Andrew.
Tommy Vercetti writes:
>
> On 2005-12-07, at 16:26, Richard Guenther wrote:
>
> > On 12/7/05, Tommy Vercetti <[EMAIL PROTECTED]> wrote:
> >> Hi there
> >>
> >> We had funny issue here lately. Someone wanted to create table that
> >> had 0 elements in C++, for instance this code:
> >
> >
Florian Weimer writes:
> * David Gressett:
>
> > It does work with the GNAT GPL 2005 that I have on my XP box at home. A
> > search of the gcc mailing list archive didn't turn up much, but there
> > was one message which indicated that there was a license problem with
> > the addr2line so
Mark Wielaard writes:
> Hi Gerald,
>
> On Mon, 2005-12-12 at 00:21 +0100, Gerald Pfeifer wrote:
> > On Sun, 4 Dec 2005, Mark Wielaard wrote:
> > >> 2005-09-21 Mark Wielaard <[EMAIL PROTECTED]>
> > >>
> > >> * lib/split-for-gcj.sh: Cut list to 3 package levels deep.
> > > I rever
Tom Tromey writes:
> > "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:
>
> Gerald> Is anyone seeing this? With current 4.1 sources, on a machine
> Gerald> with "only" 1GB of main memory + 1GB swap, the following part
> Gerald> of `make install`
> [...]
> Gerald> spawns a recursi
().printStackTrace();
}
}
$ ~/gcc/install/bin/gcj Hello.java --main=Hello -g
$ LD_LIBRARY_PATH=~/gcc/install/lib ./a.out
Hello, World!
java.lang.Throwable
at Hello.main (Hello.java:5)
Andrew.
2005-12-19 Andrew Haley <[EMAIL PROTECTED]>
* recog.c (peephole2_optimize): Copy RTX_
Ian Lance Taylor writes:
> Andrew Haley <[EMAIL PROTECTED]> writes:
>
> > On i386 we replace (add sp -4) with (push reg). This generates faster
> > and smaller code.
> >
> > However, we are not copying RTX_FRAME_RELATED_P from the old
> >
Richard Guenther writes:
>
> The problem in this PR is that code like in the testcase (from
> OpenOffice) assumes that pointer overflow is defined. As the
> standard does not talk about wrapping pointer semantics at all (at
> least I couldn't find anything about that), how should we treat
>
Richard Guenther writes:
> On Wed, 21 Dec 2005, Andrew Haley wrote:
>
> > Richard Guenther writes:
> > >
> > > The problem in this PR is that code like in the testcase (from
> > > OpenOffice) assumes that pointer overflow is defined. As the
>
Gabriel Dos Reis writes:
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> | >However, we have an obligation to define what those mappings are.
> | >
> | Why?
>
> Because it is an implementation-defined behaviour and we have to
> document how the choice is made.
Can you state some language
Richard Guenther writes:
>
> So the basic question remains - is pointer overflow defined?
No. You've already asked, and it's already been answered, with
langauge from the standard. What more do you want?
Andrew.
Richard Guenther writes:
> On Thu, 22 Dec 2005, Andrew Haley wrote:
>
> > Richard Guenther writes:
> > >
> > > So the basic question remains - is pointer overflow defined?
> >
> > No. You've already asked, and it's already been a
Jeffrey A Law writes:
> On Mon, 2006-01-02 at 19:31 +0100, Laurent GUERBY wrote:
> > Hi Rainer, this is PR24994:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24994
> >
> > And is under investigation:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01756.html
> Finally!
>
I've been experimenting with devirtualizing method calls, and
sometimes a construct like this can pay dividends:
/* Fetch vtable entry into D.914, then... */
if (D.914 != bar)
{
/* Make virtual call. */
D.915 = D.914 (this.7, p.6);
iftmp.8 = D.915;
}
else
{
Andrew Pinski writes:
>
> On Jan 5, 2006, at 8:09 AM, Andrew Haley wrote:
>
> > I've been experimenting with devirtualizing method calls, and
> > sometimes a construct like this can pay dividends:
>
> > Another possibility is to have the inliner conver
On 06/24/2015 03:12 PM, Andrew Senkevich wrote:
> Can anybody tell something about this difference in drivers?
It's a UNIX tradition to require -lm for the floating-point
library in C programs. It doesn't make much sense now, but it's
hard to change it.
Andrew.
On 09/07/15 23:17, Basile Starynkevitch wrote:
> (this is triggered by a question on the Ocaml mailing list asking about
> SystemZ backend in Ocaml; SystemZ is today a backend for GCC & probably
> GCCJIT)
>
> We might want to support better good garbage collection schemes in GCC,
> particulari
On 07/10/2015 07:35 PM, Jeff Law wrote:
> I wonder how much overlap there is between this need and what we're
> going to need to do for resumable functions which are being discussed in
> the ISO C++ standards meetings.
A considerable amount, I'll be bound.
Andrew.
On 07/28/2015 04:40 PM, Paulo Matos wrote:
> The block skips the test for ((unsigned int) xx << 1 == 0 && yy == -1),
> should we skip it if they're both zero as well?
Yes. It's undefined behaviour. If we don't want to invoke nasal
daemons we shouldn't do this.
Andrew.
On 03/10/15 21:41, Matthijs van Duin wrote:
> Anyhow, it only took four years, but you can now throw
> NullPointerExceptions on ARM. Enjoy. ;-)
Ok, nice. :-)
Do you have GCC copyright assignment, and will you turn this into
a patch which can be applied?
Thanks,
Andrew.
On 13/10/15 08:55, Abhishek Aggarwal wrote:
> The return address of the calling function is still at +4 byte offset
> wrt to new frame pointer (%ebp) of 'main' function. However, now the
> first argument of 'main' function may not be at +8 byte offset wrt to
> the new frame pointer of the 'main' fu
On 10/20/2015 05:00 PM, Jeff Law wrote:
> But the technical reality is I can't see a use outside the extended asm.
I can. In the past (and probably still today) GCC did an awful job of
allocating registers in a large function. This was visible in a
bytecode interpreter, where the programmer kno
On 10/20/2015 05:12 PM, Jeff Law wrote:
> On 10/20/2015 10:05 AM, Andrew Haley wrote:
>> On 10/20/2015 05:00 PM, Jeff Law wrote:
>>> But the technical reality is I can't see a use outside the extended asm.
>>
>> I can. In the past (and probably still today) GC
On 10/20/2015 05:22 PM, Jeff Law wrote:
> On 10/20/2015 10:15 AM, Andrew Haley wrote:
>>> But in that case, what do we guarantee.
>>>
>>> We certainly don't guarantee that those objects will be in their
>>> requested register at any point other than at
On 17/11/15 05:55, David Wohlferd wrote:
> How much pessimism are we talking here? Wouldn't clobbering everything
> effectively force the reloading of (some? most? all?) registers? And
> more memory will be needed to store things that used to just require
> registers?
No, really not. It only
On 20/11/15 01:23, David Wohlferd wrote:
> I tried to picture the most basic case I can think of that uses
> something clobber-able:
>
> for (int x=0; x < 1000; x++)
>asm("#stuff");
>
> This generates very simple and highly performant code:
>
> movl$1000, %eax
> .L2:
>
On 20/11/15 10:37, David Wohlferd wrote:
> The intent for 24414 is to change basic asm such that it will become
> (quoting jeff) "an opaque blob that read/write/clobber any register or
> memory location." Such being the case, "memory" is not sufficient:
>
> #define CLOBBERALL "eax", "ebx", "ecx
On 21/11/15 12:56, David Wohlferd wrote:
> So, what now?
>
> While I'd like to take the big step and start kicking out warnings for
> non-top-level right now, that may be too bold for phase 3. A more
> modest step for v6 would just provide a way to find them (maybe
> something like -Wnon-top-b
On 23/11/15 21:02, David Wohlferd wrote:
>> On 11/23/2015 2:04 AM, Andrew Haley wrote:
>> > My warning still holds: there are modes of compilation on some
>> > machines where you can't clobber all registers without causing reload
>> > failures. This is why Je
On 23/11/15 23:01, Jason Merrill wrote:
> There's a proposal working through the C++ committee to define the order
> of evaluation of subexpressions that previously had unspecified ordering:
>
> http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
>
> I agree with much of this, bu
On 25/11/15 02:11, David Wohlferd wrote:
> The 'fix' I am proposing is to give warnings for every use of basic asm
> inside functions (top-level asm is not a problem).
I'm not sure that's such a great idea on its own.
My suggestion:
1. Clobber memory.
2. Document a rule which says that all r
On 11/25/2015 06:25 PM, Martin Sebor wrote:
> The motivating example in the paper suggests that many C++
> programmers expect a left to right order of evaluation here
> due to the commonality of constructs like chains of calls.
Sure, I often see
foo.bar(1).bar(2).bar(3), etc.
but does anyone a
On 11/29/2015 11:53 PM, David Wohlferd wrote:
>
> Trying to guess what people might have been expecting is a losing game.
We have to do it all the time.
> There is a way for people to be clear about what they want to clobber,
> and that's to use extended asm. The way to clear up the ambiguit
On 11/12/15 22:18, David Wohlferd wrote:
> And here are the three solutions that have been proposed:
>
> Solution 1:
> Just document the current behavior of basic asm.
>
> People who have written incorrect code can be pointed at the text and
> told to fix their code. People whose code is damag
On 13/12/15 06:15, David Wohlferd wrote:
>
> However breakage and performance issues can still result solely from
> adding memory clobbers.
Breakage? Really?
> And as I mentioned, "just memory clobber" may
> not be the behavior people expect. And if we aren't solving that, might
> there be
On 17/12/15 01:41, David Wohlferd wrote:
> On the contrary, I would be surprised to learn that there are ANY
> compilers (other than clang) that support gcc's extended asm format.
Prepare to be surprised: Sun Studio compilers seem to support it
just fine.
Andrew.
On 30/12/15 15:33, Georg-Johann Lay wrote:
> Some parts of the compiler use the address of objects to compute
> hashes, but I don't remember which part(s) actually do this. That
> technique can lead to different code for different runs of the
> compiler even on the same system. This is hard to r
On 02/02/2016 05:41 PM, Manuel López-Ibáñez wrote:
> Everything is possible! Not sure how hard it would be, though. As
> said, GJC, the Java FE, was doing something similar sometime ago, but
> it has perhaps bit-rotted now.
It is doing something the other way around: bytecode to Gimple.
Andrew.
I'm fixing a bug which involves initialization of a field of an object
in its placement new function before the constructor is called. This
is falling foul of DSE, which deletes the field initialization.
I see this:
@item -fno-lifetime-dse
@opindex fno-lifetime-dse
In C++ the value of an o
On 02/16/2016 01:16 PM, Jakub Jelinek wrote:
>> > Can someone please tell me Chapter and Verse in the standard, please?
>> > Then I can close this one.
> I'd think [basic.life] describes this.
For the record, I found it in C++98 [class.cdtor]:
For an object of non-POD class type ... before the
On 26/02/16 21:28, Bradley Lucier wrote:
> Any advice on how to proceed? I'd be willing to write and test the few
> lines of code myself if I knew where to put them.
The best thing, rather than warning, would be to define this
conversion as a GCC extension and implement it consistently
everywher
On 27/02/16 11:53, Jakub Jelinek wrote:
> On Sat, Feb 27, 2016 at 10:39:59AM +0000, Andrew Haley wrote:
>> On 26/02/16 21:28, Bradley Lucier wrote:
>>> Any advice on how to proceed? I'd be willing to write and test the few
>>> lines of code myself if I knew w
On 27/03/16 06:57, Michael Clark wrote:
> GCC, Clang folk, any ideas on why there is a stack spill for a
> volatile register argument passed in esi? Does volatile force the
> argument to have storage allocated on the stack? Is this a corner
> case in the C standard? This argument in the x86_64 cal
On 17/04/16 17:58, J a h a n z e b F a h i m wrote:
> i am a java developer, i want to install gnu java compiler on LINUX
> 7.2 for testing purpose. i already have gcc version 4.8.5 20150623
> (Red Hat 4.8.5-4) (GCC) in my machine. now i want to add gcj in it.
> how can i install it?
It's going t
On 05/05/2016 07:56 PM, Antonio Diaz Diaz wrote:
> Take this example http://gcc.gnu.org/ml/gcc-patches/2016-03/msg00261.html
>
> The user sees this:
>
>if (flagA) // GUARD
> foo (0); // BODY
> #if SOME_CONDITION_THAT_DOES_NOT_HOLD
>if (flagB)
> #endif
> foo (1); // NEXT
Sure
On 05/20/2016 10:02 AM, Florian Weimer wrote:
> On 05/20/2016 10:30 AM, lh mouse wrote:
>> Implicit function declarations result in warnings since C99 or GNU99 and
>> '-pedantic-errors' turns them into errors.
>> The same goes for implicit return types.
>
> The warnings typically do not stop the
On 20/06/16 08:00, Andrew Pinski wrote:
> + /* Acceptable. */
> + asm (" "); /* { dg-warning "Deprecated: asm in function without
> extended syntax" } */
This is incorrect English. It should be
"Deprecated: asm without extended syntax in function"
because it's the asm that is missing the e
On 20/06/16 14:50, Segher Boessenkool wrote:
> If basic asm is deprecated, that means some time later it will be
> removed, at which time an asm without : can be used as extended asm
Not exactly: it'd be an asm with no inputs, no outputs, and no
clobbers i.e. no effects.
Andrew.
On 20/06/16 15:42, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>> On 20/06/16 14:50, Segher Boessenkool wrote:
>>> If basic asm is deprecated, that means some time later it will be
>>> removed, at which time an asm without :
On 20/06/16 15:52, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote:
>> On 20/06/16 15:42, Segher Boessenkool wrote:
>>> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>>>> On 20/06/16 14:50, Segher Boessenkoo
On 20/06/16 18:36, Michael Matz wrote:
> I see zero gain by deprecating them and only churn. What would be the
> advantage again?
Correctness. It is very likely that many of these basic asms are not
robust in the face of compiler changes because they don't declare
their dependencies and therefo
Hi,
On 20/06/16 19:01, Michael Matz wrote:
> On Mon, 20 Jun 2016, Andrew Haley wrote:
>
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn. What would be the
>>> advantage again?
>>
>> Correctness.
>
Hi,
On 21/06/16 13:08, Michael Matz wrote:
> On Tue, 21 Jun 2016, Andrew Haley wrote:
>
>>> As said in the various threads about basic asms, all correctness
>>> problems can be solved by making GCC more conservative in handling
>>> them (or better said
On 21/06/16 17:43, Jeff Law wrote:
> I think there's enough resistance to deprecating basic asms within a
> function that we should probably punt that idea.
>
> I do think we should look to stomp out our own uses of basic asms
> within functions just from a long term maintenance standpoint.
>
>
On 22/06/16 09:59, Florian Weimer wrote:
> On 06/20/2016 07:40 PM, Andrew Haley wrote:
>> On 20/06/16 18:36, Michael Matz wrote:
>>> I see zero gain by deprecating them and only churn. What would be the
>>> advantage again?
>>
>> Correctness. It is very l
On 04/07/16 14:43, Jonathan Wakely wrote:
> It doesn't matter how much warning people have to fix such things,
> most of them won't do it. Then at the last minute some poor person has
> to spend days or weeks going through other people's code fixing all
> the problems...
...and breaking everything
On 25/07/16 12:37, fedor...@mail.ru wrote:
> GCC 6.1.0 inserts call to __sync_synchronize and linker fails with
> error: undefined reference to `__sync_synchronize'. If this is bug I
> can send preprocessed file.
This is something that you can provide yourself. If it's a
single-core cpu the func
On 25/07/16 14:17, fedor...@mail.ru wrote:
> I build for arm cpu. How write this function? Where I can see example
> implementation? GCC builded with multilib support.
If your ARM cpu has only one core, the function can be empty. If it
has more than one core, then you must tell GCC which model o
On 26/07/16 14:31, Warren D Smith wrote:
> However, why not provide access to double-precision multiply and
> add-with-carry (subtract with borrow? shift-left?) in the same fashion?
>twofer x = mul(a,b); would cause x.hi and x.lo to be computed.
>twofer x = addwithcarry(a,b) ditto.
On 26/07/16 15:37, Warren D Smith wrote:
> --the reason I am suggesting this to this forum, is I probably am not capable
> of
> recoding GCC myself.
> Why not learn from your own history, and do that again, with these two
> extensions?
> (And in the case of uint4_t, it actually would not even BE
On 12/09/16 20:41, Igor Shevlyakov wrote:
> It would be beneficial to make the behaviour consistent between
> those 2 cases.
You've got two cases of undefined behaviour. What benefit
is there from making two cases of UB consistent with each other?
It's not worth the effort of changing the compil
On 27/10/16 13:55, Matthias Klose wrote:
> With the removal of libgcj, the only user of libffi in GCC is libgo, however
> there is now no maintainer listed anymore for libffi in the MAINTAINERS file,
> and the libffi subdir is a bit outdated compared to the libffi upstream
> repository (got aware o
On 28/10/16 04:03, Ian Lance Taylor wrote:
> On Thu, Oct 27, 2016 at 6:08 AM, Anthony Green wrote:
>> Is it still important that libffi be included in the GCC tree?
>
> [ Replying again as last message was bounced as HTML--sorry for the
> duplication.]
>
> libffi is used by libgo, for much the s
On 18/12/16 02:33, Seima Rao wrote:
> Precisely, stuffs like GENERIC, GIMPLE, RTL, gas(inline assembly),
> GCC extensions internals, ... and gnu's own debugging tied to gcc
> (if such exist nowadays), ... are not documented in a specification
> driven way.
That's interesting. Can
Summary: Devirtualization uses type information to determine if a
virtual method is reachable from a call site. If type information
indicates that it is not, devirt marks the site as unreachable. I
think this is wrong, and it breaks some programs. At least, it should
not do this if the user spec
On 04/25/2014 01:01 PM, Richard Biener wrote:
> I agree, -fstrict-aliasing has nothing to do with this. Sounds simply like
> a genuine bug (please open a bugzilla).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
Andrew.
On 04/25/2014 03:14 PM, Volker Simonis wrote:
> Could you therefore please re-categorize this as devirt bug.
It is an IPA bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60965
Andrew.
On 04/25/2014 07:48 PM, Jakub Jelinek wrote:
> On Fri, Apr 25, 2014 at 08:23:22PM +0200, Jan Hubicka wrote:
>>> On 04/25/2014 03:14 PM, Volker Simonis wrote:
Could you therefore please re-categorize this as devirt bug.
>>>
>>> It is an IPA bug. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6096
On 05/05/2014 08:47 AM, Richard Biener wrote:
> It really depends on how "3x" should materialize in the end.
> How do you triplicate ops with side-effects? If you only
> triplicate ops without side-effects what is the sink that keeps
> the duplicated ops live?
The vote, surely. CSE would be abso
On 05/16/2014 12:05 PM, Kugan wrote:
>
>
> On 16/05/14 20:40, pins...@gmail.com wrote:
>>
>>
>>> On May 16, 2014, at 3:23 AM, Kugan
>>> wrote:
>>>
>>> I would like to know if there is anyway we can use registers from
>>> particular register class just as spill registers (in places where
>>> reg
On 05/16/2014 05:20 PM, Ian Bolton wrote:
>> On 05/16/2014 12:05 PM, Kugan wrote:
>>>
>>>
>>> On 16/05/14 20:40, pins...@gmail.com wrote:
> On May 16, 2014, at 3:23 AM, Kugan
>> wrote:
>
> I would like to know if there is anyway we can use registers from
> particular regi
On 05/19/2014 01:19 PM, Ramana Radhakrishnan wrote:
> On Mon, May 19, 2014 at 1:02 PM, Andrew Haley wrote:
>> On 05/16/2014 05:20 PM, Ian Bolton wrote:
>>>> On 05/16/2014 12:05 PM, Kugan wrote:
>>>>>
>>>>>
>>>>> On 16/05/14 20:40,
On 18/07/14 08:30, Dennis Luehring wrote:
>int* array = (int*)&argv;
This looks like undefined behaviour. Don't you get a warning?
Andrew.
On 07/18/2014 09:40 AM, Dennis Luehring wrote:
> Am 18.07.2014 10:29, schrieb Andrew Haley:
>> On 18/07/14 08:30, Dennis Luehring wrote:
>>>int* array = (int*)&argv;
>>
>> This looks like undefined behaviour. Don't you get a warning?
>
> no warnin
On 07/29/2014 10:27 AM, Gengyulei (Gengyl) wrote:
> Thank you for your answer. I find the most time consuming process in
> compiling a file is the optimization of the cgraph nodes (execute
> all_passes),
> This process is sequence, one node by one node. If we divide the cgraph nodes
> into unre
On 07/31/2014 11:25 AM, Gengyulei (Gengyl) wrote:
> How to explain it?
We can't. You haven't told us what is being parsed or even which
language it's written in. Note that GCC's parsing pass isn't simply
a parse: it has to build trees, which can be an expensive process.
Andrew.
On 09/02/2014 08:33 AM, Joey Ye wrote:
> On Sat, Aug 30, 2014 at 12:26 PM, Thomas Preud'homme
> wrote:
>>> From: Grissiom [mailto:chaos.pro...@gmail.com]
>>> Sent: Friday, August 29, 2014 11:51 PM
>>>
>>> Yes, it does. The namespace reserved for the implementation is _[_A-Z].
>> > The namespace
On 20/09/14 02:45, Ian Grant wrote:
> You get first prize for most informative intelligent answer so far!
> Careful, you might get second prize too :-)
>
> The problem is that we need to find a way to tell people _what_ is in
> that "dwarf" code. Open BSD's gcc ignores it, prints a warning, and
>
On 09/23/2014 10:39 AM, Bin Meng wrote:
> On Tue, Sep 23, 2014 at 5:11 PM, Bin Meng wrote:
>>
>> Sorry I still don't get it. The inline-asm codes are put in the very end
>> of the test function just before return, so the clobbered registers are
>> not used by gcc.
And neither are they used by the
201 - 300 of 1072 matches
Mail list logo
