> What if we had this:
> uint32_t u = 0x12345678;
> upal_u32be_t tempb;
> memcpy (&tempb, &u, sizeof(uint32_t));
> uint32_t bu = tempb.val;
>
> Is that valid? We still run into the wrong code with the above case.
> memcpy here should be considered a byte-by-byte copy and therefor
> Thanks, I will take a look at Bernd's work. IIRC, he took a
> different approach from what was suggested in the wiki, right?
Yes, let's say that it's a half-baked conversion, probably a consequence of
the bounty. This might be good enough, depending on the architecture.
--
Eric Botcazou
* Tamar Christina:
> A bit late to the party, but this really doesn't work that well
> because until recent version of gitlab there was no fairness
> guarantee. another patch could be approved after mine (with hours
> in between because of CI) and yet still get merged first causing my
> own patch
On Wed, Apr 22, 2020 at 10:25 AM Jakub Jelinek via Gcc wrote:
> An -O? option is not just a set of suboptions it enables
Maybe it should be. I notice this come up often enough at least.
On Wed, Apr 22, 2020 at 11:37 PM Joel Sherrill wrote:
>
> On Wed, Apr 22, 2020 at 12:53 PM Moritz Strübe
> wrote:
>
> >
> > Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc:
> > > [..] as the
> > > alternative would be dropping the AVR port.
> >
> > Shouldn't that work be sponsored by Microchip (o
On Wed, Apr 22, 2020 at 10:08 PM Jeff Law wrote:
>
> On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote:
> > Hi,
> >
> > I'm thinking about attempting to do the CC0 transition for the
> > AVR port in my spare time. I've read the CC0Transition gcc wiki
> > page, and as the AVR ISA does
> -Original Message-
> From: Gcc On Behalf Of Florian Weimer
> Sent: Thursday, March 19, 2020 1:59 PM
> To: Richard Biener
> Cc: overse...@gcc.gnu.org; Jonathan Wakely via Gcc ;
> Overseers mailing list ; Segher Boessenkool
> ; Alexander Monakov ;
> Frank Ch. Eigler ; Frank Ch. Eigler ;
On Wed, Apr 22, 2020 at 1:14 PM Eric Botcazou wrote:
>
> > I notice this statement in the documentation:
> > Moreover, the use of type punning or aliasing to toggle the storage
> > order is not supported; that is to say, a given scalar object cannot
> > be accessed through distinct types that assi
> I notice this statement in the documentation:
> Moreover, the use of type punning or aliasing to toggle the storage
> order is not supported; that is to say, a given scalar object cannot
> be accessed through distinct types that assign a different storage
> order to it.
> --- CUT ---
> But I am n
Hi all (and Eric),
I have a question about scalar_storage_order and support of type
punning between types that have different byte order.
Take:
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
#define __big_endian__ scalar_storage_order("big-endian")
#define __little_endian__ scalar
לרג המצב משרד האוצר העמיד 8 מיליארד
לטובת עסקים נפגעי הקורונה
אופציה לגרייס לחצי שנה
עד חצי מיליון שח .אנו נבדוק עבורך בדיקה כפולה
קרן קורונה+קרן ערבות מדינה
לבדיקת זכאותך
תנאי סף ללא חזרות המחאות מהחשבון בשנה האחרונה
מחזור חודשי מעל 30,000 שח
לחץ כאן
שולח: מטה העצמאים והחברות. כתובת השולח:
On Wed, Apr 22, 2020 at 12:53 PM Moritz Strübe
wrote:
>
> Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc:
> > [..] as the
> > alternative would be dropping the AVR port.
>
> Shouldn't that work be sponsored by Microchip (or whoever currently owns
> AVR)? Arduino Inc. might also be highly interes
On Wed, 2020-04-22 at 19:52 +0200, Moritz Strübe wrote:
> Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc:
> > [..] as the
> > alternative would be dropping the AVR port.
>
> Shouldn't that work be sponsored by Microchip (or whoever currently owns
> AVR)? Arduino Inc. might also be highly interes
Am 22.04.2020 um 18:38 schrieb Jeff Law via Gcc:
[..] as the
alternative would be dropping the AVR port.
Shouldn't that work be sponsored by Microchip (or whoever currently owns
AVR)? Arduino Inc. might also be highly interested in continued
AVR-support.
Cheers
Morty
--
Redheads Ltd. Sof
On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote:
> Hi,
>
> I'm thinking about attempting to do the CC0 transition for the
> AVR port in my spare time. I've read the CC0Transition gcc wiki
> page, and as the AVR ISA does not have non-condition-code
> clobbering arithmetic instructio
Hi,
I'm thinking about attempting to do the CC0 transition for the
AVR port in my spare time. I've read the CC0Transition gcc wiki
page, and as the AVR ISA does not have non-condition-code
clobbering arithmetic instructions, concluded that I'd have to
follow the steps outlined for case #2.
Are t
Hello,
On Wed, 22 Apr 2020, Erick Ochoa wrote:
> in order for me to debug my issue, I'm going to have to refactor passes
> which directly reference optimize.
For debugging you can also work backwards: use -O3 and add -fno-xy
options. At least you then know (after disabling all O3 passes) that
On 22/04/2020 16:25, Jakub Jelinek wrote:
On Wed, Apr 22, 2020 at 04:17:56PM +0200, Philipp Tomsich wrote:
ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and
On Wed, Apr 22, 2020 at 04:17:56PM +0200, Philipp Tomsich wrote:
> ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
> common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
> common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and
> -Os. */
> common/config/arc/
On 4/22/20 4:01 PM, Erick Ochoa wrote:
Hello,
Does anyone know if the following text from the GCC internals [0] is outdated?
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2 and
also turns on the following optimization flags:
-fgcse-after-reload
-fipa-cp-
Thanks! I was looking for "optimize" (since that's the flag defined in
common.opt). But you can probably guess how many lines will match
"optimize".
On 22/04/2020 16:17, Philipp Tomsich wrote:
ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
common/common-target.h: OPT_LEVELS_3_PLUS, /
ptomsich@android:~/riscv/gcc/gcc$ git grep OPT_LEVELS_3
common/common-target.h: OPT_LEVELS_3_PLUS, /* -O3 and above. */
common/common-target.h: OPT_LEVELS_3_PLUS_AND_SIZE, /* -O3 and above and -Os.
*/
common/config/arc/arc-common.c:#define OPT_LEVELS_3_PLUS_SPEED_ONLY
OPT_LEVELS_3_PLUS
common
Hello,
Does anyone know if the following text from the GCC internals [0] is
outdated?
-O3
Optimize yet more. -O3 turns on all optimizations specified by -O2
and also turns on the following optimization flags:
-fgcse-after-reload
-fipa-cp-clone
-floop-interchange
-floop-
Hi All,
Le 21/04/2020 à 17:18, Joel Sherrill a écrit :
> On Tue, Apr 21, 2020 at 4:04 AM Richard Biener
> wrote:
>
>> On Mon, Apr 20, 2020 at 11:05 PM Jeff Law via Gcc wrote:
>>>
>>> On Mon, 2020-04-20 at 15:29 -0500, Joel Sherrill wrote:
On Mon, Apr 20, 2020, 3:13 PM Jeff Law w
24 matches
Mail list logo
