On Mon, Apr 18, 2016 at 07:59:50AM -0700, H.J. Lu wrote:
> On Mon, Apr 18, 2016 at 7:49 AM, Alan Modra wrote:
> > On Mon, Apr 18, 2016 at 11:01:48AM +0200, Richard Biener wrote:
> >> To summarize: there is currently no testcase for a wrong-code issue
> >> because there is no wrong-code issue.
I'v
On Mon, 2016-04-18 at 14:15 -0500, Joel Sherrill wrote:
> Since I stated that, we decided to use the 6.1 branch for a while.
> So I decided to look at config/sh/linux.h and see what it was doing.
> Copying if on the 6.1 branch seemed liked an option. But it only
> appears to address SH3 and SH1 fo
On Mon, Apr 18, 2016 at 11:51 AM, Jakub Jelinek wrote:
> On Mon, Apr 18, 2016 at 10:27:45AM -0700, H.J. Lu wrote:
>> On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz wrote:
>> > Hi,
>> >
>> > On Mon, 18 Apr 2016, H.J. Lu wrote:
>> >
>> >> > reason is DSO code (also handcoded assembly) may reasonabl
On 4/18/2016 6:11 AM, Oleg Endo wrote:
On Sun, 2016-04-17 at 13:33 -0500, Joel Sherrill wrote:
Thanks for the quick and thorough reply.
This doesn't happen with GCC 4.9 which we are using on our newest
release branch. With any luck your work will be in gcc 7 before we
make another release br
On Mon, Apr 18, 2016 at 10:27:45AM -0700, H.J. Lu wrote:
> On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz wrote:
> > Hi,
> >
> > On Mon, 18 Apr 2016, H.J. Lu wrote:
> >
> >> > reason is DSO code (also handcoded assembly) may reasonably expect to
> >> > be able to load the address with a PC-relativ
On Mon, 18 Apr 2016, Michael Matz wrote:
> E.g. one limitation might very well be that function pointer comparison
> for protected functions doesn't work (gives different outcomes if the
> pointer is built from inside the exe or from a shared lib). (No matter
> how it's built, it will still _w
>> That is why protected visibility is such a mess.
>
> Not mess, but it comes with certain limitations. And that's okay. It's
> intended as an optimization, and it should do that optimization if
> requested, and error out if it can't be done for whatever reason.
I completely agree.
> E.g. one
On Mon, Apr 18, 2016 at 10:23 AM, Michael Matz wrote:
> Hi,
>
> On Mon, 18 Apr 2016, H.J. Lu wrote:
>
>> > reason is DSO code (also handcoded assembly) may reasonably expect to
>> > be able to load the address with a PC-relative load-address type
>> > instruction (ADDIUPC, LEA, MOVAB, etc.) and th
Hi,
On Mon, 18 Apr 2016, H.J. Lu wrote:
> > reason is DSO code (also handcoded assembly) may reasonably expect to
> > be able to load the address with a PC-relative load-address type
> > instruction (ADDIUPC, LEA, MOVAB, etc.) and the target may not even
> > have suitable dynamic relocations a
On Mon, Apr 18, 2016 at 10:03 AM, Maciej W. Rozycki wrote:
> On Mon, 18 Apr 2016, H.J. Lu wrote:
>
>> > Any testcase the takes the address of a protected visibility variable
>> > defined in a shared library now can get the wrong answer, since you
>> > can argue that any address outside the shared
>> Given a shared library that defines a variable, and a non-PIC
>> executable that references that variable, the linker makes a duplicate
>> of the variable in the executable .dynbss section and arranges to have
>> the copy initialized by the dynamic loader with a copy relocation.
>> .dynbss is a
On Mon, 18 Apr 2016, H.J. Lu wrote:
> > Any testcase the takes the address of a protected visibility variable
> > defined in a shared library now can get the wrong answer, since you
> > can argue that any address outside the shared library is wrong
> > according to the gABI.
>
> What value should
On Mon, Apr 18, 2016 at 7:49 AM, Alan Modra wrote:
> On Mon, Apr 18, 2016 at 11:01:48AM +0200, Richard Biener wrote:
>> To summarize: there is currently no testcase for a wrong-code issue
>> because there is no wrong-code issue.
>
> That depends entirely on how far you are willing to bend the ELF
On Mon, Apr 18, 2016 at 11:01:48AM +0200, Richard Biener wrote:
> To summarize: there is currently no testcase for a wrong-code issue
> because there is no wrong-code issue.
That depends entirely on how far you are willing to bend the ELF gABI.
Any testcase the takes the address of a protected vi
2016-04-18 10:33 GMT+01:00 Richard Biener :
> On Mon, Apr 11, 2016 at 1:54 PM, Ilya Enkovich wrote:
>> 2016-04-10 3:34 GMT+03:00 David Guillen Fandos :
>>> On 07/04/16 09:09, Ilya Enkovich wrote:
2016-04-07 0:49 GMT+03:00 David Guillen Fandos :
>
> Thanks a lot Ilya!
>
> I man
On Sun, 2016-04-17 at 13:33 -0500, Joel Sherrill wrote:
> Thanks for the quick and thorough reply.
>
> This doesn't happen with GCC 4.9 which we are using on our newest
> release branch. With any luck your work will be in gcc 7 before we
> make another release branch.
That's probably because of
>>> If the current code assumes a struct and the Windows API calls need an
>>> integer then either the existing code needs to be made more flexible,
>>> or you need to define it as a struct and then convert to an integer
>>> inside your new gthread wrapper functions.
>>
>> The Windows APIs involved
On 18 April 2016 at 10:57, Jonathan Wakely wrote:
> On 18 April 2016 at 10:18, lh_mouse wrote:
>>> I don't see why it has to be a struct, it just has to be suitable as
>>> an argument to the relevant __gthread functions.
>>
>> The type __gthread_time_t is referenced in
>> gcc/libstdc++-v3/include/
On 18 April 2016 at 10:18, lh_mouse wrote:
>> I don't see why it has to be a struct, it just has to be suitable as
>> an argument to the relevant __gthread functions.
>
> The type __gthread_time_t is referenced in
> gcc/libstdc++-v3/include/std/mutex:157
> __gthread_time_t __ts = {
>
On Mon, Apr 11, 2016 at 1:54 PM, Ilya Enkovich wrote:
> 2016-04-10 3:34 GMT+03:00 David Guillen Fandos :
>> On 07/04/16 09:09, Ilya Enkovich wrote:
>>> 2016-04-07 0:49 GMT+03:00 David Guillen Fandos :
Thanks a lot Ilya!
I managed to get it working. There were some bugs regardin
> I don't see why it has to be a struct, it just has to be suitable as
> an argument to the relevant __gthread functions.
The type __gthread_time_t is referenced in
gcc/libstdc++-v3/include/std/mutex:157
__gthread_time_t __ts = {
static_cast(__s.time_since_epoch().count()),
Oh I missed the build-in specs in gcc/config/i386/mingw32.h and it was lack of
-lmcfgthread in it that caused the failure. Stage 1 seemed ok.
Already hacked that. Rebuilding.
Apologize for that.
--
Best regards,
lh_mouse
2016-04-18
On Fri, Apr 15, 2016 at 11:56 PM, H.J. Lu wrote:
> On Fri, Apr 15, 2016 at 2:49 PM, Jeff Law wrote:
>>
>> So in the immediate term, if we drop the problem 65248 patch, we're back in
>> a state where the DSO and the executable can have two different views of
>> certain objects. In which case we r
On 18 April 2016 at 08:39, lh_mouse wrote:
> I have added a thread model and added its corresponding header files. But it
> failed the linker.
>
> The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
> SHLIB_PTHREAD_CFLAG = -pthread
> SHLIB_PTHREAD_LDFLAG = -Wl,-lpthrea
On 17 April 2016 at 17:56, lh_mouse wrote:
> A glance over gthr.h reminds me __gthread_time_t. There seem few requirements
> documented in gthr.h.
> I discussed this with Adrien Nader on mingw-w64's mailing list a few days ago.
>
> Specifically, here are the two questions:
> 0) Should __gthread_t
Hi,
While tracking down a performance regression for the AVR target from
4.9.x to trunk, I noticed that failing the SHRINK_WRAPPING_ENABLED
check in ira.c led to noticeably worse code for the following
case. That check prevents live range splitting of pseudos containing
formal args, and
On 17/04/16 17:58, J a h a n z e b F a h i m wrote:
> i am a java developer, i want to install gnu java compiler on LINUX
> 7.2 for testing purpose. i already have gcc version 4.8.5 20150623
> (Red Hat 4.8.5-4) (GCC) in my machine. now i want to add gcj in it.
> how can i install it?
It's going t
I have added a thread model and added its corresponding header files. But it
failed the linker.
The file 'gcc/libgcc/config/i386/t-mingw-pthread' which contained two lines:
SHLIB_PTHREAD_CFLAG = -pthread
SHLIB_PTHREAD_LDFLAG = -Wl,-lpthread
I copied the file to 'gcc/libgcc/config/i386/t-ming
28 matches
Mail list logo
