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
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 #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 #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
Bug ID: 115189
Summary: libiberty introduces UNC paths waking up binutils bug
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122
Bug ID: 115122
Summary: Incorrect detection of C99 support when
cross-compiling
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115117
Bug ID: 115117
Summary: std::exp(Inf) result invalid with --disable-c99
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
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
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 #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 #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 #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
Tomas Kalibera changed:
What|Removed |Added
Attachment #52007|0 |1
is obsolete|
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
--- 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 #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=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=105198
Bug ID: 105198
Summary: Wrong code for C loop (GCC 12 -O2, GCC 11 -O3)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
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
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 #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 #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=92292
Tomas Kalibera changed:
What|Removed |Added
CC||tomas.kalibera at gmail dot com
--- Com
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=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 #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=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=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 #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 #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 #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 #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=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 #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=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
Bug ID: 103465
Summary: Invalid note with -fno-reorder-blocks-and-partition
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
Tomas Kalibera changed:
What|Removed |Added
CC||tomas.kalibera at gmail dot com
--- Com
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=103274
Bug ID: 103274
Summary: Remaining -freorder-blocks-and-partition/ glitch with
Windows SEH
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238
Bug ID: 101238
Summary: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need
-D__USE_MINGW_ACCESS
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: n
42 matches
Mail list logo
