https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #5 from Martin Liška ---
(In reply to vit9696 from comment #4)
> Path length limitation in the current case is 200 bytes, but in general the
> issue is that we would like _to be able to properly set the gcda path for
> the target_.(I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #1 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #6 from vit9696 ---
While true, this scenario is simply inconvenient in many cases.
(1) When filesystem path limitations exist, they will unavoidably lead to being
unable to save data due to extra large resulting paths. To remind yo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #15 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:b75f996e846d079251f3a6134617f0405c3ed535
commit r12-7932-gb75f996e846d079251f3a6134617f0405c3ed535
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103393
Richard Biener changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #7 from Martin Liška ---
(In reply to vit9696 from comment #6)
> While true, this scenario is simply inconvenient in many cases.
>
> (1) When filesystem path limitations exist, they will unavoidably lead to
> being unable to save da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
--- Comment #7 from Martin Liška ---
(In reply to Jakub Jelinek from comment #6)
> While changing mdiv= from accepting a string to Enum(something) might be
> worth it, wouldn't that be GCC 13 material? I think right now -mdiv=
> accepts random
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #8 from vit9696 ---
> Sure, well, I can imagine introducing something similar to what we have for
> gcov:
>
> $ gcov --help | grep hash
> -x, --hash-filenamesHash long pathnames
Yes, that would likely solve the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:97ad0b831386e56ecb125a25fff00b2cb0b1a2b9
commit r12-7934-g97ad0b831386e56ecb125a25fff00b2cb0b1a2b9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63675
Arnaud Charlet changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
Martin Liška changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #9 from Martin Liška --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89583
Arnaud Charlet changed:
What|Removed |Added
Target Milestone|--- |12.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027
Arnaud Charlet changed:
What|Removed |Added
Target Milestone|--- |11.0
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #3 from Jakub Jelinek ---
And I certainly can't reproduce the wrong-debug issue you're talking about.
If I change it to char l_144 = 8;
then optimized dump has:
[local count: 1073741824]:
# DEBUG BEGIN_STMT
# DEBUG l_144 => 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #4 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Yeah, there is nothing we can do in the debug info about this.
> We really can't inline just for the purposes of debug stmts or something
> similar.
> Another s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Jakub Jelinek changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #6 from Jakub Jelinek ---
Note, for computations expressible in DWARF expressions DWARF already has
DW_OP_call* which doesn't actually mean a call in the inferior call sense, but
a call in the DWARF expression evaluation sense, so on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #7 from Jakub Jelinek ---
There can be security concerns with that though if just print variable
in a debugger lets you format your disk etc. though, while DWARF expressions
can do a lot, they can't modify registers or memory of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #10 from vit9696 ---
I believe this is possible. Since we use both clang and gcc, I filed an issue
in llvm first to make sure both compilers can be updated in a similar way
(https://github.com/llvm/llvm-project/issues/54670).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #11 from Martin Liška ---
(In reply to vit9696 from comment #10)
> I believe this is possible. Since we use both clang and gcc, I filed an
> issue in llvm first to make sure both compilers can be updated in a similar
> way (https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #12 from vit9696 ---
It is an in-house airborne RTOS we develop in ISP RAS. There is a legacy paper
in English telling a bit more about the project
(https://www.ispras.ru/proceedings/docs/2016/28/2/isp_28_2016_2_181.pdf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #13 from Martin Liška ---
Created attachment 52724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52724&action=edit
Tentative patch
Can you please experiment with the following patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #3 from seurer at gcc dot gnu.org ---
I did look at the Makefile and didn't see anything that jumped out as weird. I
will try comparing it to one that works.
Those files all exist.
-rwxr-xr-x 1 seurer users 2954 Mar 30 10:16
gcc/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #31 from Segher Boessenkool ---
Well, what do other compilers do? It's not such a good idea to break ABI
compatibility with the 1990's compilers ;-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #32 from Jakub Jelinek ---
One of the reasons we changed the ABI on various arches one way or another is
that we had this ABI incompatibility between C and C++, that just can't be
right.
At that time we can and should decide if we go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #3 from Richard Biener ---
The store
D.5010.P_BOUNDS = &D.5011;
is
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 9 canonical-type
0x7653bf18 fields Ada size
pointer_to_this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #4 from Jakub Jelinek ---
Mar 30 15:14 is certainly much newer than Mar 30 10:16.
Perhaps try make -d -f Makefile.28475 all
?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645
--- Comment #3 from Jakub Jelinek ---
Created attachment 52725
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52725&action=edit
gcc12-pr104645.patch
I wonder if at least for GCC 13 we just can't treat even that cast stmt as a
preparation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104645
--- Comment #4 from Jakub Jelinek ---
The first GCC 13 should have been GCC 12 of course.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104303
--- Comment #4 from Jan Hubicka ---
What happens to the by-value parameter should get merged from
concat5_pkg2.compare (s);
I will take a look now - sorry for not handling this bug earlier.
Honza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #36 from Jakub Jelinek ---
> Created attachment 52719
> --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52719&action=edit
> gcc12-pr102772.patch
>
> So like this?
M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #38 from Rainer Orth ---
Created attachment 52726
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52726&action=edit
Use __alignof__ in several allocator headers.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #5 from seurer at gcc dot gnu.org ---
The makefiles between systems were the same.
One thing that is different is make itself. On another system where this was
working make was a later release. So I grabbed the latest release of ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #7 from Andreas Schwab ---
contrib/gcc_update is supposed to work with any make, even non-GNU ones,
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #39 from Jonathan Wakely ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #37)
> AFAICS, alignof is C++ >= 11 only. I've used the attached patch to
> use __alignof__ instead, although I don't know if that's the best f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #40 from Jonathan Wakely ---
N.B. I don't think we want to replace alignof with __alignof__ because they're
not identical. For x86 alignof(long long) != __alignof__(long long).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #8 from Jakub Jelinek ---
One possibility would be 32-bit make binary using 32-bit stat syscalls and the
new files having non-representable ino_t values, so stat on those would appear
to fail. But that is just a wild guess...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #41 from Jakub Jelinek ---
(In reply to Jonathan Wakely from comment #39)
> (In reply to r...@cebitec.uni-bielefeld.de from comment #37)
> > AFAICS, alignof is C++ >= 11 only. I've used the attached patch to
> > use __alignof__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:f6d65e803623c7ba6c8eb92ce5975fc1b90cd91e
commit r12-7936-gf6d65e803623c7ba6c8eb92ce5975fc1b90cd91e
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105112
--- Comment #3 from David Malcolm ---
Possible simplification: don't try to model floating-point operations e.g. any
binop on a floating point value has unknown_svalue as the result, so that
complicated floating-point computations can be quickly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #33 from Xi Ruoyao ---
(In reply to Segher Boessenkool from comment #31)
> Well, what do other compilers do? It's not such a good idea to break ABI
> compatibility with the 1990's compilers ;-)
Does someone have access to a Greenhi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024
--- Comment #34 from Xi Ruoyao ---
(In reply to Xi Ruoyao from comment #33)
> > So in struct B { int : 0; double a, b; }; it will go into GPR and FPR
>
> GCC trunk puts "a" into FPR, not GPR! So the "leading" zero-width
> bit-fields are ignor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #42 from Jonathan Wakely ---
It should really depend on -faligned-new which can be set for C++14 and C++11
too (and I guess C++98 in theory, but that would break when you include
because you can't have 'enum class align_val_t' in C+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #12 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:cf68f5a6d20db2aee2f3e674ad3f10e1c458edf9
commit r12-7937-gcf68f5a6d20db2aee2f3e674ad3f10e1c458edf9
Author: Martin Jambor
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083
--- Comment #6 from CVS Commits ---
The master branch has been updated by Martin Jambor :
https://gcc.gnu.org/g:7ea3a73c195a79e6740ae594ee1a14c8bf7a938d
commit r12-7939-g7ea3a73c195a79e6740ae594ee1a14c8bf7a938d
Author: Martin Jambor
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772
--- Comment #43 from Jakub Jelinek ---
Created attachment 52727
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52727&action=edit
gcc12-pr102772.patch
Another patch. This one changes (for now on 32-bit x86 solaris only)
malloc_alignment (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103171
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105063
--- Comment #14 from vit9696 ---
I have just tested this patch after rebasing it on 10.3.x branch, and can
confirm it works as intended. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
Martin Jambor changed:
What|Removed |Added
Assignee|jamborm at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last reco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #8 from Cristian Assaiante ---
(In reply to Jakub Jelinek from comment #3)
> And I certainly can't reproduce the wrong-debug issue you're talking about.
> If I change it to char l_144 = 8;
> then optimized dump has:
>[local count
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
--- Comment #9 from Cristian Assaiante ---
Created attachment 52728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52728&action=edit
Executable file at -Og with l_144 = 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #9 from joseph at codesourcery dot com ---
The dependencies in gcc_update refer to
gcc/config/loongarch/genopts/loongarch-string which doesn't exist (should
be loongarch-strings not loongarch-string, I suppose). Maybe that's
caus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:562d014efadfef6628ae670049c2d92ff6b166f0
commit r12-7941-g562d014efadfef6628ae670049c2d92ff6b166f0
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105118
Bug ID: 105118
Summary: Why is unexpected::value() named error() in libstdc++?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105119
Bug ID: 105119
Summary: the division in x / (1 << y) is optimized away when x
has unsigned type, but not when it's signed
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104949
--- Comment #1 from Tobias Burnus ---
The following addition to testcase is needed.
! ---
!$omp parallel default(A)
!$omp master
if (any (A /= [1,2,3,4,5])) error stop
A(:) = [99,88,77,66,55]
!$omp end master
!$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105117
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> There seems to be a threshold at -fmax-stack-var-size=64.
The threshold is 64 for -m64, and 36 for -m32.
Could it be that the limit applies to the array des
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #17 from Ian Lance Taylor ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102312
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||12.0
Summary|[9/1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104
--- Comment #4 from John Eivind Helset ---
It seems a non-void return-type from await-resume of a final awaitable,
combined with at least -O1 causes a segfault: https://godbolt.org/z/rzq8dM7Pr
Not sure if it's the same as the one I initially en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101833
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004
--- Comment #3 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:aaf3a5993ae49f1ae6792800e5161a1d51436ed3
commit r12-7945-gaaf3a5993ae49f1ae6792800e5161a1d51436ed3
Author: Bill Schmidt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104004
Segher Boessenkool changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever con
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105104
--- Comment #5 from John Eivind Helset ---
Created attachment 52729
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52729&action=edit
Patch with testcase.
Tried adding a testcase to the g++.dg/coroutines testsuite. Used dg-ice, but it
seem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101853
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99910
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100052
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90226
Kewen Lin changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
--- Comment #16 from Kewen Lin ---
*** Bug 90226 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105119
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105120
Bug ID: 105120
Summary: __OPTIMIZE__ macro incorrectly defined when using
pragma(optimize) with push_options/pop_options
Product: gcc
Version: 12.0
Status: UNCONFIRMED
83 matches
Mail list logo
