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
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
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
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=edit
Patch with testcase.
Tried adding a testcase to the g++.dg/coroutines testsuite. Used dg-ice, but it
seems to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
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=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
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=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
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
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=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
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=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=105118
Bug ID: 105118
Summary: Why is unexpected::value() named error() in libstdc++?
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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=105114
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
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
Ever confirmed|0 |1
Last reconfirmed|
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
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=edit
Executable file at -Og with l_144 = 8
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102629
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Last
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=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=103171
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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=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:
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=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
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
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
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
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:
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=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 #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=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
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=105114
seurer at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
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
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=edit
Use __alignof__ in several allocator headers.
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=edit
> gcc12-pr102772.patch
>
> So like this?
Mostly.
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=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=104645
--- Comment #3 from Jakub Jelinek ---
Created attachment 52725
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52725=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=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=104303
--- Comment #3 from Richard Biener ---
The store
D.5010.P_BOUNDS =
is
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set 9 canonical-type
0x7653bf18 fields Ada size
pointer_to_this chain
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
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=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
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=edit
Tentative patch
Can you please experiment with the following patch?
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 #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://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=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=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
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 #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
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
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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=89583
Arnaud Charlet changed:
What|Removed |Added
Target Milestone|--- |12.0
CC|
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=63675
Arnaud Charlet changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
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=105069
Jakub Jelinek changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org,
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105069
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|marxin at gcc
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=105091
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105114
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.0
--- Comment #1 from Richard
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
--- Comment #2 from Richard Biener ---
There isn't really a good way (w/o further analysis) to improve what
update_address_taken does. While it probably could use a BIT_INSERT_EXPR
instead of reading the other component and using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105109
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105108
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105107
--- Comment #3 from Martin Liška ---
You'll see it with:
gcc-11 pr105107.c -fsanitize=address -g -O2 &&
ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out
addr of e=0x739f4020
write to 0x739f4020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104371
Haochen Jiang changed:
What|Removed |Added
CC||haochen.jiang at intel dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105091
--- Comment #14 from Jiu Fu Guo ---
(In reply to Richard Biener from comment #13)
...
> Does the following fix the runtime error? The RTL after DSE seems to be OK.
>
> diff --git a/gcc/gimple-expr.cc b/gcc/gimple-expr.cc
> index
85 matches
Mail list logo
