++ exception.
Thanks,
Adam
int f, fd;
#ifndef HAVE_FREETYPE
if(vo_font == NULL)
return 0;
#endif
now WTF is the line 3b0 ???
ideas?
----
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
On Tue, 2 Jan 2007, Ian Lance Taylor wrote:
Adam Sulmicki <[EMAIL PROTECTED]> writes:
can someone help me understand what is going on?
are the -p and -pg options supposed to work?
This question is not appropriate for gcc@gcc.gnu.org, which is a
mailing list f
up. I have renamed all occurences of "mcount" in
sources to something else, and the program does not crash anymore.
Thanks a lot for help!
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
nd the
problem correctly the former would still fail if the test user is not
privileged enough to recreate the directory structure under /.
Thanks for working on this.
Adam
ers might have intentionally left mcount()
visible to user space so that user can replace gcc's mcount() with their
own implementation.
Just FWIW, I don't care if anything will get done about it.
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
cord :
http://www.cs.unm.edu/~sulmicki/eax/patches/xterm/xterm2.diff
this bug as present in xterm ever since it ran on linux for the first
time, up until 2001. No idea how long it is, but at least a decade.
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
trying to rationalise it.
Fine.
I am sorry, and I apoligize.
Adam
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
arget) and both versions give the same error.
Thanks,
Adam.
--
#include
using namespace std;
class Base {
public:
Base()
{
cout << "This is class " << this->number();
}
virtual int number()
other function, where this
behaviour would be permitted.
Either way, that solved the problem for me, so thanks again!
Cheers,
Adam.
on, for example.
--
Adam
I am correct and this last thing is really a bug then the
obvious question is whether it has anything to do with the more
restrictive form for conditional branches on MIPS64? And of course if
I fix it then whether it would be OK to lift the mode restrictions in
the conditional branch patterns.
Jim Wilson writes:
> Yes, it looks like fixing the combiner problem would make it possible to
> remove the mistaken mode checks.
Thanks very much, Jim. I will work toward removing these then.
Adam
Sorry for not getting back to your original post Paolo. I haven't been
picking up mails for a while.
On 2017-05-01 16:56, Jason Merrill wrote:
On Thu, Apr 27, 2017 at 2:02 PM, Paolo Carlini
wrote:
On 26/04/2017 12:32, Paolo Carlini wrote:
in 2013 (2013-09-16) Adam added two sli
s on
MIPS). I don't see how later passes would modify the code other than
removing 2 of the 3 "la rX, data" insns.
Adam
when replacement made. This must terminate since
the current contents will be tested and will always be valid. */
while (1)
{
Adam
the standard?
*
* I don't know if its possible but it may be possible to 'append'
* the lambda's stack to the existing scope rather than creating a
* new constrained scope -- from a logical point of view. This
* might be difficult if the compiler's design doesn't lend itself
* to working like that.
*/
Sorry that this is a bit a of a brain dump. I'm just finding my way around and
there is obviously at least some
interest here. Maybe one of you could try adding the finish_struct_1() call
and see how much further you get.
Regards,
Adam
Jason Merrill wrote:
> On 08/03/2009 09:36 PM, Adam Butcher wrote:
>> Thanks. I haven't any copyright assignments on file -- this is my first
>> dabbling with gcc and I've been doing it
>> mostly to experiment with C++ lambda support and non-standard extensions
Hi Jason,
Pending response from assign at gnu dot org, I've attached diffs made against
your latest lambda head. They are
cleaned up a little to from the previous diffs against trunk. First is the
re-layout fix, second is experimental
polymorphic lambda support.
Cheers,
Adam
0001-Re
Adam Butcher wrote:
>John Freeman wrote:
>>
>> I just inspected my code again. The call to layout_class_type at the
>> beginning of finish_lambda_function_body at semantics.c:5241 was
>> intended to recalculate offsets to members in the case of default captures.
>&
exts is a
workaround.
- dependent inferred return type needs to be
deferred and decayed. This may go some way (all
the way?) to solving the previous point.
- location of implementation.
- only a few use-cases have been considered.
Adam
Summary:
Subject: [PATCH] First pass polymo
Thanks for the feedback.
Jason Merrill wrote:
>Adam Butcher wrote:
>> The following examples produce
>> equivalent functions:
>>
>>1. [] (auto x, auto& y, auto const& z) { return x + y + z; }
>>2. [] (X x, Y& y, Z const& z) {
>>
dress beeing
> calculated as unsigned long int and not as unsigned int which would be
> Pmode for my target? Is this expected (and my problem originates from
> elsewhere) or am I missing something obvious here?
What's your sizetype? This could be related to:
http://gcc.gnu.org/ml/gcc/2008-05/msg00313.html
Adam
"Charles J. Tabony" writes:
> I see the same difference between GCC 4.3.2 and 4.4.0 when compiling
> for PowerPC, MIPS, ARM, and FR-V.
I can confirm this with mainline on MIPS/Octeon. Can you please file a
bug.
Adam
Charles J. Tabony writes:
> Filed as PR 41171.
Thanks.
> Is this actually a performance regression on MIPS? I suspect either
> sequence would be the same performance on most machines.
Yes it is: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171#c1
Adam
cross-jumping treats them correctly. As it merges
MEM_ATTRS it clears mismatching MEM_EXPRs no matter where the mem expression
is found in the insn. And my patch bootstraps successfully.
So, is using MEM_EXPR for this a bad idea?
Adam
o not
hesitate to ask questions.
Best regards,
Ádám Rák
StreamNovation Ltd.
Práter u. 50/a. Budapest, H-1083 Hungary
Phone: +36 20 9677 199
Email: adam@streamnovation.com
Richard Henderson writes:
> On 08/28/2009 12:38 AM, Adam Nemet wrote:
> > ... To assist the linker we need to annotate the indirect call
> > with the function symbol.
> >
> > Since the call is expanded early...
>
> Having experimented with this on Alpha a few y
Richard Henderson writes:
> On 09/01/2009 12:48 PM, Adam Nemet wrote:
> > I see. So I guess you're saying that there is little chance to optimize the
> > loop I had in my previous email ;(.
>
> Not at the rtl level. Gimple-level loop splitting should do it though.
&
Diego Novillo writes:
> If anyone has free cycles I would appreciate results from other
> ELF-capable targets.
The branch on mipsisa64-elf looks good (no regressions with languages
c,c++,objc):
http://gcc.gnu.org/ml/gcc-testresults/2009-09/msg02717.html
baseline:
http://gcc.gnu.org/ml/gcc-
e without (say) #pragma unroll.
We would also increase the chances of getting more precise bug reports
rather than "my code is slower with GCC 4.5 than it was with GCC 4.4".
IOW, we could push some of the initial investigation work over to the
user :).
Also with VTA we will hopefully be in better shape referencing
source-level constructs.
Adam
If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or CTRL-4)
instead of SIGINT?
Adam
On Fri, January 15, 2010 3:57 pm, Dave Korn wrote:
> Adam Butcher wrote:
>> On Fri, January 15, 2010 1:43 pm, Paolo Carlini wrote:
>>> I mean, why a well designed application should refuse to listen to ctrl-c
>>> when something goes wrong? Why every time for some reaso
style affect it?
Sorry for jumping in late. See make_file_assigment in combine.c.
The problem usually is that:
(set A (ior (and B C1) OTHER))
can only be turned into a bit-insertion if A and B happen to be the same
pseudos.
Adam
fanqifei writes:
> 2010/1/18 Adam Nemet :
> > Sorry for jumping in late. See make_file_assigment in combine.c.
> >
> > The problem usually is that:
> >
> > (set A (ior (and B C1) OTHER))
> >
> > can only be turned into a bit-insertion if A and B ha
s.
I think the right fix is to call convert_to_mode or convert_move in the
expansion code which ensure the proper truncation.
Adam
Mat Hostetter writes:
> Adam Nemet writes:
>
> > Ian Lance Taylor writes:
> > > Mat Hostetter writes:
> > >
> > >> Since the high bits are already zero, that would be less efficient on
> > >> most platforms, so guarding it wit
ded exactly ?
> I've checked the costs of the instructions, I have the same thing as
> the x86 port.
Maybe it is turned into an (and:DI .. (const_int 1)) and you don't
recognize that? Check your combine dump file, that should tell you what
is the pattern that combine came up with while dealing with these two
insns.
Adam
and it points somewhere above or at the local variables
(unlike on MIPS) then you'd still want the original order. So maybe this
should really be controlled by another backend knob.
Comments?
Adam
* cfgexpand.c (expand_stack_vars): Expand variables in decreasing
orde
this:
gcc -nostdlib -Wl,-r -mabi=64 ...
is probably easier to remember than this:
ld -melf64btsmip -r ...
Adam
-Wl,-r or -r depends on your belief if this switch would ever
be used for something else in GCC.)
Adam
with the
@code{aligned} attribute.
Adam
Gerald Pfeifer writes:
> +January 27, 2008
2009 ;)
Adam
e ELF class (ELF64/ELF32). (Obviously, that's a bug in libdwarf.)
So my question is whether the saving in the size of the debug info with
-msym32 is really worth the trouble here or should we just start generating
64-bit addresses with -msym32?
Adam
Richard Sandiford writes:
> How about the patch below? I'll apply it in the next couple of days
> if there are no objections.
Thanks for patch. I also like the new comments you added.
Adam
ance issues.
The patch below enables FRAME_GROWS_DOWNWARD with -mframe-grows-downward
(mostly for testing) and with -fstack-protector.
Adam
Index: config/mips/mips.opt
===
--- config/mips/mips.opt(revision 142249)
+++ config/mi
ONST_INT B))
to
(set (REGX) (CONST_INT A))
...
(set (REGX) (plus (REGX) (CONST_INT B-A)))
I think you really need the Joern's optmize_related_values patch. Also see
PR33699.
Adam
oking at something similar for PR33699 for MIPS. My plan is
to experiment extending cse.c with putting "anchor" constants to the available
expressions along with the original constant and then querying those later for
constant expressions.
Adam
Adam Nemet writes:
> I am actually looking at something similar for PR33699 for MIPS. My plan is
> to experiment extending cse.c with putting "anchor" constants to the available
> expressions along with the original constant and then querying those later for
> constant
d (on Octeon) gzip was completely dominated by the hash
table search of the deflation code. The new ABIs shine when you have function
calls or 64-bit arithmetic, which I don't think is the case in gzip.
I might look at the 4.3.2->trunk regressions (if I can reproduce on Octeon).
Adam
. Alternatively, you could create a simple, separate pass
> that applies CSE's "related expressions" thing in dominator tree walk.
See http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00158.html for handling
something similar when related expressions differ by a small additive
constant. I am planning to finish this and submit it for 4.5.
Adam
> globally or am I missing something very basic here ?
No, you're not. There are plans moving some of what's in CSE to a new LCM
(global) pass. Also note that for a global a pass you clearly need some more
sophisticated cost model for deciding when CSEing is beneficial. On a
multi-scalar architecture, instructions synthesizing consts sometimes appear
to be "free" whereas holding a value a in a register for an extended period of
time is not.
Adam
Jean Christophe Beyler writes:
> I set up your patch and I get an internal error on this test program:
You're right. I haven't handled the case properly when the constant itself
was an anchor constant (e.g. 0). Try this version.
Adam
* cse.c (get_const_anchors):
ing something? If this sounds reasonable I can try to work out a
patch and see what happens.
Adam
Richard Sandiford writes:
> Adam Nemet writes:
> > In order for my CSE const anchor patch to work I needed to drastically lower
> > the cost of immediate addition in the MIPS backend. This was acceptable as
> > a
> > proof of concept but not in general of course.
Richard Sandiford writes:
> Adam Nemet writes:
> > * Synthesizing multi-insns constants from const anchors make sense
> > regardless
> > whether the constant is used as an address so I am adjusting the cost system
> > to make those stick independent of the context.
ped.)
I am not sure I understand this. Why would we decide to hoist suboperations
of a multiplication? If it is loop-variant then even the suboperations are
loop-variant whereas if it is loop-invariant then we can hoist the whole
operation. What am I missing?
Adam
changes.
Does somebody know what's going on? I'll look at it otherwise.
Adam
Adam Nemet writes:
> For two testresults now the cleanup tests are failing in both gcc and g++:
>
> http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html
> http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html
>
> I waited for another testresults because there w
Adam Nemet writes:
> I am not exactly sure what has exposed this but the bug seems to be old.
> can_throw_external in except.c does not look at the branch delay slot (second
> entry in a SEQUENCE) to determine whether the insn may throw or not.
>
> In gcc.dg/cleanup-8.c for example
John David Anglin writes:
> The same tests now fail on hppa. This is PR 39651. I'm fairly certain
> this was introduced by the following change:
I put this PR in the checkin that was just approved on gcc-patc...@. Please
close the bug if it fixes the failures on hppa too.
Adam
0, 0, &j, sizeof(int));
> }
...
>
> Why is the memory clobber required, and why GCC does not understand to
> sync the value to memory when passing the address to a function?
Because you never inform GCC that you will use the value at
address *NAME. Try to use "m"(*name) rather than "a1"(name) in the asm.
Adam
Jamie Prescott writes:
> > From: Adam Nemet
> > Jamie Prescott writes:
> > > static inline int set_prop(char const *path, char const *name,
> > > void const *data, int size)
> > > {
> > > int error
t; easier/better way?
regno_reg_rtx in emit-rtl.c?
Adam
plit_trees/associate_trees) and
hope everything else works ;).
I am for 1, FWIW, but I know this issue has some history [2], so I'd like to
hear others' opinion before I started working on a patch.
Adam
[1] http://gcc.gnu.org/ml/gcc/2008-01/msg00215.html
[2] http://gcc.gnu.org/ml/gcc-patches/2004-07/msg01478.html
-ssa-loop-prefetch.c:1589:7: error:
>
>> format '%ld' expects type 'long int', but argument 5 has type 'long long
> int'
>> make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
>> make[3]: *** Waiting for unfinished jobs
>
> I get this error on ppc also.
See http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00712.html
Adam
n if the SC decides to support the nomination they can check with the
person if he or she would accept the appointment.
Adam
and sign-extensions before a subsequent
truncation.
Any further information on this subject would be very much appreciated.
Adam
ncate:N (and:W expr:W GET_MODE_MASK(Nmode)))
? Where == is not necessarily identical bit representation of the object
holding the value (e.g. QI HI values in MIPS) but that they are
indistinguishable in the operations that are defined on them.
Adam
Jeff Law writes:
> Ian Lance Taylor wrote:
> > Adam Nemet writes:
> >
> >
> >> I am trying to understand the checkin by Jeff Law from about 11 years ago:
> >>
> >>r19204 | law | 1998-04-14 01:04:21 -0700 (Tue, 14 Apr 1998) | 4 lin
at allows backends to
define the upper bits. For example to have sign-bit copies there in registers
to enforce the MIPS64 SI mode representation. And treating the don't care
bits outside SI mode in this way is true for any other SI-mode operations
performed on registers not just truncate, right? Hmm, nice.
Adam
representation. And treating the don't care
> bits outside SI mode in this way is true for any other SI-mode operations
> performed on registers not just truncate, right? Hmm, nice.
Thanks for all the explanations.
Adam
* For C++, gmp.h now includes cstdio, improving compiler
compatibility.
...
Adam
ve time, to fix.
MIPS bootstraps fine with --enable-build-with-cxx:
http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg02323.html
I don't know if the new failures are related to C++; I will do a C build
later and compare.
Ian, thanks for your C++ work!
Adam
?
Best regards,
/Adam
On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote:
> On 08/30/2010 09:46 AM, Richard Henderson wrote:
> >On 08/30/2010 03:45 AM, Adam Jiang wrote:
> >>When I read the source in Linux kerne, it was said that stack canary for
> >>implementing stack protector is
On Tue, Aug 31, 2010 at 09:12:57AM -0700, David Daney wrote:
> On 08/30/2010 08:36 PM, Adam Jiang wrote:
> >On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote:
> >>On 08/30/2010 09:46 AM, Richard Henderson wrote:
> >>>On 08/30/2010 03:45 AM, Adam Jiang wrote
welcome -- I have done only basic testing -- it appears to
work okay for what I want (so far at least).
Regards,
Adam
PS. I already have sorted copyright assignment a while ago so you can go
ahead and apply this at your convenience if it is any good (subject to
review of course).
0001-C-0x-Support
On Thu, January 20, 2011 4:43 pm, Jonathan Wakely wrote:
> On 20 January 2011 14:26, Adam Butcher wrote:
> > Hi there,
> >
> > Attached is a tentative patch ...
> > [snip]
>
> thanks for working on this. Patches should be sent to the gcc-patches
> list for r
Tom Tromey <[EMAIL PROTECTED]> writes:
> I think our technical approach should be to have ecj emit class files,
> which would then be compiled by jc1. In particular I think we could
> change ecj to emit a single .jar file.
I (and David Crawshaw) have actually done this.
http://tool.ibex.org/
4.1.1-13)
Same behavior on
[EMAIL PROTECTED]:~/proj/idzebra-2.0.2/isamb$ gcc -v
Reading specs from /usr/local/lib/gcc/sparc-sun-solaris2.9/3.4.6/specs
Configured with: ../configure --with-as=/usr/ccs/bin/as
--with-ld=/usr/ccs/bin/ld --enable-shared --enable-languages=c,c++,f77
Thread model: posix
Hi Jason,
On 23.04.2013 14:42, Jason Merrill wrote:
On 22.04.2013 17:42, Jason Merrill wrote:
> On 08/10/2009 08:33 PM, Adam Butcher wrote:
> > Attached are my latest experimental polymorphic lambda patches
> > against the latest lambda branch.
>
> Polymorphic lambdas were
use cases than the simple test program below but I'd welcome
any feedback at this stage.
I do feel like I've gone backward with this but I think it's worth
getting the mechanical side working right with the latest GCC before
integrating the 'auto' parame
This only supports the explicit template parameter syntax and does not
correctly support conversion to static ptr-to-function for generic
stateless lambdas.
---
gcc/cp/mangle.c| 2 ++
gcc/cp/parser.c| 43 +--
gcc/cp/semantics.c | 24
On Fri, Dec 21, 2012 at 4:41 AM, Richard Biener
wrote:
>
> On Thu, Dec 20, 2012 at 5:33 PM, Adam wrote:
> > Hi,
> >
> > When using -flto is there a way to tell gcc to not inline a particular
> > function? attribute noinline appears to have no effect. I am using g
On Fri, Dec 21, 2012 at 11:08 AM, Richard Günther
wrote:
> Adam Lewis wrote:
>
>>On Fri, Dec 21, 2012 at 4:41 AM, Richard Biener
>>wrote:
>>
>>> On Thu, Dec 20, 2012 at 5:33 PM, Adam wrote:
>>> > Hi,
>>> >
>>> > Whe
export by gcc assembler by delete "w" property,
> the warning is disappeared.
Did you try making priv_dat const?
Adam
crosstool-newlib script does as well.
Adam
agreed with MTI
> beforehand (although I hadn't realised MTI themselves had written
> the specification). Having thought it over, I think it would be best
> if I stand down as a MIPS maintainer and if someone with the appropriate
> commercial connections is appointed instead. I&#
) >= 0
2309 || recog_memoized (insn) < 0);
I am hitting this assert with the Octeon pipeline patch. Isn't the check on
recog_memoized reversed? Or are we really asserting here that the insn has
either been recognized earlier or won't be recognized now either?!
Adam
for the info but I can't seem to find the code where this is supposed
to be happening. Can you point me to the code?
Adam
before the patch. The only
new thing is the assert which now catches this.
If the consumer is an asm just like in gcc.dg/tree-ssa/stdarg-2.c:f10() then
we would not call recog on the producer inside dep_cost*.
The patch below fixes the issue for me. I am going to test this if it looks
good to peop
Eric Botcazou <[EMAIL PROTECTED]> writes:
>> Applying the patch Adam created and posted in the message below resolved
>> the issue and the compiler successfully bootstrapped:
>>
>> http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html
>
> Thanks for reporting this.
but only if ENABLE_CHECKING is defined.
Well, I can't bootstrap as it is so it would be nice if this was fixed
regardless of the checking level. (And this is what my patch does in
http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00574.html.) Another option
would be to completely remove the assert.
Adam
tle-endian. I will submit a patch later. I was just waiting for
the other Octeon patches to settle. Thanks for the note.
Adam
e-* modules.
Do people have other recommendations or a preference?
Adam
Daniel Berlin writes:
> On 6/15/07, Adam Nemet <[EMAIL PROTECTED]> wrote:
> > get_alias_set and internally record_component_aliases makes
> > assumptions about the IR that are only valid in RTL.
>
> What is this assumption, exactly?
That non-addressable fields are al
nk you're right. Obviously we don't have
this issue with bitfields in C.
I am trying now to prototype a new approach along the lines of
returning true in component_uses_parent_alias_set for SFT's with
DECL_NONADDRESSABLE_P.
Adam
s_set_entry:
get_alias_set_entry (TYPE_ALIAS_SET (t))->nonaddr_alias_set.
Adam
ype?
Type of the expression passed to get_alias_set. And without the
component_uses_parent_alias_set loop.
Adam
1 - 100 of 104 matches
Mail list logo
