https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
--- Comment #13 from rguenther at suse dot de ---
On February 21, 2018 2:13:22 PM GMT+01:00, "egallager at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
>
>Eric Gallager changed:
>
> What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
--- Comment #11 from Jerry DeLisle ---
Tentative patch. Testing now. The intent originally was to prevent unit numbers
that don't fit into kind=4. It use to be we had no negative unit numbers. With
newunit, now we do.
I need to see if this patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
Dominique d'Humieres changed:
What|Removed |Added
Keywords||wrong-code
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
--- Comment #9 from Steve Kargl ---
On Thu, Feb 22, 2018 at 03:30:01AM +, jvdelisle at gcc dot gnu.org wrote:
>
> if (D.3772 < -some-reasonable-value || D.3772 > 2147483647)
> {
> inquire_parm.3.common.unit = -3;
> }
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
--- Comment #7 from Jerry DeLisle ---
The problem is not related to the newunit functions or neunit alloc stuff.
In the call to st_inquire we are passing the correct value of -10 for the unit
number. However, the dump-original we have:
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
--- Comment #1 from Jeffrey Walton ---
__m128d is a tad bit cleaner. It does not require the casts.
$ cat test.c
#include
int main(int argc, char* argv[])
{
unsigned char t[16+1];
__m128d x = _mm_load_sd((const double *)(t+1));
_mm_store_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508
Bug ID: 84508
Summary: Load of misaligned address using _mm_load_sd
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sani
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
--- Comment #5 from Steve Kargl ---
On Thu, Feb 22, 2018 at 12:08:24AM +, sgk at troutmask dot
apl.washington.edu wrote:
> program TestInquire
>implicit none
>integer(8) :: iUnit
>integer(8) :: iPos
>open(newunit=iunit, file='
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
--- Comment #4 from Steve Kargl ---
The problem is related to UNIT.
program TestInquire
implicit none
integer(4) :: iUnit
integer(8) :: iPos
open(newunit=iunit, file='output.txt', access='stream', status='replace')
write(iUnit) 'T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84507
Justin Chen changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84507
Bug ID: 84507
Summary: stack corruption
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
--- Comment #23 from Jeffrey A. Law ---
Note that if we fix the abnormal handler to target the block after the setjmp
rather than the setjmp itself all the problems magically disappear. That's
actually a more accurate CFG and arguably the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
--- Comment #3 from Steve Kargl ---
Upon closer inspection, gfortran's dump is correct
for both INTEGER and INTEGER(8) for
program TestInquire
integer :: iUnit, iPos
! integer(8) :: iUnit, iPos
open(newunit=iunit, file='output.txt', acce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222
Justin Chen changed:
What|Removed |Added
CC||justinpopo6 at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710
--- Comment #14 from Jonathan Wakely ---
I guess because nobody asked for it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84453
--- Comment #5 from Jakub Jelinek ---
So fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84453
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505
--- Comment #2 from Martin Liška ---
(In reply to Jakub Jelinek from comment #1)
> Might very well be a dup of PR84503, let me finish up the patch.
I hope so. According to description it looks very similar ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983
Steve Ellcey changed:
What|Removed |Added
CC||sje at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
--- Comment #5 from Jakub Jelinek ---
In 7.x this exact problem doesn't really exist, so the issue must be different
there.
I'd think it might be something fixable by PR82916 - like patch, but haven't
actually tried that yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84314
--- Comment #8 from Jason Merrill ---
Author: jason
Date: Wed Feb 21 22:12:08 2018
New Revision: 257883
URL: https://gcc.gnu.org/viewcvs?rev=257883&root=gcc&view=rev
Log:
PR c++/84314 - ICE with templates and fastcall attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506
Bug ID: 84506
Summary: INQUIRE(pos=) always sets pos=0 with
-fdefault-integer-8
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60083
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
--- Comment #4 from Sriram Swaminarayan ---
OK, I will admit that my knowledge here is pretty limited so if someone could
point out what I'm missing, I'd appreciate it.
On reading the other thread [PR45290] it appears it deals with pointers bein
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
--- Comment #6 from patrick.schlangen at bmw dot de ---
(In reply to Jakub Jelinek from comment #5)
> Completely untested fix:
I've applied the patch and it seems to resolve the issue.
Thanks a lot!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80793
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84489
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
--- Comment #3 from Steve Kargl ---
On Wed, Feb 21, 2018 at 09:15:24PM +, dominiq at lps dot ens.fr wrote:
>
> > This appears to be related to PR44290.
>
> Are you sure about the PR?
>
Argh, fat fingers! r169948
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149
Thomas Koenig changed:
What|Removed |Added
CC||pault at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60018
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277
Manuel López-Ibáñez changed:
What|Removed |Added
CC||chengniansun at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 80787, which changed state.
Bug 80787 Summary: gcc -Wmaybe-uninitialized false negative when compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80787
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80787
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
--- Comment #83 from Manuel López-Ibáñez ---
*** Bug 80787 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543
--- Comment #6 from Martin Sebor ---
(In reply to Martin Sebor from comment #5)
The cutoff between (a) and (b) also depends on whether or not a function is
being optimized for speed or for size, so at -Os, the x86_64 target also uses
(b) for all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710
Ben Elliston changed:
What|Removed |Added
CC||bje at gcc dot gnu.org
--- Comment #13 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46921
Dave Pagan changed:
What|Removed |Added
Summary|Dropped side effect with|Lost side effect when
|co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064
--- Comment #6 from Manuel López-Ibáñez ---
If I remember correctly, the problem here is constants and other
non-expression nodes don't have a location, so diagnostics use
input_location, which points to the end of the initializer. Something like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
--- Comment #4 from Jonathan Wakely ---
Regressed with r255066
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
--- Comment #4 from Martin Liška ---
*** Bug 84505 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770
--- Comment #4 from Maxim Kuvyrkov ---
Update from Charles:
===
When I tried to bootstrap the compiler with the patch, it failed because of
issues with -fPIC. I'm not sure it's worth pursuing the amount of work required
to resolve the -fPIC issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65041
Jeffrey A. Law changed:
What|Removed |Added
Status|RESOLVED|REOPENED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
--- Comment #3 from Jakub Jelinek ---
Created attachment 43485
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43485&action=edit
gcc8-pr84503.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229
--- Comment #5 from Jan Hubicka ---
Author: hubicka
Date: Wed Feb 21 19:05:30 2018
New Revision: 257877
URL: https://gcc.gnu.org/viewcvs?rev=257877&root=gcc&view=rev
Log:
PR c/84229
* ipa-cp.c (determine_versionability): Do not v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913
--- Comment #4 from Dominique d'Humieres ---
AFAICT the tests in comment 0 and 1 compile at revision r257865, but compiling
the test z4.f90 still gives an ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77285
Jonathan Wakely changed:
What|Removed |Added
CC||zhykzhykzhyk at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543
--- Comment #5 from Martin Sebor ---
(In reply to Ramana Radhakrishnan from comment #4)
Setting -march=armv7-a doesn't make a difference.
The root cause is that initializers of locally defined aggregates such as
struct { char a[N]; } S s = {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118
Jeffrey A. Law changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83980
--- Comment #6 from Dominique d'Humieres ---
> The fix for pr83823 seems to have fixed the problems reported in
> comment #0 and comment #2 for 8.0 trunk. The issues persist up to
> 7.2 (haven't checked 7.3).
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505
--- Comment #1 from Jakub Jelinek ---
Might very well be a dup of PR84503, let me finish up the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770
Maxim Kuvyrkov changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505
Bug ID: 84505
Summary: [8 Regression] store-merging miscompilation on i586 in
xemacs package starting with r254391
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70186
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
See A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480
Martin Sebor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
--- Comment #2 from Jakub Jelinek ---
The bug is in the way we handle overlapping stores. The problem is that all we
do if there is overlap is:
if (IN_RANGE (info->bitpos, merged_store->start,
merged_store->start + merg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431
--- Comment #4 from Jonathan Wakely ---
Because the C front end gets the location info right in recent versions of GCC
it also marks the bad initializer with carets:
bug.c:4:3: warning: initializer-string for array of chars is too long
"Chris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
Jonathan Wakely changed:
What|Removed |Added
Keywords||wrong-code
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
--- Comment #1 from Jakub Jelinek ---
Can be reproduced also on x86_64-linux with -O3 -fno-tree-vectorize
-fno-ivopts.
For the latter, I wonder what's the point in using TARGET_MEM_REF in:
MEM[(long int *)p_28] = 0;
MEM[(long int *)p_28 + 8B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84491
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492
--- Comment #2 from David Malcolm ---
This assertion is failing, where rhs is a STMT_EXPR.
8000 /* There are only a few kinds of expressions that may have a type
8001 dependent on overload resolution. */
8002 gcc_assert (TREE_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495
--- Comment #4 from Steve Kargl ---
On Wed, Feb 21, 2018 at 10:44:07AM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495
>
> Thomas Koenig changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504
Bug ID: 84504
Summary: procedure pointer variables cannot be initialized with
functions returning pointers
Product: gcc
Version: 6.4.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #16 from Andreas Schwab ---
Created attachment 43484
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43484&action=edit
libgo support for riscv64
With this patch I can sucessfully build libgo for riscv64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
--- Comment #1 from patrick.schlangen at bmw dot de ---
Note: This problem does not happen with gcc 7.2.1.
The problem can also be reproduced with -O3 when the empty struct object passed
to the function is actually used in the function. (So it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503
Bug ID: 84503
Summary: [7/8 Regression] store-merging miscompilation on
powerpc64 with -O3 since r241789
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502
Bug ID: 84502
Summary: Argument corruption when passing empty templated
struct
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83126
--- Comment #9 from Tom de Vries ---
(In reply to Tom de Vries from comment #8)
> Created attachment 43476 [details]
> Tentative patch
>
> (In reply to rguent...@suse.de from comment #3)
>
> > This is the usual "you should not repeat analysis d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
--- Comment #56 from Martin Sebor ---
I'd say any warning option with more than just a handful of pr's against it
would benefit from having a meta-bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #15 from Ian Lance Taylor ---
> The first hunk is useless since this is a compile test.
Understood, but I would prefer to test the exact options that the build is
going to use.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264
Peter Bergner changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|kelvin at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #14 from Andreas Schwab ---
See gcc/config/riscv/linux.h for why it does that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #13 from Andreas Schwab ---
The first hunk is useless since this is a compile test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
Andrew Pinski changed:
What|Removed |Added
Keywords|patch |
--- Comment #12 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84434
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84447
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484
--- Comment #12 from Ian Lance Taylor ---
How about this patch?
diff --git a/libgo/configure b/libgo/configure
index aba4dc39..dcfc524b 100755
--- a/libgo/configure
+++ b/libgo/configure
@@ -14209,7 +14209,7 @@ if test "${libgo_cv_lib_pthread+se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82096
sudi at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84454
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84454
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 154 matches
Mail list logo
