This is the next piece towards a fix for (the x86_64 ABI issues affecting)
PR 88873. This patch generalizes the recent tweak to ix86_expand_move
for setting the highpart of a TImode reg from a DImode source using
*insvti_highpart_1, to handle both DImode and DFmode sources, and also
use the
PR target/106966
gcc/ChangeLog:
* config/alpha/alpha.cc (alpha_emit_set_long_const):
Always use DImode when constructing long const.
gcc/testsuite/ChangeLog:
* gcc.target/alpha/pr106966.c: New test.
Bootstrapped and regression tested by Matthias on alpha-linux-gnu.
Uros.
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
--- Comment #16 from CVS Commits ---
The releases/gcc-12 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:4520e2dbc73262028ad556f732871565101ef615
commit r12-9770-g4520e2dbc73262028ad556f732871565101ef615
Author: Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
--- Comment #15 from CVS Commits ---
The releases/gcc-13 branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:27e421319efcf47280339fbc17c263f36c92eee6
commit r13-7561-g27e421319efcf47280339fbc17c263f36c92eee6
Author: Uros Bizjak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
--- Comment #14 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:337649c1660211db733c1ba34ae260b8c66a3578
commit r14-2503-g337649c1660211db733c1ba34ae260b8c66a3578
Author: Uros Bizjak
Date: Thu
On Wed, 28 Jun 2023, Tamar Christina wrote:
> Adding proper maintainers.
>
> > -Original Message-
> > From: Tamar Christina
> > Sent: Wednesday, June 28, 2023 2:46 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: nd ; Richard Earnshaw ;
> > Marcus Shawcroft ; Kyrylo Tkachov
> > ; Richard
On Wed, 12 Jul 2023 at 17:35, Tobias Burnus wrote:
>
> Now committed as r14-2462-g450b05ce54d3f0.
Hi Tobias,
The newly added tests in above commit -- alloc-11.c and alloc-12.c
seem to fail during execution
on armv8l-unknown-linux-gnueabihf:
Running libgomp:libgomp.c++/c++.exp ...
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657
Jose E. Marchesi changed:
What|Removed |Added
Last reconfirmed||2023-07-13
Ever confirmed|0
On Wed, 28 Jun 2023, Patrick Palka wrote:
> On Wed, Jun 28, 2023 at 11:50 AM Jason Merrill wrote:
> >
> > On 6/23/23 12:23, Patrick Palka wrote:
> > > On Fri, 23 Jun 2023, Jason Merrill wrote:
> > >
> > >> On 6/21/23 13:19, Patrick Palka wrote:
> > >>> When stepping through the variable/alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110655
Andrew Pinski changed:
What|Removed |Added
Component|c++ |preprocessor
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654
--- Comment #1 from Andrew Pinski ---
libccp has:
/* In C++, this is an error for invalid character in an identifier
because logically, the UTF-8 was converted to a UCN during
translation phase 1 (even though
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657
--- Comment #2 from Kris Van Hees ---
Created attachment 55536
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55536=edit
Pre-processed source file
> Is COND _LEN FMA ok for trunk? I can commit it without changing
> scatter store testcase fix.
>
> It makes no sense block cond Len fma support. The middle end support
> has already been merged.
Then just add a TODO or so that says e.g. "For some reason we exceed
the default code model's +-2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657
Jose E. Marchesi changed:
What|Removed |Added
CC||jemarch at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110657
Bug ID: 110657
Summary: BPF verifier rejects generated code due to invalid
stack access
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652
--- Comment #1 from Andrew Pinski ---
new_temp does look like it is initialized on the !costing_p path too ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #3 from dave.anglin at bell dot net ---
On 2023-07-13 9:46 a.m., redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
>
> --- Comment #2 from Jonathan Wakely ---
> Created attachment 55534
>-->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
Jakub Jelinek changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment
In this version I have made f-m-o able to also eliminate constant
moves in addition to the add constant instructions.
This increases the number of simplified/eliminated instructions and is
a good addition for RISC style ISAs where these are more common.
This has led to pr52146.c failing in x86,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109112
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Last
The following patch solves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109520
The patch was successfully bootstrapped and tested on x86-64, aarch64,
and ppc64le.
commit b175b4887f928118af997f6d4d75097a64dcec5d
Author: Vladimir N. Makarov
Date: Thu Jul 13 10:42:17 2023 -0400
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293
--- Comment #7 from Andrew Pinski ---
Half of this is fixed now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110539
--- Comment #10 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:285c9d042e90a7425b37697edc9ec93a1b03b486
commit r14-2501-g285c9d042e90a7425b37697edc9ec93a1b03b486
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:285c9d042e90a7425b37697edc9ec93a1b03b486
commit r14-2501-g285c9d042e90a7425b37697edc9ec93a1b03b486
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109520
--- Comment #5 from CVS Commits ---
The master branch has been updated by Vladimir Makarov :
https://gcc.gnu.org/g:b175b4887f928118af997f6d4d75097a64dcec5d
commit r14-2500-gb175b4887f928118af997f6d4d75097a64dcec5d
Author: Vladimir N. Makarov
No, I am just want to whether we have some CALL vectorization need len or mask
predication.
For example, Current GCC vectorization CALL onyl FMAX/FMIN/FMA/FNMA/FMS/FNMS
these CALL function
need length or mask predicate. I don't care about sin/cos/popcount...etc. We
just use full vector
Yes. Not always fail.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-07-13 22:39
To: juzhe.zh...@rivai.ai
CC: Robin Dapp; gcc-patches; jeffreyalaw; kito.cheng; palmer; palmer
Subject: Re: Re: [PATCH] RISC-V: Enable COND_LEN_FMA auto-vectorization
I didn’t try on local yet, but it sounds
I didn’t try on local yet, but it sounds like …the code size might larger
than normal case?
juzhe.zh...@rivai.ai 於 2023年7月13日 週四，19:50寫道：
> Could you tell me how to add the comment?
> I am not familiar with link/binutils stuff.
>
> --
> juzhe.zh...@rivai.ai
>
>
>
From my understanding, we dont have RVV instruction for fmax/fmin?
>
> Unless I'm misunderstanding, we do. The ISA manual says
>
> === Vector Floating-Point MIN/MAX Instructions
>
> The vector floating-point `vfmin` and `vfmax` instructions have the
> same behavior as the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110656
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
On Wed, Jul 12, 2023 at 5:14 PM Jeff Law wrote:
>
>
>
> On 7/12/23 03:12, Manolis Tsamis wrote:
> > On Mon, Jul 10, 2023 at 12:58 AM Hans-Peter Nilsson
> > wrote:
> >>
> >> On Sun, 9 Jul 2023, Hans-Peter Nilsson wrote:
> >>
> >>> On Thu, 15 Jun 2023, Manolis Tsamis wrote:
> >>>
> This is a
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Thursday, July 13, 2023 6:51 PM
To: Ju-Zhe Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH V2] SSA MATH: Support COND_LEN_FMA for
This is a new RTL pass that tries to optimize memory offset calculations
by moving them from add immediate instructions to the memory loads/stores.
For example it can transform this:
addi t4,sp,16
add t2,a6,t4
shl t3,t2,1
ld a2,0(t3)
addi a2,1
sd a2,8(t2)
into the following
I resent this with just the change in the comment.
OK to merge?
Manolis
On Tue, Jul 4, 2023 at 5:32 PM Manolis Tsamis wrote:
>
> On Mon, Jul 3, 2023 at 12:12 PM Robin Dapp wrote:
> >
> > Hi Manolis,
> >
> > that looks like a nice enhancement of what's already possible. The concern
> > I had
Currently the operations allowed for if conversion of a basic block with
multiple sets are few, namely REG, SUBREG and CONST_INT (as controlled by
bb_ok_for_noce_convert_multiple_sets).
This commit allows more operations (arithmetic, compare, etc) to participate
in if conversion. The target's
This is an extension of what was done in PR106590.
Currently if a sequence generated in noce_convert_multiple_sets clobbers the
condition rtx (cc_cmp or rev_cc_cmp) then only seq1 is used afterwards
(sequences that emit the comparison itself). Since this applies only from the
next iteration it
noce_convert_multiple_sets has been introduced and extended over time to handle
if conversion for blocks with multiple sets. Currently this is focused on
register moves and rejects any sort of arithmetic operations.
This series is an extension to allow more sequences to take part in if
On Thu, 13 Jul 2023 07:01:26 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
>
>
> On 7/13/23 01:47, Richard Biener wrote:
>> On Thu, Jul 13, 2023 at 1:30â¯AM éå±
å² wrote:
>>>
>>> I notice vectorizable_call in Loop Vectorizer.
>>> It's vectorizing CALL function for example like fmax/fmin.
>>>
On 7/13/23 01:47, Richard Biener wrote:
On Thu, Jul 13, 2023 at 1:30 AM 钟居哲 wrote:
I notice vectorizable_call in Loop Vectorizer.
It's vectorizing CALL function for example like fmax/fmin.
From my understanding, we dont have RVV instruction for fmax/fmin?
There's things like .POPCOUNT
On 7/12/23 17:30, 钟居哲 wrote:
I notice vectorizable_call in Loop Vectorizer.
It's vectorizing CALL function for example like fmax/fmin.
From my understanding, we dont have RVV instruction for fmax/fmin?
So for now, I don't need to support builtin call function vectorization
for RVV.
Am I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
--- Comment #2 from Jonathan Wakely ---
Created attachment 55534
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55534=edit
libstdc++: std::stoi etc. do not need C99 support
Dave, does this patch work for hppa64-hp-hpux11.11 ?
It should
Hi Martin,
Jiufu Guo via Gcc-patches writes:
> Hi,
>
> Martin Jambor writes:
>
>> Hi,
>>
>> On Tue, May 30 2023, Richard Biener wrote:
>>> On Mon, 29 May 2023, Jiufu Guo wrote:
>>>
Hi,
Previously, I was investigating some struct parameters and returns related
PRs
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 13?
-- >8 --
This fixes a crash when mangling an ADL-enabled call to a template-id
naming an unknown template (as per P0846R0).
PR c++/110524
gcc/cp/ChangeLog:
* mangle.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106966
--- Comment #13 from Matthias Klose ---
search for "test-summary"
https://buildd.debian.org/status/logs.php?pkg=gcc-12=alpha
12.3.0-5 is gcc-12 branch 20230630
12.3.0-6 is gcc-12 branch 20230707 with the proposed patch applied
comparing gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628
--- Comment #3 from Jan Hubicka ---
> -fdump-tree-all-blocks-details produced more than 100 dump files. Which
> one(s)
> do you want?
Can you just zip them an attach all?
Thank you!
Honza
On 7/12/23 07:05, senthilkumar.selva...@microchip.com wrote:
Hi,
I've been spending some (spare) time trying to get LRA working
for the avr target.
Thank you for addressing this problem.
The code you changing is very sensitive and was a source of multiple PRs
in the past. But I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110656
Bug ID: 110656
Summary: Floating point to char/short or bitfield conversions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Thu, Jul 13, 2023 at 2:19 PM Robin Dapp wrote:
>
> > Can you add testcases? Also the current restriction is because
> > the variants you add are not always correct and I don't see any
> > checks that the intermediate type doesn't lose significant bits?
>
> The testcases I wanted to add with a
> Maybe if you spent less time worried about inconsequential things
> like people's "offensive" language, and more time worried about how
> your country (you live in the Western world, correct?)
We are all responsible for our choice of words. We aren't responsible
for the actions or policies of
> Can you add testcases? Also the current restriction is because
> the variants you add are not always correct and I don't see any
> checks that the intermediate type doesn't lose significant bits?
The testcases I wanted to add with a follow-up RISC-V patch but
I can also try an aarch64 one.
So
On Thu, 13 Jul 2023 12:10:32 +0200
Mark Wielaard wrote:
> Hi Dave,
>
> On Wed, Jul 12, 2023 at 09:34:31AM -0500, Dave Blanchard wrote:
> > You know, if you useless cocksuckers [...]
>
> Please stop using this kind of language on this list. I know it is
> annoying if the spam filters didn't
On Thu, 13 Jul 2023, Tamar Christina wrote:
> > e7ac2b5f3db55de3dbbab7bd2bfe08388f4ec533..cab82d7960e5be517bba2
> > 621f7f4
> > > 888e7bf3c295 100644
> > > --- a/gcc/cfgloop.h
> > > +++ b/gcc/cfgloop.h
> > > @@ -272,6 +272,14 @@ public:
> > > the basic-block from being collected but its
> -Original Message-
> From: Richard Biener
> Sent: Thursday, July 13, 2023 12:49 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH 8/19]middle-end: updated niters analysis to handle
> multiple exits.
>
> On Wed, 28 Jun 2023, Tamar
> e7ac2b5f3db55de3dbbab7bd2bfe08388f4ec533..cab82d7960e5be517bba2
> 621f7f4
> > 888e7bf3c295 100644
> > --- a/gcc/cfgloop.h
> > +++ b/gcc/cfgloop.h
> > @@ -272,6 +272,14 @@ public:
> > the basic-block from being collected but its index can still be
> > reused. */
> >basic_block
Could you tell me how to add the comment?
I am not familiar with link/binutils stuff.
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-07-13 19:40
To: Juzhe-Zhong; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; palmer; palmer; jeffreyalaw
Subject: Re: [PATCH] RISC-V: Enable COND_LEN_FMA
On Wed, 28 Jun 2023, Tamar Christina wrote:
> Hi All,
>
> For early break vectorization we have to update niters analysis to record and
> analyze all exits of the loop, and so all conds.
>
> The niters of the loop is still determined by the main/natural exit of the
> loop
> as this is the O(n)
I have no ideal.
This testcase cause link ICE:
FAIL: gcc.target/riscv/rvv/autovec/gather-scatter/scatter_store_run-7.c (test
for excess errors)
Excess errors:
scatter_store_run-7.c:(.text.startup+0xc8e): relocation truncated to fit:
R_RISCV_GPREL_I against `.LANCHOR1'
only LMUL = M8 will cause
Hi Juzhe,
thanks, no complaints from my side apart from one:
> +/* { dg-additional-options "-mcmodel=medany" } */
Please add a comment why we need this.
Regards
Robin
Enable COND_LEN_FMA auto-vectorization for floating-point FMA
auto-vectorization **NO** ffast-math.
Since the middle-end support has been approved and I will merge it after I
finished bootstrap && regression on X86.
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624395.html
Now, it's time
On Wed, 28 Jun 2023, Tamar Christina wrote:
> Hi All,
>
> This patch splits off the vectorizer's understanding of the main loop exit off
> from the normal loop infrastructure.
>
> Essentially we're relaxing the use of single_exit() in the vectorizer as we
> will
> no longer have a single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110655
Bug ID: 110655
Summary: incorrect position of indicator in error message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
On 2023/6/16 5:13 PM, Thomas Schwinge wrote:
> OK with one small change, please -- unless there's a reason for doing it
> this way:
>
>> --- a/gcc/fortran/trans-openmp.cc
>> +++ b/gcc/fortran/trans-openmp.cc
>> @@ -4677,6 +4677,12 @@ gfc_trans_oacc_construct (gfc_code *code)
>> break;
>>
On Thu, 13 Jul 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> Hi, Richard and Richi.
>
> Previous patch we support COND_LEN_* binary operations. However, we didn't
> support COND_LEN_* ternary.
>
> Now, this patch support COND_LEN_* ternary. Consider this following case:
>
>
Hi,
On 13/07/2023 10:48, David Malcolm wrote:
(apologies for top-posting; I'm on vacation and don't have my usual email setup)
Sounds interesting, but I'm having difficulty imagining exactly what
you have in mind.
Can you post one or more concrete examples of buggy code that would be
caught by
On Thu, Jul 13, 2023 at 12:31 PM Robin Dapp via Gcc-patches
wrote:
>
> Hi,
>
> the recent changes that allowed multi-step conversions for
> "non-packing/unpacking", i.e. modifier == NONE targets included
> promoting to-float and demoting to-int variants. This patch
> adds demoting to-float and
Sure and committed, thanks Kito.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, July 13, 2023 5:19 PM
To: Li, Pan2
Cc: Jeff Law ; gcc-patches@gcc.gnu.org;
juzhe.zh...@rivai.ai; rdapp@gmail.com; Wang, Yanzhang
Subject: Re: [PATCH v2] RISC-V: Refactor riscv mode after
On Thu, Jul 13, 2023 at 12:15 PM Tejas Belagod wrote:
>
> On 7/3/23 1:31 PM, Richard Biener wrote:
> > On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote:
> >>
> >> On 6/29/23 6:55 PM, Richard Biener wrote:
> >>> On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod
> >>> wrote:
>
>
>
>
Hi,
the recent changes that allowed multi-step conversions for
"non-packing/unpacking", i.e. modifier == NONE targets included
promoting to-float and demoting to-int variants. This patch
adds demoting to-float and promoting to-int handling.
Bootstrapped and regtested on x86 and aarch64.
A
Implement vcaddq, vhcaddq using the new MVE builtins framework.
2023-07-13 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vcaddq_rot90)
(vcaddq_rot270, vhcaddq_rot90, vhcaddq_rot270): New.
* config/arm/arm-mve-builtins-base.def (vcaddq_rot90)
Implement vcmulq using the new MVE builtins framework.
2023-07-13 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vcmulq, vcmulq_rot90)
(vcmulq_rot180, vcmulq_rot270): New.
* config/arm/arm-mve-builtins-base.def (vcmulq, vcmulq_rot90)
Factorize vcmlaq builtins so that they use parameterized names.
2023-17-13 Christophe Lyon
gcc/
* config/arm/arm_mve_builtins.def (vcmlaq_rot90_f)
(vcmlaq_rot270_f, vcmlaq_rot180_f, vcmlaq_f): Add "_f" suffix.
* config/arm/iterators.md (MVE_VCMLAQ_M): New.
Factorize vcmulq builtins so that they use parameterized names.
We can merged them with vcadd.
2023-07-13 Christophe Lyon
gcc/:
* config/arm/arm_mve_builtins.def (vcmulq_rot90_f)
(vcmulq_rot270_f, vcmulq_rot180_f, vcmulq_f): Add "_f" suffix.
*
Factorize vcaddq, vhcaddq so that they use the same parameterized
names.
To be able to use the same patterns, we add a suffix to vcaddq.
Note that vcadd uses UNSPEC_VCADDxx for builtins without predication,
and VCADDQ_ROTxx_M_x (that is, not starting with "UNSPEC_"). The
UNPEC_* names are also
Implement vcmlaq using the new MVE builtins framework.
2023-07-13 Christophe Lyon
gcc/
* config/arm/arm-mve-builtins-base.cc (vcmlaq, vcmlaq_rot90)
(vcmlaq_rot180, vcmlaq_rot270): New.
* config/arm/arm-mve-builtins-base.def (vcmlaq, vcmlaq_rot90)
This tests currently expect a directive containing .fpu fpv5-sp-d16
and thus may fail if the test is executed for instance with
-march=armv8.1-m.main+mve.fp+fp.dp
This patch accepts either fpv5-sp-d16 or fpv5-d16 to avoid the failure.
2023-06-28 Christophe Lyon
gcc/testsuite/
If GCC is configured with the default (soft) -mfloat-abi, and we don't
override the target_board test flags appropriately,
gcc.target/arm/mve/general-c/nomve_fp_1.c fails for lack of
-mfloat-abi=softfp or -mfloat-abi=hard, because it doesn't use
dg-add-options arm_v8_1m_mve (on purpose, see
On 7/3/23 1:31 PM, Richard Biener wrote:
On Mon, Jul 3, 2023 at 8:50 AM Tejas Belagod wrote:
On 6/29/23 6:55 PM, Richard Biener wrote:
On Wed, Jun 28, 2023 at 1:26 PM Tejas Belagod wrote:
From: Richard Biener
Date: Tuesday, June 27, 2023 at 12:58 PM
To: Tejas Belagod
Cc:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110654
Bug ID: 110654
Summary: inconsistent error message in presence of unexpected
encoded characters
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
Hi Dave,
On Wed, Jul 12, 2023 at 09:34:31AM -0500, Dave Blanchard wrote:
> You know, if you useless cocksuckers [...]
Please stop using this kind of language on this list. I know it is
annoying if the spam filters didn't catch some obvious scam message.
But you are not helping anybody by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110646
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> I'll split out the checks needed for std::stoi etc.
See Bug 110653 for the library improvements.
The following makes sure that FP x > y ? x : y style max/min operations
are if-converted at the GIMPLE level. While we can neither match
it to MAX_EXPR nor .FMAX as both have different semantics with IEEE
than the ternary ?: operation we can make sure to maintain this form
as a COND_EXPR so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
Hi Carl,
on 2023/7/8 04:18, Carl Love wrote:
>
> GCC maintainers:
>
> Version 3, added code to altivec_resolve_overloaded_builtin so the
> correct instruction is selected for the size of the second argument.
> This restores the instruction counts to the original values where the
> correct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110653
Bug ID: 110653
Summary: Support std::stoi etc. without C99 APIs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #1 from Iain Sandoe ---
> (In reply to Rainer Orth from comment #0)
>> When bootstrapping current trunk on macOS 14.0 beta 3 with Xcode 15 beta 4,
>> every single fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
--- Comment #1 from Iain Sandoe ---
(In reply to Rainer Orth from comment #0)
> When bootstrapping current trunk on macOS 14.0 beta 3 with Xcode 15 beta 4,
> every single fortran link test FAILs like
> * Get rid of %(libgcc) in
Hi,
I've been spending some (spare) time checking what it would take to
make LRA work for the avr target.
Right after I removed the TARGET_LRA_P hook disabling LRA, building
libgcc failed with a weird ICE. On the avr, the stack pointer (SP)
is not used to access stack slots -
v-gcc/xg++
COLLECT_LTO_WRAPPER=/tmp/gb/./prev-gcc/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/slyfox/dev/git/gcc/configure --disable-multilib
--enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230713 (experimental) (GCC)
On Wed, 12 Jul 2023 at 21:42, Ken Matsui wrote:
>
> On Wed, Jul 12, 2023 at 3:01 AM Jonathan Wakely wrote:
> >
> > On Mon, 10 Jul 2023 at 06:51, Ken Matsui via Libstdc++
> > wrote:
> > >
> > > Hi,
> > >
> > > Here is the benchmark result for is_pointer:
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110651
Bug ID: 110651
Summary: libgfortran.spec links twice with libgcc spec
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
Hmmm, anyway, I guess it's not worth spending any more of your time,
LGTM for v3 :)
On Thu, Jul 13, 2023 at 5:10 PM Li, Pan2 via Gcc-patches
wrote:
>
> It can pass the selftest with below diff based on v3, but got ICE when build
> newlib.
>
>
It can pass the selftest with below diff based on v3, but got ICE when build
newlib.
/home/pli/repos/gcc/222/riscv-gnu-toolchain/newlib/newlib/libc/time/../time/strftime.c:1426:1:
internal compiler error: in reg_overlap_mentioned_p, at rtlanal.cc:1928
1426 | }
| ^
0x87241f
When trying to bootstrap current trunk on macOS 14.0 beta 3 with Xcode
15 beta 4, the build failed running mklink in stage 2:
unset CC ; m2/boot-bin/mklink -s --langc++ --exit --name m2/mc-boot/main.cc
/vol/gcc/src/hg/master/darwin/gcc/m2/init/mcinit
dyld[55825]: Library not loaded:
Pass already evaluated class container argument from
gfc_conv_procedure_call down to gfc_add_finalizer_call through
gfc_deallocate_scalar_with_status and gfc_deallocate_with_status,
to avoid repeatedly evaluating the same data reference expressions
in the generated code.
PR fortran/110618
Hi, Richard.
>> either before or after white-space seems broken.
I use clang-format with the format in gcc/contrib/format.
I manually adjust it, could you take a look to see whether the format issue is
still there?
I have address all your comments with V2 patch:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110624
--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #5 from Iain Sandoe ---
> Here, I will test on some earlier Darwin versions - but would welcome
> confirmation that it fixes the XC15 issue.
I've done that now and could
101 - 200 of 250 matches
Mail list logo
