Re: Android native build of GCC
On Thu, 8 Jan 2015, Andrew Haley wrote: > Android native GCC can't support LTO because of a lack of support for > dlopen() in the C library. How should we patch the configury to disable > LTO by default? Doesn't setting unsupported_languages in toplevel configure.ac work for you? brgds, H-P
Re: Android native build of GCC
On 06/02/15 08:00, Hans-Peter Nilsson wrote: > On Thu, 8 Jan 2015, Andrew Haley wrote: >> Android native GCC can't support LTO because of a lack of support for >> dlopen() in the C library. How should we patch the configury to disable >> LTO by default? > > Doesn't setting unsupported_languages in toplevel configure.ac > work for you? I'm sorry, I don't understand this comment. Andrew.
Re: Android native build of GCC
On Fri, 6 Feb 2015, Andrew Haley wrote: > On 06/02/15 08:00, Hans-Peter Nilsson wrote: > > On Thu, 8 Jan 2015, Andrew Haley wrote: > >> Android native GCC can't support LTO because of a lack of support for > >> dlopen() in the C library. How should we patch the configury to disable > >> LTO by default? > > > > Doesn't setting unsupported_languages in toplevel configure.ac > > work for you? > > I'm sorry, I don't understand this comment. Not sure what's not understood. IIUC you want to disable LTO when building gcc natively on Android? As LTO is considered a "language", disabling it by means of the support for targets or hosts to disable languages (by setting the shell variable unsupported_languages) seemed to make sense...though looking closer, I see the language configury is slightly fudged and needs some code moving to fix that, as e.g. lto-plugin conditionals and special lto handling have snuck in before the unsupported_languages processing. Bah. Never mind. brgds, H-P
Re: Android native build of GCC
On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote: > On Fri, 6 Feb 2015, Andrew Haley wrote: >> On 06/02/15 08:00, Hans-Peter Nilsson wrote: >>> On Thu, 8 Jan 2015, Andrew Haley wrote: Android native GCC can't support LTO because of a lack of support for dlopen() in the C library. How should we patch the configury to disable LTO by default? >>> >>> Doesn't setting unsupported_languages in toplevel configure.ac >>> work for you? >> >> I'm sorry, I don't understand this comment. > > Not sure what's not understood. IIUC you want to disable LTO > when building gcc natively on Android? As LTO is considered a > "language", ??? LTO is considered a "language"? Who knew? > disabling it by means of the support for targets or > hosts to disable languages (by setting the shell variable > unsupported_languages) seemed to make sense...though looking > closer, I see the language configury is slightly fudged and > needs some code moving to fix that, as e.g. lto-plugin > conditionals and special lto handling have snuck in before the > unsupported_languages processing. Bah. Never mind. :-) Anyway, it turns out that only the LTO plugin should be disabled, and it turned out that was due to a bug in the weird shim library being used to do native Android builds. So I guess we're OK. Andrew.
Re: Android native build of GCC
On February 6, 2015 4:28:01 AM CST, Andrew Haley wrote: >On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote: >> On Fri, 6 Feb 2015, Andrew Haley wrote: >>> On 06/02/15 08:00, Hans-Peter Nilsson wrote: On Thu, 8 Jan 2015, Andrew Haley wrote: > Android native GCC can't support LTO because of a lack of support >for > dlopen() in the C library. How should we patch the configury to >disable > LTO by default? Doesn't setting unsupported_languages in toplevel configure.ac work for you? >>> >>> I'm sorry, I don't understand this comment. >> >> Not sure what's not understood. IIUC you want to disable LTO >> when building gcc natively on Android? As LTO is considered a >> "language", > >??? > >LTO is considered a "language"? Who knew? > >> disabling it by means of the support for targets or >> hosts to disable languages (by setting the shell variable >> unsupported_languages) seemed to make sense...though looking >> closer, I see the language configury is slightly fudged and >> needs some code moving to fix that, as e.g. lto-plugin >> conditionals and special lto handling have snuck in before the >> unsupported_languages processing. Bah. Never mind. > >:-) > >Anyway, it turns out that only the LTO plugin should be disabled, and >it turned out that was due to a bug in the weird shim library being >used >to do native Android builds. So I guess we're OK. > >Andrew. Technically not a bug, but a limitation of either fakechroot ported to Android, Android's severely stripped libc, or a combination of the two. At any rate, the Android GCC 4.9.2 "build" has been used to compile a number of other programs on device...so yeah, we're ok. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Android native build of GCC
On 02/06/2015 11:05 AM, Cyd Haselton wrote: > Technically not a bug, but a limitation of either fakechroot ported to > Android, Android's severely stripped libc, or a combination of the two. I think it's a bug. libfakechroot presents a version of dlopen() on the assumption that the libc it's fronting has dlopen(). So, anyone probing for dlopen() finds it in libfakechroot. However, when that dlopen() is called you get a (very confusing) link error. This is a bug because if the underlying C library does not have dlopen() then libfakechroot should either not export it or should forward calls to the right library (which was libdl.so, I think.) Andrew.
Vararg templates. GCC vs Clang
--- the forwarded message follows ---
--- Begin Message ---
Code:
#include
#include
template
void f(std::tuple )
{
std::cout << "std::tuple\n";
}
template
void f(std::tuple )
{
std::cout << "std::tuple\n";
}
int main()
{
f(std::tuple{});
}
GCC accepts this code silently. But Clang generates error:
test.cpp:18:5: error: call to 'f' is ambiguous
f(std::tuple{});
^
test.cpp:5:6: note: candidate function [with Head = int,
Tail = <>]
void f(std::tuple )
^
test.cpp:11:6: note: candidate function [with Head = int]
void f(std::tuple )
^
Which compiler is right? Isn't it abiguity in fact?
--- End Message ---
Re: Possible typo in LRA
On 2015-02-05 4:36 PM, sa...@hederstierna.com wrote:
Hi
When reviewing some code from LRA, I just saw some lines that looked a bit
strange,
could it be a possible typo perhaps?
The file "lra.c" from GC5 master branch current date
Line 469:
/* Try x = index_scale; x = x + disp; x = x + base. */
last = get_last_insn ();
rtx_insn *move_insn = emit_move_insn (x, index_scale);
ok_p = false;
if (recog_memoized (move_insn) >= 0)
{
rtx insn = emit_add2_insn (x, disp);
if (insn != NULL_RTX)
{
insn = emit_add2_insn (x, disp);
if (insn != NULL_RTX)
ok_p = true;
}
}
Shouldn't the code be as the comment suggest to in the second call to
emit_add2_insn use 'base' ?
- insn = emit_add2_insn (x, disp);
+ insn = emit_add2_insn (x, base);
Maybe the code is right, I tried to mail vmakarov, some months ago, but did not
get any reply.
But it looks like I typo, so I just wanted to verify it so its not a bug,
Sorry, Fredrik. I guess I overlooked your email. It is really a
typo. I tried to consider all possible situations for all possible
targets. Not all of them occurs or occurs extremely rarely, e.g. the
current code to be run needs probably a lot of coincidences (a specific
target and unusual equiv substitutions).
I'll commit this change today after testing as I remember you have no
write access to GCC repository.
Thanks for reporting this again (sometimes we overlook emails as we
have too many of them). And thanks for checking LRA code.
Re: Android native build of GCC
> On Feb 6, 2015, at 5:28 AM, Andrew Haley wrote: > > On 02/06/2015 10:18 AM, Hans-Peter Nilsson wrote: >> ... >> Not sure what's not understood. IIUC you want to disable LTO >> when building gcc natively on Android? As LTO is considered a >> "language", > > ??? > > LTO is considered a "language"? Who knew? It would be nice if ./configure --help told us what the value arguments to --enable-languages are. paul
Re: Android native build of GCC
On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley wrote: > On 02/06/2015 11:05 AM, Cyd Haselton wrote: >> Technically not a bug, but a limitation of either fakechroot ported to >> Android, Android's severely stripped libc, or a combination of the two. > > I think it's a bug. libfakechroot presents a version of dlopen() on > the assumption that the libc it's fronting has dlopen(). Wouldn't the ported version of libfakechroot do otherwise...i.e. take into account that dlopen() does not reside in bionic? So, anyone > probing for dlopen() finds it in libfakechroot. However, when that > dlopen() is called you get a (very confusing) link error. This is a > bug because if the underlying C library does not have dlopen() then > libfakechroot should either not export it or should forward calls to > the right library (which was libdl.so, I think.) Out of curiosity (and future libfakechroot porting purposes) how would this look? I know that this and the previous question are off -topic to the original email so feel free to leave the list out of your reply. > > Andrew.
Re: Android native build of GCC
On 02/06/2015 04:11 PM, Cyd Haselton wrote: > On Fri, Feb 6, 2015 at 5:34 AM, Andrew Haley wrote: >> On 02/06/2015 11:05 AM, Cyd Haselton wrote: >>> Technically not a bug, but a limitation of either fakechroot ported to >>> Android, Android's severely stripped libc, or a combination of the two. >> >> I think it's a bug. libfakechroot presents a version of dlopen() on >> the assumption that the libc it's fronting has dlopen(). > > Wouldn't the ported version of libfakechroot do otherwise...i.e. take > into account that dlopen() does not reside in bionic? I have no idea. I would hope so. >> So, anyone probing for dlopen() finds it in libfakechroot. >> However, when that dlopen() is called you get a (very confusing) >> link error. This is a bug because if the underlying C library does >> not have dlopen() then libfakechroot should either not export it or >> should forward calls to the right library (which was libdl.so, I >> think.) > > Out of curiosity (and future libfakechroot porting purposes) how would > this look? I know that this and the previous question are off -topic > to the original email so feel free to leave the list out of your > reply. I'd rather leave it on-list for future reference. The best thing would be for libfakechroot to be linked against libdl: that way, when dlopen() was called the link would be correctly satisfied. If that isn't possible (if dlopen() doesn't work or is incompatible) then libfakechroot shouldn't export the symbol for dlopen(). Andrew.
Re: not using push by gcc
On 02/02/2015 01:15 AM, Mr.reCoder wrote:
Dear gcc developer,
I have a code like this:
#include
void foo(int x)
{
int y;
x++;
y = 4;
}
int main(void)
{
foo(2);
return 0;
}
and compiled with "gcc -o outexec srcfile.c" command.
when disassemble the file we see that sending argument to function
"foo" is done by
--
sub esp, 4
mov dword ptr [esp], 2
callfoo
--
instructions. why gcc doesn't use the "push" command like:
You can find a discussion on the same subject here:
http://stackoverflow.com/questions/4534791/why-does-it-use-the-movl-instead-of-push
A recent GCC does as you suggest, so the version you're using
might be either too old or buggy. I see -mpush-args documented
as enabled by default as far back as 3.0.
Martin
How is TARGET_ASM_ASSEMBLE_VISIBILITY used?
I saw
config/darwin.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
config/darwin.h:#define TARGET_ASM_ASSEMBLE_VISIBILITY
darwin_assemble_visibility
config/i386/cygming.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
config/i386/cygming.h:#define TARGET_ASM_ASSEMBLE_VISIBILITY
i386_pe_assemble_visibility
config/rs6000/rs6000.c:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
config/rs6000/rs6000.c:#define TARGET_ASM_ASSEMBLE_VISIBILITY
rs6000_assemble_visibility
config/sol2.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
config/sol2.h:#define TARGET_ASM_ASSEMBLE_VISIBILITY solaris_assemble_visibility
doc/tm.texi:@deftypefn {Target Hook} void
TARGET_ASM_ASSEMBLE_VISIBILITY (tree @var{decl}, int @var{visibility})
doc/tm.texi.in:@hook TARGET_ASM_ASSEMBLE_VISIBILITY
How is it used?
--
H.J.
libgccjit documentation now available on gcc.gnu.org
The documentation for libgccjit is now visible on the GCC website in HTML form at: https://gcc.gnu.org/onlinedocs/jit/ (and is being built nightly). Thanks to everyone who helped make this happen (Gerald Pfeifer, Joseph Myers, Frank Ch. Eigler, Jeff Law, iirc). The "Show Source" links on each page are currently 404s, but that should be resolved shortly. Dave
Re: Vararg templates. GCC vs Clang
On 6 February 2015 at 12:12, Victor wrote:
>
>
>
> --- the forwarded message follows ---
>
>
> -- Forwarded message --
> From: Victor
> To: gcc-h...@gcc.gnu.org
> Cc:
> Date: Wed, 04 Feb 2015 15:41:56 +0600
> Subject: Vararg templates. GCC vs Clang
> Code:
>
> #include
> #include
>
> template
> void f(std::tuple )
> {
> std::cout << "std::tuple\n";
> }
>
> template
> void f(std::tuple )
> {
> std::cout << "std::tuple\n";
> }
>
> int main()
> {
> f(std::tuple{});
> }
>
> GCC accepts this code silently. But Clang generates error:
>
> test.cpp:18:5: error: call to 'f' is ambiguous
> f(std::tuple{});
> ^
> test.cpp:5:6: note: candidate function [with Head = int, Tail = <>]
> void f(std::tuple )
> ^
> test.cpp:11:6: note: candidate function [with Head = int]
> void f(std::tuple )
> ^
>
> Which compiler is right? Isn't it abiguity in fact?
This question would have been more appropriate on the gcc-help mailing list.
Technically the standard says it's ambiguous, but the C++ committee
believes that to be a defect and plan to fix it, see
http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1395
Re: Vararg templates. GCC vs Clang
On 7 February 2015 at 00:05, Jonathan Wakely wrote: > This question would have been more appropriate on the gcc-help mailing list. I should have said it *was* more appropriate on that list, and should have remained there. You could have pinged the gcc-help list, or just been patient, before sending to a different list.
Stepping down as global maintainer
It's been a long time since I did any significant work on GCC, and it is unlikely that I'll be doing much for the foreseeable future. While I still have some understanding of the modules I used to maintain, I don't think it is reasonable to have me making decisions on them. It's been too long and I am not likely to have a good understanding of these components anymore. As such, I propose to become a write-after-approval maintainer and relinquish all the other maintainer roles I had. I'll be committing this to trunk. Thanks. Diego. diff --git a/MAINTAINERS b/MAINTAINERS index 22a21ee..2cf1cc4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -31,7 +31,6 @@ Michael Meissner Jason Merrill David S. Miller Joseph Myers -Diego Novillo Bernd Schmidt Ian Lance Taylor Jim Wilson @@ -226,7 +225,6 @@ build machinery (*.in) Alexandre Oliva build machinery (*.in) Ralf Wildenhues docs co-maintainer Gerald Pfeifer docs co-maintainer Joseph Myers -docstring relicensing Diego Novillo docstring relicensing Gerald Pfeifer docstring relicensing Joseph Myers predict.defJan Hubicka @@ -238,9 +236,7 @@ option handling Joseph Myers middle-end Jeff Law middle-end Roger Sayle middle-end Ian Lance Taylor -middle-end Diego Novillo middle-end Richard Biener -tree-ssa Diego Novillo tree-ssa Andrew MacLeod PREDaniel Berlin code sinking Daniel Berlin @@ -299,10 +295,8 @@ libsanitizer, asan.c Kostya Serebryany libsanitizer, asan.c Dmitry Vyukov loop optimizer Zdenek Dvorak loop optimizer Daniel Berlin -LTODiego Novillo LTORichard Biener LTO plugin Cary Coutant -Plugin Diego Novillo Plugin Le-Chun Wu register allocationPeter Bergner register allocationKenneth Zadeck @@ -503,6 +497,7 @@ Adam Nemet Thomas Neumann Dan Nicolaescu James Norris +Diego Novillo Dorit Nuzman David O'Brien Braden Obrzut
Re: How is TARGET_ASM_ASSEMBLE_VISIBILITY used?
On Fri, Feb 6, 2015 at 2:20 PM, H.J. Lu wrote:
> I saw
>
> config/darwin.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
> config/darwin.h:#define TARGET_ASM_ASSEMBLE_VISIBILITY
> darwin_assemble_visibility
> config/i386/cygming.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
> config/i386/cygming.h:#define TARGET_ASM_ASSEMBLE_VISIBILITY
> i386_pe_assemble_visibility
> config/rs6000/rs6000.c:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
> config/rs6000/rs6000.c:#define TARGET_ASM_ASSEMBLE_VISIBILITY
> rs6000_assemble_visibility
> config/sol2.h:#undef TARGET_ASM_ASSEMBLE_VISIBILITY
> config/sol2.h:#define TARGET_ASM_ASSEMBLE_VISIBILITY
> solaris_assemble_visibility
> doc/tm.texi:@deftypefn {Target Hook} void
> TARGET_ASM_ASSEMBLE_VISIBILITY (tree @var{decl}, int @var{visibility})
> doc/tm.texi.in:@hook TARGET_ASM_ASSEMBLE_VISIBILITY
>
> How is it used?
>
It is used by generated target-hooks-def.h.
--
H.J.
