> It has been almost a year since GCC 8.3 has been released and GCC 8.4
> release should have been released already, so we should concentrate on
> getting it out soon. Unfortunately we have two P1s, one of them is
> waiting for reporter's input, so we might as well just ignore it unless
> the inpu
On 2/19/20 10:24 AM, Richard Biener wrote:
> On Tue, Feb 18, 2020 at 8:37 PM Bernd Edlinger
> wrote:
>>
>>> It has been almost a year since GCC 8.3 has been released and GCC 8.4
>>> release should have been released already, so we should concentrate on
>>>
Hi,
I do not want to start a flame war.
I just am curious what was the reason why
the old system cannot be used any more?
Would there be a possibility to get the old look-and-feel back?
Thanks
Bernd.
On 3/25/20 8:32 AM, Jonathan Wakely wrote:
> On Wed, 25 Mar 2020 at 04:48, Bernd Edlinger wrote:
>>
>> Hi,
>>
>> I do not want to start a flame war.
>>
>> I just am curious what was the reason why
>> the old system cannot be used any more?
>
>
On 3/25/20 8:58 AM, Bernd Edlinger wrote:
> On 3/25/20 8:32 AM, Jonathan Wakely wrote:
>> On Wed, 25 Mar 2020 at 04:48, Bernd Edlinger wrote:
>>>
>>> Hi,
>>>
>>> I do not want to start a flame war.
>>>
>>> I just am curious wha
-On 3/25/20 7:55 PM, Christopher Faylor wrote:
> On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
>> I believe the canonical place for the "Linux suff" mailing lists these days
>> is
>> lore.kernel.org, powered by public-inbox[1]. ISTM that software can address
>> most
>> if not al
On 3/25/20 9:29 PM, Bernd Edlinger wrote:
> Could you add a link to https://marc.info/?l=gcc-patches
Why is above link no longer updating
this is the last message there:
1. 2020-03-07 [5] [PATCH] c++: Fix ABI issue with alignas on armv7hl [P
gcc-patch Jason Merrill
is this a push or a p
On 3/26/20 4:16 PM, Christopher Faylor wrote:
> On Wed, Mar 25, 2020 at 09:29:03PM +0100, Bernd Edlinger wrote:
>> -On 3/25/20 7:55 PM, Christopher Faylor wrote:
>>> On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solokha wrote:
>>>> I believe the canonical plac
On 3/25/20 10:07 PM, Jakub Jelinek wrote:
> On Wed, Mar 25, 2020 at 09:03:15PM +, Jonathan Wakely via Gcc wrote:
>> See the link at the bottom of every page in the old archive:
>> http://www.mhonarc.org/
>>
>>> what is the exact problem that prevents it from being used any longer?
>>
>> It's
On 3/25/20 7:55 PM, Christopher Faylor wrote:
>
> FWIW, this particular overseer is is also pretty exhausted from the
> effort of moving sourceware to a new system + new software and would not
> relish the effort involved in getting all of this moved to new software.
>
I am sorry, to hear tha
On 3/26/20 4:27 PM, Bernd Edlinger wrote:
> On 3/26/20 4:16 PM, Christopher Faylor wrote:
>> On Wed, Mar 25, 2020 at 09:29:03PM +0100, Bernd Edlinger wrote:
>>> -On 3/25/20 7:55 PM, Christopher Faylor wrote:
>>>> On Wed, Mar 25, 2020 at 04:23:02PM +0700, Arseny Solo
On 4/1/20 8:51 AM, Bernd Edlinger wrote:
> On 3/26/20 4:27 PM, Bernd Edlinger wrote:
>> On 3/26/20 4:16 PM, Christopher Faylor wrote:
>>>
>>> marc.info is an independent site that is not associated with
>>> sourceware.org. We don't control it. If you hav
On 4/2/20 12:54 AM, Joseph Myers wrote:
> On Wed, 1 Apr 2020, Bernd Edlinger wrote:
>
>> PS: I have a discovered a very serious problem with the mailing lists
>> that must be fixed by our overseers.
>>
>> That is the scubbed attachments.
>>
>> As an
On 4/2/20 1:41 AM, Jonathan Wakely wrote:
> On Wed, 1 Apr 2020 at 23:54, Joseph Myers wrote:
>>
>> On Wed, 1 Apr 2020, Bernd Edlinger wrote:
>>
>>> PS: I have a discovered a very serious problem with the mailing lists
>>> that must be fixed by our overseers.
On 4/2/20 7:13 AM, Christopher Faylor wrote:
> On Wed, Apr 01, 2020 at 09:57:05PM -0700, Unidef Defshrizzle wrote:
>> We can setup a command line interface, maybe using CURSES, I mean GUIs are
>> fun, but Jesus Christ they’re full of surprises
>
> Command line interface to what?
>
> You can read
On 4/2/20 11:01 AM, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> On 4/1/20 8:51 AM, Bernd Edlinger wrote:
>>> On 3/26/20 4:27 PM, Bernd Edlinger wrote:
>>>> On 3/26/20 4:16 PM, Christopher Faylor wrote:
>>>>>
>>>>>
On 4/2/20 11:09 AM, Jonathan Wakely wrote:
> On Thu, 2 Apr 2020 at 04:35, Bernd Edlinger wrote:
>> Regarding the overseers, they repeatedly spoke up on this list,
>> but all the time they use an e-mail that bounces.
>
> No. ONE of the overseers replies from a personal email a
On 4/2/20 11:48 AM, Richard Sandiford wrote:
> Bernd Edlinger writes:
>> On 4/2/20 11:01 AM, Richard Sandiford wrote:
>>> Bernd Edlinger writes:
>>>> On 4/1/20 8:51 AM, Bernd Edlinger wrote:
>>>>> On 3/26/20 4:27 PM, Bernd Edlinger wrote:
>&g
Hi,
I have a question about the gcc-testresults mailing list,
that is I see everyone using:
[releases/gcc-9 revision
02a201f71:0f58d3b54:0e66150084aa217811a5c45fb15e98d7ed3e8839]
or
[master revision
63b2923dc6f:0c89e976db9:1c16f7fc903c1c1c912faf7889b69d83429b7b2e
what is the first 2 hashes,
On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
>>
>> Hi,
>>
>> I have a question about the gcc-testresults mailing list,
>> that is I see everyone using:
>>
>> [releases/gcc-9 revision
>> 02a201f71
On 4/3/20 7:50 PM, Jonathan Wakely wrote:
> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
>>
>> Hi,
>>
>> I have a question about the gcc-testresults mailing list,
>> that is I see everyone using:
>>
>> [re
On 4/3/20 7:57 PM, Jonathan Wakely wrote:
> On Fri, 3 Apr 2020 at 18:54, Bernd Edlinger wrote:
>>
>> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
>>> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
>>>>
>>>> Hi,
>>>>
>>>>
On 4/3/20 7:56 PM, Jonathan Wakely wrote:
> On Fri, 3 Apr 2020 at 18:55, Bernd Edlinger wrote:
>>
>>
>>
>> On 4/3/20 7:50 PM, Jonathan Wakely wrote:
>>> On Fri, 3 Apr 2020 at 18:45, Bernd Edlinger wrote:
>>>>
>>>> Hi,
>&g
On 4/2/20 10:06 AM, Andreas Schwab wrote:
> On Apr 02 2020, Bernd Edlinger wrote:
>
>> What happens to the e-mails when they are not archive, but forwarded
>> to the subscribers, like mark.info who just subscribes the mails,
>> and archived them they have a lot of har
On 4/10/20 9:06 AM, Andreas Schwab wrote:
> On Apr 10 2020, Bernd Edlinger wrote:
>
>> Interesting point with gmane.io, do they have a web-interface?
>
> No.
>
Hmm. Not good.
How do you access that data base ? NNTP ?
Bernd.
> Andreas.
>
Hi,
I just found this in the docs:
The compiler copies the assembler instructions in a basic @code{asm}
verbatim to the assembly language output file, without
processing dialects or any of the @samp{%} operators that are available with
extended @code{asm}. This results in minor differences betwe
Hi,
I just found this in the docs:
The compiler copies the assembler instructions in a basic @code{asm}
verbatim to the assembly language output file, without
processing dialects or any of the @samp{%} operators that are available with
extended @code{asm}. This results in minor differences betwe
Hi,
> Well, I start to think that Jeff is right, and we should treat a asm ("") as
> if it
> were asm volatile ("" ::: )
> but if the asm ("nonempty with optional %") we should
> treat it as asm volatile ("nonempty with optional %%" ::: "memory").
> Our docs should say that explicitly, and the i
Hi,
~/gnu/gcc/configure --prefix=/usr --enable-bootstrap --enable-shared
--enable-host-shared --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-in
On 01/12/2015 17:08, Richard Earnshaw wrote:
> On 28/11/15 04:05, David Wohlferd wrote:
>> On 11/24/2015 6:50 PM, David Wohlferd wrote:
>>> I have solved the problem with my previous patch. Here's the update
>>> (feedback welcome): http://www.LimeGreenSocks.com/gcc/24414g.zip
>>>
>>> Based on my
On 1.12.2015, David Wohlferd wrote:
On 12/1/2015 10:10 AM, Bernd Edlinger wrote:
> > But IMHO asm("bla":) isn't any better than asm("bla").
> > I think _any_ asm with non-empty assembler string, that
> > claims to clobber _nothing_ is highly suspicious,
Hi,
> Surely in code like that, you would make "x" volatile? Memory clobbers
> are not a substitute for correct use of volatile accesses.
No,
It is as I wrote, a memory clobber is the only way to guarantee that
the asm statement is not move somewhere else.
I changed the example to use volatile
On Tue, 1 Dec 2015 09:17:48, Ulrich Drepper wrote:
> On Tue, Dec 1, 2015 at 2:39 AM, Matthias Klose wrote:
> > that might be another instance of
> > https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02064.html
> > Does something like this help?
>
> No, same problem as before. This macro doesn't act
On 03.12.2015 00:27 David Wohlferd wrote:
> On 12/2/2015 3:34 AM, Bernd Edlinger wrote:
>> Hi,
>>
>>> Surely in code like that, you would make "x" volatile? Memory clobbers
>>> are not a substitute for correct use of volatile accesses.
>> No,
>
Am 03.12.2015 um 16:24 schrieb paul_kon...@dell.com:
> On the other hand, asm volatile ("foo":::) has a different meaning.
> That specifically says that "foo" doesn't clobber anything.
Well, not exactly, see the md_asm_adjust target callback.
On i386, rs6000, visium, cris and mn10300 targets
Hi,
On 12.12.2015 10:51, Andrew Haley wrote:
> On 11/12/15 22:18, David Wohlferd wrote:
>
>> And here are the three solutions that have been proposed:
>>
>> Solution 1:
>> Just document the current behavior of basic asm.
>>
>> People who have written incorrect code can be pointed at the text and
>
Hi,
On 12/15/2015 13:52, Bernd Schmidt wrote:
>
> On 12/14/2015 09:10 AM, Segher Boessenkool wrote:
> > That, and adding a memory clobber degrades performance for a lot of
> > existing basic asm that does not expect the clobber, e.g. asm(""),
> > asm("#"), asm("nop"), ...
>
> I wonder about this
Hi,
On 15. Dezember 2015 23:43, Joseph Myers wrote:
> I think the typical use of basic asm is: you want to manipulate I/O
> registers or other such state unknown to the compiler (not any registers
> the compiler might use itself), and you want to do it in a way that is
> maximally compatible with
Hi,
On Thu, 17 Dec 2015 15:13:07, Bernd Schmidt wrote:
> > What's your take on making -Wonly-top-basic-asm a default (either now or
> > v7)? Is making it a non-default a waste of time because no one will
> > ever see it? Or is making it a default too aggressive? What about
> > adding it
On 18.12.2015 10:27, David Wohlferd wrote:
> On 12/17/2015 11:30 AM, Bernd Edlinger wrote:
>> On Thu, 17 Dec 2015 15:13:07, Bernd Schmidt wrote:
>>>>What's your take on making -Wonly-top-basic-asm a default
>>>> (either now or
>>>>v7)?
Hi,
On 19.12.2015 19:54, David Wohlferd wrote:
>
mep: mep_interrupt_saved_reg looks for ASM_INPUT in the body, and
saves different registers if found.
>>> I'm trying to follow this code. A real challenge since I know nothing
>>> about mep. But what I see is:
>>>
>>> - This routine only
On 20.12.2015 23:53, David Wohlferd wrote:
> On 12/20/2015 10:26 AM, Bernd Edlinger wrote:
>> On 19.12.2015 19:54, David Wohlferd wrote:
>>>>>> mep: mep_interrupt_saved_reg looks for ASM_INPUT in the body, and
>>>>>> saves different registers if found.
Hi,
> struct fields {
> long long unsigned f0:12;
> long long unsigned f1:52;
> } __attribute__((__packed__));
the C99 standard ISO/IEC 9899 forbids this type:
6.7.2.1 Structure and union specifiers
4 A bit-field shall have a type that is a qualified or unqualified version of
_Bool, signed
Hi,
I modified Aexander's test case a bit, and found something
unexpected, which looks like a GCC-BUG to me:
cat test.c
#include
#include
#include
int main()
{
long double d0, d;
memcpy(&d0,
"\x00\x00\x00\x00\x00\x00\x00\x00\xff\x3f\x00\x00\x00\x00\x00\x00", sizeof d0);
// d = d0;
m
On 21/06/2016 17:53, Andrew Haley wrote:
> On 21/06/16 17:43, Jeff Law wrote:
> > I think there's enough resistance to deprecating basic asms within a
> > function that we should probably punt that idea.
> >
> > I do think we should look to stomp out our own uses of basic asms
> > within functions
Hi Joseph,
I've just stumbled over this function in gcc/c-family/c-common.c,
which might need adjustment for __float128:
/* Return true iff ALIGN is an integral constant that is a fundamental
alignment, as defined by [basic.align] in the c++-11
specifications.
That is:
[A
olean context
Date: Thu, 15 Sep 2016 11:19:32 +0200
From: Bernd Edlinger
To: GCC Patches
CC: Jason Merrill , Jeff Law , Joseph
Myers
Hi,
I send the latest version of the warning patch again, because I don't
see the previous patch submission on the gcc-patches list. It dropped
out silen
Hi Martin,
in the past I have seen (and fixed) code like
sprintf(buf, "%s %d", buf, x);
that may possibly work by chance, but usually
produces undefined results.
Do you see a way to enhance the warning for cases
where the output buffer overlaps an input buffer?
Thanks
Bernd.
Hi Joseph,
I just noticed that translated strings might have different
sprintf arguments than the original message:
$ LANG=de_DE.UTF-8 gcc -v --help|&grep shadow
-Wintrinsic-shadow Warnen, wenn eine Benutzer-Prozedur denselben
Namen wie ein Intrinsic hat.
-Wshadow-ivar
Hi,
I'm currently trying to add -Wshadow=local to the gcc build rules.
I started with -Wshadow, but gave up that idea immediately.
As you could expect the current code base has plenty of shadowed
local variables. Most are trivial to resolve, some are less trivial.
I am not finished yet, but it i
On 9/19/19 12:19 PM, Richard Biener wrote:
> On Wed, Sep 18, 2019 at 3:09 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> I'm currently trying to add -Wshadow=local to the gcc build rules.
>> I started with -Wshadow, but gave up that idea immediately.
>&g
On 9/18/19 3:08 PM, Bernd Edlinger wrote:
> Hi,
>
> I'm currently trying to add -Wshadow=local to the gcc build rules.
> I started with -Wshadow, but gave up that idea immediately.
>
> As you could expect the current code base has plenty of shadowed
> local varia
Hi,
I see this now as well on Ubuntu 16.04, but I doubt that the Kernel is
to blame.
I am able to reproduce this in debug-mode as follows:
strace -s 4096 -o strace.txt expect -- /usr/share/dejagnu/runtest.exp
--debug -v --tool gcc ubsan.exp=*
So I have now a dbg.out and a strace log file show
On 07/11/17 21:42, Andrew Pinski wrote:
> On Tue, Jul 11, 2017 at 12:31 PM, Andrew Pinski wrote:
>> On Tue, Jul 11, 2017 at 12:27 PM, Andrew Pinski wrote:
>>> On Tue, Jul 11, 2017 at 12:15 PM, Bernd Edlinger
>>> wrote:
>>>> Hi,
>>>>
>>&g
On 07/11/17 22:28, Bernd Edlinger wrote:
> On 07/11/17 21:42, Andrew Pinski wrote:
>> On Tue, Jul 11, 2017 at 12:31 PM, Andrew Pinski
>> wrote:
>>> On Tue, Jul 11, 2017 at 12:27 PM, Andrew Pinski
>>> wrote:
>>>> On Tue, Jul 11, 2017 at 1
On 07/13/17 16:31, Georg-Johann Lay wrote:
> On 12.07.2017 15:40, Bernd Edlinger wrote:
>> On 07/11/17 22:28, Bernd Edlinger wrote:
>>> On 07/11/17 21:42, Andrew Pinski wrote:
>>>> On Tue, Jul 11, 2017 at 12:31 PM, Andrew Pinski
>>>> wrote:
>>>
On 07/14/17 13:03, Georg-Johann Lay wrote:
> On 13.07.2017 18:47, Bernd Edlinger wrote:
>> On 07/13/17 16:31, Georg-Johann Lay wrote:
>>> On 12.07.2017 15:40, Bernd Edlinger wrote:
>>>> On 07/11/17 22:28, Bernd Edlinger wrote:
>>>>> On 07/11/17 21:4
You can get much better code if you make xrci a bit field.
so the entire bit filed region can be accessed word-wise:
#include
struct Xrb
{
uint16_t xrlen; /* Length of I/O buffer in bytes */
uint16_t xrbc; /* Byte count for transfer */
void * xrloc;
On 5/14/21 10:20 PM, Andrew Pinski via Gcc wrote:
> On Fri, May 14, 2021 at 3:27 AM Richard Biener via Gcc
> wrote:
>>
>> On May 14, 2021 10:53:21 AM GMT+02:00, "Martin Liška" wrote:
>>> On 5/12/21 10:51 AM, Richard Biener via Gcc wrote:
On Tue, May 11, 2021 at 6:34 PM Serge Belyshev via Gc
Hi,
On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
>
> Sandra, Bernd,
>
> Can you take a look at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734
>
> It seems a siimple case still doesn't work as expected. Did I miss anything?
>
> Thanks,
> Joey
Yes,
this is a major case where the C++ memory mod
On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>
> On 09/01/14 08:26, Bernd Edlinger wrote:
>> Hi,
>>
>> On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:
>>>
>>> Sandra, Bernd,
>>>
>>> Can you take a look at
>>> http://gcc.g
On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>
> On 10/01/14 08:49, Bernd Edlinger wrote:
>> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>>>
>>> On 09/01/14 08:26, Bernd Edlinger wrote:
>>>> Hi,
>>>>
>>>> On
On Fri, 10 Jan 2014 14:45:12, Richard Biener wrote:
>
> On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
> wrote:
>> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:
>>>
>>> On 10/01/14 08:49, Bernd Edlinger wrote:
>>>> On Thu, 9 Jan 2014 16:22:
++ memory model conflict)
> later. Neither of them are obvious to users. How about a configure
> option to set default?
>
> Thanks,
> Joey
>
> On Fri, Jan 10, 2014 at 10:20 PM, Bernd Edlinger
> wrote:
>> On Fri, 10 Jan 2014 14:45:12, Richard Biener wrote:
>>&g
64 matches
Mail list logo
