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
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
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
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
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
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
++ exception.
Thanks,
Adam
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
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 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
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
?
Best regards,
/Adam
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
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
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
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
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
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
If you're on a posix-compatible have you tried using SIGQUIT (CTRL-\ or CTRL-4)
instead of SIGINT?
Adam
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
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-
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.
&
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
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
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
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
"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
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
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) {
>>
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
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.
>&
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
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
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
when replacement made. This must terminate since
the current contents will be tested and will always be valid. */
while (1)
{
Adam
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
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
* For C++, gmp.h now includes cstdio, improving compiler
compatibility.
...
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
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
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
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
and sign-extensions before a subsequent
truncation.
Any further information on this subject would be very much appreciated.
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
-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
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
t; easier/better way?
regno_reg_rtx in emit-rtl.c?
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
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
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
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
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
changes.
Does somebody know what's going on? I'll look at it otherwise.
Adam
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
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.
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.
ing something? If this sounds reasonable I can try to work out a
patch and see what happens.
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):
> 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
. 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
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
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
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
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
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
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
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
Gerald Pfeifer writes:
> +January 27, 2008
2009 ;)
Adam
with the
@code{aligned} attribute.
Adam
-Wl,-r or -r depends on your belief if this switch would ever
be used for something else in GCC.)
Adam
this:
gcc -nostdlib -Wl,-r -mabi=64 ...
is probably easier to remember than this:
ld -melf64btsmip -r ...
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
tle-endian. I will submit a patch later. I was just waiting for
the other Octeon patches to settle. Thanks for the note.
Adam
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
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.
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
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
) >= 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
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&#
crosstool-newlib script does as well.
Adam
export by gcc assembler by delete "w" property,
> the warning is disappeared.
Did you try making priv_dat const?
Adam
ree with you that you should not be required to provide this pattern but I
don't think there is better way currently. We would need to subset the
original alias set similarly to restrict but since memcpy switches the alias
set of its operands to zero this approach would not work.
Adam
erthing in one chunk and then store it later. See MIPS's
movmemsi pattern and the function mips_block_move_straight.
Adam
splitter. I will try to get the patch tested
overnight.
Adam
x
movl$2, (%rax)
movl $1, %eax
ret
Adam
ype?
Type of the expression passed to get_alias_set. And without the
component_uses_parent_alias_set loop.
Adam
s_set_entry:
get_alias_set_entry (TYPE_ALIAS_SET (t))->nonaddr_alias_set.
Adam
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
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
e-* modules.
Do people have other recommendations or a preference?
Adam
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
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
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
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
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
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
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
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
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/
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
1 - 100 of 104 matches
Mail list logo
