https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #54 from Tomas Kalibera ---
(In reply to Jakub Jelinek from comment #53)
> Backported to 7.x, please test it.
Thanks! I tested the default behavior with DPOSV and reference LAPACK, where it
worked fine. Also with all of CRAN+BIOC R p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #11 from Tomas Kalibera ---
Even restoring the state that LAPACK/BLAS works but without providing
guarantees would help short-term, and I think this could be in line with the
goal of best performance within the standard.
At least in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #13 from Tomas Kalibera ---
I understand the compiler may not know and typically does not whether the
called function accepts "character(len=1)" or "character(len=*)", so it may
have to pass the 1. But the situation where I suggest no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #20 from Tomas Kalibera ---
(In reply to rguent...@suse.de from comment #19)
> I don't see how -fno-optimize-sibling-calls helps in a systematic way.
> It might obfuscate a specific example enough to make it work, but...?
There is o
erity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 51070
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51070&act
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238
--- Comment #2 from Tomas Kalibera ---
I started writing that email, but on the way I found that one should add
-D__USE_MINGW_ACCESS also BOOT_CXXFLAGS, which I have neither done nor tested.
The problem I debugged required only required adding t
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 52770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52770&action=edit
Reproducible example to compile and execute (see comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105198
--- Comment #11 from Tomas Kalibera ---
Thanks for the very quick fix! I confirm that when R is built with the fixed
version of GCC 12, the R testcase for MASS is fixed, it works with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #24 from Tomas Kalibera ---
FWIW, predict-22.c from GCC test suite is an example for which
reorder-blocks-and-partition has an effect (creates foo.cold) in GCC trunk, up
to but excluding
https://gcc.gnu.org/g:a187edd2b437fc9571d57f7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #26 from Tomas Kalibera ---
> should do the job. Tomas, can you give it a try?
Thanks, so far I tried it only on predict-22.c and it works (with a fixed comma
as below), enables the optimization. I will do more testing tomorrow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #27 from Tomas Kalibera ---
> > should do the job. Tomas, can you give it a try?
>
> Thanks, so far I tried it only on predict-22.c and it works (with a fixed
> comma as below), enables the optimization. I will do more testing tom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #28 from Tomas Kalibera ---
I've also tested the patch with GCC 10.3 (with several backports from gcc10
branch plus some minor fixes,
https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/plugins/gc
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 51809
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51809&action=edit
When compiled with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274
--- Comment #2 from Tomas Kalibera ---
(In reply to Eric Botcazou from comment #1)
> > -freorder-blocks-and-partition sometimes causes a function to end right in a
> > (non-returning) call, but SEH needs at least one more instruction on x86_64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
Tomas Kalibera changed:
What|Removed |Added
CC||tomas.kalibera at gmail dot com
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
With GCC 10.3.0 and 11.2.0, compiling this example with
-O2 -fno-reorder-blocks-and-partition
for Windows emits a note
uwi.c:3:9: note: '-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #2 from Tomas Kalibera ---
(In reply to Martin Liška from comment #1)
> I can take a look, what's the target please?
Thanks, x86_64-w64-mingw32 (with UCRT as the CRT, but that probably does not
matter).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #4 from Tomas Kalibera ---
(In reply to Martin Liška from comment #3)
> Let's speak about the current master:
>
> > With "12.0" (5e5f880d0452ef2cffb94f4a686d56833c9f4215), the note is not
> > emitted with -fno-reorder-blocks-and-par
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103274
--- Comment #12 from Tomas Kalibera ---
I've tested with GCC 10.3 with R. R can be built and passes its tests (without
the patch, it crashes). Also, I've checked the generated assembly with an awk
script looking for a call instruction immediatel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #7 from Tomas Kalibera ---
(In reply to Martin Liška from comment #5)
> > However, still talking about the current master only, I see a difference
> > with -O3, when I try on the repro example from Bug 103274 and -O3:
> >
> > x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #8 from Tomas Kalibera ---
Created attachment 51958
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51958&action=edit
Example for comment 7.
Example for Dockerfile for comment 7. To be placed in a new directory with that
Docker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #9 from Tomas Kalibera ---
Created attachment 51959
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51959&action=edit
Dockerfile for comment 7
Dockerfile to reproduce behavior in comment 7. To be placed in a fresh
directory wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #10 from Tomas Kalibera ---
(In reply to Tomas Kalibera from comment #7)
> (In reply to Martin Liška from comment #5)
> > > However, still talking about the current master only, I see a difference
> > > with -O3, when I try on the re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #13 from Tomas Kalibera ---
(In reply to Martin Liška from comment #12)
> > So, still, the reorder-stacks-and-partition optimization is not dropped by
> > target (though I am not claiming they should be dropped, I don't know,
> > tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103465
--- Comment #14 from Tomas Kalibera ---
Created attachment 51962
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51962&action=edit
example for comment 1 and 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #3 from Tomas Kalibera ---
Created attachment 52007
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52007&action=edit
Patch to ignore first format for builtins that have more than one
This patch for 10.3.0 instructs gcc to ignor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #4 from Tomas Kalibera ---
Created attachment 52008
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52008&action=edit
Example from comment 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #5 from Tomas Kalibera ---
(In reply to jos...@codesourcery.com from comment #1)
> See bug 92292. The extra attribute isn't ignored, it simply means the
> function has multiple format attributes, which is valid, but should
> probab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292
Tomas Kalibera changed:
What|Removed |Added
CC||tomas.kalibera at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #7 from Tomas Kalibera ---
I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
mailing list in May:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594960.html
The patches still apply to current 10,11,12 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #9 from Tomas Kalibera ---
(In reply to Martin Storsjö from comment #8)
> (In reply to Tomas Kalibera from comment #7)
> > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> > mailing list in May:
> >
> > htt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #11 from Tomas Kalibera ---
(In reply to LIU Hao from comment #10)
> (In reply to Tomas Kalibera from comment #7)
> > I sent an updated version for the trunk, 12, 11 and 10 to the gcc-patches
> > mailing list in May:
> >
> > https://
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
Tomas Kalibera changed:
What|Removed |Added
Attachment #52007|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #13 from Tomas Kalibera ---
Another instance of this problem is %z (to print size_t). It is supported by
UCRT, but the GCC's Microsoft format warns, because it wasn't supported with
MSVCRT (seen with GCC 12.2).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #16 from Tomas Kalibera ---
(In reply to Julian Waters from comment #15)
> It seems like the patch also doesn't fix the strftime case too, strangely
> enough. gcc with that patch applied still causes a compilation failure in
> the Win
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #17 from Tomas Kalibera ---
(In reply to Tomas Kalibera from comment #16)
> (In reply to Julian Waters from comment #15)
> > It seems like the patch also doesn't fix the strftime case too, strangely
> > enough. gcc with that patch app
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #20 from Tomas Kalibera ---
(In reply to Julian Waters from comment #19)
> (In reply to Tomas Kalibera from comment #17)
> > (In reply to Tomas Kalibera from comment #16)
> > > (In reply to Julian Waters from comment #15)
> > > > It s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #22 from Tomas Kalibera ---
(In reply to CVS Commits from comment #21)
> The master branch has been updated by Jonathan Yong :
>
> https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
>
> commit r14-3334-g966f3c134bb4802ac
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 58218
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58218&action=edit
Example program ("im(e^inf):" should be 0
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
Created attachment 58219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58219&action=edit
docker file that reprodu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122
--- Comment #2 from Tomas Kalibera ---
(In reply to Andrew Pinski from comment #1)
> When I do cross back builds, I normally don't rebuild the target libraries
> and just use the already built target libraries from the cross builds. Since
> you
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: tomas.kalibera at gmail dot com
Target Milestone: ---
With gcc 13.2 (and binutils 2.42) located on a mapped network drive on Windows,
it is not possible to build a trivial example below. It worked with gcc 12.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #3 from Tomas Kalibera ---
I hope there is a more elegant solution, but I could think of a best-effort
one. Check if the result of the normalization is a UNC path, if yes, check if
the original path started with a drive letter, if ye
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #5 from Tomas Kalibera ---
(In reply to Bill Zissimopoulos from comment #4)
> I do not currently have access to a Windows system with dev tools, but my
> recollection is that the VOLUME_NAME_DOS flag should be sufficient to
> correc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #7 from Tomas Kalibera ---
(In reply to Bill Zissimopoulos from comment #6)
> > I can reproduce the problem with "subst" and with the Windows Explorer
> > ("File/Map network drive"). I assume the is the usual way to map network
> > d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115189
--- Comment #8 from Tomas Kalibera ---
(In reply to Bill Zissimopoulos from comment #4)
> A more robust alternative to GetFinalPathNameByHandleW/VOLUME_NAME_DOS may
> be the following:
>
> - Use GetFinalPathNameByHandleW with VOLUME_NAME_NORMA
46 matches
Mail list logo
