https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #40 from Bernd Edlinger ---
Yikes, I need an assignement operator:
B(const B )
{
__builtin_memcpy(this, , sizeof(B));
}
B& operator = (const B )
{
__builtin_memcpy(this, , sizeof(B));
return *this;
}
now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #39 from Bernd Edlinger ---
one thing I do not understand is this:
if I do this in Jakub's test case:
new (b.u.b) A (x);
//c = *p;
__builtin_memcpy(, p, sizeof(B));
bar (*p, c);
the mis-compilation goes away,
if I add this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69034
--- Comment #5 from Bernd Edlinger ---
FYI: The latest version of my patch is here:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01363.html
Unfortunately there was no consensus about it ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #24 from Bernd Edlinger ---
(In reply to Richard Biener from comment #23)
> (In reply to Bernd Edlinger from comment #22)
> > (In reply to Jakub Jelinek from comment #20)
> > > which fails also on x86_64-linux at -O2. And that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
--- Comment #22 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #20)
> which fails also on x86_64-linux at -O2. And that testcase regressed with
> r223126. Now whether this is valid C++, no idea, placement new is messy.
This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79671
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79647
--- Comment #7 from Bernd Edlinger ---
(In reply to Andrew Pinski from comment #1)
> >The second warning is also bogus, the -Wno-parentheses-equality was accepted
> before.
>
> Well this error message about an unknown warning option only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79647
--- Comment #5 from Bernd Edlinger ---
When I tried to limit the memory allocation to reasonable size,
I triggered the warning again, with this modified check:
@@ -1393,6 +1393,12 @@ int speed_main(int argc, char **argv)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79647
--- Comment #4 from Bernd Edlinger ---
(In reply to Martin Sebor from comment #3)
> @@ -19021,6 +19021,13 @@
> case OPT_ASYNCJOBS:
>
> async_jobs = atoi(opt_arg());
> + if (async_jobs < 0) {
> +
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Created attachment 40786
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40786=edit
preprocessed source file
Latest gcc of today fails to build latest openssl of today,
w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366
--- Comment #8 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #3)
> > Clang's ubsan diagnoses this, but ours doesn't:
> >
> > u.cc:4:25: runtime error: value -1 is outside the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366
--- Comment #6 from Bernd Edlinger ---
FYI, the original problem was that libxml2 was unable to convert
a date value 1601-01-01T00:00:00.000+00:01 which should underflow
from 1601 to 1600, but we got the wrong date 1601-12-31T23:59:00.000 here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366
--- Comment #4 from Bernd Edlinger ---
Ah, I see, you mean C89:
3.2.1.3 Floating and integral
When a value of floating type is converted to integral type, the
fractional part is discarded. If the value of the integral part
cannot be
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
the following returns an unexpected result:
cat test.c
double f = -1.0;
int main()
{
int g = (unsigned int)(f);
__builtin_printf("%d\n", g);
}
gcc test.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78439
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78453
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Created attachment 40090
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40090=edit
reproducer
just another example:
gcc -c -Wall -O2 -c xpath.c
xpath.c:79:6: warning: ar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #62 from Bernd Edlinger ---
Both parts of the patch are now posted for review:
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00523.html
https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00830.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78202
--- Comment #2 from Bernd Edlinger ---
libitm.c++/throwdown.C is fixable, as it does not need the
internal functions from libitm.h:
Index: testsuite/libitm.c++/throwdown.C
===
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78202
--- Comment #1 from Bernd Edlinger ---
The log file of the libitm testsuite is totally cluttered because
it is not using -fno-diagnostics-color=never.
This happens only for:
libitm.c++/throwdown.C
libitm.c++/dropref.C
Other tests are
: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
C++ does currently not give a warning about it, but this is about to change
soon.
The following functions are declared in libitm.h:
void _ITM_L##T (const _ITM_TYPE##T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #61 from Bernd Edlinger ---
Created attachment 39958
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39958=edit
patch for enabling ldrdstrd peephole
And this is what I will bootstrap in the next cycle.
It will enable all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Bernd Edlinger changed:
What|Removed |Added
Attachment #39940|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #58 from Bernd Edlinger ---
(In reply to wilco from comment #57)
> (In reply to Bernd Edlinger from comment #56)
> > Agreed, I can split the patch.
> >
> > From what I understand, we should never emit ldrd/strd out of
> > the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #56 from Bernd Edlinger ---
(In reply to wilco from comment #55)
> (In reply to Bernd Edlinger from comment #39)
> > Created attachment 39940 [details]
> > proposed patch, v2
> >
> > last upload was accidentally truncated.
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78067
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #54 from Bernd Edlinger ---
(In reply to richard.earnshaw from comment #53)
> On 02/11/16 11:57, bernd.edlinger at hotmail dot de wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
> >
> > --- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #52 from Bernd Edlinger ---
(In reply to wilco from comment #51)
>
> Indeed, that's the reason behind the existing check. However it disables all
> profitable bswap cases while still generating unaligned accesses if no bswap
> is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #49 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #48)
> (In reply to wilco from comment #22)
> >
> > Anyway, there is another bug: on AArch64 we correctly recognize there are 8
> > 1-byte loads, shifts and orrs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #48 from Bernd Edlinger ---
(In reply to wilco from comment #22)
>
> Anyway, there is another bug: on AArch64 we correctly recognize there are 8
> 1-byte loads, shifts and orrs which can be replaced by a single 8-byte load
> and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #45 from Bernd Edlinger ---
(In reply to wilco from comment #44)
> (In reply to Bernd Edlinger from comment #38)
> > Created attachment 39939 [details]
> > proposed patch, v2
> >
>
> > Unlike the previous patch, thumb1 stack usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #43 from Bernd Edlinger ---
(In reply to wilco from comment #41)
>
> ARM only uses the 2nd alternative (set_attr "arch" "any,a,t2,t2"), so this
> is correct. There is no need to support this pattern for ARM as ARM doesn't
> have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #40 from Bernd Edlinger ---
BTW: I found something strange in this pattern in neon.md:
(define_insn_and_split "orndi3_neon"
[(set (match_operand:DI 0 "s_register_operand" "=w,?,?,?")
(ior:DI (not:DI (match_operand:DI 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Bernd Edlinger changed:
What|Removed |Added
Attachment #39939|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
Bernd Edlinger changed:
What|Removed |Added
Attachment #39898|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #34 from Bernd Edlinger ---
(In reply to Richard Earnshaw from comment #33)
> (In reply to Wilco from comment #32)
> > (In reply to Bernd Edlinger from comment #31)
> > > Furthermore, if I want to do -Os the third condition is FALSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #31 from Bernd Edlinger ---
Sure, combine cant help, especially because it runs before split1.
But I wondered why this peephole2 is not enabled:
(define_peephole2 ; ldrd
[(set (match_operand:SI 0 "arm_general_register_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #28 from Bernd Edlinger ---
With my latest patch I bootstrapped a configuration with
--with-arch=armv7-a --with-tune=cortex-a9 --with-fpu=vfpv3-d16
--with-float=hard
I noticed a single regression in gcc.target/arm/pr53447-*.c
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #26 from Bernd Edlinger ---
(In reply to wilco from comment #25)
>
> Alternatives can be disabled, there are flags, eg:
>
> (set_attr "arch" "neon_for_64bits,*,*,avoid_neon_for_64bits")
>
Ok I see, thanks.
Still lots of insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #24 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #23)
> @@ -5020,7 +5020,7 @@
> (define_insn_and_split "one_cmpldi2"
>[(set (match_operand:DI 0 "s_register_operand" "=w,,,?w")
> (not:DI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #23 from Bernd Edlinger ---
(In reply to wilco from comment #22)
>
> What I meant is that your patch still makes a large difference on the
> original test case despite making no difference in simple cases like the
> above.
For sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #21 from Bernd Edlinger ---
(In reply to wilco from comment #20)
> > Wilco, where have you seen the additional registers used with my
> > previous patch, maybe we can try to fix that somehow?
>
> What happens is that the move of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78110
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #19 from Bernd Edlinger ---
I think the problem with anddi iordi and xordi instructions is that
they obscure the data flow between low and high half words.
When they are not enabled, we have the low and high parts
expanded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #18 from Bernd Edlinger ---
Created attachment 39898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39898=edit
proposed patch
This disables problematic di patterns when no fpu is used, and
there is absolutely no chance that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78110
--- Comment #4 from Bernd Edlinger ---
First I was a bit shocked, but i think my patch above looks reasonable.
Because the installation is free-standing it is natural that we
cannot #include . Although the eCos has no memalign,
that is benign,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78110
--- Comment #2 from Bernd Edlinger ---
without --with-newlib the build fails miserably...
this works for me:
--- libstdc++-v3/libsupc++/new_opa.cc.orig 2016-09-16 20:09:14.0
+0200
+++ libstdc++-v3/libsupc++/new_opa.cc 2016-10-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78110
--- Comment #1 from Bernd Edlinger ---
oh, I am using eCos and that is based on newlib but on a very very old one.
I don't know what happens when I dont use --with-newlib, but I can try...
configure.ac has this:
# First, test for "known"
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
configured with:
../gcc-7-20161023/configure --prefix=/home/ed/gnu/arm-eabi --target=arm-eabi
--with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx
--disable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #16 from Bernd Edlinger ---
Wow.
look at this:
Index: arm.md
===
--- arm.md (revision 241539)
+++ arm.md (working copy)
@@ -448,7 +448,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #15 from Bernd Edlinger ---
(In reply to Wilco from comment #14)
> (In reply to Bernd Edlinger from comment #13)
> > I am still trying to understand why thumb1 seems to outperform thumb2.
> >
> > Obviously thumb1 does not have the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #13 from Bernd Edlinger ---
I am still trying to understand why thumb1 seems to outperform thumb2.
Obviously thumb1 does not have the shiftdi3 pattern,
but even if I remove these from thumb2, the result is still
not par with thumb2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041
--- Comment #15 from Bernd Edlinger ---
FYI: You could merge the two alternatives into one.
=?r,?
0, r
i, i
is equivalent to
=?
0r
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78067
--- Comment #2 from Bernd Edlinger ---
This happens with __floattisf and __floattidf in 64bit libgcc.
But because a bsr $rsi,$rsi is used, apparently the result register is zero,
when the input is zero and not completely undefined. Thus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78067
--- Comment #1 from Bernd Edlinger ---
I think in the case of x86 longlong.h
does not define COUNT_LEADING_ZEROS_0
but nevertheless count_leading_zero
is defined to __builtin_clz and
seems to return the correct result,
but I don't know if that
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
in libgcc2.c, __floatdidf, line 1637 I see:
/* If there are no high bits set, fall back to one conversion. */
if ((Wtype)u == u)
return (FSTYPE)(Wtype)u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041
--- Comment #9 from Bernd Edlinger ---
(In reply to Wilco from comment #8)
>
> I've got a patch that fixes it, it's being tested.
>
> While looking at how DI mode operations get expanded, I noticed there is a
> CQ issue with your shift change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041
--- Comment #7 from Bernd Edlinger ---
(In reply to Richard Earnshaw from comment #6)
> (In reply to Bernd Edlinger from comment #5)
> > (In reply to Wilco from comment #4)
> > > However dealing with partial overlaps is complex so maybe the best
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041
--- Comment #5 from Bernd Edlinger ---
(In reply to Wilco from comment #4)
> However dealing with partial overlaps is complex so maybe the best option
> would be to add alternatives to di3_neon to either allow full overlap
> "r 0 X X X" or no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041
--- Comment #3 from Bernd Edlinger ---
(In reply to Wilco from comment #2)
> (In reply to Bernd Edlinger from comment #1)
> > some background about this bug can be found here:
> >
> > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041
--- Comment #1 from Bernd Edlinger ---
some background about this bug can be found here:
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01561.html
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
This is a slightly modified test case:
gcc.c-torture/execute/pr34971.c
struct foo
{
unsigned long long b:40;
} x;
extern void abort (void);
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77901
--- Comment #4 from Bernd Edlinger ---
ok, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77901
--- Comment #2 from Bernd Edlinger ---
reproducer:
cat min.c
union internal_auxent
{
struct {
union {
long l;
} x_tagndx;
} x_sym;
};
struct coff_symbol
{
int c_sclass;
};
int complaint ();
int decode_type (struct coff_symbol * cs,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77901
--- Comment #1 from Bernd Edlinger ---
this seems to fix it:
Index: gcc/tree-ssa-reassoc.c
===
--- gcc/tree-ssa-reassoc.c (revision 240867)
+++ gcc/tree-ssa-reassoc.c
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
build of gdb-7.11.1 with gcc Revision: 240867 fails with ICE
last week it was OK.
../../gdb-7.11.1/gdb/coffread.c: In function 'decode_type':
../../gdb-7.11.1/gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77700
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77699
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77816
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748
Bernd Edlinger changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748
--- Comment #22 from Bernd Edlinger ---
(In reply to Christophe Lyon from comment #21)
> Ha, indeed, that's one of the differences between arm-none-eabi and
> arm-none-linux-gnueabi.
>
> Using -fno-short-enums does make execution succeed,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748
--- Comment #20 from Bernd Edlinger ---
Bah. Your target defaults to -fshort-enums: that makes
the basic_string structure much too short it uses an array of enum
to keep it at the same size as the original.
Now please try this:
Index:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748
--- Comment #15 from Bernd Edlinger ---
Thanks. Again I could reproduce the issue with the assembler flle.
This time it fails in a memcmp.
Apparently the _M_string_length is uninitialized, but used in memcmp.
Can you try this?
Index:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748
--- Comment #7 from Bernd Edlinger ---
This avoids also the _Alloc_hider constructor.
But it still reproduces with gcc-6 and gcc-7.
I have found no way to add __attribute((noinline, noclone))
to the template specialization, that works.
So I did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748
--- Comment #5 from Bernd Edlinger ---
I think the problem is that tree libstdc++ functions are called,
but the basic_string structure has been c-reduced.
Especially _Alloc_hider, but when that is removed the test
case does no longer reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77748
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
Assignee: ian at airs dot com
Reporter: bernd.edlinger at hotmail dot de
CC: cmang at google dot com
Target Milestone: ---
Hi,
now here is also a -Wint-in-bool-context warning:
../../gcc-trunk/gcc/go/go-gcc.cc: In constructor 'Gcc_backend::Gcc_backend()':
../../gcc-trunk
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
this is the next one, the line info is off by one, but it is nevertheless
a real bug:
../../gcc-trunk/gcc/cp/parser.c: In function 'tree_node*
cp_parser_base_specifier(cp_parser
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
this is also suspicious by -Wint-in-bool-context warning:
../../gcc-trunk/gcc/input.c: In function 'bool get_next_line(fcache*, char**,
ssize_t*)':
../../gcc-trunk/gcc
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
was playing with a new experimental version of my -Wint-in-bool-context
warning.
It catched this code in tree-ssa-forwprop.c
../../gcc-trunk/gcc/tree-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
--- Comment #16 from Bernd Edlinger ---
(In reply to Richard Biener from comment #15)
> The patch should at least work (loads are similarly affected). At some
> point we want some infrastructure in the middle-end to chose a better
> fallback
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77574
--- Comment #2 from Bernd Edlinger ---
(In reply to Martin Liška from comment #1)
> Hello Bernd.
>
> Thanks for the PR, as well the suggested patch. The patch works for me,
> I'm going to test it and submit to mailing list. Please ping me if
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
Hi,
an experimental version of my -Wint-in-bool-context patch
found this apparently wrong code in predict.c
../../gcc-trunk/gcc/predict.c: In function 'void force_edge_cold(edge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
Bernd Edlinger changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
--- Comment #12 from Bernd Edlinger ---
(In reply to Markus Trippelsdorf from comment #11)
> (In reply to Bernd Edlinger from comment #9)
> > I'm unable to reduce the test case...
>
> Creduce is running and hopefully I will have a small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77550
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77289
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64279
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #4 from Bernd Edlinger ---
(In reply to Bernd Edlinger from comment #3)
> The "correct" test case emits two nearly identical -Wpedantic warnings:
>
... which is probably OK, given the second one if it is emitted,
points to the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #3 from Bernd Edlinger ---
The "correct" test case emits two nearly identical -Wpedantic warnings:
One when the template is parsed, and one when the template is instantiated.
The second one is unnecessary, IMHO.
template
class z
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #2 from Bernd Edlinger ---
possible fix:
--- a/gcc-7-20160904/gcc/cp/class.c 2016-08-26 17:10:57.0 +0200
+++ b/gcc-7-20160904/gcc/cp/class.c 2016-09-06 11:55:27.252138088 +0200
@@ -8262,6 +8262,11 @@ instantiate_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77496
--- Comment #1 from Bernd Edlinger ---
But it works if I write:
int f(bool z) { return zz(0) ? : 0; }
++
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
this invalid C++ template creates an ICE:
cat test.cc
template
class z : x
{
public:
bool zz (int) { return false; }
int f(bool z) { return zz ? : 0; }
};
class t
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
see: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00202.html
The problem is that ~ on bool maps [0:1] to [-1:-2]
and thus the result is no longer boolean. But probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #11 from Bernd Edlinger ---
As I said, I think "<<" on signed integers is generally bogus in a
truth value context.
So I tried an experiment for such a warning:
Index: c-common.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #10 from Bernd Edlinger ---
(In reply to Manuel López-Ibáñez from comment #9)
> It seems to me that they are two different warnings that could be triggered
> on similar code. The one warned by the patch would also warn about:
>
> if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #7 from Bernd Edlinger ---
(In reply to jos...@codesourcery.com from comment #6)
> On Thu, 1 Sep 2016, bernd.edlinger at hotmail dot de wrote:
>
> > + warning_at (location, 0,
> > + &q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
--- Comment #5 from Bernd Edlinger ---
This is an idea for a warning that does not focus on parentheses:
Here we had: a ? c1 : c2;
but in a context where a boolean is requested.
It is always suspicious, when c1, and c2 are integer constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77434
Bernd Edlinger changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
301 - 400 of 947 matches
Mail list logo
