[Bug c/100854] TS 18661-3 and backwards-incompatible setting of __FLT_EVAL_METHOD__

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100854

--- Comment #6 from Andrea Corallo  ---
"jasonwucj at gcc dot gnu.org"  writes:

[...]

>
> I guess this issue has been resolved by newlib implementation. :)
>
> Refer to the discussions on:
> https://sourceware.org/pipermail/newlib/2021/018471.html
> https://sourceware.org/pipermail/newlib/2022/019522.html
>
> The patches have been committed into newlib code base and it should be 
> workable
> now.


Confirm

  Andrea

[Bug jit/99126] Compilation ICE trying insert trap

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126

--- Comment #9 from Andrea Corallo  ---
"dmalcolm at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
>
> --- Comment #8 from David Malcolm  ---
> (In reply to CVS Commits from comment #6)
>> The master branch has been updated by David Malcolm :
>> 
>> https://gcc.gnu.org/g:b258e263e0d74ca1f76aeaac5f4d1abef6b13707
>> 
>> commit r11-7288-gb258e263e0d74ca1f76aeaac5f4d1abef6b13707
>
> Fixed on trunk for gcc 11.  Andrea, do you need my to backport this?  What GCC
> versions are you targeting with your emacs project?

We are targetting them all, but to my test I could not trigger this bug
on GCC9 so I guess we could backport on GCC10 only?

[Bug jit/99126] Compilation ICE trying insert trap

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126

--- Comment #5 from Andrea Corallo  ---
"dmalcolm at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126
>
> David Malcolm  changed:
>
>What|Removed |Added
> 
>  Status|NEW |ASSIGNED
>
> --- Comment #4 from David Malcolm  ---
> Am testing a fix.

Nice!

As a side question: do you guys think disabling "isolate-paths" is the
right workaround for the affected versions or might have harmful side
effects?

Thanks

  Andrea

[Bug jit/99126] Compilation ICE trying insert trap

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126

--- Comment #1 from Andrea Corallo  ---
This is the bt of how the C front-end is initializing these
declarations:

#0  set_builtin_decl (implicit_p=, 
decl=, 
fncode=) at ../../gcc/tree.h:5662
#1  def_builtin_1 (fncode=, name=, 
fntype=, libtype=, both_p=, 
fallback_p=, nonansi_p=false, 
fnattrs=, implicit_p=true,
fnclass=BUILT_IN_NORMAL)
at ../../gcc/c-family/c-common.c:4729
#2  0x00a291c9 in c_define_builtins (
va_list_arg_type_node=, va_list_ref_type_node=)
at ../../gcc/builtins.def:933

Thinking loud: I guess in jit-builtins.c we should loop once over all
the builtins calling 'set_builtin_decl'?  Probably in the constructor
for gcc::jit::builtins_manager?

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931

--- Comment #10 from Andrea Corallo  ---
Following suggestions I'm testing the attached emitting the following
for long branches where LE cannot cover:

subslr, #1
bmi .L2

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931

--- Comment #9 from Andrea Corallo  ---
Right I'll rework the patch.

Thanks

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931

--- Comment #6 from Andrea Corallo  ---
I'm testing the attached fix.

[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931

--- Comment #4 from Andrea Corallo  ---
"jakub at gcc dot gnu.org via Gcc-bugs"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931
>
> --- Comment #3 from Jakub Jelinek  ---
> And the problem is not something not being multiple of 2, but just out of 
> range
> jump.  The code has:
>   10:   f04e e001   dls lr, lr
>   14:   9900ldr r1, [sp, #0]
> ...
> 130e:   f00f c7ff   le  lr, 316 
> if I manually move .L2 label so that it doesn't complain anymore, which means
> it can jump only to -4096 bytes from the end of the le instruction, but it was
> supposed to jump to foo+0x14, i.e. to 4862 bytes before the end of the le insn
> at 0x1312.
> So, either the computation of the instruction sizes is incorrect, or for this
> kind of branch nothing checks whether the distance is in range.

I think this (the second) is the case.

[Bug target/96372] [11 regression] arm/ivopts.c fails since r11-2012

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96372

--- Comment #2 from Andrea Corallo  ---
I see what's going on, originally this object-size text <= 20 test was
gated with target 'arm_thumb2'.

My patch to exclude LOB targets replaced that with
'arm_thumb2_ok_no_arm_v8_1_lob', unfortunatelly this is relying on
'arm_thumb2_ok' that has a different semantic compared to the original
'arm_thumb2'.

I'll post the patch I'm testing.  Looks nothing serious to me tho.

  Andrea

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

--- Comment #9 from Andrea Corallo  ---
"marxin at gcc dot gnu.org via Gcc-bugs"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615
>
> --- Comment #8 from Martin Liška  ---
> (In reply to Andrea Corallo from comment #7)
>> Thanks Martin, I can confirm that also the bootstrap is back okay.
>
> You're welcome.
> Can you please point me to Emacs JIt usage? I'm curious what for is libgccjit
> used in the project?

That's a feature branch that being integrated as is planed to have it in
for 28.

Essentially we use it to compile .el files into shared libraries we then
load to have Elisp executed as native code.

Here is the recording for my presentation at LPC2020/Cauldron:


and this is my development blog:
.

  Andrea

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

--- Comment #7 from Andrea Corallo  ---
Thanks Martin, I can confirm that also the bootstrap is back okay.

[Bug jit/98615] libgccjit crash while freeing 'clone_info' in 'cgraph_c_finalize'

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98615

--- Comment #4 from Andrea Corallo  ---
Thank you for looking into it!  I tried my self but with no success

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092

--- Comment #10 from Andrea Corallo  ---
"acoplan at gcc dot gnu.org via Gcc-bugs"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #9 from Alex Coplan  ---
> Thanks for fixing this Andrea! FWIW I can reproduce the ICE with the same
> testcase and options on the head of the GCC 10 branch (contrary to my first
> message).

Hi Alex,

I'll test the patch also on gcc-10 then so we can have it there too (it
should apply).

Thanks for checking!

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092

--- Comment #7 from Andrea Corallo  ---
"rsandifo at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #6 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Andrea Corallo from comment #5)
>> "rsandifo at gcc dot gnu.org via Gcc-bugs" 
>> writes:
>> 
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>> >
>> > --- Comment #4 from rsandifo at gcc dot gnu.org > > gnu.org> ---
>> > (In reply to Andrea Corallo from comment #3)
>> >> Created attachment 49710 [details]
>> >> PR97092.patch
>> >> 
>> >> What is going on is that in 'update_costs_from_allocno' we try to
>> >> identify the smallest mode using narrower_subreg_mode to then update the
>> >> costs.
>> >> 
>> >> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> >> are not ordered we ICE in 'paradoxical_subreg_p'.
>> >> 
>> >> Now I don't know if the strategy we want is:
>> >> 
>> >> - In 'update_costs_from_allocno' when modes are not ordered instead of
>> >>   calling 'narrower_subreg_mode' just keep the current one.
>> >> 
>> >> - Always select the cheapest mode in terms of cost.
>> >> 
>> >> The attached I'm testing implements the second.
>> 
>> Hi Richard,
>> 
>> thanks for commenting.
>> 
>> > I think instead we should consider recomputing “mode” in each
>> > iteration of the loop, rather than carry over the result of
>> > previous iterations.  I.e. use:
>> >
>> > mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>> >  ALLOCNO_MODE (cp->second));
>> 
>> Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
>> (cp->second) always satisfying 'ordered_p'?
> Yeah, I think so.  If the modes aren't ordered then we shouldn't
> create a copy between them.

Great, I'm going to test the suggested then.

Thanks

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092

--- Comment #5 from Andrea Corallo  ---
"rsandifo at gcc dot gnu.org via Gcc-bugs" 
writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #4 from rsandifo at gcc dot gnu.org  
> ---
> (In reply to Andrea Corallo from comment #3)
>> Created attachment 49710 [details]
>> PR97092.patch
>> 
>> What is going on is that in 'update_costs_from_allocno' we try to
>> identify the smallest mode using narrower_subreg_mode to then update the
>> costs.
>> 
>> The two modes involved here are E_DImode and E_VNx2QImode, cause these
>> are not ordered we ICE in 'paradoxical_subreg_p'.
>> 
>> Now I don't know if the strategy we want is:
>> 
>> - In 'update_costs_from_allocno' when modes are not ordered instead of
>>   calling 'narrower_subreg_mode' just keep the current one.
>> 
>> - Always select the cheapest mode in terms of cost.
>> 
>> The attached I'm testing implements the second.

Hi Richard,

thanks for commenting.

> I think instead we should consider recomputing “mode” in each
> iteration of the loop, rather than carry over the result of
> previous iterations.  I.e. use:
>
> mode = narrower_subreg_mode (ALLOCNO_MODE (cp->first),
>  ALLOCNO_MODE (cp->second));

Are we garanteed to have ALLOCNO_MODE (cp->first) and ALLOCNO_MODE
(cp->second) always satisfying 'ordered_p'?  In case not I think we
can't use 'narrower_subreg_mode'.

I thought we select the smallest because is the cheapest, so not to use
'narrower_subreg_mode' I compared directly the costs.

> instead of:
>
> mode = narrower_subreg_mode (mode, ALLOCNO_MODE (cp->second));
>
> Before g:e2323a2b77c91d1ba8194b01e6deaa2e00f15990 “mode”
> was a loop invariant, so it made sense to set it outside
> the loop.  I think the intention of that patch was to use
> the smaller of the two modes involved in the copy, and carrying
> the result over to future copies might have been unintentional.
>
> The difficulty with carrying the mode over to later copies
> is that the costs then become dependent on the order of
> the copies, whereas I'm not sure the order of the copies
> is significant.

I see

Thanks!

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092

--- Comment #3 from Andrea Corallo  ---
What is going on is that in 'update_costs_from_allocno' we try to
identify the smallest mode using narrower_subreg_mode to then update the
costs.

The two modes involved here are E_DImode and E_VNx2QImode, cause these
are not ordered we ICE in 'paradoxical_subreg_p'.

Now I don't know if the strategy we want is:

- In 'update_costs_from_allocno' when modes are not ordered instead of
  calling 'narrower_subreg_mode' just keep the current one.

- Always select the cheapest mode in terms of cost.

The attached I'm testing implements the second.

  Andrea

[Bug rtl-optimization/97092] [10/11 Regression] aarch64, SVE: ICE in ira-color.c since r10-4752-g2d56600c

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092

--- Comment #2 from Andrea Corallo  ---
"akrl at gcc dot gnu.org via Gcc-bugs"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97092
>
> --- Comment #1 from akrl at gcc dot gnu.org ---
> Hi all,
>
> I can't reproduce this on current master (76a1719f0ff), I guess has been 
> fixed in the meanwhile?

As not said I swapped two reproducers.  I *can* reproduce the issue on
current master.

  Andrea

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968

--- Comment #8 from Andrea Corallo  ---
"iains at gcc dot gnu.org via Gcc-bugs"  writes:
[...]
> unfortunately, I've not been able to test since you applied this - currently
> bootstrap is broken on aarch64-darwin for reasons outside our control (new
> security provisions stopping the gcc/build/gen* programs from running).  If it
> could stay open for a few more days, while we try to find a fix for that - (or
> close it and we can reopen if needed).

Sure no rush, thanks for testing it!

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

[andrea.corallo at arm dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968

--- Comment #6 from Andrea Corallo  ---
I believe f5e73de00e9c853ce65333efada7409b0d00f758 should have fixed
this.

Okay to close?

Thanks

  Andrea

[Bug target/96968] aarch64 : ICE in vregs or expand pass, lowering __builtin_aarch64_get_{fpcr,fpsr,fpcr64,fpsr64}

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96968

--- Comment #4 from Andrea Corallo  ---
Patch posted at:

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553882.html

[Bug target/96375] [11 regression] arm/lob[2-5].c fail on some configurations

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96375

--- Comment #5 from Andrea Corallo  ---
"clyon at gcc dot gnu.org"  writes:

> Just that I have no config where lob[16].c are supported because when running
> arm-none-eabi tests I override -mcpu. When I don't override -mcpu, I don't
> enable multilibs which in turn causes some effective-target checks failures.
> Hence I'm wondering what toolchain settings you are using to run these new
> tests?

I'm testing these on arm-none-eabi having GCC configure with:
--target=arm-none-eabi --with-newlib --with-multilib-list=rmprofile.
And invoking it with -march=armv8.1-m.main -mthumb.

  Andrea
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

[Bug target/96375] [11 regression] arm/lob[2-5].c fail on some configurations

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96375

--- Comment #3 from Andrea Corallo  ---
"clyon at gcc dot gnu.org"  writes:
> Hi,

Hi,

> It does fix the FAIL, thanks.

Thanks for testing it!

> I suspect you also want to add -mthumb to
> check_effective_target_arm_v8_1_lob_ok for consistency.

isn't the patch already doing this?

> In practice, how do you exercise these tests given that with the arm-eabi
> configurations I'm testing they are unsupported because I override -mcpu?

Not sure I understand, what is the problem if the test is not supported
with a specific -mcpu?

Thanks

  Andrea

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #13 from Andrea Corallo  ---
"aoliva at gcc dot gnu.org"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720
>
> Alexandre Oliva  changed:
>
>What|Removed |Added
> 
>   Attachment #48886|0   |1
> is obsolete||
>   Attachment #48889|0   |1
> is obsolete||
>
> --- Comment #12 from Alexandre Oliva  ---
> Created attachment 48891
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48891=edit
> another try
>
> Sorry about the bugs in the previous patch.
>
> Besides integrating your s/_1/_list/ fix (thanks), I understood why you needed
> the [set $opts], but the intended logic was to have a [set $i] in the previous
> line.  I didn't know about this use for "set", though; I would have gone for
> "eval set opts \$$i" instead.  I liked set opts [set $i] much better.  Thanks
> for cluing me into it!
>
> Would you be so kind as to confirm that this slightly modified version still
> works for you, and that I didn't miss any of your changes?

Hi Alexandre,

I confirm the patch works here.

Just a small nit, whitespace-mode shows me trailing spaces at the end of
gcc_adjust_linker_flags_list.

> Thanks,

Thank you for the fix!

  Andrea

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #11 from Andrea Corallo  ---
Hi Alexandre,

thanks for the patch, the version attached does the job here for the
mentioned testcase.

I touched a couple of lines, please have a look as my tcl is quite
limited.

  Andrea

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #9 from Andrea Corallo  ---
"clyon at gcc dot gnu.org"  writes:

> I guess that's the "testglue" object file added by Dejagnu when
> needs_status_wrapper is set in the .exp file.

Yep, is set in libs in proc 'gcc_target_compile'

If I print all $options in 'gcc_target_compile' I've:

{additional_flags=-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never 
-fdiagnostics-urls=never } additional_flags=-mthumb libs=gcc_tg.o
{ldflags=-Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main -Wl,-wrap,abort}
timeout=300 {compiler=.../gcc/xgcc -B.../gcc/}

[Bug testsuite/95720] [11 Regression] New dump output filename strategy invalidates tests

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95720

--- Comment #4 from Andrea Corallo  ---
"aoliva at gcc dot gnu.org"  writes:

> --- Comment #3 from Alexandre Oliva  ---
> akrl, any clue as to where this .out is coming from in your runs?  I get .exe
> in my arm test runs; I don't see anything that selects .out, only .exe; and 
> the
> driver disregards the .exe suffix in executable output, regardless of 
> platform,
> when recognizing that the single source has the same basename as the linker
> output.

Hi Alexandre,

Apologies I guess the provided example was not the best.

Here what I've specifically for the mentioned testcase, this is the
compiler invocation:

.../build/gcc/xgcc -B.../build/gcc/
.../src/gcc/gcc/testsuite/gcc.target/arm/memset-inline-1.c gcc_tg.o
-march=armv8.1-m.main -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -save-temps -O2 -fno-inline -ffat-lto-objects
-fno-ident -specs=rdimon.specs -Wa,-mno-warn-deprecated
-Wl,-Ttext-segment=0x0050 -Wl,-wrap,exit -Wl,-wrap,_exit -Wl,-wrap,main
-Wl,-wrap,abort -lm -o ./memset-inline-1.exe

The assembly file generated is called
'memset-inline-1-memset-inline-1.s' but IIUC the expected one by proc
'scan-assembler-not' (scanasm.exp:92) is 'memset-inline-1.s' (I'm just
printing $output_file).

Hope it helps.

  Andrea

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #31 from Andrea Corallo  ---
I confirm master now builds for me aarch64-none-elf.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #23 from Andrea Corallo  ---
"foreese at gcc dot gnu.org"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
>
> --- Comment #21 from Fritz Reese  ---
> Created attachment 48332
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48332=edit
> Patch to protect trigd functions based on system availability
>
> Patch for trigd include pieces to check for HAVE_XXX[*]. If a required piece 
> is
> not defined, the function is replaced with simply a runtime_error().
>
> @akrl and @ktkachov, please combine this with Jakub's patch and see how the
> build goes. Like Jakub I am also on x86_64-linux and it is difficult to
> exercise all the conditions.

Hi,

I confirm that combining the two patches works for me for building
aarch64-none-elf now.
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.

[Bug libfortran/94694] [10 Regression][libgfortran] libgfortran does not compile on bare-metal aarch64-none-elf (newlib)

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694

--- Comment #10 from Andrea Corallo  ---
"jakub at gcc dot gnu.org"  writes:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
>
> --- Comment #9 from Jakub Jelinek  ---
> Created attachment 48326
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48326=edit
> gcc10-pr94694.patch
>
> Completely untested full patch.  Will try to test it on x86_64-linux where it
> hopefully shouldn't change anything, but have no (easy) way to test on targets
> where it is actually needed.

Hi Jakub,

great I'll do some testing too then thanks.

[Bug target/94530] [9/10 Regression] ICE: SIGSEGV in rhs_regno (rtl.h:1924) with -Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530

--- Comment #7 from Andrea Corallo  ---
Hi,

should be fixed now by 8a4436d89bfa:

"aarch64: Fix valid_src_p for use of uninitialized value".

Thanks

  Andrea

[Bug target/94530] [9/10 Regression] ICE: SIGSEGV in rhs_regno (rtl.h:1924) with -Os -mcpu=falkor -mpc-relative-literal-loads -mcmodel=large

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94530

Andrea Corallo  changed:

   What|Removed |Added

 CC||andrea.corallo at arm dot com

--- Comment #2 from Andrea Corallo  ---
I'm going to fix it.

And I'm going to investigate also why I can't assign the but to my self...

[Bug target/94144] New: ICE on aarch64-linux-gnu: in aarch64_print_operand at gcc/config/aarch64/aarch64.c:9528

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94144

Bug ID: 94144
   Summary: ICE on aarch64-linux-gnu: in aarch64_print_operand at
gcc/config/aarch64/aarch64.c:9528
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrea.corallo at arm dot com
  Target Milestone: ---

The compiler get ICE in final when compiling at -O3 the code below.

Note: this appears to be a regression to gcc 9.

---

int a, b, z;
int c(int d, int e) { return d && e > 0 && d > 5 - e ? 0 : d + e; }
int k();
void h(int);
void f(short d) {
  int g = !(0 < d);
  h(d);
  if (b) {
unsigned i[1];
i[0] = g = 0;
for (; g <= 8; g++)
  d || k();
if (c(!(i[0] <= z) >= d, d) != a)
  k();
  }
}

---

during RTL pass: final
test.c: In function ‘f’:
test.c:20:1: internal compiler error: in aarch64_print_operand, at
config/aarch64/aarch64.c:9528
   20 | }
  | ^
0xde435f aarch64_print_operand
../../gcc/config/aarch64/aarch64.c:9528
0x85acfb output_operand(rtx_def*, int)
../../gcc/final.c:4051
0x85b76f output_asm_insn(char const*, rtx_def**)
../../gcc/final.c:3944
0x85f06f output_asm_insn(char const*, rtx_def**)
../../gcc/final.c:3840
0x85f06f final_scan_insn_1
../../gcc/final.c:3106
0x85f537 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/final.c:3152
0x85f7ff final_1
../../gcc/final.c:2020
0x85ff73 rest_of_handle_final
../../gcc/final.c:4658
0x85ff73 execute
../../gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug jit/91928] New: libgccjit fails on subsequent compilations in ipa-cp

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91928

Bug ID: 91928
   Summary: libgccjit fails on subsequent compilations in ipa-cp
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: andrea.corallo at arm dot com
  Target Milestone: ---

Created attachment 46971
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46971=edit
repro.c gziped (3Mb uncompressed)

libgccjit get ice in subsequent compilations.
the attached reproducer compiles code A then B and then recompiling A crash.
I struggle to create a minimal artificial reproducer so I attach the
auto-generated one that is rather big.
I'm quite sure this is related to static structures we store into
gcc/ipa-prop.c and I'm currently looking into it.

$ gcc repro.c -O0 -g3 -o repro -lgccjit
$ ./repro 
compiling A
compiling B
compiling A
during IPA pass: cp
libgccjit.so: error: in operator[], at vec.h:859
0x7f54abfc412f vec::operator[](unsigned int)
../../gcc/vec.h:859
0x7f54abfc412f vec::operator[](unsigned int)
../../gcc/vec.h:1425
0x7f54abfc412f ipcp_update_bits
../../gcc/ipa-prop.c:5026
0x7f54abfc412f ipcp_transform_function(cgraph_node*)
../../gcc/ipa-prop.c:5202
0x7f54ac6888e4 execute_one_ipa_transform_pass
../../gcc/passes.c:2231
0x7f54ac688a59 execute_all_ipa_transforms(bool)
../../gcc/passes.c:2270
0x7f54ac107000 cgraph_node::expand()
../../gcc/cgraphunit.c:2187
0x7f54ac1076d4 expand_all_functions
../../gcc/cgraphunit.c:2332
0x7f54ac1083dc symbol_table::compile()
../../gcc/cgraphunit.c:2688
0x7f54ac10887d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2868
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

This reproducer output was run on the current trunk (gcc 10 37584e9) but I see
it affect at least also the gcc-9-branch.

[Bug target/83033] aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033

--- Comment #2 from Andrea Corallo  ---
Patch proposed
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01402.html

[Bug target/83033] aarch64/cortex-a57-fma-steering.c: 3 * poor C++ style ?

[andrea.corallo at arm dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83033

Andrea Corallo  changed:

   What|Removed |Added

 CC||andrea.corallo at arm dot com

--- Comment #1 from Andrea Corallo  ---
Path proposed
https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01402.html