https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121004
--- Comment #3 from Harald van Dijk ---
I think comment #0's f could be optimised even more to just return a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120978
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118681
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
Created attachment 61669
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61669&action=edit
X86RecognizableInstr.cpp.ii.gz
I'm not really sure where the pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120421
--- Comment #5 from Harald van Dijk ---
(In reply to Andrew Pinski from comment #4)
> But printing out the preprocessed line is equally as wrong in many cases.
> Especially when it comes to `#line` markers. That is it is there is no
> correct an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120421
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119215
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109214
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116082
--- Comment #9 from Harald van Dijk ---
(In reply to Alejandro Colomar from comment #8)
> (In reply to Harald van Dijk from comment #7)
> > The warning is called -Wunterminated-string-initialization, but there is no
> > unterminated string. That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116082
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #9 from Harald van Dijk ---
(In reply to Jann Horn from comment #8)
> (In reply to Harald van Dijk from comment #7)
> > I think implementations have two valid ways of dealing with this: either
> > malloc must fail to allocate such a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
--- Comment #7 from Harald van Dijk ---
(In reply to Jakub Jelinek from comment #5)
> but you shouldn't call standard string/memory functions on it,
> you are then on your own to deal with it.
Does the standard say so anywhere? Yes, it says poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119693
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109027
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118230
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118095
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116834
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116631
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115903
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115566
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #21 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #20)
> (In reply to Harald van Dijk from comment #18)
> > (In reply to Jonathan Wakely from comment #16)
> > > ... incorrectly though?
> >
> > Given that you hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
--- Comment #18 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #16)
> ... incorrectly though?
Given that you have expressed your view that *any* attempt at using TZ is
inherently incorrect, I am not surprised that you view l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114645
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #20 from Harald van Dijk ---
(In reply to Kaz Kylheku from comment #19)
Needless to say I still disagree, but I interpreted your comment #17 as
suggesting this aspect of the discussion is neither necessary nor useful for
this bug, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #18 from Harald van Dijk ---
(In reply to Kaz Kylheku from comment #17)
> The standrad does not define the conversion at the *type* level.
> ...
> The program is strictly conforming because it has no problem with type.
The DRs I ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #16 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #15)
> In the cases where there is no statement either way, the behavior is
> undefined as a property of the translation unit (not just of the execution):
> it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #14 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #11)
> I think that simply failing to say whether a value of type X may be
> converted to type Y is clearly enough for it at least to be unspecified
> whether or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #10 from Harald van Dijk ---
Sorry, sent my earlier comment too soon.
(In reply to Joseph S. Myers from comment #8)
> I believe conversions between function and object pointers are undefined as
> a property of the translation unit -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #9 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #8)
> "rejects", in the ISO C sense, only applies to errors and pedwarns in GCC;
> not to warnings conditional on -pedantic (of which there are also some, but
> wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
--- Comment #6 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #5)
> The -pedantic documentation was updated to reflect reality - that the option
> is about more than just when diagnostics are required by ISO C ("forbidden
> e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114363
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114163
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
--- Comment #7 from Harald van Dijk ---
(In reply to Joseph S. Myers from comment #6)
> Contrary to what was claimed in bug 66462, I don't think there ever was a
> fixed patch. Note that in bug 66462 comment 19, "June" is June 2017 but
> "Novembe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94083
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114104
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113959
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
--- Comment #13 from Harald van Dijk ---
(In reply to Marek Polacek from comment #12)
> Thank for your comment. In the end I went with
>
> -std=c++03 -pedantic-errors -Wextra-semi -> warnings
> -std=c++03 -pedantic -Wextra-semi -> warnings (no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113760
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830
--- Comment #14 from Harald van Dijk ---
(In reply to Bo Wang from comment #13)
> (In reply to Harald van Dijk from comment #12)
> > (In reply to Bo Wang from comment #11)
> > > I have read the working draft standard of C++20
> > > (https://gith
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113830
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113628
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113110
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113049
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44179
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071
--- Comment #10 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Harald van Dijk from comment #8)
> > (In reply to Andrew Pinski from comment #7)
> > > Isn't doing the extern "C" around standard C++ headers de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102201
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
--- Comment #27 from Harald van Dijk ---
(In reply to jos...@codesourcery.com from comment #25)
> The option to use to detect this is -fsanitize=float-cast-overflow (note:
> I haven't tested if it detects this particular case). As per the manu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101953
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101638
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101864
Harald van Dijk changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIR
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
This testcase comes from glibc 2.34's sys/cdefs.h, so this is a problem showing
up for any program that uses any of glibc's headers with -Wtradition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101489
--- Comment #2 from Harald van Dijk ---
Ah, thanks for the pointer. Agreed that the signatures are correct based on
that, but they are not exactly clear as they make it impossible to tell apart
the xf and tf cases. Please consider this as an enh
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
At <https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html>,
all functions that take __float128 / _Float1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409
--- Comment #9 from Harald van Dijk ---
(In reply to Richard Biener from comment #8)
> It has been consensus that throwing exceptions and const/pure are different
> concepts that co-exist. See for example the recent discussion at
> https://gcc.
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
According to PR100409
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100409
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101234
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71458
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100805
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
--- Comment #8 from Harald van Dijk ---
I take it that means there's no need for me to continue with what Richard asked
me to do?
At any rate, it looks like this fix won't be enough for GCC 12, but that's an
issue with the environment, not GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
--- Comment #6 from Harald van Dijk ---
(In reply to rguent...@suse.de from comment #5)
> At this point a minimal fix is prefered - in principle the file
> should be a valid source to any C++ 11 capable host compiler, not
> just GCC. The mainta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
--- Comment #4 from Harald van Dijk ---
(In reply to Richard Biener from comment #3)
Yes, including is enough to get the build to pass. My last point in
comment #2, however, means that that leaves things in an inconsistent state and
that the r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
--- Comment #2 from Harald van Dijk ---
There are more missing or wrong includes here: looking at the code, it's also
using functions from without including that, but that one gets
implicitly included for me even on this old G++ so happens to n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731
--- Comment #1 from Harald van Dijk ---
The full configure line I used for reproducing this on glibc, btw:
../gcc-11.1.0/configure --prefix=$HOME/gcc-11.1.0-run CC=gcc-4.8.5
CXX=g++-4.8.5 --enable-languages=c,c++
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
When building GCC 11 with GCC 4.8 on a platform without _GLIBCXX_USE_C99, the
build fails. The result is:
../../gcc-11.1.0/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100353
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100309
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
GCC 8 and newer no longer issue an error for
const int i = 0;
const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99362
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97755
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370
--- Comment #3 from Harald van Dijk ---
(In reply to eggert from comment #2)
> That's so unlikely as to not be worth worrying about.
See PR 7543 for the history of that warning.
> And even if it were
> more likely, the same argument would apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97370
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97279
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
--- Comment #31 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #30)
> I'm curious why the preprocessed code in comment 28 doesn't warn,
This was still bugging me, so I looked into it a little bit, and since I had
trouble find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96747
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96486
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95157
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95027
Harald van Dijk changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
$ cat test.c
int f() {
int i;
return i;
}
$ LC_ALL=C gcc-10.1.0 -Wall -c test.c -fdiagnostics-urls=always 2>&1 | cat -v
test.c: In function 'f':
test.c:3:10: war
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94998
--- Comment #4 from Harald van Dijk ---
Just confirming that that patch works for me, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94998
Harald van Dijk changed:
What|Removed |Added
Component|bootstrap |target
--- Comment #1 from Harald van
erity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: harald at gigawatt dot nl
Target Milestone: ---
Configuring libiberty fails when gcc is configured as
../gcc-10.1.0/configure --build=x86_64-forcecross-linux-gnu
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91187
--- Comment #9 from Harald van Dijk ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Albert Astals Cid from comment #0)
> > #define Z_NULL 0
>
> N.B. this is actually a bug. Using Z_NULL where a null pointer is expected
> might c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #11 from Harald van Dijk ---
(In reply to Rich Felker from comment #10)
> On this particular target, and on every target of any modern
> relevance, (float)16777217 has well-defined behavior.
That was exactly the point of my original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #9 from Harald van Dijk ---
(In reply to Rich Felker from comment #8)
> So arguments about generality to non-Annex-F C
> environments are not relevant to the topic here.
The comment it was a reply to suggested (possibly unintentional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60540
--- Comment #7 from Harald van Dijk ---
(In reply to Rich Felker from comment #6)
> > Only if the int is out of float's range.
>
> float's range is [-INF,INF] (endpoints included). There is no such thing as
> "out of float's range".
Floating po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91609
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
Assignee: ian at airs dot com
Reporter: harald at gigawatt dot nl
CC: cmang at google dot com
Target Milestone: ---
r269424 introduced in libgo/mksysinfo.sh:
if test "$statfs" == ""; then
test == is non-POSIX and not supported in all she
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91418
--- Comment #5 from Harald van Dijk ---
(In reply to Darrell Wright from comment #4)
> The weird part is, other than compilers don't agree, but the lookup finds it
> if you put the template argument in
The idea there seems to be that `class A;`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91418
--- Comment #3 from Harald van Dijk ---
I believe GCC is correct here. [class.friend]p11
(http://eel.is/c++draft/class.friend#11) specifies that `friend class A;`, with
an unqualified name, does not find the global scope class A, but makes a (nev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29931
--- Comment #11 from Harald van Dijk ---
Thinking about this a bit more, the logic should probably be: pick a file known
to exist. libgcc.a could be a good candidate, but there could be better
options. Look this up twice, once following symlinks,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91418
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91314
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment
1 - 100 of 241 matches
Mail list logo
