https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
Jeffrey A. Law changed:
What|Removed |Added
Summary|[6/7/8 Regression] spurious |[6/7 Regression] spurious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81897
--- Comment #11 from Jeffrey A. Law ---
Author: law
Date: Sun Jan 7 05:31:51 2018
New Revision: 256320
URL: https://gcc.gnu.org/viewcvs?rev=256320&root=gcc&view=rev
Log:
PR middle-end/81897
* tree-ssa-uninit.c (compute_control_d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
--- Comment #8 from Chanpreet Singh ---
(In reply to Jakub Jelinek from comment #7)
> You shouldn't read random blogs, but the standard of the language you are
> writing in.
> E.g. in n3797.pdf it is in [expr]/10:
> "Otherwise, the integral promo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722
--- Comment #1 from Andrew Pinski ---
0x81c19b8 gen_rtx_SUBREG(machine_mode, rtx_def*, poly_int<1u, unsigned long
long>)
../../src/gcc/emit-rtl.c:1010
0x86d8a89 lra_substitute_pseudo(rtx_def**, int, rtx_def*, bool)
../../src/gcc/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83722
Bug ID: 83722
Summary: [8 Regression] the ICE dumper doesn't comment-out some
error messages
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83201
Jeffrey A. Law changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83721
Bug ID: 83721
Summary: [8 Regression] ICE: in generic_overlap, at
gimple-ssa-warn-restrict.c:821
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83563
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83572
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83640
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83640
--- Comment #7 from Jeffrey A. Law ---
Author: law
Date: Sun Jan 7 04:19:35 2018
New Revision: 256319
URL: https://gcc.gnu.org/viewcvs?rev=256319&root=gcc&view=rev
Log:
2018-01-06 Martin Sebor
PR tree-optimization/83640
* gi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83668
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699
Jeffrey A. Law changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699
--- Comment #7 from Jeffrey A. Law ---
Author: law
Date: Sun Jan 7 03:59:54 2018
New Revision: 256318
URL: https://gcc.gnu.org/viewcvs?rev=256318&root=gcc&view=rev
Log:
PR rtl-optimization/83699
* expmed.c (extract_bit_field_1):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83720
Bug ID: 83720
Summary: [8 Regression] ICE: in mangle_decl, at
cp/mangle.c:3847
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719
Matthias Klose changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83719
Bug ID: 83719
Summary: [8 Regression] ICE (segfault) in
hash_table::elements()
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83718
Bug ID: 83718
Summary: [8 Regression] ICE: Floating point exception in
profile_count::apply_scale
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
Thomas Koenig changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #6 from Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
--- Comment #5 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #4)
> Is there a way to check that the type of expr->value.character.length in
> gfc_conv_substring_expr (fortran/trans-expr.c) is gfc_charlen_t?
That is corr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
--- Comment #4 from Dominique d'Humieres ---
With
integer(8), parameter :: n=2_8**31 - 1_8
I get (compilation time ~4 minutes)
2147483647
'xxx', 'xxx'
With
integer(8), parameter :: n=2_8**32
I get (compilation time ~4 minute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #7 from Andrew Pinski ---
If you want to have signed integer overflow being defined as wrapping use
-fwrapv.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #6 from Freddie Chopin ---
The runtime checks are no good in deeply embedded (like a MCU)...
Anyway - would this behave the same if the values in `in[]` would NOT be known
at compile time? For example provided by user for each run of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
Dominique d'Humieres changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83717
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83717
Bug ID: 83717
Summary: Segfault with long character parameter
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83671
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #5 from Jakub Jelinek ---
We provide the sanitizers (-fsanitize=undefined, -fsanitize=address, etc.) that
you can use to find those issues at runtime. There are some warnings but
runtime instrumentation can catch far more than warnin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #4 from Freddie Chopin ---
Would it be possible to have a warning with -Wall -Wextra when something like
that happens? I think this behaviour here is really strange and really
unexpected. In "real" programs I guess there are tons of s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #10 from Janne Blomqvist ---
Author: jb
Date: Sat Jan 6 19:09:52 2018
New Revision: 256313
URL: https://gcc.gnu.org/viewcvs?rev=256313&root=gcc&view=rev
Log:
PR 83704 Use size_t in write_character
For printing long characters, we n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83716
--- Comment #1 from uruwi at protonmail dot com ---
Created attachment 43051
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43051&action=edit
Preprocessed file (gzipped)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: uruwi at protonmail dot com
Target Milestone: ---
GCC version: 8.0.0 20180106
System: GNU/Linux x64 (kernel version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #9 from Jerry DeLisle ---
(In reply to Janne Blomqvist from comment #8)
> - for (i = 0; i < length; i++)
> + for (size_t = 0; i < length; i++)
typo above. Change to:
+ for (size_t i = 0; i < length; i++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #8 from Janne Blomqvist ---
Good catch! Though as is, there's a few warnings due to signed/unsigned
comparisons. Some minor fixes results in:
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index 3aa2f0e..f966917 100644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79224
Jeffrey A. Law changed:
What|Removed |Added
Summary|[7/8 Regression] Large |[7 Regression] Large C-Ray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #7 from Jerry DeLisle ---
(In reply to Dominique d'Humieres from comment #6)
> > However this does not fix the output of
>
> print *, "'", ch(1:2_8**32_8+3_8), "'"
>
> This is fixed by the following patch
>
> --- ../_clean/libgfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #6 from Dominique d'Humieres ---
> However this does not fix the output of
print *, "'", ch(1:2_8**32_8+3_8), "'"
This is fixed by the following patch
--- ../_clean/libgfortran/io/write.c2018-01-05 20:02:38.0 +0100
++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #2 from Freddie Chopin ---
Indeed, reducing the values in `in[]` makes the code behave properly. But
anyway - how does this particular (minor) issue in the code affect a seemingly
unrelated loop? After all, this loop's variable - `b1`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #5 from Dominique d'Humieres ---
> If I compile with -O2, or compile with -O0 and set the stack size limit
> to unlimited before running, the segfault disappears for me.
I can confirmed that the 'Illegal instruction' is gone if I com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #4 from Jerry DeLisle ---
I can compile it fine, but do not have enough memory to run it. So dominiq, how
much RAM do you have, maybe I can find a machine of sufficient capacity. One
has to be careful we dont take someones OS to its k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83704
--- Comment #3 from Janne Blomqvist ---
If I compile with -O2, or compile with -O0 and set the stack size limit to
unlimited before running, the segfault disappears for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83715
Marc Glisse changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80763
David Binderman changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83715
Bug ID: 83715
Summary: Missed optimization in math expression: optimize
double comparing
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
URL||https://gcc.gnu.org/ml/gcc-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83714
Bug ID: 83714
Summary: [8 Regression] ICE in build_address, at
cp/typeck.c:5733
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83713
Bug ID: 83713
Summary: [6/7/8 Regression] ICE in do_narrow at
gcc/convert.c:474
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
--- Comment #1 from Mikael Pettersson ---
There's a signed int overflow in this code, leading to UB. Compile and run
with -fsanitize=undefined and you'll get
reg.cpp:49:23: runtime error: signed integer overflow: -359 * 599 cannot be
repres
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83712
Bug ID: 83712
Summary: "Unable to find a register to spill" when compiling
for thumb1
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
--- Comment #2 from Janne Blomqvist ---
With the following patch the testcase works:
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index 3e5abd4..d68975c 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -6084,8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
--- Comment #1 from Janne Blomqvist ---
> which makes sense for variables, but IMO not for parameters.
I agree, that's why a few lines before that block checking the size limit we
have:
/* For further simplification, we need the character st
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534
--- Comment #22 from Janne Blomqvist ---
Author: jb
Date: Sat Jan 6 10:42:57 2018
New Revision: 256311
URL: https://gcc.gnu.org/viewcvs?rev=256311&root=gcc&view=rev
Log:
PR 78534 libgfortran ChangeLog
The libgfortran/ChangeLog entry was accide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892
--- Comment #10 from Janne Blomqvist ---
Author: jb
Date: Sat Jan 6 10:41:03 2018
New Revision: 256310
URL: https://gcc.gnu.org/viewcvs?rev=256310&root=gcc&view=rev
Log:
PR 50892 Latent bug in char pointer assignment
Due to r256284 (PR 78534)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
--- Comment #6 from Chanpreet Singh ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Chanpreet Singh from comment #4)
> > (In reply to Andrew Pinski from comment #3)
> > > For imull discussion see
> > > https://stackoverflow.com/que
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
--- Comment #5 from Andrew Pinski ---
(In reply to Chanpreet Singh from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > For imull discussion see
> > https://stackoverflow.com/questions/42587607/why-is-imul-used-for-
> > multiplying-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
--- Comment #4 from Chanpreet Singh ---
(In reply to Andrew Pinski from comment #3)
> For imull discussion see
> https://stackoverflow.com/questions/42587607/why-is-imul-used-for-
> multiplying-unsigned-numbers .
I understand that. However, can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
--- Comment #3 from Andrew Pinski ---
For imull discussion see
https://stackoverflow.com/questions/42587607/why-is-imul-used-for-multiplying-unsigned-numbers
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
--- Comment #2 from Chanpreet Singh ---
Can you please clarify a bit? In the above code, there are 3 vairable, c(int),
b(unsigned int) & a(int). The type of 'a*b' is expected to be (int) [same as
type of 'c', as also 'imull' instruction is used].
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83710
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82428
Tom de Vries changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Tom de Vries -
63 matches
Mail list logo
