The function SetCategory(v) returns void and simply assigns
the value of v to a class member, so there are no trap conditions.
TA, on the other hand, stands for "trap always", so the condition
code is unimportant anyway. Why has the trap instruction been generated?
Usually this is because you
On 10/05/2009 09:29 PM, Sergey Sadovnikov wrote:
Can anybody explain why line marked with '{*1}' produce this error
message:
I think it's because there is no constructor for array that takes an
initializer_list. I get this message if I change your {*2} line to:
std::array < wchar_t, sizeof.
On 10/01/2009 11:37 PM, Sriraman Tallam wrote:
Hi,
I moved implicit-zee.c to config/i386. Can you please take another look ?
I think this patch is best reviewed by an x86 backend maintainer now.
Thanks for doing the adjustments, BTW.
Paolo
That exactly is the problem. You can't have a CONST_INT inside a
ZERO_EXTEND. That is not valid.
You'll need a separate pattern to recognize the CONST_INT without a
ZERO_EXTEND around it. Unfortunately, this will not give reload
the freedom it should have.
You mean I should remove the con
On 09/25/2009 09:35 PM, Joseph S. Myers wrote:
Viewing deleted files and their history (and for SVN deleted branches are
just a special case of deleted files) is something SVN is bad at since you
do need to work out the last revision the file was present first.
Yep. Anyone deleting dead branch
-Winline doesn't help here. Scanning the assember output does (obviously!).
nm also does.
Paolo
We should also keep in mind that such logs aimed at users should support
i18n - unlike the existing dumps for compiler developers, which are quite
properly English only, and most calls to internal_error which should only
appear if there is a compiler bug and are also only meant to be useful for
On 10/19/2009 10:48 AM, Richard Guenther wrote:
On Mon, Oct 19, 2009 at 3:19 AM, Joel Sherrill
wrote:
Hi,
I got a random unsolicited email about arc-elf since
I pop up in google a lot asking cross compiler questions.
I decided to try to build it and as PR41747 indicates
4.3.4, 4.4.1, and the
On 10/22/2009 01:57 AM, Ian Lance Taylor wrote:
See cfg*.[ch] and df*.[ch]. Note that df*.[ch] only applies to RTL.
There is no clean way to extract the dependency information.
On trees, the SSA def-use edges could be seen as (well, are) a DFG.
Paolo
Hi all,
with the new plugin infrastructure, it makes sense to replace the
one-catches-all md reorg pass with target-specific passes plugged into
the pass manager.
If the md reorg is doing just complex peephole optimizations that cannot
be achieved with targets, that's fine.
This has the ad
Possible special combination pattern: If the two
operands to a comparison die there and both come from insns that are
identical except for replacing one operand with the other, throw away
those insns. Ok if insns being discarded are known 1 to 1. An andl
#1 after a seq is 1 to 1
On 11/02/2009 08:49 AM, Joern Rennecke wrote:
This would only be valid if the comparison is in an equality context
(or for special input operand ranges).
So (unless the target is CC0) you'd either have to use dataflow analysis
to look at all the contexts the comparison result is used in, or you'
On 11/08/2009 10:29 PM, David Edelsohn wrote:
The problem is shell append += and libtool not running with the same
shell used by configure.
What version of libtool is used by mpc? Libtool HEAD could fix this bug.
Paolo
On 11/09/2009 06:33 AM, Kaveh R. Ghazi wrote:
From: "David Edelsohn"
AIX Shell is KSH.
The problem is shell append += and libtool not running with the same
shell used by configure.
Hm, the mpc configure script actually has a check for shell +=, and on
my solaris box it correctly detects tha
On 11/13/2009 12:43 PM, Paul Edwards wrote:
I normally define PREFIX in a
common header file. However, this caused a conflict between
prefix.c and regex.c which both try to use this keyword.
regex.c is forked from anything else, so I don't think a patch changing
PREFIX to FUNC_PREFIX will hav
On 11/14/2009 12:27 PM, Paul Edwards wrote:
So what I have done is get the compiler to fail on any missing
prototype. I think perhaps we need to have a generic gcc or
autoconfigure option called "config by prototype". MVS is just
one instance where you might wish to do it this way. Other
port
On 11/22/2009 10:48 AM, John Nowak wrote:
Hello. I would like to get the necessary forms for copyright assignment
to GCC for future work on GNAT. I was told this is the way to kick off
the process.
I sent them offlist.
Paolo
On 11/23/2009 11:32 AM, Paul Edwards wrote:
So, given the scope below, can someone please explain what
4.4 changes are affecting me and what I need to do to overcome
them?
I think your best bet is to grep the changelogs for what has changes,
and see what was done for other ports. Many target
On 11/25/2009 08:38 PM, Richard Guenther wrote:
If you can offer advice on how to teach quilt
(which I belive uses patch) to ignore whitespace changes when
applying patches then more power to you - the only tool that
seems to be able to ignore whitespace changes is diff.
sed -i '/^-/s/[ \t]*$//
On 11/25/2009 06:45 PM, Dave Korn wrote:
Michael Matz wrote:
Someone with the appropriate rights needs to shutdown the svn server so
that no additional commits can be done, then the revision files in
db/revs/ and db/revprops/ starting with the wrong revision need to be
removed, then db/current
On 11/26/2009 12:20 AM, Alexandre Oliva wrote:
sed -i 's,[ \t]*$,,' probably won't work, if there are all-blanks lines
being left alone in the patch (so the rx will match the patch markers
too), but something slightly more elaborate preserving a fixed number of
leading blanks dependng on the patc
On 11/27/2009 03:21 PM, Dave Korn wrote:
you and Paolo are pretty much the only
people who feel that it should have been backed out
Uh? I said that the repository should have been made readonly if there
was a concrete possibility of backing out the patch, be it with svn cp
(which we already
On 11/30/2009 09:47 PM, Michael Witten wrote:
On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI wrote:
The patch which makes the MPC library a hard requirement for GCC
bootstrapping has been approved today.
Out of curiosity and ignorance: Why, specifically, is MPC going to be
a hard requiremen
On 12/14/2009 09:31 PM, John Regehr wrote:
Ok, thanks for the feedback Andi. Incidentally, the LLVM folks seem to
agree with both of your suggestions. I'll re-run everything w/o frame
pointers and ignoring testcases where some compiler warns about use of
uninitialized local. I hate the way these
I also wonder if you have something like LTO enabled.
No, he doesn't enable LLVM LTO. Even if it did, LTO wouldn't touch
the 'CC1000SendReceiveP*' definitions because they are not static
(unless he explicitly built with an export map).
Interesting.
I haven't analyzed what is going on in t
On 12/16/2009 03:21 AM, John Regehr wrote:
Hopefully the results are more fair and useful now. Again, feedback is
appreciated.
I would also avoid testcases using volatile. Smaller code on these
testcases is often a sign of miscompilation rather than optimization.
For example,
http://embed.
On Thu, Dec 17, 2009 at 19:54, Eric Botcazou wrote:
>> However I would prefer to leave these testcases in, unless there is a
>> strong feeling that they are too distracting. They serve as poignant
>> little reminders about how easy it is to get volatile wrong...
>
> They skew the results in favor
On 12/19/2009 01:07 AM, Joern Rennecke wrote:
Quoting Michael Eager :
Hi --
I'm working on creating the cstore and cbranch templates
for the Xilinx MicroBlaze processor.
In theory cstore / cbranch should be the future, but the last time I tried
to use them, they didn't quite work right yet,
On 12/17/2009 06:17 PM, Richard Guenther wrote:
It shouldn't as *(int *)0 = 0; might trap. But if you want to be sure
use
__builtin_trap ();
instead for the whole sequence (the unreachable is implied then).
GCC choses a size-optimal trap representation for your target then.
Agree that it s
On 12/21/2009 08:10 PM, Richard Henderson wrote:
(define_insn_and_split "*cmp"
[(set (match_operand:SI 0 "register_operand" "=r")
(lt:SI (match_operand:SI 1 "register_operand" "r")
(match_operand:SI 2 "register_operand" "r")))]
""
"cmp %0,%1,%2\;andi $0,$0,1"
On 12/22/2009 07:24 PM, Jeff Law wrote:
On 12/22/09 11:16, Andrew Hutchinson wrote:
I came across this RTL on AVR in combine dump (part of va-arg-9.c test)
(set (reg:QI 25 r25 [+1 ])
(subreg:QI (sign_extend:HI (reg:QI 49)) 1))
The sign extension is completely redundant - the upper part of
regi
On 12/23/2009 01:01 PM, Steven Bosscher wrote:
On Wed, Dec 23, 2009 at 12:49 PM, Bingfeng Mei wrote:
Hello,
I encounter an issue with PRE optimization, which created worse
Is this at -O2 or -O3?
I think this could be fixed if fwprop propagated addresses into loops;
it doesn't because it ma
On 12/23/2009 03:05 PM, Joern Rennecke wrote:
So if this is only useful for a limited set of targets, why isn't it
controlled by an option or a target hook so that it is only turned on
on the targets where it is deemed to make sense overall?
Well, this optimization is basically the opposite of
On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
this should be fixed? Or it requires extra patch?
No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
properly for your target), we could fix this very easily.
Paolo
On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
It seems that just commenting out this check in fwprop.c should work.
Yes, but it would pessimize x86.
Paolo
On 12/23/2009 06:47 PM, H.J. Lu wrote:
On Wed, Dec 23, 2009 at 8:41 AM, Paolo Bonzini wrote:
On 12/23/2009 04:19 PM, Bingfeng Mei wrote:
It seems that just commenting out this check in fwprop.c should work.
Yes, but it would pessimize x86.
Is there a bug open for x86? Can't we ma
> There are some other quirks with the MicroBlaze architecture.
> The cmp/cmpu instructions only take a register. Other instructions
> which can be used for equality or signed comparisons (xor or sub)
> can take an immediate operand. I'll see how they can be added.
You can probably convince comb
On 01/03/2010 11:25 PM, Richard Guenther wrote:
>char charray[sizeof(long)] = {...};
>long l = *(long*)charray; // ok
not correct;) (the lvalue has to be of character type, yours is of
type 'long' - the type of the actual object does not matter)
What would be correct instead is
On 01/09/2010 12:16 PM, Steven Bosscher wrote:
This is with gcc SVN revision 155740, and src checked out yesterday
(top of src/Changelog is the fix from Kaveh and FX for gcc PR42424).
Not knowing a thing about libtool, I hope someone can tell me what's
wrong here;-)
src and gcc's libtool are o
On 01/09/2010 04:48 PM, H.J. Lu wrote:
On Sat, Jan 9, 2010 at 6:26 AM, Paolo Bonzini wrote:
On 01/09/2010 12:16 PM, Steven Bosscher wrote:
This is with gcc SVN revision 155740, and src checked out yesterday
(top of src/Changelog is the fix from Kaveh and FX for gcc PR42424).
Not knowing a
I think the main reason is that DMD front end sources are dual licensed
with GPL and Artistic License. The DMD backend is not under an open
source license (personal use only), so the Artistic License is how the
two are integrated. The fork is required to allow DMD to continue under
its current
On 01/23/2010 04:29 PM, Richard Guenther wrote:
We could warn about this when building with C++ but with C we do not
see bools but ints here.
With such a warning there would be no reason not to build stage2 and
stage3 with bool == _Bool.
Paolo
Strictly speaking, that's not true. Even if the submitter would still
be required to have copyright assignment for the FSF, they could be
copyable to the DMD front-end _as long as the submitter himself sends
them for inclusion there too_. This is the practical significance of
the license grant
On 01/25/2010 03:04 PM, Joern Rennecke wrote:
Quoting Christian Joensson :
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Ok.
Paolo
This probably is a new version of PR41418 then. We have the problem that
fortran is turned on in --enable-languages, so libgomp configure expects the
fortran compiler to be available.
Does this fix it for you?
Index: configure.ac
===
On 01/25/2010 11:38 PM, Dave Korn wrote:
On 25/01/2010 20:58, Paolo Bonzini wrote:
This probably is a new version of PR41418 then. We have the
problem that
fortran is turned on in --enable-languages, so libgomp configure
expects the
fortran compiler to be available.
Does this fix it
On 01/26/2010 08:57 AM, Paolo Bonzini wrote:
On 01/25/2010 11:38 PM, Dave Korn wrote:
On 25/01/2010 20:58, Paolo Bonzini wrote:
This probably is a new version of PR41418 then. We have the
problem that
fortran is turned on in --enable-languages, so libgomp configure
expects the
fortran
On 02/02/2010 05:04 AM, Michael Witten wrote:
On Sun, Jan 31, 2010 at 6:38 PM, Paolo Carlini
wrote:
it's extremely unlikely that the C++ front-end maintainers could
even consider reviewing patches from a novice for such an hard to
implement feature.
That says more about the tangled mess th
I'm adding autoc...@gnu.org to the destinations, since this is a
pretty fundamental problem with AC_CHECK_DECL and C++
On Tue, Feb 9, 2010 at 02:17, Joern Rennecke
wrote:
>
>> On 02/08/2010 09:58 AM, Joern Rennecke wrote:
>>>
>>> That would only work if every program that uses libiberty uses
>>>
On 02/16/2010 05:14 PM, Richard Guenther wrote:
On Tue, Feb 16, 2010 at 4:59 PM, Paulo J. Matos wrote:
Hi,
From http://gcc.gnu.org/ml/gcc/2009-08/msg00066.html
I get that 4.3.5 should come out after 4.4.2, however, 4.4.2 has come
and gone (with 4.4.3) and no 4.3.5.
Any ideas when this is goi
On 02/17/2010 04:41 PM, Joern Rennecke wrote:
Quoting Ralf Wildenhues :
sed alternation \| is not portable.
I've replaced it now with a pair of substitutions. I also fixed
the ',' substitution to give yield on opening bracket for the next cast,
and to apply for all commas.
+ $[]as_decl_type
>> Maybe we can use this in AC_CHECK_DECLS instead of having a new
>> separate macro. If there is a parenthesis in the name call the new
>> version, if there is none, call the old one.
>
> You shouldn't need to keep the old version around, it's supposed to be
> a drop-in replacement. The reason I
This will probably break building glibc, as problems building when __i686
is a predefined macro have been known since at least 2002 but none of the
many patches proposed since then have been accepted.
I imagine changing the default would help with that...and packagers can
work around it.
I t
On 02/25/2010 08:07 AM, Uros Bizjak wrote:
On Thu, Feb 25, 2010 at 12:00 AM, Jason Merrill wrote:
On 02/18/2010 07:46 PM, Joseph S. Myers wrote:
On Thu, 18 Feb 2010, Jason Merrill wrote:
I periodically get bitten by bug 34115: a compiler configured without
--with-arch on i686-pc-linux-gnu d
On 02/25/2010 08:51 AM, Arnaud Charlet wrote:
The main "mangling" (in Ada parlance, we talk rather about "encoding")
that is performed by GNAT is to handle packages ("namespace" in C++) and
to differentiate overloaded functions (and there, a simple counter is all
that is needed).
One of the adv
On 03/01/2010 09:48 PM, DJ Delorie wrote:
But I've previously noted that target libiberty seems completely useless;
It's a target library, like newlib, libz, libstdc++, or anything else.
How do you know there are no target applications that want to link
against it?
Is it still used outside th
On 03/05/2010 05:03 PM, Joseph S. Myers wrote:
I don't know if there's an existing free software implementation of UAX#14
(Unicode Line Breaking Algorithm) suitable for use in GCC; that would be
the very heavyweight approach.
Yes. You can get it from gnulib like gdb does, or you can link
libu
On 03/25/2010 12:31 PM, Eric Botcazou wrote:
The combine pass had been written at least a decade before vector modes were
introduced so it essentially doesn't expect them, i.e. some transformations
simply don't make sense for vector modes. You need to analyze the one you're
seeing (e.g. where do
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
I suppose they are not exported.
Richard.
Richard,
Shouldn't these still show up in the output from...
nm libgc
On 03/31/2010 06:00 PM, Jack Howarth wrote:
On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
I suppose
On 03/31/2010 06:24 PM, Jack Howarth wrote:
On Wed, Mar 31, 2010 at 05:50:14PM +0200, Paolo Bonzini wrote:
[MacPro:darwin_objdir/x86_64-apple-darwin10.3.0/libgcc] howarth% nm
libgcc_ext.10.5.dylib | grep emutls
00013e70 T ___emutls_get_address
00014070 T ___emutls_register_common
I suppose
On 03/31/2010 11:25 AM, Vincent Lefevre wrote:
On 2010-03-31 11:04:03 +0200, Marc Glisse wrote:
IMHO this transformation mostly makes sense for the
-ffinite-math-only case where you can replace: "put a constant and
multiply/divide" by "put a constant and add/sub" and never care
about extracting
On 04/07/2010 06:17 PM, Gary Funck wrote:
We have access to only a few of the listed platforms,
(and in the case of IA64 the underlying OS is SuSE not
"unknown-linux-gnu").
That does not matter. You're obviously not required to use Linux From
Scratch. :-) If you run "./config.guess" from the
On 04/11/2010 06:26 PM, Duncan Sands wrote:
Hi Robert,
b) better behavior for undefined cases
this is one of the problems with using LLVM with the Ada front-end.
LLVM makes pretty aggressive deductions when it sees undefined
behaviour
These do not seem to point at LLVM's optimizer bugs/aggr
On 04/11/2010 06:50 PM, Dave Korn wrote:
Grepping the -patches archives to see which platforms submitted
patches get testing on would also be interesting, but somewhat
harder owing to the more free-form nature of the text there. Still,
a two-to-one ratio of linux to rest-of-the-world would be in
On 04/12/2010 04:18 PM, Dave Korn wrote:
Could anyone really believe that without being a grade A tinfoil-hat
wearing crazy? More precisely, could anyone capable of the kind of
rational thought processes that they'd need to have in order to be
able to make any kind of contribution to the GCC pro
On 04/13/2010 07:14 PM, Jack Howarth wrote:
Paolo,
I hope you don't think I was trolling in my initial post. Assuming
plugins will eventually be welcomed into the FSF gcc source tree in
general, there is a valid argument for having dragon-egg present with
a configure option that builds it if
On 04/13/2010 09:16 PM, Jack Howarth wrote:
Paolo,
It is unclear to me what the original intentions were when the
plugin infrastructure was created. That is, was it envisioned that
FSF could accumulate the plugins directly in the source tree to
ensure they were well maintained across FSF gcc
On 04/14/2010 03:36 PM, Jack Howarth wrote:
On Wed, Apr 14, 2010 at 08:24:35AM +0200, Duncan Sands wrote:
Hi Steven,
FWIW, this sounds great and all... but I haven't actually seen any
comparisons of GCC vs. LLVM with DragonEgg. A search with Google
doesn't give me any results.
Can you point o
On 04/19/2010 03:35 PM, Jack Howarth wrote:
The annoucement should probably note that targets which lack
objdump currently can't build plugins. I've had about as much
luck getting the patch to fix this...
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00610.html
Sorry if I haven't reviewed a
Well your review does pretty much amount to "because darwin lacks
objdump like linux, the patch is rejected...".
Please reread.
Paolo
On 04/21/2010 07:04 PM, Steven Bosscher wrote:
On Wed, Apr 21, 2010 at 6:56 PM, Robert Dewar wrote:
Actually for my taste, you have to get a MUCH bigger factor in compile
time before you can call yourself a fast compiler (Realia COBOL by
comparison compiles millions of lines a minute of code on
On 04/21/2010 07:42 PM, Jack Howarth wrote:
However in the past when I submitted patches for areas outside
of the darwin specific source files, they were rejected*if* they
made the code too darwin-centric.
Well, in this case I gave you a suggestion, so it was implicit that I'd
have approved t
On 04/21/2010 07:51 PM, Jack Howarth wrote:
I'm not sure if "nm -g" would work under Linux, since
$ nm -g /usr/lib64/libsqlite3.so
nm: /usr/lib64/libsqlite3.so: no symbols
$ objdump -T /usr/lib64/libsqlite3.so|head -5
/usr/lib64/libsqlite3.so: file format elf64-x86-64
DYNAMIC SYMBOL TABLE
On Thu, Apr 22, 2010 at 00:35, Andreas Schwab wrote:
> Paolo Bonzini writes:
>
>> I'm not sure if "nm -g" would work under Linux, since
>>
>> $ nm -g /usr/lib64/libsqlite3.so
>> nm: /usr/lib64/libsqlite3.so: no symbols
>>
>> $ objdump
> Paolo,
> We don't have -D in our nm. How about the following change to
> configure.ac?
Ok. See? ;-)
As a followup, if you have access to a Linux machine you can try
removing the objdump requirement altogether.
(Thanks Eric too).
Paolo
> This revised patch builds plugin support fine on x86_64-apple-darwin10 and
> x86_64 Fedora 10...
Ok for trunk and 4.5 branch after a few days.
Paolo
Farlie A wrote:
> Hi,
>
> Would you be willing to consider supporting the PE object formats on the
> ARM based port of ReactOS?
If you are willing to contribute code for this, that's possible indeed.
Otherwise, no one will probably do the work.
Paolo
> The following ports haven't been converted yet:
>
> arc m32c m68hc11 mmix pdp11 score vax
DJ has reported problems on the list for m32c.
Regarding ARC and MMIX we might expect some action from Joern and H-P
respectively, but nobody is probably going to do the work for the others
Paolo
> though that is probably inadequate.
Especially because Makefile.in is automatically generated. :-)
> It's not the default goal that matters, but if bootstrap4 is a goal at all.
> Or if compare3 is a goal.
I have a (correct) patch which I'll apply in a day or two.
Thanks,
Paolo
Thomas Schwinge wrote:
> Hello!
>
> We, the GNU Hurd people, would like to get GCC in a compilable/usable
> shape for us again, without needing to do the patching that was needed
> since the 4.2 release. I have already some weeks ago sent the needed
> patches to the gcc-patches mailing list, wher
> To get around this you'd have to either
> link a separate copy of the plugin for each executable, or access the
> symbols in the executable indirectly through GetProcAddress and function
> pointers.
Hacking the compiler (or postlinker!) to emit a special constructor that
does the necessary GetPr
> The main difference that springs to mind: SIN is built-in, MATMUL is a
> library
> function. In gcc/builtin.defs, one finds
Not just that: SIN is a pure (or const, depending on -frounding-math)
function, which can be subject to CSE and DCE. I don't see anything
suggesting that for MATMUL in
Andreas Schwab wrote:
> Why is the libjava directory configured with raw_cxx?
>
> Makefile.def:151:target_modules = { module= libjava; raw_cxx=true; };
>
> The problem with this is that it keeps the libtool test for dynamic
> linker characteristics from working properly, due to the undefined
> re
Andreas Schwab wrote:
> Paolo Bonzini writes:
>
>> If it bothers you (does it cause a PR?),
>
> It causes a program to fail to run during build.
>
> ./gcj-dbtool -n classmap.db || touch classmap.db
> /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava
If it bothers you (does it cause a PR?),
>>> It causes a program to fail to run during build.
>>>
>>> ./gcj-dbtool -n classmap.db || touch classmap.db
>>> /usr/local/gcc/gcc-20081202/Build/powerpc64-suse-linux/libjava/.libs/gcj-dbtool:
>>> error while loading shared libraries: libgcj.so.10: c
Rafael Espindola wrote:
>>> git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
>> This will put the remote branch heads in refs/remotes, you might want to
>> put them in refs/remotes/origin instead.
>>
>> $ git config --add remote.origin.fetch
>> '+refs/remotes/*:refs/remotes/or
Rafael Espindola wrote:
>> Because the right one should have been
>>
>> $ git config --add remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
>>
>
> That is what "git clone" adds, but with that "git branch -r" will not
> list the remote branches.
Uhm, it does here (I don't have a GCC repo,
I have here an (attached) testcase which unexpectedly turns off
warnings. Compiling it using `gcc test.c -c -Wall` (or test.i) gives:
test.c: In function 'pam_sm_authenticate':
test.c:6: warning: implicit declaration of function 'undef'
>>> This works on the trunk but fail
> +AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
> + [if grep __emutls_get_address conftest.$ac_objext
> >/dev/null ; then
grepping in a binary file is not portable. If this works it would be
better:
AC_COMPILE_IFELSE([[__thread int a; int b;
ext
> Both are same.
Ah, I see, the call is optimized out because __emutls_get_address is
const. You can try
__thread int a;
int main () {
return *(int *)__emutls_get_address ((void *)0) == a;
}
I don't have an emutls target at hand, but it does fail on Linux.
Paolo
> Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report
> error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from
> Debian unstable. __emutls_get_address is defined in libgcc even the
> target has real TLS.
Uff... not my day. I used 4.2 (emutls was posted in 4.2 ti
>> But since you have to have a new gas anyway, wouldn't it be simpler to
>> have
>> a new option for gas to instruct it to choose the opcodes that are
>> expected
>> by the win32 applications?
> This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked
> it and prefered a funct
> movl.s %edi, %edi
> pushl %ebp
> movl.s %esp, %ebp
Have you thought about making .s an assembler command-line flag, so that
this flag could be passed automatically by the compiler under mingw?
Paolo
> For my purposes it is not really suitable, because we have to make sure that
> the push %ebp and mov %esp, %ebp are there, no matter what the compiler
> arguments are(-fomit-frame-pointer). So just adding the mov %edi, %edi isn't
> enough, and while I'm at it I can add the .s to the insns anyway.
>>
>> int *
>> x(void)
>> {
>> register int *a asm("unknown_register"); /* { dg-error "invalid register"
>> } */
>> int *v[1] = {a};
>> return v[1];
>> }
>>
>
> I think simply scalarizing for the above testcase
James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, wrote:
>> I was debugging a function and by inserting the debug statement crashed
>> the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
>> from sources) with -O2 under some circumstances assumes that if a pointer
>> i
>> However, -fno-delete-null-pointer-checks will do.
>
> Not for PTA though ;)
Care to expand?
Paolo
>>> Not for PTA though ;)
>> Care to expand?
>
> PTA tracks points-to-NULL as pointing to "nothing".
> This probably should be conditional on -fdelete-null-pointer-checks.
> Otherwise *NULL and *anything won't alias.
Yes, you're right. I'll see if I can construct a testcase and a patch.
BTW, I
Richard Guenther wrote:
> On Tue, Jan 27, 2009 at 11:35 AM, Paolo Bonzini wrote:
>>>>> Not for PTA though ;)
>>>> Care to expand?
>>> PTA tracks points-to-NULL as pointing to "nothing".
>>> This probably should be conditional on -fdel
401 - 500 of 1076 matches
Mail list logo
