https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56538
Jan Kratochvil changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #17 from Jan Kratochvil ---
Yes, the testcase TestTypeCompletion.py category 'dwo' is now fixed with the
patch from Comment 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #14 from Jan Kratochvil ---
DW_AT_addr_base is for .debug_addr in the main file, I agree, my mistake. That
should be inherited from the skeleton to the split-unit.
But DW_AT_loclists_base, DW_AT_rnglists_base and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #12 from Jan Kratochvil ---
That looks as a DWARF5 bug to me. DW_AT_str_offsets_base, DW_AT_addr_base and
DW_AT_rnglists_base do not make any sense for a split unit. Split unit contains
only one CompileUnit (and optionally one
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #10 from Jan Kratochvil ---
clang is using DW_AT_ranges+DW_FORM_rnglistx+DW_AT_rnglists_base in the main
file but in the DWO file it assumes DW_AT_rnglists_base is right after the
.debug_rnglists header (as it does not make sense to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #7 from Jan Kratochvil ---
It would be nice if you could provide the .s/.o/.dwo files so that one does not
have to rebuild the patched GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #3 from Jan Kratochvil ---
LLDB testsuite failure from it is:
PASS: LLDB (/usr/bin/gcc-x86_64) :: test_with_run_command_dwarf
(TestTypeCompletion.TypeCompletionTestCase)
error: a.out {0x5850}: DIE has DW_AT_ranges(0x0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #2 from Jan Kratochvil ---
Created attachment 50341
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50341=edit
range-gcc.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #1 from Jan Kratochvil ---
Created attachment 50340
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50340=edit
range-clang.s
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
FAIL: gcc-11.0.0-0.19.fc35.x86_64
PASS: clang-12.0.0-0.1.rc1.fc35.x86_64
double p_ext=3.14,e_ext=2.71;
int main(void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
--- Comment #3 from Jan Kratochvil ---
LLVM has workarounded it by:
https://reviews.llvm.org/rG0e3d7e61867d69721b28e557272bdf4b66010327
template <>
- struct DenseMapInfo> {
+ struct llvm::DenseMapInfo> {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
--- Comment #2 from Jan Kratochvil ---
Created attachment 50210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50210=edit
2j.cpp.xz
gcc-11.0.0-0.19.fc34.x86_64
g++ -c 2j.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
Created attachment 48998
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48998=edit
1.cc.xz reprodu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96471
--- Comment #2 from Jan Kratochvil ---
Created attachment 48997
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48997=edit
.tar.xz reproducer for: gnat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96471
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
2ac7fe2769890fe4c146da9cfa6d0eabb185d7db = 2020-08-03
gfortran -O2 -g -fdebug-types-section -fallow-argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878
--- Comment #9 from Jan Kratochvil ---
(In reply to Richard Biener from comment #8)
> The .debug_types section isn't supposed to be output when in_lto_p
> (that's for the LTRANS units where we generally do not output any
> types into DWARF).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669
Jan Kratochvil changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299
--- Comment #7 from Jan Kratochvil ---
OK, true, thanks, sorry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94299
--- Comment #3 from Jan Kratochvil ---
(In reply to Andrew Pinski from comment #1)
> #1 0x7fffdb147b04 in
> lldb_private::CommandObject::CommandObject(lldb_private::CommandInterpreter&,
> llvm::StringRef, llvm::StringRef, llvm::StringRef,
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675
Jan Kratochvil changed:
What|Removed |Added
Version|4.8.2 |9.2.1
--- Comment #6 from Jan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93269
--- Comment #4 from Jan Kratochvil ---
Thanks.
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
#include
#include
#include
int main() {
void *p=(void *)0x8000;
printf( "%p""\n", p );// 0x8000
prin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86900
--- Comment #2 from Jan Kratochvil ---
Created attachment 44523
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44523=edit
1.cc.xz
Sorry, the 1.cc file somehow did not get attached.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
g++ -gdwarf-5 -O2 -ffunction-sections -c 1.cc -o 1.o
/tmp/ccnCmT6w.s: Assembler messages:
/tmp/ccnCmT6w.s:61840: Error: invalid operands
(.text.unlikely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #13 from Jan Kratochvil ---
Why the example code should not work with "a user-provided non-member function
with the same signature defined anywhere in the program, in any source file,
replaces the default version. Its declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #11 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #10)
> Does your !=##n check still work if operator new is replaced in a
> different translation unit, but the default one is the only one in scope in
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #8 from Jan Kratochvil ---
Created attachment 44236
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44236=edit
incredibleshrinkingvector.C
What's wrong with this implementation? The permitted operator new symbols
interposition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #6 from Jan Kratochvil ---
(In reply to Marc Glisse from comment #5)
> I can't find anywhere a guarantee that realloc doesn't move stuff when the
> new size is smaller than the old.
In practice it does not.
> What would be the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #2 from Jan Kratochvil ---
You apparently know better all the pitfalls, I just got shocked that a
squeezing shrink_to_fit() does a copy.
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
std::vector::shrink_to_fit() when reducing the size it still calls new()+copy.
It could use realloc() when the objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
--- Comment #10 from Jan Kratochvil ---
It should affect all functions, not just main.
But then GDB already needlessly expands so many CUs that usually when some
function is needed its CU is already expanded. So maybe it is seen just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
--- Comment #8 from Jan Kratochvil ---
(In reply to Jakub Jelinek from comment #7)
> Thanks. Is that something that can be fixed in GDB easily?
Expecting a significant performance hit on initial scan of a file when
.gdb_index/.debug_names is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155
--- Comment #6 from Jan Kratochvil ---
(In reply to Jakub Jelinek from comment #5)
> where gdb sees the difference and why doesn't it make the file
> containing main the default?
pr43051-1.exe.good
<1><117>: Abbrev Number: 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56062
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
There is already:
-fuse-ld=bfd
-fuse-ld=gold
but missing:
-fuse-ld=lld
-rwxr-xr-x 1 root root 1279512 Aug 2 20:35 /usr/bin/ld.bfd*
-rwxr-xr-x 1 root root 3303248 Aug 2 20:35 /usr/bin/ld.gold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83199
--- Comment #6 from Jan Kratochvil ---
The Comment 5 binaries SEGV and do not start on Fedora 26 armv7l.
But I do not see some wrong DWARF there.
(In reply to Jan Kratochvil from comment #3)
> Addresses are missing when the function is inlined.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83199
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61940
--- Comment #8 from Jan Kratochvil ---
Still valid for: gcc-7.1.1-3.fc26.x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65188
Jan Kratochvil changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65132
Jan Kratochvil changed:
What|Removed |Added
Version|5.0 |7.1.1
--- Comment #3 from Jan
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: jan.kratochvil at redhat dot com
CC: cmang at google dot com
Target Milestone: ---
gcc-7.1.1-2.fc27.x86_64
cat >foo.go <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
Jan Kratochvil changed:
What|Removed |Added
CC||palves at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #12 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #7)
> That doesn't help:
>
> std::vector::iterator it;
> {
> std::vector v{1};
> it = v.begin();
> }
>
> The iterator is safely initialized,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #11 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #9)
> Most developers don't even know the debug mode exists.
That's a problem communicating it to users. -O0 -g would be best to always use
-D_GLIBCXX_DEBUG if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #8 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #7)
> That doesn't help:
>
> std::vector::iterator it;
> {
> std::vector v{1};
> it = v.begin();
> }
>
> The iterator is safely initialized,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #6 from Jan Kratochvil ---
(In reply to Jonathan Wakely from comment #5)
> I think it's simply wrong to automatically dereference iterators. GDB
> doesn't do that when printing pointers, so why do the pretty printers do it
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
Jan Kratochvil changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
Jan Kratochvil changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171
Jan Kratochvil changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49726
Jan Kratochvil changed:
What|Removed |Added
Summary|-g0 file.S -g does not |[4.4/5/6/7 Regression] -g0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78204
--- Comment #2 from Jan Kratochvil ---
Yes, that would be the best, to stay compatible with clang.
Or is there some other way how to disable -fsanitize=float-divide-by-zero only
for one function / block of code?
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72822
--- Comment #4 from Jan Kratochvil ---
Comment 3 is for: https://bugzilla.redhat.com/show_bug.cgi?id=1377020
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72822
--- Comment #3 from Jan Kratochvil ---
Without a fix I do not know if it is the same problem or not:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77589
--- Comment #1 from Jan Kratochvil ---
Created attachment 39617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39617=edit
dwarf-stridex.f90
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
Fedora testcase: gdb.fortran/dwarf-stride.exp
! File written by Alan Matsuoka.
FAIL: gcc-6.2.1-1.fc26.x86_64
PASS: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72822
--- Comment #2 from Jan Kratochvil ---
Without a fix I do not know if it is the same problem or not:
++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
https://bugzilla.redhat.com/show_bug.cgi?id=1364588
r239179 2016-08-05
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71906
--- Comment #3 from Jan Kratochvil ---
Could you attach here the ICC .s file if you have it handy? Thanks.
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
Description of problem:
Some GDB testcases started to failing gcc-5.3.1 -> gcc-6.1.1.
Version-Release number of selected compon
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
struct a {
int i;
};
struct b {
struct a a;
int j;
};
int main(void) {
static struct b b;
struct a *ap=(struct a *)
return ((struct b *)>i)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65821
--- Comment #9 from Jan Kratochvil ---
-O2 -g does not show this problem so I am testing it with -O0 -g below:
g++ (GCC) 4.7.3 20130221 (prerelease)
0x00400748 <+4>: sub$0x10,%rsp
=> 0x0040074c <+8>: mov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
Jan Kratochvil changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
--- Comment #1 from Jan Kratochvil ---
https://bugzilla.redhat.com/show_bug.cgi?id=1279406
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
--- Comment #2 from Jan Kratochvil ---
[patch] Python Pretty Printers get disabled on libstdc++ reload by GDB (PR
libstdc++/68448)
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02418.html
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@230621
138bc75d-0d04-0410-961f-82ee72b054a4
echo -e '#include \nint main(){std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68303
Jan Kratochvil changed:
What|Removed |Added
CC||jan.kratochvil at redhat dot
com
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
libstdc++ spends most of the time on:
div %rdi
computing modulo even when commonly the container is empty().
Moreover for small size()s it is more effective
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52960
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
CC||dodji
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66069
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target Milestone: ---
Target: x86_64-linux-gnu
For debugging (-O0 -g) code there could be a way to provide all instantiable
methods for TYPE when anything from templateTYPE gets used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66069
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59161
--- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com ---
valid for: gcc-5.1.1-1.fc23.x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59171
--- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com ---
valid for: gcc-5.1.1-1.fc23.x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59170
--- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com ---
-D_GLIBCXX_DEBUG
gcc-5.1.1-1.fc23.x86_64
(gdb) p end._M_current == ((std::__debug::vectorint, std::allocatorint
*)end._M_sequence)._M_impl._M_finish
$11 = true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675
--- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com ---
gcc-4.9.2-6.fc21.x86_64:
gcc-5.1.1-1.fc23.x86_64
#include debug/string
int main() { __gnu_debug::string s((const char *)0); }
g++ -o gcc59675b gcc59675b.C -Wall -g
: plugins
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: pmuldoon at redhat dot com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
r30
Current libcc1 uses just: make_node (RECORD_TYPE)
which crashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Created attachment 35368
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35368action=edit
GDB patch
GDB patch to crash GCC.
together with:
cat 1.c EOH
// b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
--- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Created attachment 35369
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35369action=edit
Attempted GCC fix.
With this GCC fix and the GDB reproducer it looks as fixed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #5 from Jan Kratochvil jan.kratochvil at redhat dot com ---
(In reply to Manuel López-Ibáñez from comment #3)
Does this patch work in your real-world code?
There were just many tests like:
if (!r)
return 0;
So it should really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65168
--- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com ---
It should check the '!r' condition which makes no sense. The variable
initialization in real world programs is too complicated to be able to figure
out it may be NULL.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65366
--- Comment #1 from Jan Kratochvil jan.kratochvil at redhat dot com ---
[patch] PR other/65366: Fix gdbhooks.py for GDB with Python3
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00502.html
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Host: x86_64-linux-gnu
GDB Python support upstream has always been compatible with Python3.
Fedora since F-22 builds GDB with Python3 by default (=F-21 GDB used Python2).
gdbhooks.py
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228
--- Comment #8 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Great, thanks.
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
CC: pmuldoon at redhat dot com
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
Component|other |c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65228
--- Comment #3 from Jan Kratochvil jan.kratochvil at redhat dot com ---
Interesting that FSF GCC r220934 which should be gcc-5.0.0-0.16.fc23.x86_64
still crashes while that Fedora GCC does not crash.
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target: x86_64-linux-gnu
class C { public: void f() {} } c;
int main() { return c.f.a; }
-Wall
g++ (GCC) 5.0.0 20150224
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65188
--- Comment #2 from Jan Kratochvil jan.kratochvil at redhat dot com ---
(In reply to Manuel López-Ibáñez from comment #1)
How does Clang message help in this case? The suggested fix 'c.f().a' will
just give 'invalid use of void type'
I have
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Target: x86_64-linux-gnu
int main() {
int *p=static_castint *(0),r=*p;
return !r;
}
-Wall
g++ (GCC) 5.0.0 20150221 (experimental
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
class C { bool x:1=false; };
g++ (GCC) 5.0.0 20150219 (experimental):
field.C:1:20: error: an assignment cannot appear in a constant-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58123
--- Comment #8 from Jan Kratochvil jan.kratochvil at redhat dot com ---
(In reply to Aldy Hernandez from comment #7)
Putting this aside for a second, my question is, do we really want a
debugging experience where we jump from back from the end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64300
Jan Kratochvil jan.kratochvil at redhat dot com changed:
What|Removed |Added
Status|UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.kratochvil at redhat dot com
Host: x86_64-linux-gnu
Target: s390x-linux-gnu
Created attachment 34274
-- https://gcc.gnu.org/bugzilla
1 - 100 of 251 matches
Mail list logo
