Re: Archaeology time: Help me identify these ancient OSes and vendors
On 28 May 2024, at 14:35, Zack Weinberg wrote: > These are probably all either vendor or OS names from the late 1980s or > early 1990s. Can anyone help me fill out the following list of things > that ought to appear in testsuite/config-sub.data, if I knew what to > put in place of the question marks? > > ???-storm-chaos ???-???-??? I remember the storm-chaos port being added to binutils and/or GCC in around 2000 -- the name was fairly distinctive! A bit of spelunking leads to https://sourceware.org/pipermail/binutils/2000-November/007871.html https://sourceware.org/pipermail/binutils/2000-November/007873.html and thence to https://github.com/chaos4ever/chaos John
Archaeology time: Help me identify these ancient OSes and vendors
I've been trying to fill in as many gaps as possible in the config.sub test suite (and finding a whole bunch of actual bugs in the process). I have a short list of inputs where the actual code to handle them is incomplete or broken, there's nothing in config.guess to use as a clue, and I don't know what the correct canonical system name should be. gcc@ mailing list cc:ed because I know some of you have long memories. These are probably all either vendor or OS names from the late 1980s or early 1990s. Can anyone help me fill out the following list of things that ought to appear in testsuite/config-sub.data, if I knew what to put in place of the question marks? ???-pc533???-pc533-??? ???-sim ???-sim-??? ???-ultra???-ultra-??? ???-unicom ???-unicom-??? ???-acis ???-???-aos ???-triton ???-???-sysv3 ???-oss ???-???-sysv3 ???-storm-chaos ???-???-??? n.b. "storm-chaos" is extra troublesome because (a) it's too generic to search for, and (b) it's being treated as a $os value but it's got a dash in the middle, i.e. the code to handle it never got updated for four-part canonical system names. Thanks for any hints you can provide. zw
[Bug target/99548] Help me! Lost the fight against the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99548
--- Comment #3 from Andrew Pinski ---
#include
#include
#if defined(_MSC_VER)
#include
#elif defined(__x86_64__) || defined(__i386__)
#include
#endif
using field_number =
std::conditional_t=8,std::array,std::array>;
namespace intrinsics
{
template
#if __cpp_lib_concepts >= 202002L
requires (std::unsigned_integral)
#endif
inline constexpr bool sub_borrow(bool borrow,T a,T b,T& out) noexcept
{
#if defined(_MSC_VER) || defined(__x86_64__) || defined(__i386__)
#if __cpp_lib_is_constant_evaluated >= 201811L
if(std::is_constant_evaluated())
return (out=a-b-borrow)>=a;
else
#endif
{
if constexpr(sizeof(T)==8)
#if defined(__x86_64__)
return _subborrow_u64(borrow,a,b,
#if !defined(__INTEL_COMPILER ) &&(defined(__GNUC__) || defined(__clang__))
reinterpret_cast());
#else
);
#endif
#else
return (out=a-b-borrow)>=a;
#endif
if constexpr(sizeof(T)==4)
return
_subborrow_u32(borrow,a,b,reinterpret_cast());
else if constexpr(sizeof(T)==2)
return
_subborrow_u16(borrow,a,b,reinterpret_cast());
else if constexpr(sizeof(T)==1)
return
_subborrow_u8(borrow,a,b,reinterpret_cast());
}
#else
return (out=a-b-borrow)>=a;
#endif
}
}
template
#if __cpp_lib_concepts >= 202002L
requires (std::unsigned_integral)
#endif
inline constexpr bool add_carry(bool carry,T a,T b,T& out) noexcept
{
#if defined(_MSC_VER) || defined(__x86_64__) || defined(__i386__)
#if __cpp_lib_is_constant_evaluated >= 201811L
if(std::is_constant_evaluated())
return (out=a+b+carry)<=a;
else
#endif
{
if constexpr(sizeof(T)==8)
#if defined(__x86_64__)
return _addcarry_u64(carry,a,b,
#if !defined(__INTEL_COMPILER ) &&(defined(__GNUC__) || defined(__clang__))
reinterpret_cast());
#else
);
#endif
#else
return (out=a+b+carry)<=a;
#endif
else if constexpr(sizeof(T)==4)
return
_addcarry_u32(carry,a,b,reinterpret_cast());
else if constexpr(sizeof(T)==2)
return
_addcarry_u16(carry,a,b,reinterpret_cast());
else if constexpr(sizeof(T)==1)
return
_addcarry_u8(carry,a,b,reinterpret_cast());
}
#else
return (out=a+b+carry)<=a;
#endif
}
void my_asm_field_add(
std::uint64_t* __restrict r,
std::uint64_t const* __restrict x,
std::uint64_t const* __restrict y) noexcept
{
std::uint64_t r0,r1,r2,r3;
std::uint64_t rv;
__asm__ __volatile__(R"(mov (%[x]),%[r0]
add (%[y]),%[r0]
mov 8(%[x]),%[r1]
adc 8(%[y]),%[r1]
mov 16(%[x]),%[r2]
adc 16(%[y]),%[r2]
mov 24(%[x]),%[r3]
adc 24(%[y]),%[r3]
sbb %[rv],%[rv]
and $38,%[rv]
add %[rv],%[r0]
adc $0,%[r1]
adc $0,%[r2]
adc $0,%[r3]
sbb %[rv],%[rv]
and $38,%[rv]
add %[rv],%[r0]
mov %[r0],(%[res])
adc $0,%[r1]
mov %[r1],8(%[res])
adc $0,%[r2]
mov %[r2],16(%[res])
adc $0,%[r3]
mov %[r3],24(%[res]))":
[r0]"="(r0),[r1]"="(r1),[r2]"="(r2),[r3]"="(r3),[rv]"="(rv):
[x]"r"(x),[y]"r"(y),[res]"r"(r):"memory","cc");
}
void intrinsics_add(std::uint64_t* __restrict f,
std::uint64_t const* __restrict x,
std::uint64_t const* __restrict y) noexcept
{
using namespace intrinsics;
using unsigned_type = field_number::value_type;
constexpr unsigned_type zero{};
std::uint64_t f0,f1,f2,f3;
bool carry{add_carry(false,x[0],y[0],f0)};
carry=add_carry(carry,x[1],y[1],f1);
carry=add_carry(carry,x[2],y[2],f2);
carry=add_carry(carry,x[3],y[3],f3);
unsigned_type v=0;
sub_borrow(carry,v,v,v);
v&=static_cast(38);
carry=add_carry(false,f0,v,f0);
carry=add_carry(carry,f1,zero,f1);
carry=add_carry(carry,f2,zero,f2);
carry=add_carry(carry,f3,zero,f3);
sub_borrow(carry,v,v,v);
v&=static_cast(38);
carry=add_carry(false,f0,v,f[0]);
carry=add_carry(carry,f1,zero,f[1]);
carry=add_carry(carry,f2,zero,f[2]);
carry=add_carry(carry,f3,zero,f[3]);
}
Can someone help me understand cgraph_nodes & cgraph_edges during WPA
Hello, I've been working on an LTO points-to analysis pass for a little while. Because of LTO's design, gimple bodies are inaccessible during WPA. This essentially means that every LTO pass compiles down function bodies into their own IR which gets stored in function summaries and later read during WPA. This is also what I plan to do. I recently started looking into how IPA-CP works. I noticed that again, IPA-CP compiles down every function into its own function summary. However, while reading functions, it selectively decides which information to store by looking at symtab_node::prevailing_p. I was not aware of this function but from what I understand it is a way of deciding which symtab_node's bodies survive when removing duplicates before the execute stage of the pass. Is this correct? For IPA-CP, those cgraph_nodes for which the predicate symtab_node::prevailing_p are just read and discarded. This makes sense if it is a duplication of content. I know that different cgraph_nodes might represent the same function but maybe one of them has been specialized, another version has been inlined. I also think that two different cgraph_nodes might represent the same function implementation (i.e., they shared the same body and the same information but this information is duplicated during LGEN across partitions). I believe that it is not until the WPA/execute (making a distinction between WPA/execute and WPA/read_summary) that the distinct cgraph_nodes are merged. Would it be correct to say that a more faithful representation of reality is that non-prevailing_p nodes are eliminated while the other ones remain?) However, cgraph_nodes which represent the same function, but have been specialized will be marked as prevailing_p. Is this correct? (Here, I am not sure about the internals of the LTO, because in some sense, the points-to analysis hasn't run, but it is possible that other analysis have already run their WPA/execute stage and have said that some function bodies need to be specialized but at the moment they are still virtual clones? Related question, do virtual clones have cgraph_node?) I did a little experiment yesterday where I had the following control group: 1. encoded a cgraph_node during LGEN/write_summary 2. decoded a cgraph_node during WPA/read_summary and printed cnode->name () and compared it against the following experimental group: 1. encoded a cgraph_node during LGEN/write_summary 2. decoded a cgraph_node during WPA/read 3. during WPA/execute I printed cnode->name () What I found was that during the run of the "control group" I was able to print all cnodes' names. However, during the run of the "experimental group" only some of the names were printed before a segmentation fault occurred. Again, this might have been because those cgraph_node's were deleted. My theory is that these are non-prevailing_p cgraph_nodes but I haven't confirmed it experimentally, is this the case? I also do not know if all data being pointed to by these cgraph_node* is corrupted or if only some parts of the cgraph_node* have been removed from memory (like the name). Would cgraph_node* during WPA/execute in the experimental run have some valid fields or should it all be considered invalid and not even accessed outside of WPA/read? Looking at the definition of non-prevailing_p, it seems that all functions without a gimple body will be marked as non-prevailing_p. What does this mean though? There are definitely calls to external functions and so having a call to a non-prevailing_p just means that you are calling a function with no defined body. But what does that mean for functions that were "merged" or removed because they are duplicates? Can you have a cgraph_edge to a non-prevailing_p cgraph_node whose function body was once available at LGEN/lwrite but it is no longer available during WPA/execute? If that's the case how does one know the target of the call? Sorry if these are too many questions, I do greatly appreciate all the support given to me in the mailing list. In the meanwhile, I'll continue looking into how ipa-cp works to see what I can learn from other sources. Thanks -Erick
[Bug target/99548] Help me! Lost the fight against the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99548 --- Comment #2 from cqwrteur --- (In reply to Andrew Pinski from comment #1) > For aarch64 we get: > ldp x4, x3, [x1] > mov x7, 38 > ldp x6, x5, [x2] > ldr x8, [x1, 16] > add x6, x4, x6 > cmp x4, x6 > adc x5, x3, x5 > cmp x3, x5 > ldr x3, [x1, 24] > ldp x4, x1, [x2, 16] > adc x4, x8, x4 > cmp x8, x4 > adc x1, x3, x1 > cmp x3, x1 > csetm x2, cs > and x2, x2, x7 > add x2, x2, x6 > cmp x2, x6 > cincx6, x5, ls > cmp x6, x5 > cincx5, x4, ls > cmp x5, x4 > cincx3, x1, ls > cmp x3, x1 > csetm x1, ls > and x1, x1, x7 > add x1, x1, x2 > str x1, [x0] > cmp x1, x2 > cincx1, x6, ls > str x1, [x0, 8] > cmp x1, x6 > cincx1, x5, ls > cmp x1, x5 > cincx3, x3, ls > stp x1, x3, [x0, 16] > ret > There is only one missing optimization there really: > csetm x1, ls > and x1, x1, x7 > Should be turned into: > csel x1, x7, xzw, ls > Which is repeated a few times. > > It looks like x86_64 has other issues. my add carry implementation for none-x86_64 platforms is wrong on godbolt.
[Bug target/99548] Help me! Lost the fight against the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99548 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target --- Comment #1 from Andrew Pinski --- For aarch64 we get: ldp x4, x3, [x1] mov x7, 38 ldp x6, x5, [x2] ldr x8, [x1, 16] add x6, x4, x6 cmp x4, x6 adc x5, x3, x5 cmp x3, x5 ldr x3, [x1, 24] ldp x4, x1, [x2, 16] adc x4, x8, x4 cmp x8, x4 adc x1, x3, x1 cmp x3, x1 csetm x2, cs and x2, x2, x7 add x2, x2, x6 cmp x2, x6 cincx6, x5, ls cmp x6, x5 cincx5, x4, ls cmp x5, x4 cincx3, x1, ls cmp x3, x1 csetm x1, ls and x1, x1, x7 add x1, x1, x2 str x1, [x0] cmp x1, x2 cincx1, x6, ls str x1, [x0, 8] cmp x1, x6 cincx1, x5, ls cmp x1, x5 cincx3, x3, ls stp x1, x3, [x0, 16] ret There is only one missing optimization there really: csetm x1, ls and x1, x1, x7 Should be turned into: csel x1, x7, xzw, ls Which is repeated a few times. It looks like x86_64 has other issues.
[Bug rtl-optimization/99548] New: Help me! Lost the fight against the compiler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99548 Bug ID: 99548 Summary: Help me! Lost the fight against the compiler. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- https://godbolt.org/z/Kd8q57 The compiler just could not generate as good as assembly as I manually wrote. Unfortunately, due to the calling convention issues, the inline asm version would never be portable and hurt other compiler optimizations. Some patterns like neither GCC nor clang could correctly deal with it. std::uint64_t v=0;//set 0 to make compiler happy or it is UB. sub_borrow(carry,v,v,v); movl$0, %eax movq%rax, %rdx sbbq%rax, %rdx What the code actually want is to sbb %rdx,%rdx Which is to set the register to the UINT64_MAX when carry (borrow) flag is 1. movq(%rdx), %rcx movq8(%rsi), %r9 addq(%rsi), %rcx movq16(%rsi), %r8 movq24(%rdx), %rax adcq8(%rdx), %r9 movq24(%rsi), %rsi adcq16(%rdx), %r8 adcq%rax, %rsi movl$0, %eax Do we have any possibility to fix those optimization issues in the compiler?
Re: Please help me understand & patch GCC re. "gcc -L/usr/lib -lz" problem, also "-nostdlib"
Hi Jonathan,
Thank you very much for your response.
Since the previous email I have had more correspondence with Marc at
the OpenBSD misc mailing list.
He clarified that the reason the -L/usr/lib prefix was added, was
"because of ld.ldd, the linker from clang. see, that one does not link
with /usr/lib by default, which tends to break everything.",
apparently.
I asked him if it would not be better if GCC (both OS-bundled and port)
would locate the -L/usr/lib to the trailing position just like clang
does on OpenBSD and GCC does on all other platforms, and he responded:
> I have zero idea how to do that purely in specs. Have fun tinkering.
>
> This is probably something we'll adopt but low priority.
(https://marc.info/?l=openbsd-misc=161479588215993=2)
On my part, I have zero idea how to do this in GCC spec syntax too.
On Wednesday, 3 March 2021 14:16, Jonathan Wakely wrote:
> On Wed, 3 Mar 2021 at 12:35, Bob via Gcc gcc@gcc.gnu.org wrote:
..
> > Here is to trig the behavior on OpenBSD:
..
> > As you see here my "-LMYDIRTEST" comes after -L/usr/lib .
> > Normally on any Unix the -L/usr/lib is appended to the end of LD's
> > arguments, is it not - can you please confirm?
> > (This question affects why OpenBSD added a custom behavior.)
> > Second, a GCC patching question, your help to figure would be much
> > appreciated: OpenBSD's patchset to GCC v8 is in the patches
> > subdirectory here:
> > https://cvsweb.openbsd.org/ports/lang/gcc/8/
> > As I get it, GCC's default behavior is to put -L/usr/dir in the
> > trailing position, so one of these patches must modify GCC to put
> > it in the leading position instead. Can you tell me which line in which
> > patch file it is that has this effect?
>
> It's done in several different files, one for each supported arch.
> You've already found where it's done for x86:
> https://cvsweb.openbsd.org/ports/lang/gcc/8/patches/patch-gcc_config_i386_openbsdelf_h
>
> The latest version has been fixed (as you say below) but the previous
> version added -L/usr/lib unconditionally. That LINK_SPEC is the first
> group of options passed to the linker. If -L/usr/lib is added to
> LINK_SPEC then it comes before any other -L options. In other words,
> there's no patch to say "put -L/usr/lib first instead of last"
> there's just a patch that puts it first.
>
> That's not how other targets do it, which is why -L/usr/lib doesn't
> come first for other targets, only for OpenBSD.
Can you please clarify what needs to be changed exactly on OpenBSD,
for the -L/usr/lib to come last instead of first?
Per what Marc said above here, your clarification should be
incorporated to become OpenBSD default configuration.
> > Last for completeness a discussion of GCC's "-nostdlib" argument:
..
> > -L/usr/lib . However, there is no TRAILING -L/usr/lib so that one needs
> > to be added manually.
>
> Of course. Because when you use -nostdlib ALL libraries and library
> paths need to be added manually. That's what it means.
For my situation, -nostdlib is overkill is it not?
> > And, especially, -nostdlib has a handful
> > other effects which I don't understand and which are not really
> > discussed anywhere, as I get it:
>
> They're discussed in the manual.
(Unimportantly but anyhow, I see no complete list of GCC arguments
that would need to be added, to reverse -nostdlib .)
> > Grepping GCC's code for nostdlib gives me this:
..
> > of special GCC-internal language with its own syntax. Is this called
> > "GCC spec file" syntax?
>
> Yes, documented athttps://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
>
> > The patch I referenced above, modifies
> > patches/patch-gcc_config_i386_openbsdelf_h 's line 11
> > from " + -L/usr/lib\"" to "%{!nostdlib:-L/usr/lib}\"", again the
> > same syntax language.
>
> That means that -L/usr/lib is only added when -nostdlib is not used.
Right.
> > Someone's discussion on what -nostdlib actually does, would be great
> > for the purpose of GCC documentation, the current description at
> > https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html is too brief.
>
> I don't see why it's too brief. It's quite accurate.
>
> The option means that GCC won't tell the linker to use any of the
> default libraries and library paths (which you can see by adding -v to
> the gcc command you use to link). That's accurate.
-nostdlib has no more effect than that? So it's about linking back
the C/C++ library and adding -L paths for GCC to find them. What about
crtbegin/end.o such?
Bob
Re: Please help me understand & patch GCC re. "gcc -L/usr/lib -lz" problem, also "-nostdlib"
On Wed, 3 Mar 2021 at 12:35, Bob via Gcc wrote:
>
> Hi GCC users mailing list,
>
> I am currently figuring out a GCC usecase on OpenBSD. This situation
> involves some non-superficial understanding of GCC's code, and
> therefore I wish to query you here even in the situation that it turns
> out not to be needed.
>
> I describe my problem here:
> https://marc.info/?l=openbsd-misc=161472828522043=2
>
> In summary my problem is that on OpenBSD, GCC will prepend to LD's
> arguments "-L/usr/lib", which means that "-lz" NEVER will take my
> local custom-built libz.so (which is what I want GCC/LD to do), but
> instead always will take the OS-bundled libz.so which is in
> /usr/lib/ , which is what I don't want.
>
> In practice this means that I can't make a custom software build in
> my home directory, that uses a custom libz (or any other .so whose
> name also exists in /usr/lib), and I guess this also disturbs the
> ability to do cross-platform builds. What I described now is a veru
> normal usecase isn't it?
>
>
> Here is to trig the behavior on OpenBSD:
>
> $ echo "int main(){}">t.c; gcc -c -o t.o t.c; gcc -o t t.o -LMYDIRTEST -Wl,-v
> collect2 version 4.2.1 20070719 (OpenBSD/x86-64 ELF)
> /usr/bin/ld --eh-frame-hdr -e __start -Bdynamic -dynamic-linker
> /usr/libexec/ld.so \
> -L/usr/lib -o t /usr/lib/crt0.o /usr/lib/crtbegin.o -LMYDIRTEST \
> -L/usr/lib/gcc-lib/amd64-unknown-openbsd6.7/4.2.1 t.o -v -lgcc -lc -lgcc \
> /usr/lib/crtend.o LLD 8.0.1 (compatible with GNU linkers)
>
> As you see here my "-LMYDIRTEST" comes after -L/usr/lib .
>
> Normally on any Unix the -L/usr/lib is *appended to the end* of LD's
> arguments, is it not - can you please confirm?
>
> (This question affects why OpenBSD added a custom behavior.)
>
>
> Second, a GCC patching question, your help to figure would be much
> appreciated: OpenBSD's patchset to GCC v8 is in the patches
> subdirectory here:
>
> https://cvsweb.openbsd.org/ports/lang/gcc/8/
>
> As I get it, GCC's default behavior is to put -L/usr/dir in the
> trailing position, so one of these patches must modify GCC to put
> it in the leading position instead. Can you tell me which line in which
> patch file it is that has this effect?
It's done in several different files, one for each supported arch.
You've already found where it's done for x86:
https://cvsweb.openbsd.org/ports/lang/gcc/8/patches/patch-gcc_config_i386_openbsdelf_h
The latest version has been fixed (as you say below) but the previous
version added -L/usr/lib unconditionally. That LINK_SPEC is the first
group of options passed to the linker. If -L/usr/lib is added to
LINK_SPEC then it comes before any other -L options. In other words,
there's no patch to say "put -L/usr/lib first **instead** of last"
there's just a patch that puts it first.
That's not how other targets do it, which is why -L/usr/lib doesn't
come first for other targets, only for OpenBSD.
> (This way if I remove that line / file, GCC should behave the same as
> on other platforms and my problem would be solved.)
>
>
> Last for completeness a discussion of GCC's "-nostdlib" argument:
>
> I figure that the since this very recent patch
>
> https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/8/patches/patch-gcc_config_i386_openbsdelf_h.diff?r1=1.3=1.4=h
>
> , the GCC command line argument "-nostdlib" offers partial help, in
> the form that adding it causes the *removal* of the leading
> -L/usr/lib . However, there is no TRAILING -L/usr/lib so that one needs
> to be added manually.
Of course. Because when you use -nostdlib ALL libraries and library
paths need to be added manually. That's what it means.
> And, especially, -nostdlib has a handful
> other effects which I don't understand and which are not really
> discussed anywhere, as I get it:
They're discussed in the manual.
> Grepping GCC's code for nostdlib gives me this:
>
> gcc/cp/g++spec.c: case OPT_nostdlib:
> gcc/gcc.c:
> %{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}} \
> gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):"
> LIBASAN_EARLY_SPEC "} \
> gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):" LIBASAN_SPEC "\
> gcc/gcc.c:%{!nostdlib:%{fvtable-verify=std: -lvtv -u_vtable_map_vars_start
> -u_vtable_map_vars_end}\
> gcc/gcc.c:%{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}} \
> gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%(link_ssp)
> %(link_gcc_c_sequence)}}\
> gcc/gcc.c:%{!nostdlib:%{!nostartfiles:%E}} %{T*} \n%(post_link) }}"
>
> As you see the nostdlib logics are not in C/C++ code, but in some kind
> of special GCC-internal language with its own syntax. Is this called
> "GCC spec file" syntax?
Yes, documented at https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html
> The patch I referenced above, modifies
> patches/patch-gcc_config_i386_openbsdelf_h 's line 11
> from " + -L/usr/lib\"" to "%{!nostdlib:-L/usr/lib}\"", again the
> same syntax language.
That means that -L/usr/lib is
Please help me understand & patch GCC re. "gcc -L/usr/lib -lz" problem, also "-nostdlib"
Hi GCC users mailing list,
I am currently figuring out a GCC usecase on OpenBSD. This situation
involves some non-superficial understanding of GCC's code, and
therefore I wish to query you here even in the situation that it turns
out not to be needed.
I describe my problem here:
https://marc.info/?l=openbsd-misc=161472828522043=2
In summary my problem is that on OpenBSD, GCC will prepend to LD's
arguments "-L/usr/lib", which means that "-lz" NEVER will take my
local custom-built libz.so (which is what I want GCC/LD to do), but
instead always will take the OS-bundled libz.so which is in
/usr/lib/ , which is what I don't want.
In practice this means that I can't make a custom software build in
my home directory, that uses a custom libz (or any other .so whose
name also exists in /usr/lib), and I guess this also disturbs the
ability to do cross-platform builds. What I described now is a veru
normal usecase isn't it?
Here is to trig the behavior on OpenBSD:
$ echo "int main(){}">t.c; gcc -c -o t.o t.c; gcc -o t t.o -LMYDIRTEST -Wl,-v
collect2 version 4.2.1 20070719 (OpenBSD/x86-64 ELF)
/usr/bin/ld --eh-frame-hdr -e __start -Bdynamic -dynamic-linker
/usr/libexec/ld.so \
-L/usr/lib -o t /usr/lib/crt0.o /usr/lib/crtbegin.o -LMYDIRTEST \
-L/usr/lib/gcc-lib/amd64-unknown-openbsd6.7/4.2.1 t.o -v -lgcc -lc -lgcc \
/usr/lib/crtend.o LLD 8.0.1 (compatible with GNU linkers)
As you see here my "-LMYDIRTEST" comes after -L/usr/lib .
Normally on any Unix the -L/usr/lib is *appended to the end* of LD's
arguments, is it not - can you please confirm?
(This question affects why OpenBSD added a custom behavior.)
Second, a GCC patching question, your help to figure would be much
appreciated: OpenBSD's patchset to GCC v8 is in the patches
subdirectory here:
https://cvsweb.openbsd.org/ports/lang/gcc/8/
As I get it, GCC's default behavior is to put -L/usr/dir in the
trailing position, so one of these patches must modify GCC to put
it in the leading position instead. Can you tell me which line in which
patch file it is that has this effect?
(This way if I remove that line / file, GCC should behave the same as
on other platforms and my problem would be solved.)
Last for completeness a discussion of GCC's "-nostdlib" argument:
I figure that the since this very recent patch
https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/lang/gcc/8/patches/patch-gcc_config_i386_openbsdelf_h.diff?r1=1.3=1.4=h
, the GCC command line argument "-nostdlib" offers partial help, in
the form that adding it causes the *removal* of the leading
-L/usr/lib . However, there is no TRAILING -L/usr/lib so that one needs
to be added manually. And, especially, -nostdlib has a handful
other effects which I don't understand and which are not really
discussed anywhere, as I get it:
Grepping GCC's code for nostdlib gives me this:
gcc/cp/g++spec.c: case OPT_nostdlib:
gcc/gcc.c:
%{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}} \
gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):"
LIBASAN_EARLY_SPEC "} \
gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%{%:sanitize(address):" LIBASAN_SPEC "\
gcc/gcc.c:%{!nostdlib:%{fvtable-verify=std: -lvtv -u_vtable_map_vars_start
-u_vtable_map_vars_end}\
gcc/gcc.c:%{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!nostartfiles:%S}} \
gcc/gcc.c:%{!nostdlib:%{!nodefaultlibs:%(link_ssp) %(link_gcc_c_sequence)}}\
gcc/gcc.c:%{!nostdlib:%{!nostartfiles:%E}} %{T*} \n%(post_link) }}"
As you see the nostdlib logics are not in C/C++ code, but in some kind
of special GCC-internal language with its own syntax. Is this called
"GCC spec file" syntax?
The patch I referenced above, modifies
patches/patch-gcc_config_i386_openbsdelf_h 's line 11
from " + -L/usr/lib\"" to "%{!nostdlib:-L/usr/lib}\"", again the
same syntax language.
Someone's discussion on what -nostdlib actually does, would be great
for the purpose of GCC documentation, the current description at
https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html is too brief.
I'll wait for the OpenBSD mailing list to respond too. Any thoughts
much appreciated.
Bob
Re: Please help me to review the patch about improve cse optimization for insn with inout ops
On 3/23/19 11:46 AM, 钟云德 wrote: > hi, all >I am a new guy work on this GCC Bugzilla, and need some help to review > patch detailed showed on > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83855, thanks! > I'd need to see the machine description you're working with. It may be better to avoid match_dup and instead use a matching constraint. The latter will give the majority of RTL passes more freedom to optimize and the register allocator & reloader will handle forming 2-operand formats (assuming this is what you're trying to accomplish). jeff
Re: Please help me to review the patch about improve cse optimization for insn with inout ops
On 3/23/19 11:46 AM, 钟云德 wrote: > hi, all >I am a new guy work on this GCC Bugzilla, and need some help to review > patch detailed showed on > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83855, thanks! > Also note we're in regression bugfix state only right now in preparation for gcc-9. From my quick look, this BZ wouldn't qualify. Jeff
Please help me to review the patch about improve cse optimization for insn with inout ops
hi, all I am a new guy work on this GCC Bugzilla, and need some help to review patch detailed showed on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83855, thanks!
help me
hi list
I need help
I make Dynamic-link library in c
I want link it from a C++
I Create .h file like this
#ifdef __cplusplus
extern C { // only need to export C interface if
// used by C++ source code
#endif
__declspec( dllimport ) static void flood_loop(MAP *map, int x,
int y, unsigned int dst_c, unsigned int
src_c);
#ifdef __cplusplus
}
#endif
but cannot work
--
Think not of them, thou hast thy music too
#include stdio.h
#include stdlib.h
#include limits.h
#include stddef.h
#define BOARD_WIDTH 10
#define BOARD_HEIGHT 20
typedef struct MAP
{
unsigned char b[BOARD_HEIGHT][BOARD_WIDTH];
} MAP;
static void flood_loop(MAP *map, int x, int y,
unsigned int dst_c, unsigned int src_c)
{
int fillL, fillR, i;
int in_line = 1;
//unsigned char c = src_c, fillC = dst_c;
/* find left side, filling along the way */
fillL = fillR = x;
while( in_line )
{
map-b[y][fillL] = dst_c;
fillL--;
in_line = (fillL 0) ? 0 : (map-b[y][fillL] == src_c);
}
fillL++;
/* find right side, filling along the way */
in_line = 1;
while( in_line )
{
map-b[y][fillR] = dst_c;
fillR++;
in_line = (fillR BOARD_WIDTH-1) ? 0 : (map-b[y][fillR] == src_c);
}
fillR--;
/* search top and bottom */
for(i = fillL; i = fillR; i++)
{
if( y 0 map-b[y - 1][i] == src_c )
flood_loop(map, i, y - 1, dst_c, src_c);
if( y BOARD_HEIGHT-1 map-b[y + 1][i] == src_c )
flood_loop(map, i, y + 1, dst_c, src_c);
}
}
void flood_fill(MAP *map, int x, int y, unsigned int c)
{
flood_loop(map, x, y, c, map-b[y][x]);
map-b[y][x] = c; /* some buggy optimizers needed this line */
}
char Taq(char* number)
{
const char taqDhmd111rr[]=
03175986427092154863420687135917509834266123045978
36742095815869720134894536201794386172052581436790;
char interim='0';
char* p;
for(p=number;*p!='\0';++p){
if((unsigned char)(*p-'0')9)
return '-'; //minus sign indicates an error: character is not a digit
interim=taqDhmd111rr[(*p-'0')+(interim-'0')*10];
}
return interim;
}
char CalculateCheckDigit(char* numberWithoutCheckDigit)
{
return Taq(numberWithoutCheckDigit);
}
typedef int BOOL;
BOOL IsCheckDigitValid(char* numberWithCheckDigit)
{
return Taq(numberWithCheckDigit)=='0';
}
int kmp_search(char W[], char S[])
{
int t[5];
int m = 0;
int i = 0;
while (S[m + i] != '\0' W[i] != '\0') {
if (S[m + i] == W[i]) {
++i;
} else {
m += i - t[i];
if (i 0) i = t[i];
}
}
if (W[i] == '\0') {
return m;
} else {
return m + i;
}
}
void selection_sort (int *a, int n) {
int i, j, m, t;
for (i = 0; i n; i++) {
for (j = i, m = i; j n; j++) {
if (a[j] a[m])
m = j;
}
t = a[i];
a[i] = a[m];
a[m] = t;
}
}
void shell_sort (int *a, int n) {
int h, i, j, k;
for (h = n; h /= 2;) {
for (i = h; i n; i++) {
k = a[i];
for (j = i; j = h k a[j - h]; j -= h) {
a[j] = a[j - h];
}
a[j] = k;
}
}
}
static void insertion_sort(int *a, const size_t n) {
size_t i, j;
int value;
for (i = 1; i n; i++) {
value = a[i];
for (j = i; j 0 value a[j - 1]; j--) {
a[j] = a[j - 1];
}
a[j] = value;
}
}
void gnome_sort(int *a, int n)
{
int i=1, j=2, t;
# define swap(i, j) { t = a[i]; a[i] = a[j]; a[j] = t; }
while(i n) {
if (a[i - 1] a[i]) {
swap(i - 1, i);
if (--i) continue;
}
i = j++;
}
# undef swap
}
#define try_swap { if (aa[ii] aa[ii - 1])\
{ tt = aa[ii]; aa[ii] = aa[ii - 1]; aa[ii - 1] = tt; tt = 0;} }
void cocktailsort(int *aa, size_t len)
{
size_t ii;
int tt = 0;
while (!tt) {
for (ii = 1, tt = 1; ii len; ii++) try_swap;
if (tt) break;
for (ii = len - 1, tt = 1; ii; ii--) try_swap;
}
}
void bubble_sort(int *a, int n) {
int j, t = 1;
while (n-- t)
for (j = t = 0; j n; j++) {
if (a[j] = a[j + 1]) continue;
t = a[j], a[j] = a[j + 1], a[j + 1] = t;
t=1;
}
}
void quick_sort (int *a, int n) {
if (n 2)
return;
int p = a[n / 2];
int *l = a;
int *r = a + n - 1;
while (l = r) {
if (*l p) {
l++;
continue;
}
if (*r p) {
r--;
continue; // we need to check the condition (l = r) every time we change the value of l or r
}
int t = *l;
*l++ = *r;
*r-- = t;
}
quick_sort(a, r - a + 1);
quick_sort(l, a + n - l);
}
void bead_sort(int *a, int len)
{
int i, j, max, sum;
unsigned char *beads;
#define BEAD(i, j) beads[i * max + j]
for (i = 1, max = a[0]; i len; i++)
Re: help me
On 18 March 2014 17:35, Ali Abdul Ghani wrote: hi list I need help This is the wrong list for user support, please use the gcc-help mailing list instead. You will probably want to provide more information that but cannot work if you expect anyone to be able to help.
Re: Can Some one please help me on this gcc plugin..
Hi David,
I am very much thankful to you as your answer worked wonders for me.
The problem with the plugin is solved now. Thanks again.
On 3/5/14, David Malcolm dmalc...@redhat.com wrote:
On Wed, 2014-03-05 at 21:58 +0530, Mohsin Khan wrote:
Hi,
I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
I wrote a plugin and tried to count and see the Goto Statements using
the gimple_stmt_iterator. I get gimple statements printed on my
stdout, but I am not able to find the line which has goto statements.
I only get other lines such as variable declaration and logic
statements, but no goto statements.
When I open the Gimple/SSA/CFG file seperately using the vim editor
I find the goto statements are actually present.
So, can anyone help me. How can I actually get the count of Goto
statements or atleast access these goto statements using some
iterator.
I have used -fdump-tree-all, -fdump-tree-cfg as flags.
Here is the pseudocode:
struct register_pass_info pass_info = {
(pass_plugin.pass), /* Address of new pass,
here, the 'struct
opt_pass' field of
'gimple_opt_pass'
defined above */
ssa, /* Name of the reference
pass for hooking up
the new pass. ??? */
0, /* Insert the pass at the
specified instance
number of the reference
pass. Do it for
every instance if it is 0.
*/
PASS_POS_INSERT_AFTER/* how to insert the new
pass: before,
You're inserting your pass after the ssa pass, which converts the CFG
to SSA form. This is run *after* the function has been converted from a
flat list of gimple statements into a CFG of basic blocks, and that CFG
conversion eliminates the goto statements in favor of edges within the
CFG. If you see goto in the dump, that's presumably just a textual
way of expressing an edge in the CFG.
To see gimple goto statements, you need to run your pass *before* the
convertion to CFG, which happens fairly early on, in the cfg pass
FWIW there's a diagram showing the passes here:
http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
Hope this is helpful
Dave
Regards
Mohsin Khan
Can Some one please help me on this gcc plugin..
Hi,
I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
I wrote a plugin and tried to count and see the Goto Statements using
the gimple_stmt_iterator. I get gimple statements printed on my
stdout, but I am not able to find the line which has goto statements.
I only get other lines such as variable declaration and logic
statements, but no goto statements.
When I open the Gimple/SSA/CFG file seperately using the vim editor
I find the goto statements are actually present.
So, can anyone help me. How can I actually get the count of Goto
statements or atleast access these goto statements using some
iterator.
I have used -fdump-tree-all, -fdump-tree-cfg as flags.
Here is the pseudocode:
struct register_pass_info pass_info = {
(pass_plugin.pass), /* Address of new pass,
here, the 'struct
opt_pass' field of
'gimple_opt_pass'
defined above */
ssa, /* Name of the reference
pass for hooking up
the new pass. ??? */
0, /* Insert the pass at the
specified instance
number of the reference
pass. Do it for
every instance if it is 0. */
PASS_POS_INSERT_AFTER/* how to insert the new
pass: before,
after, or replace. Here
we are inserting
a pass names 'plug' after
the pass named
'pta' */
};
.
static unsigned int dead_code_elimination (void)
{
FOR_EACH_BB_FN (bb, cfun)
{
// gimple_dump_bb(stdout,bb,0,0);
//printf(\nIn New BB);
gsi2= gsi_after_labels (bb);
print_gimple_stmt(stdout,gsi_stmt(gsi2),0,0);
/*Iterating over each gimple statement in a basic block*/
for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next (gsi))
{
g = gsi_stmt(gsi);
print_gimple_stmt(stdout,g,0,0);
if (gimple_code(g)==GIMPLE_GOTO)
printf(\nFound GOTO stmt\n);
print_gimple_stmt(stdout,gsi_stmt(gsi),0,0);
//analyze_gimple_statement (gsi);
}
}
}
Re: Can Some one please help me on this gcc plugin..
On Wed, 2014-03-05 at 21:58 +0530, Mohsin Khan wrote:
Hi,
I am developing plugins for the GCC-4.8.2. I am a newbie in plugins.
I wrote a plugin and tried to count and see the Goto Statements using
the gimple_stmt_iterator. I get gimple statements printed on my
stdout, but I am not able to find the line which has goto statements.
I only get other lines such as variable declaration and logic
statements, but no goto statements.
When I open the Gimple/SSA/CFG file seperately using the vim editor
I find the goto statements are actually present.
So, can anyone help me. How can I actually get the count of Goto
statements or atleast access these goto statements using some
iterator.
I have used -fdump-tree-all, -fdump-tree-cfg as flags.
Here is the pseudocode:
struct register_pass_info pass_info = {
(pass_plugin.pass), /* Address of new pass,
here, the 'struct
opt_pass' field of
'gimple_opt_pass'
defined above */
ssa, /* Name of the reference
pass for hooking up
the new pass. ??? */
0, /* Insert the pass at the
specified instance
number of the reference
pass. Do it for
every instance if it is 0. */
PASS_POS_INSERT_AFTER/* how to insert the new
pass: before,
You're inserting your pass after the ssa pass, which converts the CFG
to SSA form. This is run *after* the function has been converted from a
flat list of gimple statements into a CFG of basic blocks, and that CFG
conversion eliminates the goto statements in favor of edges within the
CFG. If you see goto in the dump, that's presumably just a textual
way of expressing an edge in the CFG.
To see gimple goto statements, you need to run your pass *before* the
convertion to CFG, which happens fairly early on, in the cfg pass
FWIW there's a diagram showing the passes here:
http://gcc-python-plugin.readthedocs.org/en/latest/tables-of-passes.html
Hope this is helpful
Dave
please help me
hi everybody, I want to analyse the gcc source code. i have code but i am not getting it. So please help me by providing any documentation for the code or with any suggetions -- View this message in context: http://old.nabble.com/please-help-me-tp27604613p27604613.html Sent from the gcc - bugs mailing list archive at Nabble.com.
Please help me test the power7-meissner branch before I submit the changes
The power7 stuff should be fairly stable at this point, and I feel it is time to submit it to the mainline GCC. If other powerpc users can try out the branch to see if there are regressions, it would be helpful. Note with the recent gimple type validation errors, the mainline now has more failures than it had previously, so be sure to compare it to the mainline branch of the same vintage (the branch is currently syned to svn version 147021). I have fixed some of the vectorizer failures in this branch, but there are still failures for both mainline and this branch. In particular, I would like to know if I caused any regressions in the embedded powerpc (spe, e500, etc.). Some of the E500/SPE stuff would fit in with the abstractions I put in for distinguishing between altivec and vsx. The branch is at: svn+ssh://@gcc.gnu.org/svn/gcc/branches/ibm/power7-meissner Thanks in advance. -- Michael Meissner, IBM 4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA meiss...@linux.vnet.ibm.com
Re: Help me with the patterns
On Thu, Apr 24, 2008 at 12:01 PM, Mohamed Shafi [EMAIL PROTECTED] wrote:
Hello all,
The target that i am porting in gcc 4.1.2, has the following instructions
setb Rx, bitno
clrb Rx, bitno
where bit bitno of Rx will either be set or reset.
For statements like
a |= (1 2); and
b = ~(1 2);
I can use the above instructions directly. But i am not sure how to
write the patterns for the above instructions.
Can anybody help me with this?
What i have done is to have the following pattern
(define_insn setbhi3
[(set (match_operand:HI 0 register_operand =r)
(ior:HI (match_operand:HI 1 register_operand %0)
(match_operand:HI 2 setclrb_operand I)))]
setb\\t%0, %2
)
where setclrb_operand is
(define_predicate setclrb_operand
(match_code const_int)
{
if (CONSTANT_P (op))
{
if (INTVAL(op) !(INTVAL(op) (INTVAL(op) - 1)))
if (INTVAL(op) BITS_PER_WORD)
return 1;
}
return 0;
})
I am now able to generate the instruction.
Is this OK?
Thank you for your time.
Regards,
Shafi.
Help me with the patterns
Hello all, The target that i am porting in gcc 4.1.2, has the following instructions setb Rx, bitno clrb Rx, bitno where bit bitno of Rx will either be set or reset. For statements like a |= (1 2); and b = ~(1 2); I can use the above instructions directly. But i am not sure how to write the patterns for the above instructions. Can anybody help me with this? Thank you for your time. Regards, Shafi.
[Bug java/34201] Help me with gcj options
--- Comment #1 from tromey at gcc dot gnu dot org 2007-11-23 21:39 --- Please read the documentation and other info on the web site. Then, if you still can't make it work, post specific questions, along with what you tried, what platform you are using, and what the results were, to the gcj list. Thanks. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34201
[Bug java/34201] New: Help me with gcj options
I have two differences pakages name org.math.tool and org.gui.maintennance contain java files, I want to compile these files to bin folder and create exe file name Demo.exe, my main class is org.gui.maintenance.BeautifulLife.class I don't know how to solve this problem, I tryed to solve it but impossible. Please help me ! Thanks in advance ! [EMAIL PROTECTED] -- Summary: Help me with gcj options Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pmdatok at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34201
Re: it'urgent please help me!!!!!!!!!!!!!!!!!!!!!!!!!!!!
sameer sinha [EMAIL PROTECTED] writes: Please can any one tell me how to bulid gcc newer version for generating code for i960MC processor. is there any switch to generate coed for i960MC or i will have to build it first for target i960. Right now i am using Linux i686.Pleasee help me. And also tell me whether it's possible to generate i960Mc code for language Ada95 or it is only possible for language C ??? This question would be more appropriate for the [EMAIL PROTECTED] mailing list than for the gcc mailing list. The gcc mailing list is for gcc developers. Unfortunately support for the Intel i960 was dropped in gcc 4.0. There is no way to generate i960 code with a recent gcc release. Ian
Re: it'urgent please help me!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Ian Lance Taylor wrote: Unfortunately support for the Intel i960 was dropped in gcc 4.0. There is no way to generate i960 code with a recent gcc release. which means that GNAT is also unavailable at this stage.
it'urgent please help me!!!!!!!!!!!!!!!!!!!!!!!!!!!!
hello, Please can any one tell me how to bulid gcc newer version for generating code for i960MC processor. is there any switch to generate coed for i960MC or i will have to build it first for target i960. Right now i am using Linux i686.Pleasee help me. And also tell me whether it's possible to generate i960Mc code for language Ada95 or it is only possible for language C ???
Re: Help me about C language Specification
On Apr 13, 2005, at 1:30 AM, thanh tuan wrote: I am a student, and I am studying to build an ANSI C compiler into ASM. I know, you can download gcc and then do configure make CFLAGS=- save-temps. This will give you asm for an ANSI C compiler. :-) [ wrong list, please use gcc-help instead. ]
Can You Help Me
I'm looking for the VP/Director of Customer Care and/or Data Services. Can you let me know who this is and how I would contact them. Thank you in advance, Helen
